Mobile App Development: Native vs Hybrid
Your company needs a mobile app and you want to save money (of course). You want the app live last week, and you’d really like to avoid hiring Android and iOS devs on top of your existing web team.
In light of these considerations, going the hybrid route looks like a pretty good option. Hybrid mobile apps promise to be cheaper and faster to develop, and they’re built with tried and true technologies like Javascript, HTML, and CSS. The hybrid sales pitch can be summarized as “one codebase for multiple platforms”. Hybrid platforms include React Native, PhoneGap, Ionic, Titanium, and others.
Ok, so I should build a hybrid app, right?
Maybe. There is a lot to consider. Slow down.
Why? What’s the problem? Why would anyone go with a native process when that takes more time and money?
As it turns out, for many mobile apps there are overwhelmingly good reasons to avoid the hybrid route. Hybrid apps can lead to poor performance, choppy user experience, and long-term developer headaches. Stakeholders usually find out out about these problems after the project is well underway. In other words, there is often a hidden (unadvertised) cost to hybrid mobile app development. You should study the landscape and your project needs very carefully before making a final decision on whether to go hybrid or native.
On the plus side, frameworks such as React Native have been steadily improving. Popular apps such as Instagram, Airbnb, and Skype are built on the technology. Hybrid prototypes can be very quick to stand up, which is great for user testing. For simple apps (without a lot of native functions), going hybrid can save time and money. Definitely, going the hybrid route can lead to successful outcomes.
So what are the problems with hybrid mobile technologies. Here are some complaints::
Hybrid Issue #1: Performance
Mobile users expect instant gratification, and that means apps that work without glitches and hiccups. Hybrid apps often offer subpar performance on two measures — they’re inherently slower, and they’re vulnerable to disruptions in connectivity.
For very simple apps — no long scrolling lists, complex animations, or graphics – the difference in speed might not be noticeable. But every hybrid app takes a hit from network calls. Hybrid apps run in the browser and work the same way traditional web apps do — they make browser-based network calls (using ajax), which implicitly assume connectivity. Mobile devices are often used in areas of imperfect connectivity, and connectivity glitches lead to app glitches. Poor connectivity may be the underlying problem, but most users will never know that. They’ll just assume your app is broken.
Hybrid Issue #2: Compatibility
The hybrid approach attempts to serve both iOS and Android with a single codebase and design. Straddling two systems is supposed to make development simpler — but what you’re actually doing is introducing a third system. In many cases the outcome is awkwardly in between.
Let’s start with design. As anyone who’s worked with both systems knows, Android components, patterns, and paradigms are vastly different from iOS components, patterns, and paradigms. Hybrid frameworks attempt to imitate both, but the result can be a confusing “least common denominator” experience. While you can use stylesheets to make a web button look like a native button, it doesn’t react the same way. When you try to fake it, you create something that just feels wrong.
The costs are even greater when it comes to development. Sure, it’s faster to work with one codebase instead of two — until you start trying to reconcile that codebase with numerous devices, OS versions, and platforms. Device and OS compatibility issues tend to pile up throughout the hybrid development process, and many go unnoticed until they’re flagged by late-stage QA testers. At that point, they can drag out a project timeline by months.
Hybrid Issue #3: Complexity
All but the simplest apps need at least a few native components. Even a small deviation from the platform standard is usually a no-go for things like navigation and settings controls — the misalignment is just too jarring for the user — and there’s often no way around using native components for features like push notifications, device storage, and camera, microphone, accelerometer, and address book access. Integration with these mobile device features is the thing that really differentiates mobile apps from web apps.
Eventually, you’ll realize that you just can’t avoid using native code to support one or two native features. Then you’ll add one or two more, and then a third, until you end up with three codebases — iOS, Android, and web — in a single repo, tied together with a Javascript bridge. This means that your team will need the chops to support iOS and Android; something you hoped to avoid. If there are native screens, you’ll need to write your own state management solution for the web views.
Hybrid Issue #4: Upgrades
iOS and Android are regularly adding features and changing APIs, which means that hybrid framework providers are essentially building a platform on shifting terrain. And while native developers can start building new features as soon as a new software development kit (SDK) is released, hybrid developers have to wait for their hybrid framework provider to integrate the new SDK, so there’s a substantial wait time — up to a year in extreme cases — before hybrid developers can take advantage of new features.
It’s not always a quiet wait, either; OS upgrades can and do break hybrid apps. In one case, we saw a client’s Cordova-based hybrid iOS break when Apple upgraded the WebView API in order to make it more secure. The problem was fixable, but not easily — it took a few days of frantic scrambling by a senior iOS dev to hack the Cordova source code. For that particular upgrade issue, a Cordova patch was released two weeks later – that’s a long time to wait for your app to start working again.
Hybrid Issue #5: Debugging
Let’s say a business decides it’s worth investing in native code for a small feature such as a settings screen. This seems innocuous enough until the settings screen fails to load. To investigate the problem, a developer connects Xcode or Android studio to the native portion of the app, connects Chrome developer tools to the web view, and monitors both debuggers.
Two debuggers is cumbersome, but not terrible. However, when loading the settings screen, the app is likely to destroy the resource-intensive web view on occasion in order to save memory. When this happens, the chrome debugger will drop, forcing the developer to reattach it and possibly start the process over from the beginning.
For larger hybrid projects, it can be hard to figure out whether the iOS, Android, or web code is the cause of a problem. The upshot is that the debugging process can be slower on hybrid.
Hybrid Advantages
Ok, so there are some downsides to going hybrid. On the plus side, there are many winning apps that have been built using hybrid technology. React Native in particular has stood out as a technology that is particularly successful from a performance/responsiveness perspective as compared to older hybrid technologies. For simple apps and prototypes, going hybrid might be a quick way to get off the ground. Another great advantage of hybrid apps is in-app updates – you can deploy a production update to the code without having to deploy through iTunes Connect and the Play Store.
Another advantage of going hybrid is the ability to refresh code changes without recompiling. This can actually speed up development cycles. For the hybrid codebase itself (aside from the plugins that you will probably have to write) you can staff the project with web developers. These can be easier to come by than experienced iOS and Android devs.
Wrapping up:
If you are building a mobile app, you will need to consider a myriad of factors when deciding between hybrid and native. Risks on the hybrid side include glitchy performance, UI/UX inconsistencies, compatibility issues, security holes, and delayed feature updates. In many cases it might actually be cheaper in the long run to go 100% native. On the other hand, for straightforward applications the native route might be overkill for your needs. Unfortunately, the choice is not easy to reverse without a full rewrite. Take the time to analyze which choice is right for you.
