What You Need to Know about the Progressive Web Application Add to Homescreen or Installation Process
An important Progressive Web Application selling feature to business owners and stakeholders is the ability for PWAs to earn a place on a visitor's home screen or desktop.
In many ways having your PWA icon a resident on the home screen represents the penultimate moment where a covalent bond is forged between the brand and customer. The brand has provided enough value to the visitor for them to decide, yes I want you to be a regular part of my digital life.
Every app, native or web, goes through a relationship funnel. In the marketing world this is better known as a sales funnel. This is where the relationship goes through phases, with each step representing a close and closer bond.
The moment the consumer takes the step to add a progressive web app to their home screen is something intimate to most, even if it is a digital connection. Today we don't just let any brand occupy a spot on that homescreen, no it has to be something we want to be a regular part of our life.
That home screen icon represents the need to make something easily accessible, not something we want to continue to search and fumble around to open.
The home screen icon is important and by many it feels like the most important part of the progressive web application life cycle. I am not one of those, but I think it is one of the most important aspects of the life cycle and a step you should seek.
At the same time this is the one aspect of the progressive web application journey that is a bit chaotic. Each browser has a different path for users to add a PWA to the home screen or desktop.
There is also a healthy debate about should we call it 'add to homescreen' or 'install'?
I think semantically to the user it should probably be phrased as 'install' because it is an explicit action on their part. At the same time as soon as the user visits a page in the progressive web app they have 'installed' the core plumbing as the service worker is registered and triggers the activate event.
It is the action of responding to a prompt to add that icon to the home screen that completes the real install process.
So why is there so much fragmentation when it comes to browser and platform implementation?
Where does the term even come from?
The History of 'Add to Homescreen'
Apple is the company that created the term 'add to homescreen'. This is how they labeled the action in Safari on iOS.
This is where we get the term, sometimes abbreviated as 'A2HS'.
This term is still in the iOS Safari lexicon and available from the 'share icon' in iOS Safari. As the years have progressed Apple has buried this option a little further from the 'top' as now the user has to invoke the share icon, then swipe to the right for the option.
There is also not any sort of automated trigger mechanism like the 'beforeinstallprompt' event. It is up to you to prompt and guide the user to and through the process.
This is part of how our recently released Add to Home screen library works. It is an Add to Home screen tool that detects the platform and displays the prompt and guidance to the user so they will know how to add your web app to their homescreen.
Apple was the first to provide a path to add web apps to the device, a few years later Google updated Chrome to honor the Apple web app META tags (I will discuss in the next section).
Today we have a formal specification in the web manifest file to provide detailed meta content to describe your application to the browser and platform for the home screen and install experience.
Unfortunately, Apple has yet to ship a version of Safari that supports the web manifest file, not the beforeinstallprompt event.
iOS Add to Home screen Web Apps
When the iPhone was first announced the original app strategy was to use web apps. So Apple created the concept of 'mobile-web-app-capable' and touch icons.
These are META tags you can add to a web page to direct iOS Safari as to how you want the web app to behave once the user has added the web app to the homescreen. Today there is a little confusion about what to call web apps on iOS, are they web apps or web clips. Apple seems to be calling them web clips today, but that sounds a little corny to me, so I will stick with web app.
But, as far as I can tell, the iOS web app META tags don't really kick in until the website has been added to the iOS homescreen. Once the site has been added this is how the META tags work.
The mobile-web-app-capable META tag really has one value, content="yes". If you set content to no there is really no reason to have the tag in the first place.
When the tag is present and set to yes, when the web app is launched it is launched in full screen mode and looks just like a native app. In fact, when I used to demonstrate mobile first web apps as far back as 2009 users would be amazed they were not native apps.
This is how Apple wants web apps to be, just like native apps:
A web application is designed to look and behave in a way similar to a native application—for example, it is scaled to fit the entire screen on iOS. You can tailor your web application for Safari on iOS even further, by making it appear like a native application when the user adds it to the Home screen. You do this by using settings for iOS that are ignored by other platforms.
The next iOS web app META tag is the 'apple-mobile-web-app-status-bar-style'.
There are three values, default, black and black-translucent. When default or black are selected the web app's content is displayed below the status bar. It the black-translucent is set the content consumes the entire screen, but the status bar overlays the top of the viewport as a semi-transparent overlay.
The next META tag, really set of META tags is the 'apple-touch-icon'. This specifies the actual icon used on the iOS home screen to represent the web app.
In the example, which comes from the PWA Starter, demonstrates configuring a web page to reference a series of icons for the platform to select the best sized icon for the screen resolution. You can think of it as a crude responsive image mechanism for iOS web app icons.
When a web app is launched it may have a start or splash screen, just like most native apps. You can also specify the image used in this splash screen.
Personally, this is not that much of a priority for me as our apps tend to render rather quickly and the splash screen never comes into play. But if your app takes a while to render, for example if you use React or Angular, then you will want to make sure you specify the splash screen image.
You can also specify the app name displayed on the home screen using the 'apple-mobile-web-app-title' META tag.
If this META tag is omitted, then the TITLE tag is used. But that value is not really what you want in most cases as the title changes from page to page and should be around 60 characters.
Unfortunately, Apple has never matured the web app, home screen icon experience. We also don't know if they are adding support for the web manifest file or not. I can't imagine them not upgrading to the web manifest file approach just because the peer pressure is too great.
While the add to home screen experiences are not as fragmented as the Android operating system device ecosystem, there is still fragmentation.
The main division with Android browsers is between Chrome and all the rest. Chrome supports the 'beforeinstallprompt' event driven sequence, and the others, well they act more like iOS Safari.
The 'beforeinstallprompt' event does two things, signifies PWA qualification and initiates a process to install a progressive web app to the device.
Since I wrote about the 'beforeinstallprompt' event and how to handle it in another article I won’t dive into that here.
Instead I want to touch on why the Chrome on Android progressive web app installation process differs from the iOS web app or merely adding a bookmark icon to the homescreen.
A couple of years ago Google upgraded the PWA install process to create a WebAPK. Instead of just creating an icon on the home screen that will open the application according to the web manifest display property, it actually creates a semi-app.
To oversimplify what happens to make it easy to understand, when a PWA is installed to the home screen it is packaged within an APK, the Android app packaging. It sort of creates an Android app, but without elevating it to a full blown Android app in a hybrid wrapper.
It does this so the installed progressive web app can have access to some of the application plumbing. Specifically, so it uses the same channels or paths an app from the Play Store does when it comes to having a presence in the app shelf and settings.
I think there is a little more to the process, but they are not as important for general understanding. The main takeaways are the user can access the PWA not only from the homescreen, but the app shelf and can 'uninstall' the PWA just like a native app. The user can also manage storage, notifications and other settings just like native apps.
The boundary, if you will, is the PWA does not get access to platform specific APIs like a native app would. But honestly, today the differences between native apps and PWAs are so minimal there is not a lot that could be gained by providing access to the platform specific APIs anyway.
So you are left with a PWA installed using Chrome on Android is a full blow native app, just without the Play Store or some private app store involved!
Non-Chrome Browsers Add to Homescreen
Unfortunately, even though Google has made the WebAPK plumbing available for other browsers to use, they haven't.
And it is frustrating.
Instead of a nice event driven installation process the user must fumble around to add the PWA to their device homescreen, just like iOS.
Some browsers, like FireFox, Opera and Samsung Internet will display an icon in their address bar to indicate the site can be added to the home screen as a PWA, but no one outside of the hard core PWA fanboys like me know this is a thing.
Sure a few people will hit the icon to see what happens, but for the most part consumers are not so fearless and would not want to risk triggering something that will 'break' their phone if you will.
This leaves it up to use to 'guide' the user to the settings menu or the icon to let them know how to add to the home screen and that it is 'safe' for them to do.
After the PWA is installed it will launch according to the web manifest values, but they are not WebAPKs. This means no settings control or app shelf presence. Just an icon on the homescreen, usually with the browser's icon overlaid in a corner of the application's home screen icon.
Again, this is something the Add to Home screen library helps to abstract away so you can prompt the user with graphics and instructions for a specific browser.
Add Progressive Web App to Desktop
To confuse you even a little more let's talk about adding a progressive web app to your PC or Mac desktop. Notice, not add to homescreen, since well we don't call it a home screen on our laptops.
Chrome and the Chromium based Edge will add the PWA"s icon to the desktop in response to the 'beforeinstallprompt' sequence. You will even see the application listed in the Windows start menu application list.
The PWA is also present in Windows application uninstall list, which means you can 'remove' it from the computer.
You can also pin a PWA to the taskbar, just like any other app.
What we don't have are Windows Live Tile support or the old pinned sites features we had when a web site was pinned to the task bar using the now deprecated Internet Explorer.
Installed progressive web apps will launch according the web manifest display property, which for me means standalone mode. So, they launch just like a regular application.
Other than Chrome and new Edge the other browsers have a similar store as they do on Android. You have to provide some sort of way point based map to guide them to the settings menus to install the PWA.
The Add to Home screen or Install step is an important part of the Progressive Web Application engagement life-cycle. You just have to understand how the experience is fragmented and provide an appropriate experience to guide the user to install your application.
You may need to exercise some control over this experience so the user is not constantly prompted, but prompted when appropriate. This is why using an Add to Home screen tool like our library can give you control over the prompt timing and messaging to guide the user through the process.
Because you are trying to connect with your customer you need to make sure they are comfortable with the install process. They not only need to know how to do it, but also know it is safe.
My hope is someday soon all browsers will not only support the 'beforeinstallprompt' event, but will also support some form of the WebAPK. This will give us a fair shot at progressive web applications have that final piece of parity we need to leverage native app capabilities. For now, we are close enough, just fragmented.