PWA vs native app: which should you build?

1. Start with the disqualifying constraint

Decide from the critical user journey, not from a list of features a browser supports somewhere. Write down the operating systems, browser versions, and device types you will actually support.

The useful question is which capabilities must work on those exact devices. “Available on the web” is not the same as “available everywhere you support.”

2. Decide how users arrive

A progressive web app is useful when acquisition starts with a search result, an advert, an email, or a shared link. The first visit is a normal web page, and the person can use the link before installing anything.

Native makes more sense when store presence is part of distribution or users already expect to install before doing anything. A store listing and a crawlable website solve different discovery problems. Many native products still need a website.

3. Check the critical device capability

Write down the one device feature the journey cannot lose. Examples include Bluetooth hardware, NFC behavior, background location, a share extension, or high-performance graphics.

Check the browser compatibility table for that API on every supported operating system. If a required capability is absent or restricted on one important platform, native—or a native shell around shared code—is the safer choice.

4. Define offline behavior separately

A service worker can intercept requests and choose a cached or network response. That can provide an offline page, cached content, and queued work, but it is code you design. A native app can still fail when its server is unavailable.

web.dev’s service-worker guide says to treat the worker as optional because it does not control the first load and can be unavailable. Define what users may read or edit offline, how conflicts resolve, and what the screen says while data is stale.

Cache an offline explanation before caching a complicated write workflow. For writes, keep a local identifier, show pending state, retry safely, and resolve conflicts when the same record changed on the server.

5. Separate installation from notifications

Chrome’s current install-promotion criteria require HTTPS, user engagement, and a manifest. The manifest needs a name or short name, 192px and 512px icons, a start URL, and a display mode of fullscreen, standalone, minimal-ui, or window-controls-overlay. prefer_related_applications must be absent or false.

Chrome’s engagement heuristic requires at least one click or tap and at least 30 seconds viewing the page, including during an earlier visit. A service worker is no longer one of Chrome’s install-promotion criteria. It remains the mechanism for offline handling and Web Push. Other browsers have their own install rules.

Do not make a custom Install button the only route into the product. Users can still install some web apps when the promotion criteria are not met, and browser prompts differ.

{
  "name": "Field Service Portal",
  "short_name": "Service",
  "start_url": "/app/",
  "display": "standalone",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

6. Test the iPhone Home Screen app

Apple supports standards-based Web Push for Home Screen web apps on iOS and iPadOS 16.4 or later, and for webpages in Safari 16 on macOS 13 or later. Apple’s Web Push documentation says no Apple Developer Program membership is required.

Permission must follow a user gesture, such as a tap, and the subscription call should run from that gesture’s event handler. A service worker receives the push. Safari does not support invisible pushes: the worker must present a visible notification immediately, or Safari can revoke permission.

Test the installed Home Screen experience. A Safari tab on iPhone is not the same context, and Apple’s developer forum states that Web Push is not supported inside Safari on iOS.

7. Compare the whole maintenance path

A progressive web app lets one web deployment update the product, but one codebase does not mean one test. Browsers and operating systems still differ.

Native adds store review, signing, platform releases, and often separate interface work, while providing the platform’s full application model. Compare builds, analytics, crash reporting, accessibility, releases, and support—not only the first development estimate.

A straightforward cross-platform workflow may need less duplicated interface work. Complex offline synchronization, browser workarounds, or a missing critical API can remove that advantage. Estimate the required behavior, not the label.

8. Frequently asked questions

9. Related articles and next steps

Test the browsers, devices, offline behavior, and notifications your users need before choosing an app architecture.

Continue learning

• Software and app development
• Webhooks vs polling
• Deploy a static site to Cloudflare Workers