When building a software product for mobile, there comes a time early on when you must decide between building a native application or a responsive web app. When making such a decision, it’s very important to understand the implications of going one way or the other. A native app is typically more expensive to build, but the extended capabilities and high speed execution often makes it necessary or at least advantageous for certain products. Today we’ll explore a few benefits of building native apps to help make this decision easier for anyone setting out to build a new mobile product.
Why go native?
Direct Hardware Access
One huge advantages of natively built applications is they have direct access to many hardware features that web apps simply do not. While HTML5 has brought easy access to the camera and microphone with the <input> tag, these elements simply output a file and don’t give you access to the media in real-time. If you want to build fun camera filters or do any kind of signal processing, you’re much better off in the native realm.
While web apps have some access to media capturing hardware, they don’t have any access to some of the other sensors on the device. For example, native apps on iOS have full access to all HealthKit data (should you allow them) collected by the motion co-processor and other activity trackers, which are always working whether your app is running or not. Native apps can also use geofences and other location-based triggers to provide context-aware behavior and offline notifications, which can draw your user’s attention back to your app at opportunistic moments.
Blazing Fast Execution
Native apps can work more efficiently because they run directly on the hardware, meaning there’s very little overhead to performing computation. This can make a huge difference when doing lots of graphical work or anything that is computationally expensive. While hardware-targeting makes applications less portable, it allows them to really take advantage of the processors they run on, giving you the high resolution and fluid graphics you see in native games and media apps today. Apple’s graphics library Metal is a great example of this, being designed specifically for the GPUs in Apple’s products to achieve maximum performance.
There’s usually a clear difference in appearance and quality between native and web-based apps, as web apps lack the responsiveness and familiar UI elements of a native app. While web apps can certainly accomplish a lot, the extra layer of separation brought by running in a browser or web view rather than natively means the app can’t respond as quickly to things like touch events. This accounts for the slight lag you experience when interacting with the UI of web-based mobile apps, which amounts to a less-than-stellar user experience. Also, users may not pick up on custom UI controls from the web when they are used to a consistent experience from native apps on their platform, which can lead to usability problems. If the user feels like they’re swimming upstream to use your app, they probably won’t keep at it for long.
One clear limitation of web apps is the necessity to download them over the internet each time they are loaded. Since native apps are installed once and can store tons information on the device, they can provide all kinds of functionality without an internet connection. iOS apps can even preemptively load data before the user opens the app through silent push notifications that “wake up” the app to retrieve new data.
Even with an internet connection, the first few seconds of a web app experience often consist of spinners and sluggish stylesheets causing elements on the page to jump around as it loads. This requires a measure of patience from your user, which might be too much to ask from some users especially after navigating through a few pages. With user attention spans getting shorter and shorter, you need to capitalize on every second they spend in your app, creating value for them and not putting them on hold to download and render bloated web pages.
"We're getting really close to ready" – the false dream of hybrid apps pic.twitter.com/xyvXT3qNao
— Bill Morein (@wmorein) May 5, 2015
In short, while native certainly isn’t the right choice for everyone, there are a quite a few cases where it’s necessary or at least beneficial. It’s important to consider these implications not only for the current state of your product but also for it’s future, as it would be unfortunate to commit to a web-based platform only to have to rebuild later when you need native-only features. While historically writing native apps have meant coding for one platform at a time, there have been big developments in native, cross-platform solutions such as Xamarin, now backed by Microsoft, and React Native, brought to you by Facebook. These solutions, while still growing, hope to deliver the fully native experience without limiting you to a single platform which can greatly reduce the cost of certain projects.