Blog May 25, 2018
Mobile App Architecture: Native, Hybrid, and Common Misconceptions
- Topics
- Mobile Innovation
Ultimately, choosing between native and hybrid hinges on the project's requirements. With that said, let's evaluate a few misconceptions. The goal here is not to campaign for one approach over the other, but to take a closer look at this debate's most frequent arguments.
What does "hybrid" really mean?
Different hybrid methodologies exist in various stages of maturity, each with pros and cons. Here are some of the more popular hybrid SDKs:
First, let's go through a high-level review of what hybrid is all about.
Apple and Google encourage developers to write apps targeted to their specific platform. When an enterprise wants to create a mobile app, they typically create two codebases: one for iOS, and another for Android. These two codebases are incompatible, so most app dev teams are divided into Android and iOS developers. iOS developers work in their codebase, Swift or Objective-C, and Android developers work in their codebase, Kotlin or Java. (Friendly rivalry often ensues.)
Typically, these teams build similar features sourced from the same business requirements. They're essentially doing the same work, except writing in their language, their IDE, and their codebase, to target either iOS or Android. This arrangement results in the highest-quality mobile applications and complies with Apple and Google's recommendations.
Hoping to mitigate duplicate work, some firms elect to use a hybrid approach instead. Hybrid SDKs require developers to create only one codebase, from which native iOS and Android apps are generated. Developers can work together on a single project-in a single language-and compile whatever output they want: iOS, Android, or even Windows Phone. (For game developers out there, this is how Unity works. Unity code gets compiled into platform-specific code-iOS, Android, Windows, Linux, OS X, PS4, Xbox, and so forth-instead of coding for these platforms directly.)
Some frameworks, like PhoneGap, render a mobile webpage inside a simple native app wrapper, letting you build views in HTML while gaining access to the phone's hardware features. Other methodologies, like Ionic, also leverage a WebView to render a UI, but require the views to be hosted locally, using modern web technologies like Angular4 and Typescript. Solutions like Xamarin and Flutter build native views instead of WebViews to create near-native experiences, which we'll discuss below.
On the surface, hybrid sounds like a brilliant idea-and it can be, in the right circumstances. But using a hybrid platform can have consequences, often in the form of an inflexible, substandard user experience.
With both native and hybrid landscapes ever-evolving, it can be hard to keep up. With each new hybrid methodology comes renewed debate about its viability as a native alternative. Below is an in-depth review of the more common claims.
The Common Arguments
Hybrid apps are slow to load.
Some people confuse WebViews as hybrid apps. Tossing a clunky mobile site into PhoneGap will drastically understate hybrid's capabilities. Modern hybrid frameworks require its views to live on the client rather than a server. Lightweight JSON requests populate view content, not the view itself. Native apps work this same way-as do PWAs. Most hybrid frameworks today were designed to compete with their native counterparts and ensure their views load immediately, so this problem of slow-loading views has been largely solved.
This concern lingers from hybrid's first impression it made in 2012. When PhoneGap burst on the scene, it was heralded as a clever solution for web developers to extend their mobile site with native functionality-without requiring native expertise. The results were subpar, with many PhoneGap apps feeling slow, buggy, and disingenuous. Reviews like "this is just a dumb website wrapped in an app" were commonplace, and native apps looked pristine by comparison. PhoneGap was the only hybrid option in 2012, but alternatives like Ionic, Sencha Touch, Microsoft's Xamarin, and Facebook's React Native have since matured to offer vastly improved user experiences.
Apple and Google don't like hybrid.
It depends on the platform.
Google is hybrid-friendly, with robust support for their Chromium WebView. Google has even pioneered their own hybrid framework called Flutter, which, though still in beta, looks promising.
Apple is another story. For years, they've failed to address challenges surrounding WebViews, which has flummoxed the browser-based hybrid frameworks. More concerning is their December 2017 update to the App Store Review Guidelines, touted as part of a spam-reduction effort. This update included broad verbiage that effectively banned all template-generated apps-thus hybrid. They later narrowed these terms to hone in on commercial providers using templated systems for their clients, rather than the hybrid SDKs themselves.
So, while it appears Apple still tolerates hybrid SDKs for now, their nonchalance towards anything non-native sent tremors through the app dev community and even caused some hybrid-heavy firms to close down.
In short, Apple and Google fully encourage the native approach and are, at best, only lukewarm on hybrid. All their documentation, best practices, new features, testing libraries, etc. are tailored for native development. Native remains the de facto standard for creating mobile apps, and architects should keep this in mind if planning years ahead.
Hybrid doesn't work offline.
Sure it can, unless you're building a dead-simple PhoneGap app (and even then, you have options with HTML5). Hybrid frameworks can read/write from on-device SQL databases and utilize disk caching to handle offline scenarios gracefully.
Development Time is Shorter with Hybrid.
It certainly requires less code, since you only need one codebase instead of two. And many hybrid frameworks are less verbose than, say, Java in Android. But be warned-most projects still require platform-specific fine-tuning before they can reach production, so the labor savings could be negligible, depending on your complexity. You'll still need skilled iOS and Android developers to understand their respective IDEs, build processes, testing, etc. Hybrid or not, enterprises should have an intimate familiarity with whatever platform they're targeting.
Perhaps some small firms can release without platform-specific expertise, but for apps representing a business or commercial enterprise, it's an open invitation for bad reviews.
App Updates Are Easier with Hybrid.
This has a two-part answer, since we need clarify what's meant by an "app update."
If you're referring to updating your app in the iTunes or Play stores, then yes, hybrid can have an edge. Some hybrid frameworks allow you to update your HTML/JS/CSS content (the core of your app) without requiring an app store release, thus reducing testing effort and mitigating backwards-compatibility concerns. But it's not perfect. Some updates still require full app store releases-particularly if your new version impacts permissions, adds new plugins, targets new SDKs, etc.
But when it comes to keeping up with Apple and Google's latest features, hybrid lags behind. What happens when the next iPhone X comes out? Or when Android changes their permissions model again?
With hybrid, you'll either need to mangle your builds with native code or wait until your hybrid platform incorporates these features. Both are bad options, which require either a lot of waiting or a lot of customization.
Imagine an executive who gets all excited to engage customers with smartwatches. Then, some poor soul has to explain that, due to their simplified hybrid architecture, they can't deliver that feature-even though their competitors can.
Facebook bet big on Hybrid/HTML5, and it failed.
Here's Mark Zuckerberg's oft-cited quote from 2012:
"The biggest mistake we've made as a company was betting on HTML5 over native."
Facebook famously rolled back their attempt to engage users with HTML5, then fully embraced native and haven't looked back. To see a tech giant like Facebook reverse course was a major milestone in the native/hybrid debate, but with each passing year, this quote has lost relevance as hybrid solutions improve. Facebook itself now provides React Native, which is, in effect, a hybrid framework.
And remember-Facebook is a technology leader with aspirations to evangelize all of humanity, so their customer-facing interfaces must be state of the art. Not all apps have such lofty requirements.
Native UIs look better than hybrid UIs.
The short answer: yes, this is true, and it's often the final straw that make enterprises go native.
This question should loom large for mobile architects, and it depends on your UI requirements. Are you rendering complex graphics, with lots of shadows and animation? Native will probably look best. Are you rendering an employee directory with text and avatars? The user experience between the two, if executed properly, can be indiscernible, making hybrid a viable option. If you're targeting older phones-perhaps for international usage-bear in mind that hybrid performance can suffer on less powerful devices.
Some argue that native-generated UIs (e.g., Xamarin's Forms) result in a user experience that parallels any UI created with ordinary native code. While generated UIs look just like native, they can be difficult to modify. Developers shoe-horning their existing native apps into a UI-generating SDK like Xamarin will find some views difficult to render, leading to unwanted design changes. Most hybrid SDKs work best if you work within their UI templates/guidelines, and the further you deviate from those, the more likely you are to encounter challenges.
When someone says that the native UIs look better than hybrid UIs, they may be right, but the follow up question is harder to answer: how much better will it look, given our UI needs?
As phones improve, the hybrid frameworks only get better.
True, but native is improving too. Swift and Kotlin are now fully supported; support libraries continue to expand; XCode and Android Studio are sleeker than ever.
Hybrid frameworks strive to achieve native-like experiences, since native is the standard that hybrid hopes to match. As long as native keeps improving, hybrid will always trail behind. It takes time for hybrid frameworks to build native plugins, and for those plugins to reach production-level maturity.
My native developers don't like hybrid.
Native developers have spent a lot of time and energy specializing in their native, platform-specific skillset. Keeping up with Apple and Google's ever-evolving trends is an onerous task. Shifting to hybrid means setting their specialty aside to learn a more generic, debatably inferior architecture. Many see it as a step-backwards professionally, into a less lucrative field. Contrarily, project managers are sometimes quick to embrace hybrid for its low cost and quick turnaround, dismissive of native's long-term advantages. Obviously, there are tons of open-minded professionals able to provide objective guidance regardless of their own skillset, but it can be helpful to understand what forces may influence their stance.
My hybrid developers don't like native.
Unless they're already skilled native developers, it's unrealistic to expect hybrid devs to deliver enterprise-quality native code overnight. Hybrid frameworks mask some of native's challenges, like understanding the nuance of the view lifecycle, managing configuration changes, and ensuring proper testability. Though there is some overlap, native and hybrid are two vastly different specialties.
I don't want to compromise my customer's experience.
Then go native. It's the premier experience in the mobile app space, performs the best, and supports Apple and Google's latest features immediately. The key is to find the right personnel who have comprehensive experience delivering top-notch native solutions.
Conclusion
Hybrid has a place in the mobile app space and should neither be shunned nor adopted without first assessing its strengths, weaknesses, and compatibility with your project. Hybrid can be a wonderful fit for some apps-especially ones with flexible requirements and low-stakes ambition. Hybrid can also fail, particularly if you're hoping for a state-of-the-art design or are unwilling to make UI concessions in exchange for code-simplicity.
Some firms proudly boast that they "only do native," while others claim that virtually any app can be built in the right hybrid SDK. Both extremes are ill-advised. Good mobile architects will use the right tool for the job.
