Progressive Web Applications (PWA) on iOS 13 & 14 Provide a Rich Channel to Reach Customers Despite the Platform Limitations
This includes Apple's iPhones and iPads using iOS Safari.
Do Progressive Web Apps (PWA) work on iOS?
The catch is Apple's implementation is somewhat restrained compared to other platforms, especially when compared to Chrome and Edge.
Stop right there!!!!
THIS DOES NOT MEAN Progressive Web Apps don't work on iOS, they do and they are great!
The limitations are limited at this time. Almost every feature you want n your application is supported by Safari on iPhone.
Safari supports service worker caching. It does not support push notifications or background sync. Safari does use parts of the web manifest file.
There is a 50MB service worker cache limit, but that does not mean you cannot persist more data. IndexedDB allows you to store a few GBs of data. It really depends, like other platforms, on the available space.
There is no native add to homescreen prompt, but other than Chrome and Edge no one else does either.Unused web apps that have not been added to the homescreen will have their cached assets purged after 7 days. This is less of a problem than most think.
That may sound like a lot is missing, but it is not as bad as it sounds.
A great feature of the web platform is the ability to progressively enhance (the progressive part of PWA) and polyfil many features when a browser does not support them natively.
To be fair Apple was really the first platform to support the concept of a web app. When they released the iPhone the first apps were HTML5 based.
As such they provided a way to manually add a website to the homescreen and launch in a full screen experience.
They kept the process simple, just sort of hidden.
Unfortunately, they never matured the experience. And service workers did not exist at the time.
Today that has changed, but like I mentioned, the iOS PWA experience is a little different than other platforms, but very serviceable. It is also improving with each Safari update.
I should note that Apple is not a fan of the term 'Progressive Web App' or 'PWA'. Instead they prefer to call them HTML Apps or Web Apps.
This is merely semantics. There is no official PWA specification, it is merely a term created to describe a modern breed of websites.
They are keen to point out that progressive web application is a term created by a Googler and initially promoted by Google. To be fair they are right.
The main takeaway from this article is why PWAs are a great choice to target iPhone and iPad users for your application. In fact Apple will probably tell you that too if you pay attention to the direction they are heading.
For now we know how Safari on iOS 13 supports modern web APIs. We are still waiting to see what updates and features will be added to iOS 14 and the next version of Safari.
- Does Apple Even Want Progressive Web Apps?
- Current PWA Implementations Have More Success on iOS than Before
- Consumers Are Burned Out on Apps
- PWA Technology Supported on iOS
- iOS Progressive Web App Cache Capacity
- Does iOS Support Push Notifications?
- Background Sync on iOS
- iOS PWA Quirks
Does Apple Even Want Progressive Web Apps?
Many wonder if Apple wants PWAs to succeed or even work on iOS and MacOS. The reason is progressive web apps compete with the AppStore.
The reality is Apple is more than willing to see apps leave the store and migrate to the web. They are doing a great job themselves of running off many brands from the AppStore as it is.
Recently they denied Hey.com's app update because they were not using Apple's in app payment services. Instead BaseCamp chose to use traditional merchant card services that charge 1-3% or 10% of Apple's 30% fee.
And then there is the Epic battle with Apple over Fortnite.
If you don't believe me, you should see app owners contacting me to create a PWA for them. Some because their apps were removed. Others because they fear removal or rejection.
By removing apps and making others 'uncomfortable' they are recommending to use the web.
Seriously, they even use that language:
"if the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too."
Clients have confirmed these Apple notices suggesting they move to the web.
So does Apple care about AppStore success? Yes, they do, but at the same time it is not their priority, selling hardware at massive margins is the goal.
Sure the AppStore generates billions in sales each year and yes Apple takes a 30% cut. But as I highlighted in the Spotify vs Apple article, much of that revenue is from a handful of apps.
I have created a litmus test to determine if your app should be native or a progressive web app: Does your app sell iPhones?
If the answer is no, then don't waste your time and money on a native app. Apple does not want you anyway.
But if you want to invest $5000-50000 on an iOS app to see if they will accept it be my guest. I am still here to make it available to everyone for less.😁
Current PWA Implementations Have More Success on iOS than Before
When you take the time and create a proper progressive web app you are taking the time to create a better user experience. This better UX ultimately means your customers are happier with your online experience and of course engage at higher rates.
Even with platform limitations a consistent message from brands using PWA is their iOS engagement numbers increase.
It is sort of real-world application of the 'a rising tide raises all ships' saying.
There are many PWA examples out there reporting across the board improvements to key performance indicators.
AliExpress saw an 82% increase in iOS conversions, the Washington Post saw nearly a 5x increase in user engagement and MyNet saw a 19% page view increase on iOS just to name a few sites and stats.
Even with the current limitations making a better web user experience means you will reap rewards on iOS. And eventually Apple will catch up to the competition. At least to where Chrome, Edge and other browsers are today. When those missing features light up your customers will just experience them.
Consumers Are Burned Out on Apps
Oh, and if you think having a presence in the App Store will make you successful, think again.
We know about 4 years ago consumers reached app fatigue and stopped downloading or installing apps.
Yes, apps are still downloaded, but for the most part it is the 4 or 5 apps the consumer uses the most and only when they get a new device.
For the most part these apps are Facebook. I mean Facebook, Messenger, WhatsApp and Instagram, all Facebook apps.
When you read over 80% of a consumer's screen time is in an app, almost all that time is using social media. The other apps are video, which honestly can be progressive web apps without degrading experience. I mean Netflix is phasing their apps out.
If you study mobile app consumption 99% of apps are rarely downloaded. If an app is downloaded 90% of the downloads are used once before the app is removed.
Most apps are eventually abandoned and after a while purged from the platform due to lack of interest by device owners.
Unfortunately, many still fear or falsely assume they need to have their brand in the AppStore to be found.
Are you Facebook? Are you Fortnite?
If you answered no, then most likely no one is looking for your app in the store.
They are searching for your products and services in search engines. While SEO~ is not simple, it can provide piles of targeted traffic to your site.
Once you get them on your site you can easily remarket and engage them in your sales funnel. By the time you get them to the purchase point they don’t want to go through the 6-8 steps to download your app to their phone.
If you have a progressive web app they have already ‘installed’ the core plumbing required for your PWA experience. You just need to get them to formally install or add your PWA to their device homescreen. A far easier task than downloading an app.
PWA Technology Supported on iOS
I frequently read articles about limitations of progressive web apps on iOS. Most are a bit naïve and paint a much bleaker picture about capabilities than reality.
Sure, there are limitations with Apple Safari due to its laggardness in supporting modern web standards. The current joke among web developers is Safari is the new Internet Explorer.
Of course, Internet Explorer is Microsoft's old, long deprecated browser that had so much disdain passed its way. It lagged behind its rivals FireFox and then Chrome.
Today most browsers support the same modern web standards and capabilities. Most except Safari, which always seems to be at least 2-3 years behind the competition.
The story is not as bad as that sounds. The boundaries can be handled if you plan for them. And if and when Apple ships support for a feature it can just light up in your application.
I have built applications that deal with iOS limits. Even with the lack of push notifications you can fall back to SMS. Sure USB and Bluetooth are not supported, but the demand for these APIs is very niche.
Today's modern standards have elevated the web platform to almost even parity with native counterparts. Sure there are a few edge cases where the web does not have a viable specification. But these missing features tend to have rare implementations even with native apps.
So yeah, right now the web does not offer Geo-Fencing, but I know very few applications that leverage this technology anyway, so I am not that concerned.
As for progressive web applications, what they are and what they can do that mere websites can do is well, no different.
To be classified as a progressive web application there are 3 criteria:
- Use HTTPS
- Register a Service Worker with a fetch event handler
- Valid web manifest file with a minimal homescreen icon set
That is the bare minimum, but of course there is more to the puzzle.
PWAs are just websites, but they differ from a common website in that they have those three technical features but are designed to just plain be better.
Ambiguous and anecdotal as you can get. Yes, it is the eye of the beholder if you will.
The thing about a progressive web app that makes them stand out can often be just taking advantage of platform APIs like Geolocation, biometric authentication, the payment request API, Bluetooth, Camera, Web Share and many other user experience APIs available today.
When you really boil it down, Progressive Web Applications deliver a superior user experience. This user experience gracefully degrades when the browser does not support a modern feature.
In other words, the web site provides the best possible experience the browser allows.
I find it frustrating how many of these features are assumed to not be supported or worse brand new when they have existed for years.
For example, Geolocation has been supported by all browsers for a decade.
As far as PWA support on iOS the only core thing missing is the support of the web manifest. The file that provides enhanced meta data about the web site to the browser. It facilitates the add to homescreen experience.
Apple has shipped limit support, or really partial use, for this feature. It is not a deal breaker.
That's right, a web manifest file is not required for a great user experience, and you CAN add a progressive web app to the iPhone homescreen.
iOS has had add to homescreen support on iOS since the first iPhone shipped. So rather than divert engineering resources to support this standard they focused more on catching up in the service worker space.
I think this was the right choice.
You can still include Safari's mobile-web-app-capable and touch-icon META tags in your page's HEAD without causing issues with other browsers on other platforms.
This is what is great about the web. It is very forgiving and you can add modern functionality to a website and gracefully degrade when the browser does not support a feature.
I am sure Apple will eventually support web manifest files, but for now I would prefer they focus on adding service worker features, other platform APIs and fixing bugs.
iOS Progressive Web App Cache Capacity
Right now, the biggest progressive web application limitation on iOS is the small cache capacity quota Apple imposes, ~50MB.
Again this is not a deal breaker for most web sites. If you need 50MB to cache your site's assets you really should revisit your application's code and caching logic.
I am working on a few projects right now that do need to cache more than 50MB, but they need to cache audio and video files. For these applications the media files can be looked at more as data rather than a network addressable resource, which is what service worker cache is really designed.
In these cases, the audio and video files can be cached using blob storage in IndexedDB, a browser database with much more available capacity. In fact, the IndexedDB capacity on iOS seems to be almost unlimited in the tests I have run, up to 1GB.
Let me put this in perspective, I have built several large web sites with 100s of unique web pages and support assets and cached everything (excluding images) in localStorage. localStorage is typically limited to 5MB, so you get the idea.
IndexedDB access is available within your service worker, where localStorage is not. This does mean you can intercept the network request to the more 'binary' responses and cache them in IDB in the service worker and sort of build a special caching abstraction layer to make managing their caching easier across different browsers.
Of course, even with Android and other mobile devices disk space is a premium. This is why Apple chose to limit service worker cache to 50MB. A 32GB phone does not have much storage once you factor in the operating system and other mandatory platform apps.
So, don't expect to be able to cache a high definition, large screen formatted movie. But audio books, podcasts and properly formatted videos should have no problem being cached on iOS.
So don't let the lack of service worker cache capacity stop you from using a Progressive Web App.
Does iOS Support Push Notifications?
At this point in time Apple's iPhone and iPads do not support native push notifications. You can gracefully fallback to SMS notifications. Both provide high engagement levels with minimal costs.
I am asked about this more than any other web platform feature, at least it feels that way.
Even though I get frustrated with Safari's limitations it does support most modern web APIs needed to make great user experiences.
This does not mean I am not asked by clients and potential clients if they can do some pretty crazy stuff. Most of the request are often not even possible with a native app. Others violate Apple, Google and Microsoft's terms, which means native apps are rejected and the stakeholders are hoping they can use the web to achieve their goals.
Background Sync on iOS
As for background sync this is a bummer. However, this is not supported by browsers outside the Chromium ecosystem at the moment.
You can create your own synchronization support by leveraging offline detection and IndexedDB. The main drawback here is the user will need to open your web app in order for your fallback to work. You cannot trigger the service worker to just execute in the background when the network returns, which is the main feature of the service worker background sync API.
iOS PWA Quirks
Another quirk PWAs have on iOS is being purged. This can be very problematic.
Recently Apple has addressed this problem. When a PWA is added to the user's homescreen the platform will retained cached assets for an indefinite period. Even more incentive too push users to install your PWA.
Because Apple assumes space on its devices is cramped, they aggressively throw unused items overboard to free up disk space. Add to homescreen seems to be a signal to the operating system the assets are more important, therefor they are retained.
If your PWA or any website for that matter, goes unused for a few days (we think it is roughly 14 days, it is not documented) the device will remove all cached assets associated with the origin. This includes IndexedDB, service worker cache, localStorage, etc. Again, this concerns sites not added to the homescreen.
This has made relying on cached assets a bit of an issue. The real problem lies when a user might try to load your PWA while they are offline for the first time in a month. The PWA won’t work, even if your service worker pre-caches all the required files for offline functionality.
You should also build in a check for purged cached assets in your service worker. I think just important is you should also include some sort of notice for your users if they expect the application to function offline.
Let them know the content they are caching now may not be available if unused for a long period of time. If they anticipate needing your app for offline usage try to plan ahead.
In theory your cached content could be purge by other browsers too, but they are not as aggressive. Providing a message to set user expectations can go a long way to curb potential issues down the road.
Sure there are limitations to for Progressive Web Apps on iOS, but they are not deal breakers. Many of the most requested features have at least some form of fallback solution. It may not provide a comparable user experience the native web platform API or service offers.
For most mobile apps, especially on iOS, are not a good channel to promote and engage your customers. App installs are rare for most apps. Development, maintenance and marketing for these apps is also very expensive.
The web, progressive web apps specially, are available to everyone in every browser on every device. Plus they can be affordably marketed using organic search, PPC and traditional marketing funnels.
Many brands have reported improved customer engagement stats after upgrading their websites to a PWA, especially on iOS. Most likely your brand will too.