The Diminishing Use Case of Hybrid Apps

PhoneGap is the most comprehensive, and most influential polyfill in the history of web development. PhoneGap had the audacity to envision the web as a first-class citizen on mobile, and did so in an era when we were hacking around the bug-laden iOS 4 and Android 2.2 browsers. But like all polyfills, PhoneGap was built with its ultimate obsolescence in mind — in fact, it’s one of the frameworks’s founding goals.

“The ultimate purpose of PhoneGap is to cease to exist.”

Over the last few years I believe we’re seeing the start of this decline.


Google Trends data for the search term “PhoneGap” shows a slow decrease in traffic since 2014. Interest in PhoneGap’s underlying Cordova framework is down as well, but not as steeply.

Although PhoneGap, or more generically hybrid development, used to be the de facto choice for building web apps that needed a bit of native functionality, today two new approaches are providing powerful alternative choices.

First, Google’s Progressive Web App initiative has added a lot of power to what you can accomplish on the web, making it possible to implement features like push notifications and offline access — features that previously required building a hybrid app to implement. Second, a new class of JavaScript-driven native frameworks — most notably React Native and NativeScript — have made it possible to build more performant native iOS and Android applications using the same hybrid development skill set.

In this article I’m going to argue that, as the web becomes more powerful and as native becomes more approachable, hybrid is becoming the correct choice for a decreasing number of developers. My argument will not be that hybrid is dead or even dying, but rather, that these new app development options are a better fit for what were some common hybrid use cases. Let’s take a deeper look at where hybrid fits into the modern development picture by digging into each of these new approaches.

Progressive Web Apps

Progressive Web Apps (PWA) is a Google-led initiative that brings a series of new features to traditional web apps. PWAs were designed as an enhancement to a normal web app, meaning, making your web app “progressive” is as simple as adding a service worker and a web app manifest. For the purposes of this article, PWAs are especially relevant as their features address the biggest reason developers choose to build hybrid apps — namely, that the web doesn’t offer features that these developers need.

As someone that has helped developers build iOS and Android apps for the last three years, I can anecdotally say that most web developers do not get involved with hybrid development by choice. Web developers prefer the ease of use and simplicity of the web, and are not interested in learning completely new platforms.

However, sometimes they have no choice. Native apps offer more features than web apps, and if one of those features is essential for the app you’re building, then you have no choice but to build a hybrid or native application. There are a number of features that can potentially cause the need for a hybrid app, but in my experience the single biggest showstopper is push notifications, as studies have shown that push can make or break the success of an application. Take a look at this data from Kahuna on user retention rates, with and without push notifications, to see for yourself.

push-works
Users tend to retain apps that use push notifications far more than apps that don’t.

And PWAs not only make push notifications possible, they do so in a way that’s considerably easier to implement than handling push notifications in a native apps. In a hybrid app, because you’re running on native iOS and Android that lives in the app stores, you cannot avoid the arcane setup inherent to native application development. That setup does give you more power, for instance the ability to send really rich notifications and handle them within your app, but for many applications the simplicity of the web’s push architecture is all that you need.

That being said, there’s one massive limitation keeping PWAs from being broadly adopted by hybrid developers: iOS. Although Chrome has had the two major features of PWAs, service workers and web app manifest files, implemented for some time now, the only indication that Apple intends to bring the same features to iOS is a “Under Consideration” status on their underlying web engine’s status page.

webkit-status
Service workers are marked as “Under Consideration” on WebKit’s status page

More concerning is that Apple’s business model conflicts with the whole concept of PWAs. Apple takes a 30% cut of all revenue the iOS App Store generates, which added up to a mind-boggling 6+ billion dollar amount in 2015. It’s hard to see Apple choosing to provide an alternative means of building apps on their platform, especially when it could cannibalize an amazingly profitable revenue stream for them.

The lack of web features on iOS may be the biggest thing keeping developers building hybrid apps, but those features aren’t limited to push notifications or service workers. Although there are a lot of features developers want from the web, in my experience the most common ones that push people into hybrid development are:

Despite these limitations, it’s clear that the web is slowly eating into the use cases where building a hybrid application has traditionally made sense. If you’re building a web-based app where sending push notifications is a nicety, and not a necessity, building a PWA is a compelling option. You can enable push notifications on Android rather quickly, and use that as an experiment to see whether you need to go through the hassle of building a hybrid or native app to get that feature on iOS.

This trend towards the web and PWAs is only going to continue as the web gains more features, but PWAs aren’t the only technology eating into hybrid development’s use cases. Another group of frameworks are tackling the mobile problem from the opposite end, and lowering the barrier to building completely native applications.

JavaScript-driven native

The term JavaScript-driven native refers to an approach of building native apps that are driven by JavaScript code at runtime. Whereas hybrid apps are native apps that run in a WebView, JavaScript-driven native apps use native iOS and Android user interface components, and therefore have the performance you’d expect from an app written in Objective-C or Swift in Xcode, or Java in Android Studio.

