What's wrong with mobile web apps, anyway?

Every mobile app developer knows the dilemma. To get decent market coverage you need to develop your app for at least three completely different operating systems: iOS, Android and Windows Phone.

Okay, I'm obviously just kidding about Windows Phone. But still, implementing an app for iOS and Android essentially doubles the development effort, doubles the maintenance effort… and to do it properly you probably have to spend significant additional time on UX to create a user interface that looks and acts natural on both operating systems.

This state of affairs is nothing new. In my first job, in the early 1990s, I was tasked with implementing a terminology management system for a translation company. It had to run on Windows, Mac and Linux.

I ended up with something that looked a bit like this. It worked on all the target platforms but didn't feel entirely satisfying anywhere.

It was then that I came up with the First Law of Multiplatform App Development: you can have a multiplatform app, or a good app… but not both.

Then came the web. While originally designed for exchanging documents, it quickly (and perhaps unexpectedly) grew into a popular app development platform. Initially web apps were very clunky, requiring the server to send back a whole new page in response to every user interaction.

The introduction of XMLHttpRequest, despite its "interesting" capitalization, made it possible to implement so-called "single page apps" that offered much better interactivity.

An example of an early single-page app is Gmail, released in 2004. It was a cutting-edge web app that was in many ways better than its desktop competition but worked the same on all platforms. Partly this was because the web was designed from the beginning to run in its own container – the web browser – that was entirely operating system agnostic. The web also introduced a new UI paradigm with hyperlinks, the back button and so forth that is not tied to a specific operating system but is still familiar and comfortable to users.

Browsers differed in API support and performance, with Internet Explorer being the worst culprit. But the effort to make a crossplatform web app was still much lower than for desktop apps, and libraries like jQuery quickly cropped up that made the task even easier by smoothing over the differences between browsers.

So everything was rainbows and unicorns… but not for long.

In 2007, the iPhone came along and ruined everything.

Suddenly mobile apps, which used to look like this…

…started to look like this. And developers decided that the web paradigm did not give them what they needed to create the new breed of slick mobile apps.

It wasn't immediately obvious that things would turn out this way. When the first iPhone was released, Steve Jobs famously announced that the web would be the SDK for the iPhone. But developers were up in arms. The perception was that third-party devs wouldn't be able to compete with Apple's own apps without access to a true native SDK. Apple quickly relented and released a real SDK a few months later.

The dream of a multiplatform future based on the web suffered a huge setback. Mark Zuckerberg's statement in 2012 that using HTML5 for the Facebook app was the biggest mistake they had made as a company only reinforced the sense that native was the only right way to develop on mobile.

And yet web apps have a lot of advantages. Firstly, as I have been emphasizing, they are multiplatform by nature.

Secondly, because the web ecosystem is so big and open, the pace of innovation is much faster than in closed ecosystems like iOS or Android. The modern web stack is incredibly powerful and elegant compared to just a few years ago, whether you are using Angular, React, Vue or whatever amazing new framework came out since the beginning of this talk. And we are continuing to see the steady introduction of new ideas like MobX State Tree and React Hooks that move the state of the art forward.

Thirdly, companies often want to deploy both on mobile and on the web, which is a pain to do if your mobile app is native but basically free if it's a web app.

Fourthly, many companies already have teams in place with deep expertise in web app development. In a world where recruiting developers is a daunting challenge, no one wants to have to recruit and manage additional teams for iOS and Android. Since mobile web apps are just web apps, you can take advantage of the skills and experience you already have instead of having to tackle new, steep learning curves for native app development.

And, as I often hear when speaking with clients and prospects, there is a lot of resistance to paying the so-called "Apple tax", where you have to pay a commission of up to 30% to Apple (or Google for that matter) when collecting payments in your mobile app. Making a web app lets you circumvent the smartphone manufacturers and keep user payments for yourself.

Which brings me to the main point of this talk: why? Specifically, why did developers react so negatively to Steve Jobs's suggestion that they use web technologies to program for the iPhone? Why did Mark Zuckerberg consider Facebook's use of HTML5 to be such a huge mistake?

