 Demián Renzulli [X](https://twitter.com/drenzulli) [GitHub](https://github.com/demianrenzulli)  Pete LePage [X](https://twitter.com/petele) [GitHub](https://github.com/petele) [Mastodon](https://techhub.social/@petele) [Homepage](https://petelepage.com/)
Published: May 12, 2020
In the past, app installation was only possible in the context of
platform-specific applications. Today, modern web apps offer installable
experiences that provide the same level of integration and reliability as
platform-specific apps.
You can achieve this in different ways:
- Installing the PWA [from the browser](https://web.dev/articles/customize-install).
- Installing the PWA [from the app store](https://developer.chrome.com/docs/android/trusted-web-activity).
Having different distribution channels is a great way to reach a broad user
base. However, choosing the right strategy to promote your the installation
of your PWA can be challenging.
This guide explores best practices for combining different installation options
to increase installation rates and avoid platform competition and
cannibalization. The installation offerings covered include PWAs installed from
both the browser and the App Store, as well as platform-specific apps.
[Video](https://www.youtube.com/watch?v=6R9pupbDXYw)
## Why make your web app installable?
Installed Progressive Web Apps run in a standalone window instead of a browser
tab. They're launchable from the user's home screen, dock, taskbar, or shelf.
It's possible to search for them on a device and jump between them with the app
switcher, making them feel like part of the device they're installed on.
But having both an installable web app and a platform-specific app can be
confusing for users. For some users platform-specific apps may be the best
choice, but for others they can present some drawbacks:
- **Storage constraints:** installing a new app might mean deleting others, or cleaning up space, by removing valuable content. This is especially disadvantageous for users on low-end devices.
- **Available bandwidth:** downloading an app can be a costly and slow process, even more so for users on slow connections and expensive data plans.
- **Friction:** leaving a website and moving to a store to download an app creates additional friction and delays a user action that could be performed directly in the web.
- **Update cycle:** Making changes in platform-specific apps might require going through an app review process, which can slow down changes and experiments (such as A/B tests).
In some cases, the percentage of users who won't download your platform-specific
app might be large, for example: those that think that they won't use the app
very often, or can't justify spending several megabytes of storage or data. You
can determine the size of this segment in several ways, for example by using an
analytics setup to track the percentage of "mobile web only" users.
If the size of this segment is considerable, that's a good indication that you
need to provide alternative ways of installing your experiences.
## Promote installation of your PWA in the browser
If you have a high quality PWA, it may be better to promote its installation
over your platform-specific app. For example, if the platform-specific app is
missing functionality offered by your PWA, or if it hasn't been updated in a
while. It can also be helpful to promote installation of your PWA if the
platform-specific app wasn't optimized for bigger screens, such as on ChromeOS.
For some apps, driving platform-specific app installations is a key part of the
business model, in that case, it makes business sense to promote installation of
your platform-specific app. But, some users might be more comfortable staying on
the web. If that segment can be identified, the PWA prompt can be shown only to
them. We call this *PWA as fallback*.
### PWA as primary installable experience
Once a PWA meets the [installability criteria](https://web.dev/articles/install-criteria), most
browsers show an indication that the PWA is installable. For example, desktop
Chrome shows an installable icon in the address bar, and on mobile, it shows a
mini-infobar:
 Standard Chrome install prompt is called a mini-infobar.
> [!NOTE]
> **Note:** Users can install your web app even if it doesn't meet the [installability criteria](https://web.dev/articles/install-criteria) in Chrome. Check out [How Chrome helps users install the apps they value](https://developer.chrome.com/blog/how_chrome_helps_users_install_the_apps_they_value#manual_installation_of_any_app)
While that may be enough for some experiences, if your goal is to drive
installations of your PWA, we highly recommend you listen for the
[`BeforeInstallPromptEvent`](https://developer.mozilla.org/docs/Web/API/BeforeInstallPromptEvent),
and follow the [patterns to promote the installation](https://web.dev/articles/promote-install)
of your PWA.
## Prevent your PWA from cannibalizing your platform-specific app install rate
In some cases, you may choose to promote the installation of your
platform-specific app over your PWA. However, we still recommend you provide a
mechanism to allow users to install your PWA. This fallback option makes it
possible for users who can't (or don't want to) install your platform-specific
app to get a similar, installed experience.
The first step to implement this strategy is to define a heuristic for when
you'll show the user an install promotion for your PWA.
For example, a PWA user is could be a user that has seen the install prompt for
your platform-specific app, but hasn't installed it. They may return to your
site five or more times, click the app banner, but still continued to use the
website instead.
The heuristic can be implemented in the following way:
1. Show the platform-specific app install banner.
2. If a user dismisses the banner, set a cookie with that information (such as `document.cookie = "app-install-banner=dismissed"`).
3. Use another cookie to track the number of user visits to the site (such as `document.cookie = "user-visits=1"`).
4. Write a function, such as `isPWAUser()`, that uses the information previously stored in the cookies along with the [`getInstalledRelatedApps()`](https://web.dev/articles/get-installed-related-apps) API to determine if a user is considered a PWA user.
5. When the user performs a meaningful action, call `isPWAUser()`. If the function returns true and the PWA install prompt was saved previously, you can show the PWA install button.
## Promote installation of your PWA in an app store
App store apps can be built with a number of different technologies, including
PWA techniques. In [Blending PWA into native environments](https://youtu.be/V7YX4cZ_Cto)
you can find a summary of the technologies that can be used to that end.
Apps in the store can be classified in two groups:
- **Platform-specific apps:** These apps are mostly built with platform-specific code. App size depends on the platform, but they're usually more than 10MB on Android, and 30MB on iOS. You might want to promote your platform-specific app if you don't have a PWA, or if the platform-specific app presents a more complete feature set.
- **Lightweight apps:** These apps can be built with platform-specific code, too, but they are commonly built with web technology, packaged in a platform-specific wrapper. [Full PWAs can be uploaded](https://web.dev/articles/define-install-strategy#promoting_lightweight_apps) to the store, as well. Some companies choose to provide these as "lite" experiences, and others have used this approach for their flagship (core) apps as well.
### Promote lightweight apps
According to a [Google Play study](https://medium.com/googleplaydev/shrinking-apks-growing-installs-5d3fcba23ce2),
for every 6 MB increase to an APK's size, the install conversion rate decreases
by 1%. This means that the download completion rate of an app of 10 MB could be
approximately **30% higher than an app of 100 MB.**
To address this, some companies are leveraging their PWA to provide a
lightweight version of their app in the Play Store using
[Trusted Web Activities](https://developer.chrome.com/docs/android/trusted-web-activity)
(TWA). TWAs wrap your PWA in a webview like component, and the resulting app
size is usually only a few megabytes.
Oyo, one of India's largest hospitality companies, built a
[Lite version of their app](https://web.dev/case-studies/oyo-lite-twa), and made it available
in the Play Store using a TWA. As of May 2020, the Oyo app was only 850 KB,
just 7% the size of their Android app. And once installed, it's
indistinguishable from their Android app:
OYO Lite in action.
Oyo kept both the flagship and "lite" app versions in the store, providing a
choice to their users.
#### Provide a lightweight web experience
Intuitively, users on low-end devices, might be more inclined to download
lightweight versions of apps than users on high-end phones. Therefore, if it's
possible to identify a user's device, you could prioritize the lightweight app
install banner over the heavier platform-specific app version.
On the web, it's possible to obtain device signals and approximately map them to
device categories (such as "high", "mid", or "low"). You can obtain this
information in different ways, using either JavaScript APIs or client hints.
#### Use JavaScript
With JavaScript properties, such as
[`navigator.hardwareConcurrency`](https://developer.mozilla.org/docs/Web/API/NavigatorConcurrentHardware/hardwareConcurrency),
[`navigator.deviceMemory`](https://developer.mozilla.org/docs/Web/API/Navigator/deviceMemory),
and [`navigator.connection`](https://developer.mozilla.org/docs/Web/API/Navigator/connection),
you can get information about the device CPU, memory and network status
respectively. For example:
const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';`
#### Use client hints
Device signals can be also inferred in HTTP request headers, through
[client hints](https://developer.mozilla.org/docs/Glossary/Client_hints). Here's
how you can implement the previous code for device memory with client hints.
1. Tell the browser you are interested in receiving device memory hints in
the header of the HTTP response for any first-party request:
HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory
2. You'll start receiving `Device-Memory` information in the request header of
HTTP requests:
GET /main.js HTTP/1.1
Device-Memory: 0.5
3. Use this information in your backends to store a cookie with the category of
the user's device:
app.get('/route', (req, res) => {
// Determine device category
const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';
// Set cookie
res.setCookie('Device-Category', deviceCategory);
...
});
4. Create your own logic to map this information to device categories, and show
the corresponding app install prompt on each case:
if (isDeviceMidOrLowEnd()) {
// show "Lite app" install banner or PWA A2HS prompt
} else {
// show "Core app" install banner
}
> [!NOTE]
> **Note:** In-depth techniques to map signals to device categories is out-of-scope for this guide. To learn more, read the about the [Device Memory API](https://developer.chrome.com/blog/device-memory), the [adaptive loading guide](https://dev.to/addyosmani/adaptive-loading-improving-web-performance-on-low-end-devices-1m69), and [Adapting to Users with Client Hints](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/client-hints/).
## Let users install your app, no matter the platform
The ability to have an icon in the user's home screen is one of the most
engaging features of applications. Given that historically this was only
possible for apps installed from app stores, companies might think that showing
an app store install banner would be enough to convince users to install
their experiences.
There are more options for letting users install an app, including offering
lightweight app experiences in the stores, and letting users add PWAs to the
home screen by prompting them to do it directly from the website.