Sometimes it feels like we’ve been arguing over which is better, a native app or a hybrid app, since the beginning of time, with dire consequences predicted for anyone who chose incorrectly.
The debate became overheated when, in 2012, Mark Zuckerberg famously dissed HTML5 at the Disrupt conference:
When I’m introspective about the last few years, I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native. – Mark Zuckerberg
But a lot has changed since 2012. First of all, HTML5 support is now so ubiquitous that even the term itself has begun to sound like an anachronism. Nobody really touts their HTML5 support anymore — it’s simply assumed.
In terms of mobile app development, the landscape has changed dramatically too.
The native development landscape changed significantly with introduction of Swift. This eliminated one of the major “pain points” of doing native development, at least according to some — Objective C.
Cordova (aka PhoneGap) has improved for hybrid development, as has the WebViews that it relies upon for both iOS and Android. Projects like Crosswalk have even smoothed out the fragmentation issue that famously plagued Android. In addition, a large number of cloud-based tools, including our very own Telerik Platform, have even eliminated the complications of the setup and build processes for hybrid.
However, there’s much more today than simply traditional native or hybrid. For instance, solutions like RubyMotion or Xamarin, that compile to native from Ruby or C# respectively, have gained popularity.
The most well known of these solutions would be React Native and Telerik’s own NativeScript, but there are a growing number of alternatives, both pre-existing (Appcelerator Titanium) and new (Tabris.js and Fuse).
Let’s start with a quick definition of what each type is before moving on to which of these options make sense for your next project.
In the context of mobile app development, the term “native” refers to building applications using each platform’s native language and development tools. For iOS this means writing your code in Objective–C or Swift, and doing your application development in Xcode. For Android this means writing your code in Java, and doing your application development in Android Studio or Eclipse.
Native apps are typically associated with the very best performance, as you’re coding directly against the native platform APIs. But native apps are also associated with higher development costs, as developers must learn the how to build for each platform individually, with very little skill reuse across platforms (aka mastering Swift won’t really help you build an Android app).
<button> element in NativeScript is actually implemented as
UIButton on iOS and an
android.widget.Button on Android, but the native implementation details are abstracted away from the developer.
By its nature, hybrid has the benefit of targeting multiple platforms with, primarily, a single codebase. In fact, using Cordova, hybrid apps have the benefit of targeting the widest array of mobile platforms compared to anything outside of simply a mobile web site. Cordova currently targets eight platforms including Windows, Blackberry, FirefoxOS and FireOS. If those platforms matter to you, in addition to Android and iOS, then hybrid offers the easiest way to get there.
Partly because of this broad array of platform targets, hybrid also arguably offers the fastest route to market for a mobile app. This is particularly true if your team has strong web development skills but it’s supported by a number of mature frameworks such as Kendo UI Mobile (offered by Telerik), Ionic and jQuery Mobile to name just a few.
Additionally, hybrid offers the most opportunities for code reuse from your existing web assets.
Obviously, hybrid has suffered from perception of its performance, a view that wasn’t helped when hardware vendors chose to leave important performance enhancements out of the WebView available to hybrid apps (though, this situation has improved dramatically in recent releases). However, the performance implications are often overstated and are unlikely to impact a large number of applications — particularly things like internal business applications, where the fast iteration and skill reuse may offer the most benefit.
Many developers might be saying to themselves, “What do you mean? Performance is always critical!” Well, that is true — to a degree. Think about it this way, the engine in a Formula One car theoretically performs better than the engine in a consumer car (at least from a speed perspective anyway), but this does not mean that consumer cars should start having Formula One engines. The performance of an application is as much about expectations and perceptions as it is about actual performance — and those expectations are often heavily dependent on the nature of the application you are creating.
We may be stating the obvious, but it’s worth noting that native offers the best possible means of gaining unfettered access to the all the features and capabilities of each platform. If you are building an application that needs to take full advantage of all of the capabilities of a particular platform (push the limits, you might say) then native is the way to go. This is enhanced by the tooling as that tooling is geared towards the specific requirements and needs of developing for that mobile OS (the painfully slow Google-provided Android emulator notwithstanding).
Of course, this is complicated by the need to maintain multiple codebases for a single app that targets multiple platforms. You may only really care about two platforms right now, which might make it less daunting, but it will obviously significantly impact the time and complexity of completing an app.
For instance, in the video below I use NativeScript’s
UIButton and an
tns install command.
background-color: redCSS rule, parses out the necessary values, and then sets a
backgroundColorproperty to an instance of
The big advantage cross-compiled native apps can offer is the ability for developers to code in a language they’re comfortable with. For instance, if you’ve invested a lot of time learning C# in and out, then the ability to reuse those skills and build Xamarin-based native apps has a lot of appeal. Ditto building RubyMotion-based apps with Ruby, and ditto building RoboVM-based apps with Java.
In addition to this code reuse, cross-compiled apps can also offer near-native performance, as the code that runs at runtime is true bytecode.
Developers have more choices than ever about how to build their mobile apps. As we discussed, each has its merits and its complications. To summarize:
The trick is to understand the differences between these approaches, and choose the option where you can take the most advantage of the merits while being least affected by the complications. This will change depending on the type of application you are building, and the skillsets you and your team have. So rather than debating which option is better than the other, let’s embrace the opportunity that the array of options presents.
Header image courtesy of Chris Dlugosz