The biggest reason is surely performance. The web was originally designed to display hypertext documents, not apps… and it shows. There's a lot happening under the surface when you display something in the web browser.

The power of CSS lets you do amazing stuff like recreate the Stars Wars intro in pure CSS. I'm showing the whole CodePen here so you can see that the page is being generated in real-time using HTML and CSS.

Clearly the web enables some impressive text effects. But the underlying rendering process kind of reminds me of a Rube Goldberg machine.

For those who don't know what I'm talking about, here's a classic example: an automatic back scratcher. The way it works is that you light your curtain on fire, then wait for the fire brigade to arrive and start spraying water onto the fire. The dwarf thinks it's raining and grabs the umbrella, which pulls the string and causes the big metal ball to fall off the platform. This pulls the other string, releasing the hammer. It smashes the mirror, making a loud noise that wakes up the puppy. The mommy dog starts rocking the cradle to put him back to sleep, which moves the wooden hand and scratches your back. Simple, right?

Now this is obviously a crazy way to scratch your back. But if you look at how browsers render HTML, it looks kind of similar, wouldn't you say? [No one thinks so.] Okay then maybe it's just me. In any case, as someone who worked in the Mozilla codebase for many years, I can assure you that the rendering code itself is even scarier. At least when I was involved in the project, there were probably like two people in the world who really understood the CSS processing code and were able to make changes in it. With so much going on, it's no wonder that web interfaces have traditionally felt sluggish compared to native UIs.

Another issue is access to native hardware and operating system services like the camera, accelerometer and push notifications. At the time of the iPhone's initial release there was no way to do any of this from a web app because, until then, no one had been writing apps for a device that had any of these capabilities.

It has also been a huge challenge to make web apps that behave sanely when you are not connected to the internet, whereas native apps avoid this problem by storing their code directly on the device.

Last, but certainly not least, there is no standard way to distribute a web app. As any mobile app developer knows, the iOS App Store and Google Play are essential distribution channels, especially if you're lucky enough to get your app featured. It is natural to worry that users will have a harder time discovering your app if you can't put it into the stores, and that your marketing budget will have to grow significantly to compensate for this.

So the case against mobile web apps seems pretty clear cut, right? As you've probably guessed, I don't think so.

Let's consider these objections one by one. As far as performance is concerned, we mustn't forget about Moore's Law. There is a long tradition of technologies that were considered too slow to succeed but won in the long term thanks to rapid improvements in hardware performance.

In 1986, the New York Times compared running Windows 1.0 to "pouring molasses in the Arctic". And yet, it's probably safe to say that Windows turned out okay for Microsoft, a few hundred billion dollars later. The reason, in a nutshell, is that desktop computers kept getting faster, making Windows more and more usable (at least as far as performance is concerned).

Mobile phones have experienced similarly rapid speed improvements. I couldn't find a more recent graph that covers all iPhone models, but as you can see the iPhone 6, which was released in 2014, was up to 84x faster than the original iPhone.

For multicore tasks the iPhone XS is almost 5x faster than the iPhone 6.

So all we have to do is multiply these numbers together, and we see that the total performance improvement from the first iPhone to the most recent model is about 400x. 400x is a lot.

If an iPhone XS were 400 times heavier, it would weigh as much as a full keg of beer.

If it were 400 times cheaper, it would cost the same as a medium latte from Starbucks.

If it were 400 times longer, it would stretch as high as the leaning tower of Pisa.

Actually it might be easier to compare like this.

Basically this means that doing a lot of stuff that was unacceptably slow in 2007 is probably just fine now. And the phones keep getting faster. The performance disadvantage of web apps is already arguably not that important and this trend is likely to continue to the point where it will be overshadowed by other considerations.

Access to hardware features is now largely a solved problem. Web apps have had access to the device's geolocation via standard APIs as far back as 2010 and to the device's camera starting in 2012. There are other APIs for gettings readings from the accelerometer, gyroscope and so forth.

