Mobile vs Web vs PWA in 2026: When a Browser Shell Is Enough (and When It Isn't)

Google Chrome fires `beforeinstallprompt` — and shows an in-browser install promotion — only after a site is served over HTTPS, ships a web app manifest with a name, 192px and 512px icons, a `start_url`, and a standalone-class `display` mode, and after the user has tapped once and spent at least 30 seconds on the page. That is Chrome's current installability floor, not a store listing.

Safari on iOS does not fire that event. web.dev's installation guide is explicit: there is no browser install prompt on iOS or iPadOS. Home screen web apps are added by hand through Share → Add to Home Screen. Chrome and Edge on iOS cannot install a PWA at all; the user has to open Safari. A PWA that "installs" on a Pixel is a different product from the same URL on an iPhone.

This piece is the operator decision for year-one surface — responsive web, installable PWA, or store-distributed native or cross-platform binary. It is not a stack-language essay. Flutter versus React Native versus native already priced compilers. It is not monetization models, build timelines, Austin cost and ROI, App Store rejection patterns, or the Play target API 36 clock. Those already exist. The question here is narrower: which distribution surface is load-bearing in year one, and which one you are pretending is free.

A PWA is not free native

MDN's definition is the honest one. A progressive web app is built with web platform technologies and can be installed, work offline, and integrate with the device — a website that borrowed some of an app's manners. That is not a store binary. It does not give you StoreKit, Live Activities, Home Screen widgets, or a listing a reviewer will accept as app-like if the only native thing you shipped is a webview.

The agency pitch still sells "ship a PWA, skip the stores." On Chromium, that can be a real product: an installed window, an icon, a service worker cache, and on many Android devices a silently minted WebAPK. On iOS it is a home-screen bookmark with a standalone display mode if you earned it. Apple's App Store Review Guideline 4.2 still requires features, content, and UI that elevate the binary beyond a repackaged website. Wrapping the same URL in WKWebView and submitting it as your iOS app is the trench coat rejection patterns already cover. Do not fund that as a distribution strategy.

You are buying three different contracts:

• A URL that ranks, shares, and works in any browser.
• An installable web shell that Chromium will promote and that iOS users can add by hand.
• A store binary that can take IAP, sensors, widgets, and catalog discovery — and that owes Apple and Google their upload floors.

Two install paths, not one

web.dev's installation chapter splits the world the way operators should. Desktop Chromium — Chrome and Edge on Linux, Windows, macOS, and Chromebooks — shows an install badge in the URL bar and an Install item in the browser menu. Android may show a mini-infobar or a richer dialog if you shipped `description` and `screenshots` in the manifest. iOS has none of that chrome. Safari for macOS still does not treat a site as installable the Chromium way; macOS Sonoma's Add to Dock is a separate, File-menu path.

The Chromium path is programmable. When the site meets the criteria, the browser fires `beforeinstallprompt`. You capture it, hide the default mini-infobar, and call `prompt()` from your own button after a journey that actually earned the ask — checkout, save, subscribe. web.dev's prompt guide is clear about the limits: you can call `prompt()` once per event; if the user dismisses it you wait for the event to fire again; Chrome and Edge on iOS never fire it. If the event never arrives, there is no other API that pops the OS install sheet. MDN marks the event experimental and non-standard. Treat it as a Chromium convenience, not a web platform guarantee.

The iOS path is a tutorial. web.dev documents the four gestures: open the Share menu, tap Add to Home Screen, confirm the name, tap Add. Apple's archived Configuring Web Applications notes still describe the Web Clip: `apple-touch-icon`, `apple-mobile-web-app-capable`, standalone chrome without Safari's URL bar. Safari Services is the current framework home for the browser-integration APIs around that world. WWDC23 What's new in web apps is the current product statement: a site added to the Home Screen becomes a Home Screen web app only if the manifest `display` is `standalone` or `fullscreen`. Otherwise it is a bookmark that opens in the default browser. Cookies and storage are isolated from Safari after install. Web Push and badging on iOS require that standalone mode.

MDN's installability guide adds the split that still matters in 2026: on iOS 16.4 and later, Add to Home Screen is available from Safari, Chrome, Edge, Firefox, and Orion — still as a Share-menu gesture, not as `beforeinstallprompt`. Third-party browsers can offer the sheet. They cannot mint a programmable prompt. WebKit's 16.4 note is the same fact from Apple's side: a `WKWebView` in a browser with the web-browser entitlement can include Add to Home Screen in the share sheet. The user still has to tap it.

Price install friction as a product line, not a CSS ticket:

• Chromium users who meet the heuristics can be asked in-product.
• iOS users have to be taught a Share-sheet dance, and you cannot trigger it.
• A store listing replaces both with search, ratings, and an OS install sheet — at the cost of review, IAP rules, and a binary you keep current.

Android can mint a WebAPK. iOS cannot list a PWA

On Android, Chrome on devices with Google Mobile Services mints a WebAPK — a signed APK produced by a trusted minting server, installed silently, visible in Settings → Apps, able to badge, shortcut, and capture links. Samsung Internet does the same on Samsung hardware. Firefox, Edge, Opera, Brave, and Samsung-on-non-Samsung fall back to a badged home-screen shortcut with none of those capabilities. You do not build or sign that package. The browser does. Fail the mint and you still have a shortcut. You do not have a store listing.

If you want a Play listing for the same web app, that is a different artifact. Trusted Web Activity opens your origin fullscreen from an Android app, verified both ways with Digital Asset Links. Chrome 72 and later. Content must be useful in the browser first. The host app does not get cookies or `localStorage`. The integration guide is the current packaging path; Bubblewrap generates the project. Play Billing inside a TWA is available through the Digital Goods API and Payment Request on Chrome 101 and later — and Google is explicit: if you sell digital goods through Play, you must use Play Billing. The web app still has to be freely reachable on the open web. A paid APK that only exists in Play is the wrong shape for a TWA.

iOS has no equivalent mint. There is no WebAPK. There is no "publish this origin to the App Store as a PWA." web.dev lists WKWebView plus App-Bound Domains as the catalog path, then warns that stores have their own technical and business requirements. Guideline 4.2 is the business requirement that kills the trench coat: your app should include features, content, and UI that elevate it beyond a repackaged website. Other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. If the store listing is the product — discovery, ratings, IAP, TestFlight — you are funding a binary. If the URL is the product, stay on the web and stop paying review to re-skin a browser.

Choose by load-bearing capabilities

Do not pick a surface by "we need an app." Pick it by the capabilities that fail the product if they are missing. web.dev's capabilities chapter is the right inventory: check for the API before you bet the roadmap on it. Mature APIs — geolocation, getUserMedia, Cache, service workers — work across browsers when the hardware exists. Web Bluetooth, Web NFC, background sync, and File System Access are Chromium-heavy. If the core loop needs a red-or-missing API, you are already in a store-binary conversation.

Push and background. Chromium PWAs can use the Push API from a service worker. On Apple platforms, Web Push for Home Screen web apps shipped in iOS and iPadOS 16.4 — standards-based Push, Notifications, and service workers, using the same Apple Push Notification service that powers native apps, no Apple Developer Program membership required, permission only after a user gesture, Focus-aware. Safari in a tab is not that surface. The web app has to be on the Home Screen in standalone. Declarative Web Push — iOS and iPadOS 18.4 and later, walked in WWDC25 session 235 — lets the payload describe the notification so Intelligent Tracking Prevention can evict the service worker without killing delivery. That is a real reliability fix. It is still not silent background work, not a Live Activity, and not a widget. If the product is lock-screen presence, you left the web.

Hardware. getUserMedia covers camera and microphone in a page. Continuous BLE, NFC session work, background location, and HealthKit-class sensors are where PWAs stall and store binaries start. A QR scan in a tab is a web feature. A warehouse scanner that must stay connected to a BLE printer in the pocket is not. If the core loop is a sensor, do not prototype yourself into a PWA and discover the gap in month five.

Store discovery and IAP. Monetization already covered receipts and entitlements. The surface implication: web checkout is a URL. Store IAP is a binary plus StoreKit or Play Billing. A TWA can reach Play Billing. A home-screen web app on iOS cannot take App Store IAP. If year-one revenue is digital goods inside Apple's catalog, you are funding a store shell. If year-one revenue is a card on your own checkout page, the store is optional.

Offline reliability. Service workers plus Cache and IndexedDB are the PWA offline story. They are excellent for repeat visits and form drafts. They are not a promise that iOS will keep your worker alive. Intelligent Tracking Prevention deletes site data for origins the user has not visited. Home Screen web apps and declarative push reduce that pain. They do not eliminate it. If the field tool must open in a warehouse with no radio and a cold cache, test that device — or ship a binary with its own storage budget.

Install friction, SEO, and shareable URLs. Covered above, and they pull in opposite directions. A store binary can deep-link; it cannot be the thing Google indexes as the page. If acquisition is search, ads, and shared links, the web surface is not optional. It is the front door. The PWA or the store app is a second door for people who already converted.

Three honest year-one shapes

Content and commerce browse. Default to responsive web. Catalog, article, marketing site, most checkout. Install is a nice-to-have, not the product. Spend the money on Core Web Vitals, structured data, and the payment page — not on a manifest you will never promote. If someone bookmarks you, fine. Do not staff an "install campaign" for a brochure.

Engaged utility with Chromium-heavy users. Default to an installable PWA. Field tools, internal dashboards, Android-first consumer utilities, desktop-plus-Android. Fund the manifest, the service worker, the `beforeinstallprompt` journey, and an iOS Share-sheet tutorial you will measure. Do not promise native install rates on iPhone. Do not tell the board the PWA "is on the App Store" because a contractor wrapped it.

Store billing, Live Activities or widgets, sensors, or iOS-first distribution. Default to a store binary — native or cross-platform, chosen against surfaces, not slogans. The web can still be the marketing and legal URL. It is not the app. The expensive lie is funding the PWA as if it were a cheaper iOS listing, then discovering Guideline 4.2 in week twelve.

Budget three distribution lines

Same rigor as the stack-cost piece, different ledger. That article split shared UI, native modules, and OS surfaces. This one splits the doors people actually walk through. Price three lines, not one "app" row.

• Web surface. The URL, the design system, the API, the SEO. Every product in this article pays this line. Skipping it to "go straight to the store" is how you fail Guideline 4.2 and also fail ads.
• Installable shell. Manifest, icons, service worker, install UX, iOS fallback copy. Add a WebAPK-quality origin if Chromium users are the product. Add a TWA only if you need a Play listing for that same origin.
• Store binary. Compilers, review, IAP, widgets, sensors, the Play API 36 upload floor, and Apple's current SDK gate. This line does not get cheaper because you already have a PWA. It is a second product that happens to share a backend.

The Austin ROI piece is about whether an app is the right spend. This is about which surface that spend buys. A PWA quote that hides the iOS Share-sheet work inside "mobile web" is the same lie as a Flutter quote that hides native modules inside "one codebase." Make the three lines visible, then decide which ones you are funding this year.

When the capability gap appears, stop patching the web

The expensive pattern is sequential denial. You ship the responsive site. Someone asks for an icon. You add a manifest. Android looks "installed." An iOS user never finds Share. You wrap the origin in a TWA for Play. A contractor wraps the same origin in WKWebView for the App Store. Guideline 4.2 rejects it. You then discover the BLE printer, the Live Activity, or the IAP SKU that was the actual product. Each workaround is a month. Build timelines already priced honest QA. They did not price a year of polyfills for APIs the browser vendors have not shipped.

A shop that quotes "we'll do a PWA and add the app later" without naming the iOS install path, the IAP surface, and the one sensor that is not on the web is selling a template. Ask which of those three they have already tested on an iPhone that did not come from the Android QA pile. If they cannot answer, they have not priced the surface.

Next steps: pick the surface before you fund compilers

Bring that list to the estimate — capabilities, iOS versus Android mix, and whether IAP or lock-screen presence is year-one — not a slide that says "mobile app" as if it were one row. We will tell you whether a browser shell is enough, and what the store binary will cost if it is not.

If the product conversation is still open, start with what the first year actually costs and how long a build takes when the stack is honest. Then pick the surface. Compilers come after.