React Native, PWAs and the decline of native mobile app development

As the head of a software services company, I am often asked to advise clients on strategic technological decisions. The most common query nowadays is which framework to choose for mobile app development. The menagerie of standards, from native to Cordova and React Native, can be bewildering even for industry insiders. Since the various approaches are mutually incompatible, a wrong choice can mean a complete rewrite down the road. This post is an attempt to provide guidance to managers facing this all-important decision.

A (seriously) brief history of multi-platform app development

My first project as a professional software developer was a terminology management system for translators. My boss insisted that the app must work on Windows, Mac and Linux. (This was 1992, and it is striking that the dominant desktop operating systems and the challenge of supporting them are essentially the same more than 25 years later.)

I scoured the tech landscape in search of appropriate multi-platform tools for the user interface, database and so forth. The result was an app that worked on all the target operating systems but was not entirely satisfying on any of them (an outcome that is depressingly familiar to anyone experienced with the traditional approach to cross-platform development).

Just as this project was coming to a close, the web was beginning its inexorable rise. Like many developers, I was excited by its potential to solve our multi-platform woes once and for all. And indeed, the vast majority of popular apps over the next decade, from Gmail to Facebook, were web apps that looked and worked pretty much the same wherever you used them. Libraries like jQuery emerged to paper over cross-browser incompatibilities. Cross-platform development was a solved problem... or so it seemed.

Then came the iPhone. Despite Steve Jobs's exhortations that the web (and specifically "Web 2.0") was the SDK for the new mobile platform, developers had their pocket protectors in a twist, complaining that web apps could not match the fit and finish of their native counterparts. This meant that Apple had an unfair advantage as the only company able to take full advantage of iPhone's capabilities. A year later Jobs relented and the first native software development kit (SDK) was made available to iOS app developers.

A digression about web apps

So what's wrong with web apps, anyway? The problem, in short, is that the web was conceived not as a platform for apps but as a means of exchanging hypertext documents. Its web-like nature stems from the ability to easily link one document to another.

Web apps came later, initially with the advent of forms that could serve as the basis for simple user interfaces. Users interact with the page by filling in the appropriate form fields and then submit the data to the server, which generates and returns a brand new page.

If that sounds slow and clunky: it is. Web apps didn't really come into their own until the advent of XMLHttpRequest, initially a (charmingly oxymoronic) "proprietary standard" from Microsoft. By allowing developers to request new data from the server without reloading the entire page, it spawned a new generation of so-called Ajax apps (think Gmail) which came much closer to rivaling the responsiveness and usability of native apps.

Through all this, the web stayed true to its document-centric roots. For the uninitiated, it is hard to fathom what goes on under the hood just to display a single line of text in a modern web browser. Layout is determined by stylesheets written in CSS, a beast of a standard (albeit an impressive one) made up of a dozen or more separate specs comprising thousands of pages. The resulting process would make Rube Goldberg blanch.

Rendering text in the browser (source: Mozilla)

CSS is incredibly powerful, but it is too slow to be an obvious choice for laying out an application user interface. What's more, web interfaces need to look good in all browsers on all platforms, whereas native mobile apps need target only a single operating system. It is certainly possible to make fast, attractive web interfaces but a daunting level of skill is sometimes required.

Going native

Native Android and iOS apps do not have to worry about rendering documents (they typically use an embedded web view for this purpose). They can thus focus on doing one thing well: providing a slick application experience. Each platform bakes in a consistent look-and-feel so there is no need to dream up a "third way" that looks decent (but never entirely satisfying) on every device. These advantages are so significant that Mark Zuckerberg stated in 2012 that the biggest mistake made by Facebook was depending too much on HTML5 for its mobile apps.

And so it's 1992 all over again, as app developers are faced with the same decades-old dilemma: maintain separate codebases for different platforms, or embrace multi-platform technologies at the cost of subpar user experience?

Then came React Native. Thanks to a sustained arms race between Google and Facebook, web development has been evolving at breakneck speed. The tech collossi have been vacuuming up droves of top computer scientists and deploying their essentially unlimited resources in pursuit of the ultimate web development stack. React Native is one notable achievement.

Released by Facebook in 2015, it goes a long way towards bridging the divide between web and native. Apps are developed using code that is largely shared across all platforms, but with a truly native user interface. The underlying approach is brilliant in its simplicity: use the same techniques as the wildly popular React web framework but generate native widgets instead of HTML, using a subset of CSS that is tailored for fast user interfaces rather than documents.

Raves from the developer community and adoption by well-known companies like Facebook (and its Instagram subsidiary), Walmart, Tesla and Skype suggest that React Native is already a force in mobile app development. It is the first widely used framework to enable the creation of truly native multi-platform apps. By leveraging popular web technologies like JavaScript, CSS and React, it mitigates the need to implement and maintain separate codebases for each target platform.

