07/18/2016 | Digital Experience and Mobile
When you decide it’s time to invest in a mobile app, your next big decision is to choose how it will be developed. Should you choose Native development or should you go Hybrid? Like so many technology solutions questions, the answer will depend on your goals and resources. Each path can lead to success, and you can increase the odds of a great outcome by understanding the opportunities and costs associated with each choice.
Native Apps
What Is It?
Native development means producing apps using officially supported languages and tools for the specific platform. The two major platforms, iOS from Apple and Android from Google, each require specific programming languages that differ from each other. Apple allows Objective-C for iOS and is encouraging a shift to Swift, its new proprietary language. The official language for Android development is Java.
Both iOS and Android platforms were designed to give developers full, direct control over the capabilities of the device, so the only limitations are the imagination and skills of the coder. This allows a peak level of visual fidelity, snappy responsiveness to inputs, and access to device components that other approaches cannot match.
However, this very specificity is also the downside of Native development. Since both the hardware and firmware of the device ecosystems differ at a fundamental level, the frameworks necessary to unlock their potential differ as well. This means that iOS and Android apps can be similar from a broad architectural perspective, but the actual code will be unique for each platform. Releasing the same app concept on both platforms essentially means coding it twice, effectively doubling costs for a simultaneous initial release as well as all subsequent maintenance and enhancement.
Where Native might be most appropriate:
- When the app’s functionality requires extensive control over the device, accessing things like the camera, accelerometer, GPS tracking, NFC, Bluetooth, etc.
- With apps where even brief response lag for user input would be problematic, like games
- Where the intended monetization path requires deep integration with app store functionality (in-app purchases, etc.)
Example Native apps:
Facebook (went Hybrid then back to Native), Starbucks, Netflix, Spotify
Hybrid Apps
What Is It?
As mentioned above, the main downside to Native development is the necessity of coding in two separate languages. Hybrid tools were developed, in part, to address this. They do so by sandwiching two layers of technology together, hence the name Hybrid. One layer is the user interface, which is coded using web technologies like HTML5, CSS, and JavaScript. The other layer consists of a container for the web code known as a WebView, plus a set of JavaScript hooks that allow the web code to control device components. This layer is executed in Native code, and Hybrid platforms (such as Ionic and PhoneGap) purport to offer a full, uniform solution so that individual developers can stay out of the Native code entirely. This way, a single codebase can power apps for both Android and iOS.
One of the main benefits of a Hybrid approach is speed to market. The tools get you up and running in very little time. If you’re doing a basic app without needing all the latest APIs and device hardware to tap into, it can be great for getting something out quickly
Furthermore, web development technologies are well-known and long-established, and the coding skills required are considered less specialized and less rare than Native mobile developers. If Hybrid app tools can do the heavy lifting and you can still get the benefit of leveraging advanced device capabilities, it could be a big win in cost and efficiency as well as speed to market. Indeed, some excellent and successful apps have been created in this way. At their best, Hybrid apps are nearly indistinguishable from Native.
However, the best case scenario is not the most common one. The reality is that a lot of what determines success for an app depends on what you need the app to do. As much as the Hybrid platform providers strive to remove the stress of platform interoperability, there are still differences in how the WebViews for each platform render HTML, and there are quirks to how they achieve access to the device hardware. It’s not quite as one-size-fits-all as promised, and Hybrid mobile app developers end up having to cultivate Hybrid-specific expertise that makes them more specialized than first assumed. Additionally, in Hybrid there is always an intermediary step to translate instructions from the front end to the device hardware, which can cause noticeable input lag and other experience blemishes.
Finally, although you might get your app to market faster with a Hybrid approach, each time the hardware or platform software updates, the Hybrid framework will need to be adapted, which creates a permanent lag in availability for the latest features. As a result, Hybrid apps tend to lag behind – both in technology and user experience. This has improved over time but most users can still tell when an app is Hybrid.
Ultimately, the potential benefits of Hybrid can fail to materialize. Projects don’t actually end up being cheaper because they don’t deliver on time. Delays mount as resources are not as plentiful as suspected and hardware integration is found to be more difficult than anticipated. Achieving a truly uniform experience across platforms requires additional overhead when the basic framework experience isn’t adequate.
There have been a few high-profile Hybrid apps that failed to satisfy customers. Both Disney and Facebook released flagship mobile experiences built using a Hybrid approach and both had to change course back to Native at great cost. That is the nightmare scenario for organizations trying to make this choice, and those examples have led cautious organizations to stick to Native.
Where a Hybrid App might be most appropriate:
- When the experiences you want consist of simple interfaces and interactions. Hybrid apps should avoid complex gestures and multi-touch input.
- In organizations with strong web developers
- In contexts where speed to market is paramount, or where budgets are constrained
- With applications requiring frequent content updates. WebView content can be changed without requiring the app to be updated and reinstalled.
Example Hybrid Apps:
Evernote, Basecamp, Instagram
Conclusion
At AIM, we take an approach to mobile app development that emphasizes finding the right solution for the client. To achieve that we take the time to understand the client’s goals, assets, and expectations. We avoid making firm recommendations until we know what the client’s app needs to do, what’s at stake, and what we have to work with.
That said, the mobile app space is competitive. Customers have high expectations for mobile apps that include ease-of-use, responsiveness, and overall quality. User perceptions of the experience create lasting impressions of the company providing the app, and unlike other forms of technology, many mobile app users do not give second chances. In our experience, Native apps are able to deliver the necessary level of quality more consistently and with fewer compromises. However, Hybrid frameworks continue to improve and we don’t count them out. In cases where the Hybrid option is being strongly considered, just make sure to carefully consider the risks and realities before beginning development to avoid surprises and ensure the outcome will meet your long-term goals.
Are you interested in consulting for Digital Experience and Mobile Solutions? Tell us about your challenge to learn more about our flexible engagement model and the approach we would take with your organization, and check out the links below for more information about our capabilities and expertise:
