One installable experience, many paths

Installation used to be exclusive to platform-specific applications. Progressive Web Apps changed that by delivering comparable integration, reliability, and standalone-window behavior through the browser. Users can now launch PWAs from the home screen, dock, taskbar, or shelf, and they feel like part of the device.

With PWAs, you can distribute your experience in two ways: directly from the browser or via an app store. Choosing between these routes, as well as competing with your own platform-specific app, demands a clear strategy. The wrong approach creates platform competition and cannibalizes your install rate from the channels that matter most.

Assessing whether your platform-specific app is the right pitch

For many users, a platform-specific app isn't the best choice. A few common blockers:

  • Storage: Installing a new app can force users to delete other content, a real problem on low-end devices.
  • Bandwidth: Large downloads are slow and costly, especially on metered or weak connections.
  • Friction: Leaving the site to visit an app store delays an action the user could complete right in the browser.
  • Update cycle: App review processes slow down iteration and experimentation, including A/B tests.

Many users will refuse the download altogether, for reasons such as not expecting to use the app often or being unwilling to spend storage and data. Analytics focused on "mobile web only" segments can reveal how large this group is. If substantial, that is a signal to offer alternative installation paths.

Choosing the PWA as your primary experience

Promoting your PWA over your platform-specific app is often the better call when the latter is missing features, hasn't been updated recently, or is poorly optimized for larger screens such as those on ChromeOS. While most browsers surface an installable icon in the address bar (desktop Chrome) or a mini-infobar (mobile) once your PWA meets the criteria, you should drive stronger adoption by listening for the BeforeInstallPromptEvent and following established installation promotion patterns.

Using the PWA as fallback

If the business model is driven by platform-specific installs, showing your PWA prompt to higher-converting web users only, is the way forward. This is referred to as PWA as fallback. The first step is defining conditions to identify when a user should see a PWA install promotion. For example: a user dismisses your platform-specific app banner, returns to the site several times, but does not install the app.

You can construct a heuristic like this:

  1. Show the platform-specific app banner.
  2. When dismissed, set a cookie: document.cookie = "app-install-banner=dismissed".
  3. Track visits with another cookie: document.cookie = "user-visits=1".
  4. Create a function like isPWAUser(), which consults these cookies and the getInstalledRelatedApps() API to make the determination.
  5. On a meaningful user action, call isPWAUser(); if the result and the previously saved PWA prompt indicate, show the PWA install button.

Looking at the app store

Installing from a store requires understanding the two broad categories of store apps:

  • Platform-specific apps: Mostly built with platform code, these are usually over 10MB on Android and over 30MB on iOS. They are the right promotion target when your primary feature set lives there, or if you don't offer a PWA.
  • Lightweight apps: Often built with web technology inside a wrapper, these can be a complete PWA uploaded to a store. Many companies present these as "lite" options, others as their core product.

Why lightweight matters

The install conversion penalty is steep: a Google Play study found that for every 6 MB added to an APK, install conversion drops by 1%. A 10 MB app, therefore, could see conversion rates up to 30% higher than a 100 MB app. To get that benefit, several companies wrap their PWA in Trusted Web Activities (TWAs) to produce lightweight store apps of only a few megabytes.

Oyo, India's large hospitality company, shipped a Lite version this way in May 2020 at just 850 KB — 7% of the size of their Android app — while providing an experience that is indistinguishable from their native app. The company kept both versions, giving users the choice.

Device-aware promotion

Users of low-end devices are more likely to download lightweight apps than high-end users. Consequently, promoting the lightweight version first when device signals indicate low-end hardware can raise install rates.

Two ways exist to acquire such signals:

JavaScript APIs

Read CPU, memory, and network status via APIs like navigator.hardwareConcurrency, navigator.deviceMemory, and navigator.connection, then adjust your install banner logic.

Client hints

Signal the server through HTTP headers:

  1. Include device memory hints in the HTTP response header for first-party requests.
  2. Read the Device-Memory value from subsequent request headers.
  3. Map this information to a device category and store it in a cookie at the backend.
  4. Use that category to present the corresponding app install prompt.

The takeaway is that installed app engagement is powerful, but achieving it no longer has to hinge on a single storefront. Combining browser-based PWA promotion, in-store lightweight offerings, and platform-specific routes lets you meet diverse user needs without competing against yourself.