PWA or native app? A developer's checklist for the 'web app vs mobile app' question

Clients rarely ask "should we build a PWA or a native app?". They ask "do we need an app?", and the developer in the room has to turn that into a technical decision. This is the checklist we use when we scope that question for businesses in the USA, UK, Canada and Australia. It's written for developers and tech leads, and the business-facing version is linked at the end.

Start with usage frequency, not technology

The most useful single question is: how often will a typical user open this?

• A few times a year (quotes, renewals, one-off bookings): build for the web. Every page is indexable, nothing has to be installed, and you ship fixes the moment they merge.
• Weekly or daily (ordering, field work, fitness, banking): an installed app starts to pay for itself, because a home-screen icon, saved sessions and reliable notifications matter at that frequency.

Everything else on this list refines that first answer.

What a PWA can actually do in 2026

A progressive web app is a normal web app plus a web app manifest and usually a service worker. That gets you:

• Install to home screen with its own window and icon.
• Offline and flaky-network support through a service worker caching shell assets and data.
• Push notifications, including on iPhone. Since iOS/iPadOS 16.4, Home Screen web apps can receive Web Push. Two constraints matter in practice: the user must add the app to the Home Screen first, and the permission prompt must follow a user gesture.

A minimal manifest looks like this:

{
  "name": "Acme Field Jobs",
  "short_name": "Acme Jobs",
  "start_url": "/?source=pwa",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b5fff",
  "icons": [
    { "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

And the iOS-safe way to ask for push permission is from a click handler, never on page load:

document.querySelector('#enable-alerts').addEventListener('click', async () => {
  const permission = await Notification.requestPermission();
  if (permission !== 'granted') return;
  const reg = await navigator.serviceWorker.ready;
  const sub = await reg.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: VAPID_PUBLIC_KEY, // Uint8Array
  });
  await fetch('/api/push/subscribe', { method: 'POST', body: JSON.stringify(sub) });
});

Where the web still falls short

Every browser on iPhone runs on Apple's WebKit engine, so iOS support sets the ceiling. Check each "must-have" feature against MDN's compatibility tables before you promise it. Typical deal-breakers:

Requirement	Web / PWA	Native or cross-platform
Bluetooth devices, wearables	Web Bluetooth: Chrome/Edge only, not Safari or Firefox	Yes
Reliable background location	No	Yes (with store-policy justification)
Large offline datasets	Limited by browser storage quotas	Yes
Health data, widgets, wallet passes	No	Yes
Push on iPhone without "Add to Home Screen"	No	Yes
Camera, mic, geolocation (foreground), file upload	Yes	Yes

If any row in the "No" column is on the day-one list, you're building an app.

Don't ship a wrapped website

The tempting shortcut is a WebView shell around the existing site. Apple's App Review Guideline 4.2 (Minimum Functionality) expects more than a repackaged website, so thin wrappers risk rejection. If you go to the stores, give the app real native value: offline mode, notifications, device features or a faster task flow.

The architecture that keeps both doors open

Whatever you build first, put the business logic behind an API:

1. Backend + API first (auth, data, payments, admin).
2. Responsive web app / PWA on top. Ship, measure what people actually use.
3. Cross-platform app (Flutter or React Native) on the same API for the frequent users, when the numbers justify it.

Because the second client reuses accounts, data and rules, it costs noticeably less than the first. The mistake to avoid is business logic inside the web front end. That makes the later mobile app a rewrite.

The six questions to put in the brief

1. How often will a typical user open it: yearly, monthly, weekly?
2. Where do new users come from: search and links, or store browsing?
3. Which device features are essential on day one?
4. How critical are notifications, and on which devices?
5. What's the budget for version one, including yearly store fees (Apple's developer program is US$99 a year, Google Play a one-time US$25)?
6. Who releases updates, and how often?

"Weekly", "Bluetooth or background location" or "notifications are essential" point to a mobile app. Otherwise start on the web. If you'd like a second opinion on a scope, our mobile app development team writes up both options with estimates.

FAQ

Can a PWA be listed in the App Store? Not as a PWA. You'd need a native wrapper with real native features to pass review. Google Play accepts PWAs packaged as Trusted Web Activities.

Do iPhone web apps get push notifications? Yes, since iOS 16.4, but only after the user adds the app to the Home Screen.

Is Flutter or React Native "native enough"? For most business apps, yes. Both reach Bluetooth, background tasks and platform APIs through plugins or native modules.

Originally published on the Dzimark blog.