Altering expectations by improving PWA on iOS

In an article this week, Jeremy Keith shares the experience that Clearleft have had while designing and deploying the Virgin Holidays app onto mobile. If you have read anything that Jeremy has shared in the past year you will know that he’s is a huge fan of the Progressive App approach, in fact he’s even written a book on the subject.

In Jeremy’s article, however, the client decided to go with the Hybrid App in the end.

Why?

Well it seems it was two reasons. The first was that at the time iOS hadn’t provided support for Progressive Web Apps so a large number of customers wouldn’t be able to use the product. That has changed now, thanks to Apple/Webkit’s support of Service Workers on Safari across the iPhone and iPad range (although not supporting all the features that Chrome on Android might support).

For example, Background Sync is still not supported in anything other than Chrome, although Firefox and Edge are in development of the feature. Other features we’d like to see on PWA’s, like app notifications, are not supported across Apple devices at the moment but will be a huge improvement in the competition with native apps when they do finall land… if they land.
The problem with Apple
While Apple are making billions of dollars through the sale of their hardware, the ecosystem they have created through the App Store have made it possible for them to maintain quality control and a very healthy slice of the sales across the Apps that can be downloaded and used on their mobile devices.

By opening up more app like features that are ready and available within the toolset avaialble to us to create Progressive Web App, Apple are in fact making a case for developers to bypass the process of

Purchasing a development account ($99 per year)
Learning Swift
Writing an propriatary App for the Apple ecosystem
Apply to Apple to publish the app to the store
Sell on the App store (-30% commission that Apple will take for every sale, including in app purchses)
Re-request to publish to the store for every update.

Why would Apple want to do that? Sure, it benefits the entire world to make apps immediately accessible without having to go through the pain of the App store — but what about their control and their revenue?
What is the other reason to go with an App?
The second reason is a harder mountain to climb.

The client that Jeremy spoke about in his article believes that their users expect them to be in the App store, so they need to be there.

While stores like Windows are going to include Progressive Web Apps as a first class citizen (and rightly so) I’m not sure that Google Play and Apple are going to have the same open approach for my reasons above — they will loose revenue and control (although Google Play has less control in the first place).
For over a decade, people have formed ideas about what to expect from the web and what to expect from native. From a technical perspective, native and web have become closer and closer in capabilities. But people’s expectations move slower than technological changes.

First of all, there’s the whole issue of discovery: will people understand that they can “install” a website and expect it to behave exactly like a native app? This is where install prompts and ambient badging come in. I think ambient badging is the way to go, but it’s still a tricky concept to explain to people.

But there’s another way of looking at the current situation. Instead of seeing people’s expectations as a negative factor, maybe it’s an opportunity. There’s an opportunity right now for companies to be as groundbreaking and trendsetting as Wired.com when it switched to CSS for layout, or The Boston Globe when it launched its responsive site.
I agree with Jeremy on this point, I think by building it first you will get people visiting the site first on mobile through the web, and then because of such a great experience they won’t worry about going to find it on the app store itself.

Now, the only thing that gets in the way of that is Apple opening up the ability for the Service Worker to work within browser apps that are not Safari (like Chrome and Firefox for example).

Subscribe to our Newsletter

Add your email address and receive an email every Friday covering off everything worth knowing about building your websites responsively.