The announcement by Airbnb that they are moving away from React Native, of which they were a prominent early adopter, caused ripples in the developer community. A counterpoint to this is Zynga's unwavering commitment to the framework. Airbnb's problems stemmed largely from the need to integrate React Native code into a huge existing code base. Moreover, they began using the framework in its early days and had to contend with considerable teething pains. Companies adopting it today for greenfield projects are unlikely to encounter the same hurdles.

Progressive ideas

While mobile apps offer a great user experience, they are not the right fit for every use case. For example, it sometimes seems that every restaurant and online publication is pushing you to install their app. I have at least ten airline apps on my iPhone so that I can load the boarding pass into my Apple Wallet (something that, inexplicably, is usually not possible if you check in via their website).

Yet why should I install the McDonalds or IKEA app if I only dine or shop in their establishments every couple of months? Why should I install the Wired or Huffpost app just to read a single interesting article? The absurdity of this trend is underscored by the average number of apps installed monthly by the typical US user: zero.

Mobile apps are also a throwback to a more primitive era when every improvement required the user to upgrade to a new version. Decades after the web pioneered a model where apps require no explicit installation and are always up-to-date, it is all too easy to end up using an obsolete mobile app version for months or even years without realizing it.

Introduced by Google in 2015, Progressive Web Apps (PWAs) provide an intriguing alternative to traditional mobile apps. To use a PWA, you just enter the URL into your browser. But, as the name suggest, they become more "app-like" over time as a byproduct of regular usage.

To a large extent, the term PWAs is are just a buzzword layered on top of trends that were already underway. Readers will doubtless be familiar with web sites that bombard them with requests to track their location, access their camera or send them push notifications. None of these new web app capabilities were introduced by PWAs. But if they hadn't already existed, PWAs would presumably have had to invent them.

The principal innovation specific to PWAs is the service worker. This is best understood as a miniature web server running inside a web app. By offering local access to server-like functionality, service workers enable offline operation so that web apps load fast and work without a live internet connection, just like native apps. They also help to manage the aforementioned push notifications.

The rise of hybrid apps (Source: Ionic)

Rather than install the IKEA app while buying a new couch, only to have it clog up your home screen for all eternity, a PWA would let you go to ikea.com and access whatever features you need in your web browser. Thanks to service workers, the app would load faster (with a pretty splashscreen) and even work offline the next time you access it. If you fall in love with the app, you can opt to add it to your home screen, but unlike native apps you don't have to jump into bed with it on the first date.

Spoiled for choice

Like React Native, PWAs are a recent innovation. As a Google initiative, it is perhaps not surprising that right now they are much better supported on Android than on iOS. The latter finally added service workers in March 2018, albeit with no support (yet) for push notifications. But while PWAs are still bleeding edge, developers would do well to ask themselves whether the choice of React Native (or true native) for their mobile app is going to condemn them to rewrite it if PWAs take off.

One major drawback of PWAs is that, while it recently became possible to submit them to the Android app store, Google Play, they cannot be listed in the (iOS) App Store. Many users still discover apps in the App Store (especially if you are lucky enough to get your app featured). Neglecting it might represent an unacceptable brake on user acquisition.

It is probable, though by no means guaranteed, that Apple will eventually address this limitation. In the meantime, I would not even consider writing a PWA without offering a version wrapped using Cordova. The latter turns a web app into a native app (by embedding a web view that hosts the application's user interface). You can submit the wrapped version to the App Store and, through the use of Cordova plugins, access capabilities like push notifications that are currently unavailable to PWAs on iOS.

Another criticism of web apps is that they do not look quite native on either Android or iOS, both of which have a proprietary look-and-feel that app developers are supposed to respect. React Native handles this in a semi-satisfying way by forcing app developers to write separate view components for the two platforms (thereby reducing the code reuse that is one of its principal attractions).

Design languages like Material Design and libraries like Ionic attenuate this problem using visual components that look consistent and attractive regardless of device. Google invented Material Design precisely to avoid the need to implement and maintain two separate user interfaces for its own apps. It is very popular among third-party app developers, and there are libraries for implementing it in both web apps and React Native. This is good for React Native and great for PWAs, since the latter were never going to look entirely native anyway.

So, having carefully weighed the pros and cons of each approach, on the question of which mobile framework to choose I can say now with confidence: it depends.

If you are embarking on a new mobile app project, I would recommend that you first consider a PWA wrapped in Cordova, especially if you already have a development team with strong web skills. There are still legitimate reasons not to go the PWA route, such as the need for native-level UI performance (e.g. for video games) or access to bleeding edge native APIs for features like augmented reality. In these cases, React Native may be the right choice. But you should understand the trade-offs of the different approaches before rejecting PWAs.

The mobile app market is vast, and a single development framework "to rule them all" is unlikely ever to emerge. React Native and PWAs may end up happily sharing the limelight, or a new contender (Flutter?) may achieve primacy. One trend is clear already, however: truly native apps are losing their appeal as the breadth and quality of multi-platform alternatives is steadily improving.