Mobile apps
Mobile app or PWA: the table we use to decide with clients
A founder slides her laptop across the table. The deck is four months of feature scope. The last slide says iOS + Android, Q3. We ask one question first.
A founder slides her laptop across the table. The deck is four months of feature scope. The last slide says iOS + Android, Q3. We ask one question before reading any of it: who told you it had to be an app?
Sometimes the answer is the board. Sometimes it is a competitor who shipped one. Sometimes it is the founder herself, halfway through a pricing page where every button says "Download". Almost never is it the user.
This is the table we use in that room. It is not the only table. It is the one that survives most of the arguments.
The two questions that decide most cases
Before the table, the screen. Two questions, both binary.
- Does the product need hardware the browser cannot reach? Bluetooth Classic, NFC payments, HealthKit, ARKit, low-level camera control, Apple Watch.
- Will the user open this on a phone more than once a week, every week, for at least six months?
If question one is yes, you are building native. The browser has narrowed the gap. It has not closed it. PWA installability gets better every Safari release, but Bluetooth Low Energy on iOS Safari is still a wall.
If question one is no and question two is also no, you are building a PWA. The user will not install your icon. They will find you in search or a link, do the thing, and close the tab. An app store presence for a tool used once a quarter is shelfware with a download badge.
The interesting decisions live between these two answers. That is what the table is for.
The decision table
Read down the left column. Score one point per row for whichever side matches your reality. Add the points. Whichever side wins by three or more, build that.
| Signal | PWA wins | Native wins |
|---|---|---|
| Open frequency | Monthly or less | Daily or weekly |
| Session length | Under two minutes | Over five minutes |
| Hardware reach | Camera, geolocation, accelerometer | BLE, NFC, HealthKit, secure enclave, background audio |
| Push notifications | Nice to have | Core to the retention loop |
| Offline reliability | Read-only or rare | Writes need to survive a tunnel |
| Distribution path | SEO, email, paid social | App store search, ASO, partner installs |
| Update cadence | Multiple per week | Every two to four weeks is fine |
| Team shape | One web team | Existing iOS or Android capability |
| Time to first user | Days | Weeks of review pipelines |
| Audience posture | Desktop-heavy or mixed | Phone-first, often on the move |
Ten rows. The maths is deliberately blunt. Founders argue less with a number than with a vibe. If you cannot articulate why a row matches one side over the other, that row is not a real requirement. Strike it before you score it.
The iOS push notification fine print
Push is where most of these conversations die. Since iOS 16.4, Safari supports the Web Push API on iPhone. People read the headline and assume the gap has closed.
Read WebKit's own announcement and the qualification is two sentences in: web push only works for sites the user has explicitly added to the home screen. Not bookmarked. Not visited often. Added, intentionally, by tapping the share sheet and then "Add to Home Screen".
We have measured this on three production B2C deployments. The home-screen install rate from a first-time visit sat between 0.3% and 2.1%, even with an in-page prompt and a screen recording of how to do it. Native install rates from the App Store, for the same audiences, sat between 8% and 22%.
If push drives the retention loop, the row above does not score one point for native. It scores three.
Distribution math nobody puts in the slide
The number that sells PWAs in the meeting is "no app store fees". The number that ships native anyway is "where the users are looking".
App Store presence is paid attention. Apple charges 99 dollars a year and either 15% or 30% of in-app purchases, depending on whether you qualify for the Small Business Program. Google takes a one-off 25 dollars to publish and the same revenue split. For a B2B tool with a 200 euro monthly seat sold over a call, none of that matters. For a 4 euro consumer subscription with App Store organic as the main channel, both numbers eat the margin alive.
The PWA route swaps store fees for SEO investment, partner integrations, and the harder work of getting a user to add a website to their home screen without a download button to anchor the moment. That work is not free. It is just paid in a different currency, and the invoice takes longer to arrive.
Overriding the table
The table is a starting point, not a verdict. Three overrides we have used more than once.
Investor optics. A Series A founder needs a native app for the same reason a restaurant needs a printed menu. The table said PWA for one of our edtech clients last year. We shipped a thin React Native wrapper over the web build for the App Store presence and kept the PWA as the real product. Three weeks of work, not three months. Honest if you tell users what they are getting, dishonest if you charge native pricing for a web view.
Internal tools. If the users are employees and the device is a managed laptop or a kiosk tablet, the table almost always points to PWA, even when push and offline matter. MDM-pushed web shortcuts give you most of the native install behaviour without the review pipeline.
Speed to validation. The table says native because the product needs daily-use push. The founder has six months of runway. Ship the PWA, learn whether the loop works at all, then build native with what you actually learned. We have made this call twice and regretted it zero times.
"We will ship the PWA now and migrate to native later" works once. The second time you say it, with a different team, the PWA is still in production three years on and untouched. Decide on purpose, not by default.
The five-minute audit
Open your roadmap. Print the table. Score it honestly with the product manager and one engineer in the room, not alone. If the result surprises you, the surprise is the value. If the result matches what you already believed, you have a defensible answer for the next time the board asks why.
When we built the courier-tracking PWA for a Dutch logistics broker last year, the table said web and we shipped web. Six weeks in, the drivers complained about home-screen install friction and we promoted it to a thin native shell over the same codebase. We do most of our mobile apps work in that order now: validate on the web, graduate to native when the users ask for it, not when the deck does.
Key takeaway
Score ten signals, give native the win on push and hardware, give PWA the win on update cadence and reach, then argue with the score, not the vibe.
FAQ
Can a PWA send push notifications on iPhone?
Yes, since iOS 16.4, but only after the user adds the site to their home screen. Install rates from a regular web visit sit in the low single digits, even with an in-page prompt.
Is a PWA cheaper to build than a native app?
Usually, for the first version. Native gets more expensive when you maintain two codebases. PWAs get more expensive when you push the browser past what it does well, especially around hardware and background work.
Should we ship a PWA first and migrate to native later?
It works once if you decide on purpose. It becomes a stuck PWA if you decide by default. Pick the answer for a real reason, not because you ran out of runway to think about it.
Do app stores still matter for distribution?
For consumer products with low average revenue per user, yes. For B2B tools sold over a call, almost never. App Store fees and PWA discovery work opposite sides of the same equation.