PWAs are here, or are arriving very soon, depending on which web browser you use. This isn’t really news if you’ve been following along with the PWA story. However, with WebKit’s implementation of Service Workers and Web App Manifest, one major lingering question over the future of PWAs has been answered: Will PWAs ever come to Safari? The answer is yes! And with this, PWAs seem to have reached critical mass.

So now we can shift focus to some related questions: What of native apps? And what of app stores?

What of native apps?

The web vs native debate is one that predates the rise of mobile operating systems. Web hasn’t replaced native applications on desktop PCs and is unlikely to on mobile either. Just as on desktop, the native app model is more suited to certain types applications on mobile. Native apps aren’t going anywhere.

This said, it’s interesting to take a brief look at Safari on iOS pre-PWA.

The full Safari engine is inside of iPhone

“The full Safari engine is inside of iPhone”! How amazing is this? OK, so in 2018, maybe not the most amazing thing you will hear—there’s an electric car flying through space towards Mars right now, after all. This statement, however, is from 2007. It was made by Steve Jobs over 10 years ago at the WWDC conference on June 11, 2007, 18 days before the launch of the first iPhone.

It would seem Apple has been a long-time believer in the power of the Web as an app platform, using it to promise an “innovative new way to create apps for a mobile device” through Safari. These couple of minutes make an interesting watch (from 1:14:11), given where we are now, and how we got here.

So this was Apple and Jobs’ vision of apps in 2007:

• Safari
• Web 2.0 + AJAX
• Integrate with iPhone services
• Instant distribution
• Easy to update
• Secure

Apps powered by web technologies and delivered via Safari.

Perhaps it was a combination of the commercial opportunity afforded by the app store proposition, and the advantages that native offered over the then capabilities of Safari powered web apps, but this vision didn’t last long.

Within a year or so, iOS 2.0 was released, along with the App Store and third-party native apps, and the web took a back seat to native on iOS. Safari, once a browser industry leader, began to lag behind the other popular browsers in supporting new features.

Native apps have always had some advantages

Traditionally two compelling reasons to choose to build a native app over a web app were performance and capabilities:

• Native apps are closer to the metal: there’s a smaller stack required to run an app, so they have a performance advantage. Native apps run on the OS itself, while web apps run in the web browser, itself essentially a native app. So web apps have all the overhead of native apps, and more, and so performance could never match that of a native app.

• Device APIs: because a native app runs directly on the OS, it has access to all the hardware that the OS exposes, such as location and orientation data from GPS and accelerometer sensors, access to the camera and microphone and so on. The web browser didn’t have access to most of these things, at least not at the time, so web apps couldn’t compete on features. For some applications, there simply wasn’t a choice between native and web: it was native or not at all.

In prioritising the native model, Apple traded the instant distribution and easy to update tenets of its vision for apps for performance and capabilities.

HTML5 and the web

Some applications were traditionally better suited as native apps, and others as web apps. This hasn’t changed. But web technology has. With HTML5, and the device APIs it offered, like Device Orientation and Geolocation, web apps began to offer a much richer feature set. The scope of problem suited to web apps has grown so that, where in the past it might not have been even possible to deliver some feature using a web app, for many applications the web is now a viable alternative that must be considered.

Indeed, with service workers, web apps can work offline, and with web app manifests, they can be packaged up and launched just like native apps. In fact, the experience offered by PWAs is now often indistinguishable from native apps. A good example of this is the Twitter PWA: it can send tweets offline, queued up until the network is recovered, and supports reading offline and push notifications. It can be launched from the homescreen in the same way that a native app can be.

And with WebAPKs on Android, the illusion is even stronger: web apps are installed as apps, appearing exactly as native apps do in the app-management and task-switching functions of the device.

Performance is also not the blocker it once was for web apps. With hardware accelerated graphics offered through WebGL and Canvas, intensive graphics applications and games are possible using web technologies. 60 fps animations is now the norm, and not an aspiration. Indeed, 60 fps was possible even five years ago.

Developers should be asking themselves whether what they are building needs to be a native app, or if the same goals could be achieved more efficiently with a web app.

There is nothing eminently new about all this, and there will always be some problems better addressed with a native app than a web app. However, with Safari all but on board, and with performance and feature differences between web and native negligible for many application domains, at the very least, developers should be asking themselves whether what they are building needs to be a native app, or if the same goals could be achieved more efficiently with a web app.

What of app stores?

A key difference between the nascent PWA ecosystem and native apps is that any PWA can happily exist outside of an app store, well, because of the web.

So what about the future of the app store model? App stores will likely still be around for a while: While there are native apps, there will be app stores, and native apps will be with us for a while yet!

Perhaps the more interesting question to ask is how do PWAs fit into the app store model? Sure, they’re web apps, and we already have automatic indexing and sophisticated search for the web; but is there room for PWAs too?

In a way, a centralised directory of PWA web apps, feels a little like the web coming full circle again; kind of like the Yahoo! and Dmoz web directories of the 1990s, but with flashy PWA icons instead of links, and with a payment model built in. A payment framework is something that is clearly in Microsoft’s sights:

we’ll empower developers to differentiate their PWAs on Windows – including allowing developers to claim and monetize their PWAs in the Store

We’re already getting a glimpse of what this future might look like, with Microsoft leading the way with plans to make PWAs first class citizens in Windows 10. Service workers and push notifications will be enabled by default in the next verson of Edge browser, and in the coming weeks Microsoft plans to crawl and index “PWAs from the Web to list them in the Microsoft Store, where users can find them just like any other app on Windows 10“.

Microsoft isn’t the only one bringing PWAs to their app store. Google Maps Go is a lighter version of Google Maps, built for low-end Android phones. It’s really just a PWA and it’s also available in the Google Play Store.

It’s probably safe to say we’ll see more PWAs popping up in app stores in the near future.

To sum up, native apps aren’t going anywhere. However with PWAs, and their almost indistinguishable experiences, developers approaching a new problem should at least pause to consider if building a native app is the right thing to do, or whether the project goals might better be served with a PWA.

And again, since native apps are going to be around for a while, app stores will be too. At the same time, app stores may find a new role in the distribution and monetisation of PWAs, as we’re already seeing with Microsoft’s efforts.