Now some of you may be asking yourselves: how has he been talking about this for 15 minutes already and hasn't even mentioned Progressive Web Apps. So let's fix that. Just a quick overview for anyone in the audience who has been living under a rock for the past year or so. PWAs were introduced by Google in 2015 and are really a blanket term for a set of technologies that aim to give web apps the same capabilities as native mobile apps. They're "progressive" because they can run like normal web apps in any web browser, then ask for additional capabilities as needed. So you can get to know the app gradually without jumping into bed with it on the first date.

One important component of a PWA is the manifest. This contains the name, URL, icon, etc. of the app and makes it possible, for example, to install the app on the phone's home screen. Service workers are another key component. They are kind of like a local web server and make it possible for the app to run offline and to receive push notifications.

In January of this year, Google even added support for the Trusted Web Activity API. This means you can embed a PWA inside an Android app and distribute the app in the Play Store. As a result, at least on Android, PWAs have really arrived. Your app can have pretty much all the capabilities of a native app and even be distributed in the Android app store, but with all the advantages of a web app: multiplatform, usable in a web browser and so forth.

On iOS the picture is a bit murkier. Apple added key PWA capabilities last year including services workers. But PWAs can't be listed on the App Store and some key capabilities like push notifications are still missing from Mobile Safari. It's anyone's guess when and if Apple will add the features to iOS necessary to achieve parity with Android.

In the meantime, you can always wrap your app using Cordova and get access to any native features not supported by PWAs on iOS, and list your app in the App Store, but at the cost of some additional development effort. As most of you probably know, Cordova is an open-source successor to Adobe's Phonegap that wraps web apps in a container so they can be installed and run like native apps.

You don't hear so much about it nowadays, but rumors of its demise are greatly exaggerated. For one thing, it is used under the hood by the popular Ionic framework. Of course, the whole point of PWAs is to make frameworks like Cordova obsolete, but in the meantime it's a good way to fill in the gaps on iOS while we wait for it to catch up with Android.

One final word about React Native. Along with older frameworks like Xamarin and newer ones like Flutter, React Native enables developers to create true native mobile UIs with a multiplatform codebase. As a long-standing fan of React, I was very excited when Facebook announced React Native in 2015. It offers almost all of the advantages of React, including use of JavaScript, an elegant component model and a rich ecosystem of complementary libraries, while generating UIs that are as smooth as slick as native… because they are native. As React Native matured, I became more and more convinced that it was the best choice for most mobile apps.

I still think React Native is great, but PWAs now offer stiff competition. The trade-off is straightforward: PWAs let you use one codebase everywhere. React Native gives you a lot of code reuse, but you still have to implement separate views for iOS, Android and web. On the flip side, React Native gives you true native user interfaces. So if your biggest priority is the slickness of the UI, React Native might be the best choice. If you can live with a web interface, a PWA will require less development effort to support all platforms and relies only on open standards, not proprietary frameworks.

Xamarin has a lot of the benefits of React Native but relies on Microsoft's .NET framework and C# language instead of JavaScript. It might make sense for you in you have strong .NET expertise and intend to deploy on iOS and Android but not the web. Flutter is a newer Google framework that uses the Dart language to generate multiplatform native mobile apps. A thorough comparison of Flutter and React Native could take up a whole talk of its own. For now, suffice to say that if you are planning to use React Native but don't insist on using JavaScript and React, you might want to take a look at Flutter as well before making a final decision.

In summary: mobile web apps have many significant advantages over native apps, but have been hampered by negative attitudes that date from the introduction of the iPhone over 10 years ago. These attitudes are still widespread but are largely outdated. Mobile devices are just way, waaaay faster than they were in 2007. Web standards have come a long way, adding access to native hardware and features... and culminating in the advent of PWAs. At least on Android, PWAs are rapidly achieving parity with native apps but with all the advantages of the web. On iOS, the picture is a bit more mixed, but the inclusion of PWA features in iOS 11 suggests that this is an area of active interest for Apple, and we can at least hope that they will one day catch up with Android.

And so, while we may not be there just yet, it is time to start questioning the First Law of Multiplatform App Development.

As we've seen, we are getting closer and closer to the day where we can make apps that are both good, and multiplatform!

Any questions?