Image via larnr.com

The Curious Case of Native Apps

When a Great Solution is the Wrong Solution

Imagine for a moment that you’re building a mobile app for a major enterprise client.

It needs to do exceptionally well once it’s released — they’re putting a lot of money and resources into developing the app after all — so you’ve got a lot to consider:

  • What function(s) will the app perform and what user needs is it answering?
  • What will it look like and how will the use context inform the design?
  • How will it be built? Will you be making an existing website responsive or building a completely native mobile app?

In terms of the app’s functionality, user research will help inform what you make and what gets cut from development. And in terms of appearance, pre-existing brand guidelines will help inform the look and feel of the app, even as you seek to evolve it and make it work for a mobile presentation. But how do you decide what platform to use?

*****

You may hear (regularly) from clients that think they need a native app. They’ve heard that it will look best, it will perform best, and it will have device interoperability that a web app will never have. And from a pure functionality standpoint, they’re probably right.

But your clients — and therefore you — should be concerned about more than just getting the highest possible app quality.

Keeping costs down (something your clients probably are already focused on) is important, and how much time, how many resources, and what kind of ongoing support will be required matter in a cost equation.

Native apps may require more time (if you’re building for two platforms plus a responsive site, for example), more money, and more specialized skills from developers. And updates down the line will have similar resource drains.

Jerry Low, one of our Senior Developers, agrees. “As a developer or a company looking to support and maintain an app, native apps complicate matters, for sure.”

Even if your client signs-off on added expenses, there are still lots of reasons a native app may not the right choice for their needs.

At Myplanet, we work with enterprise organizations. Most of our projects reach tens or even hundreds of thousands of people, which means they are big, complicated, and have massive scope (by and large). Because of that, we constantly advocate to our clients the importance of figuring out what the right solution is, not just what would be cool to build.

Finding out what users actually need and will get value from is a very different proposition than making something for the sake of it.

If the app you’re building requires a solution that connects to the hardware functions of the device (auto-pay accounts, for example), you will absolutely need to look at a native app solution.

But if the solution that makes the most sense is a broadly accessible (i.e. not requiring any downloads or specific device types) web experience that can be used by anyone, anywhere, then a native app might be the wrong choice.

Erick Cardenas Mendez, another developer here at Myplanet, notes that in most cases, you’ll still need a mobile-ready site, even if you do choose to go with a native app. “You’ll have to have a responsive site and a native app, which makes parity of features across interfaces more difficult and complicated.”

Building a native app means you must stay within the constraints of the Android and iOS platforms and meet the standards laid out for all apps seeking to be included in their stores. Keeping the apps in line with one another and with your responsive web experience can be complicated.

In essence, things can get exponentially more challenging — and therefore expensive — very, very quickly.

And the potential issues don’t stop there. Ryan Seaton, also a Myplanet developer, agrees with Jerry and Erick that native apps offer the highest potential for quality in an app. “In terms of the experience, full native is usually the best.” But he also notes that there are other factors to consider.

Take this example he offers: “Let’s say you’re making a native app that a company would deploy to its employees — logging work time and other HR necessities. You need that to stay up to date without thousands of employees falling behind on versions.”

When the app you’re building is an employee tool, like an HR time-tracking app employees use daily to accurately log their hours, keeping it updated isn’t just a nice thing, it’s a necessity.

But not everyone on staff can be counted on to update the app the moment a new version comes out. What if you release a crucial update? Employees that aren’t on the latest version may find themselves unable to use the app for the very reason it was intended — to simplify time-tracking and basic HR interactions — resulting in a bureaucratic nightmare that could be costly and would definitely be time consuming.

And version control, as we all know, isn’t just about updates. As Erick noted, parity of features is a major consideration as well.

Keeping a unified experience for all users should be a top priority when developing for mobile. If you’re building a native app, you must adhere to the standards and guidelines laid out for Android and iOS apps in order to pass muster and be included in their respective stores. And those guidelines can be quite different in their execution.

How then, do you create the look, feel, and function of your app as a unified experience for all users, when the standards are different across devices? Mammoth amounts of work and human-hours, that’s how. And even then you’ll just be getting close. You’ll never truly have a singular experience to offer.

Native apps provide better performance, a more robust experience and a greater assortment of integration opportunities, but for enterprise scenarios in particular, they may not offer the best solution for the needs at hand.

Ryan suggests some of the newly emerging hybrid platforms, like IBM’s MobileFirst™, to help bridge the distance between the two. “Hybrid frameworks, like IBM’s mobile first and other pure HTML wrapper-type hybrid applications, now allow you to start to push updates automatically, instead of having them managed by the individual platform’s app stores.”

You’ll also be able to leverage pre-existing expertise. Native app development requires a very specialized set of skills and when you’re building an iOS or Android hybrid app, you still need to know about the development platforms of each of those operating systems.

But making hybrid apps means you get to build everything with JS/HTML/CSS, rather than the native language for iOS (Objective-C or Swift) or Android (Java) and the native widgets in those platforms. It gives you a bit more latitude in the way you do things.

Of course, there will always be trade-offs to choosing one over the other.

On top of the potentially lower-grade performance and limited capabilities, you’ll likely be making a bigger data consumption ask of your users with a web app, which can be minimized to a certain extent by careful dev work, but as Erick notes, it’s not always easy.

“You as a web developer have to think about it from day one. And still, even when you do all that, most likely your web app is going to be more data hungry than a native app”

But as Ryan notes, when we lean towards the hybrid or web option “the assumptions we’re making are that these are not highly interactive apps.” If the solution that’s required is fairly straightforward, the higher performance of a native app may not matter as much as the ease of maintaining the app over the long haul.

Choosing to go with native, hybrid, or web app development requires a careful think-through of all the factors at play.

Building natively may seem like the obvious choice: of course better performance and more capabilities will make a better app! But while those factors can be important to an app’s success, they may not be as important as easy maintenance or a simple way to access a basic function or two for your client’s users.

Especially in the case of enterprise apps and employee tools, building something that is easy to adopt and maintain for users — and that keeps costs and resource management considerations top of mind — may mean that the choosing to build natively is actually the wrong choice.

*****

Written by Leigh Bryant

Thoughts? Share ’em below. Liked the article? Fave it or share it with a friend. Interested in building employee tools or apps for enterprise clients? Join our team! Designers, developers and account managers wanted.