Hybrid development, or the approach of building native apps using Web technologies, has gone through its fair share of highs and lows. But, despite high-profile abandonments from the likes of Facebook and LinkedIn, hybrid development continues to be used by a substantial number of developers.
For instance, a VisionMobile 2014 study of over 7,000 developers found that “15% of app developers use HTML5 beyond the browser, via hybrid apps or HTML5-to-native tools.” PhoneGap’s about page touts that the library “has been downloaded over 1 million times and is being used by over 400,000 developers.”
But what do those numbers mean for the future of hybrid? Is hybrid as a platform growing or shrinking? Is performance still a limiting factor for hybrid apps? In this article we’ll attempt to answer those questions. We’ll look at where the hybrid ecosystem is today, and where it’s heading.
The Technology Life Cycle
Personally, I find the Gartner hype cycle (shown below) to be an elegant way to visualize the life cycle of most technologies.
The hype cycle breaks a technology’s life into five phases: Technology Trigger, Peak of Inflated Expectations, Trough of Disillusionment, Slope of Enlightenment, Plateau of Productivity. Below, I give my opinion on where hybrid mobile development lies on this cycle.
The Technology Trigger for hybrid was the rise of multiple mobile platforms. Developers were — and still are — overwhelmed by the need to support a growing number of platforms. Hybrid development, and its single codebase approach, resonated with developers, particularly Web developers who salivated at the opportunity to write native iOS and Android apps with the technologies they already knew.
PhoneGap led the hybrid charge, providing an elegant way to create hybrid apps without having to fight with device SDKs. PhoneGap’s success, and its acquisition by Adobe in 2011, is what I consider to be hybrid’s Peak of Inflated Expectations.
PhoneGap and hybrid’s popularity were skyrocketing, but then something happened: a number of companies publicly abandoned hybrid. The biggest headline came from Facebook, whose CEO Mark Zuckerberg famously said the following in September of 2012:
“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… because it just wasn’t there.”
A few months later, LinkedIn joined Facebook by switching from HTML to native for its mobile apps. In my opinion, these public moves represent hybrid’s Trough of Disillusionment. Why did these companies leave hybrid? LinkedIn’s director of mobile engineering said the following in April of 2013 (emphasis is mine):
“There are a few things that are critically missing. One is tooling support — having a debugger that actually works, performance tools that tell you where the memory is running out.
If you look at Android and iOS, there are two very large corporations that are focused on building tools to give a lot of detailed information when things go wrong in production. On the mobile web side, getting those desktop tools to work for mobile devices is really difficult.”
This lack of tooling is corroborated by Vision Mobile, whose 2014 study of developers includes the following statement:
Our research on HTML5 vs native apps in Q3 2013 showed that the key issue in HTML5 development, is not performance or API reach, but the lack of mature development tools.
Facebook had similiar issues. Tobie Langel, a Facebook software engineer said the following in September of 2012:
“The lack of tooling in mobile browsers makes it very difficult to dig down and find out what the real issues are. Hence tooling, or rather, lack-thereof is a key issue.”
These demands for tooling have not fallen on deaf ears. Over the last year or so, mobile developers have been inundated with tools and services. Due to this, I see the current state of hybrid, or the Slope of Enlightenment from the hype cycle, as the rush to provide the tooling needed for hybrid to be a viable mobile app development option. Let’s look at these tooling improvements.
Tooling Improvement #1: Remote Debugging
When I first started doing hybrid development, my primary debugging tool was the alert() because there was nothing better available. Then weinre came along, which provided a JavaScript console and basic access to the DOM. While weinre was great for basic debugging — and is still the best debugging option for some platforms such as Windows Phone — its functionality was limited. You cannot do things like step debugging of JavaScript code.
Luckily, the two major mobile platforms, iOS and Android, have each integrated remote debugging natively into their platforms. As of iOS6, you can use the full Safari Web Inspector to debug hybrid iOS applications. For instance, in the gif below I inspect the DOM of a hybrid application.
For details on how to do this debugging yourself, see our Concise Guide to Remote Debugging for iOS, Android, Windows Phone.
The improvements in Android have been even more drastic. Android 4.4 migrated its WebView (the container native applications are displayed within) from the default Android browser to one based on Chromium. This move provided a major performance improvement to hybrid applications, and made the powerful Chrome DevTools available for remote debugging. For instance, the following screenshot shows a heap profile of a hybrid Android app — which is exactly the type of memory management tool LinkedIn and Facebook were looking for.
Tooling Improvement #2: Cloud-Based Builds
Because hybrid applications are still native apps, you need the platform’s native SDK to build them — one SDK for each platform you support. This process is at best tedious, and at worst impossible. (You need Windows to compile for Windows Phone; you need OS X to compile for iOS.)
Cloud-based builds provide this compilation as a service. Instead of managing SDKs on your development machine, you perform builds in the cloud, and get back an app that’s ready to go. PhoneGap Build and Telerik AppBuilder provide this and a number of additional features, such as QR-code-based deployment.
PhoneGap Build additionally includes Hydration, which checks for updates every time you open an app. If there is one, the system prompts the user to install it. PhoneGap also recently released a Developer App for iOS and Android. You can load connect your development machine to the Developer App, and then preview your changes on your device as you make them.
Telerik AppBuilder provides no direct equivalent of Hydration, but it makes it trivial to get apps in the hands of testers through integration with Telerik AppManager — which provides a secure mechanism for deploying apps to groups of users. Like PhoneGap, AppBuilder also has companion apps for iOS and Android, along with the capability to immediately preview changes. The project additionally offers LiveSync, which pushes HTML, CSS, and JavaScript changes to native apps — without going through a development app, and without requiring a new build. It’s basically LiveReload for mobile apps. The gif below shows me making CSS changes, and seeing them reflected live in a native iOS app.
Tooling Improvement #3: UI Frameworks
Up until recently, hybrid developers used the same frameworks they used to build more traditional websites. And while this approach works, it ignores considerations unique to hybrid, such as the need for a more “native” look and feel, as well as the increased importance of performance. Over the last year or two, a number of frameworks have appeared that specialize in hybrid web apps; I’ll mention three here.
Ionic is an open-source project for building iOS and Android hybrid apps. The project provides a CSS framework and a JavaScript UI library built on top of AngularJS. According to its documentation, Ionic supports iOS6+ and Android 4+ (with some support for 2.3).
Chocolate Chip UI is a mobile framework for building apps with a native look for iOS7, Android Jelly Bean, and Windows Phone 8. The project encourages the use of semantic HTML5 elements, and provides well over a dozen components for writing mobile apps. Chocolate Chip UI is free for open source, and you must contact them for commercial usage.
Kendo UI Mobile is a performance-minded web application framework. The project provides over a dozen widgets, as well as app framework functionality, such as an MVVM framework, and a series of view transitions. Kendo UI Mobile is now a part of Kendo UI Core, which is open source and free for everyone to use. The framework supports iOS6+, Android 2.3+, BlackBerry 10+, and Windows Phone 8+.
Tooling Improvement #4: Backends
By their very nature, hybrid mobile applications do not have a traditional back end; if you want to use an existing backend in a mobile app, you must expose it over HTTP, which often involves the time-consuming process of setting up a database, writing an API to interact with it, and deploying that service on a server somewhere.
To ease this process, several providers now offer a Backend-as-a-Service, or BaaS. At its core, most BaaS offerings provide a database in the cloud, and SDKs to interact with it over HTTP. Some services, such as Telerik Backend Services, also offer additional functionality, such as push notifications, user administration and email messaging.
If you don’t want to use Telerik Backend Services, don’t worry; there are plenty of other BaaS offerings. To give you an idea of the scope, Developer Economics — a research series that tracks developer mindshare, revenue and tools — says that they are “tracking at least *fifty” BaaS offerings, and it seems more options appear nearly every month.”
To help you sift through these options, Jim Cowart has an excellent guide on how the find the right BaaS.
What About Performance???
Although tooling improvements have certainly helped hybrid development, any look at the state of hybrid would be incomplete without tackling the elephant in the room: performance. For better or worse, hybrid development has been associated with poor performance, and it’s not without reason. Facebook listed several performance issues, most notably on older Android devices, among their reasons for abandoning HTML-based apps.
The performance of a hybrid app — like all software — is dependent on the platform it runs on. But a hybrid app is unique, because its performance is also dependent on the software it runs on—namely, the browser. The faster the browser, the faster the hybrid app runs. And on this front, there is both good and bad news.
The good news is, as of Android 4.4, the web view used by hybrid Android applications is Chromium-based, and is not subject to the performance penalties of earlier Android versions.
The bad news is the iOS 7 UIWebView still incurs a 4x performance penalty over the same app run in iOS Safari, at least according to the SunSpider JavaScript benchmark. And because iOS is developed in an offshore volcano, we have no idea if the UIWebView will be updated in iOS 8 — or ever.
Nevertheless, the performance of browsers in general continues to improve at a rapid pace. For instance iOS 6 runs SunSpider 20% faster than iOS 5, and iOS 7 runs SunSpider 12% faster than iOS6. Android devices have had similar improvements. In general, the performance of hybrid application will never be on par with native applications, but as speeds improve, hybrid becomes “good enough” for an increasing number of applications.
The Future of Hybrid
Given the improvements in performance and tooling, is the usage of hybrid applications growing or shrinking? As it turns out, this is a very difficult question to answer. The various app stores don’t exactly post statistics on the number of apps built with Web-based code. One thing we do have is survey and trending information. For instance Google Trends shows that the popularity of PhoneGap — the most recognizable hybrid development term — is still growing, but slowly.
There’s another reason getting accurate data is hard: the term “hybrid” is becoming increasingly blurry. For instance, consider cross-compile tools such as Xamarin and Titanium that let you write in a single language and produce native apps on multiple platforms. Are those “hybrid” apps? Furthermore, some apps are using completely custom mixes of HTML and native code. The iTunes app on iOS is a perfect example of this; it uses native code for its header and navigation, but Web-based code to build the content.
Despite these uncertainties we do know a few things. The first is that mobile is consuming the software development world. We’ve all seen charts that show this; here’s one of my favorites:
The second thing we know is that there’s a strong desire to reach multiple platforms. A VisionMobile 2014 study found that the average mobile developer now targets 2.5 platforms.
Because of this need to hit multiple platforms, and because hybrid provides a cross-platform solution, hybrid development isn’t going anywhere. With the recent explosion in tooling, as well as a variety of performance improvements, hybrid developers are able to build more robust apps than they were just a year ago. Whether they will, however, is a story that is still being written.