The concept of driving native apps with JavaScript is not new, as Appcelerator has been taking this sort of approach since ~2009. What is new, however, is a bunch of new players innovating with this technology stack, bringing many web-like features to native iOS and Android development.

The two biggest entries in this space are React Native and NativeScript, both of which became publicly available in early 2015. (Full disclosure: I work on the NativeScript team at Progress.) One key feature of these frameworks is they leverage popular web frameworks — React Native is built on top of React, and NativeScript offers integrated Angular 2 support, each of which gives the ability to share a framework’s APIs between their native and web apps.

Regardless of features, it’s clear that JavaScript-driven native apps have already made a sizable dent in the development world. For example, the term “React Native” is already googled more than the term “PhoneGap”.

google-trends-phonegap-react-native

The recent State of JavaScript 2016 survey shows similar interest in React Native, as well as burgeoning interest in NativeScript.

state-of-js-mobile-results

What’s so compelling about these frameworks is that you can use JavaScript, as well as other web-dev-friendly tools like CSS and npm, to build apps that go above and beyond what you can accomplish in a hybrid app. You can build endless scrolls, pull-to-refresh lists, and more without having to mess with error-prone virtual DOM techniques; you can integrate existing iOS and Android libraries like CocoaPods and Android Arsenal; and you can leverage the vast array of built-in user interface components that iOS and Android provide out of the box.


An example of a NativeScript app in action. Search for “Examples NativeScript” in Google Play or the iOS App Store to try this app yourself. You may want to also download a few apps from the React Native and NativeScript showcases pages to see just how powerful JavaScript-driven native frameworks can be.

That being said, even though JavaScript-driven native frameworks are more powerful, they’re also harder to use than hybrid development frameworks. Because JavaScript-driven native apps use native iOS and Android user interface components, you have to learn a new syntax for constructing your UIs. For instance, here’s how you build a page with some simple text in React Native:

<View>
  <Text>React Native!</Text>
</View>

And here’s how you would do the same in NativeScript:

<Page>
  <Label text="NativeScript!"></Label>
</Page>

This proprietary syntax means that JavaScript-driven native frameworks can't reuse as much existing online content as hybrid frameworks can. And in a more general sense, because JavaScript-driven native framework are relatively new, they cannot match the breadth of information currently available for frameworks like Cordova and PhoneGap. If you choose a JavaScript-driven native framework, expect it to be harder to find information you’re looking for until solutions like React Native and NativeScript become more established.

Despite the barriers, because JavaScript-native frameworks provide a way to build native apps without the limitations inherent to hybrid development, they present an appealing alternative when developers need to build a powerful mobile application. And I believe that will only become more true over time as these frameworks become more established.

The future of hybrid

So what does this all mean for the hybrid development model?

First of all hybrid is not going away. The Cordova and PhoneGap projects are actively maintained and support a growing number of production applications. Here at Progress we’ve heavily invested in Cordova, and we’ll continue to support and add to our Cordova tooling in products like the Telerik Platform. We believe hybrid is still the right choice for many developers, and will continue to evolve our tooling to help those developers build great apps.

However, the development world has diversified, and you as a developer now have more choices for building apps. If you need to build a mobile web app, take a minute to look over progressive web apps and see if they offer the features you need without going through the hassle iOS and Android app development and distribution. The Ionic Framework has PWA support that you might find interesting if you come from a hybrid development background.

And if you do need to go native, test out JavaScript-driven native frameworks like React Native and NativeScript. These frameworks will have a higher learning curve than Cordova if you’re coming from a web background, but the extra learning has the potential to help you build a more performant application that your users will love.

Perhaps the best way to sum this article up to return to the quote from earlier in this article.

“The ultimate purpose of PhoneGap is to cease to exist.”

We’re not at this point yet, and we may never be, but, it’s important to reflect on how far the web has come since this statement was first made more than four years ago. You can now build offline apps on the web and send push notifications; you can access the battery, location, and the camera; and soon you’ll be able to use Bluetooth, send money, and a whole lot more. In fact, if you look at a list of the Cordova core plugins, a staggering amount of what was previously Cordova-only functionality is now possible on the web directly.

To be fair many of these features are only available in a single browser, and many of these features aren’t as robust as their equivalent native APIs, but it’s still pretty impressive just how much the Cordova and PhoneGap teams have helped propel the web to catch up with native.

I foresee a future where the web has everything you need to build an app to reach broad audiences, and JavaScript-driven native frameworks make it easy to build truly native apps for your users. We’re a few years away from this, and we’re somewhat at the mercy of the Safari and iOS teams to make it happen, but I believe it’s clear that this is where the development world is heading.

Related resources:

Comments