People arrive asking for an app. Usually they mean they want the thing on a phone, which is not the same question. Native and web are two different cost structures, two different release models and two different maintenance burdens, and the choice between them is worth more than most of the decisions that follow it.
So we run six tests. If none of them come back positive, we say so, and we build a web app instead.
The six tests
1. Does it have to work with no connection?
Not “should be resilient on a bad train connection” — genuinely offline, for a whole shift, with data captured while offline that has to survive and reconcile later. Field crews in basements. Inspectors in car parks. Anyone whose job happens where signal does not.
This is the single strongest argument for native, and it is not really about the interface. It is about owning a local database, a sync queue and a conflict-resolution policy. You can approximate some of that on the web now, and every approximation we have shipped has been more fragile than the native equivalent.
2. Does it need to do work while nobody is looking at it?
Background upload, background location, background refresh, geofencing, processing that continues after the screen locks. A web app gets suspended. A native app gets a constrained but real background execution model. If your product depends on something happening at 3am on a phone in a pocket, that is native.
3. Do push notifications matter to the business model?
Web push exists and works, with real caveats around iOS and around how many users will grant it from a browser. If a notification is a nice-to-have, that is fine. If your retention model depends on reaching people reliably, native is the safer bet and the difference is not close.
4. Does it need the device itself?
Biometric authentication, Bluetooth peripherals, NFC, the secure enclave, continuous camera work like scanning or measurement, HealthKit, CarPlay, widgets, Live Activities. Some of this has a partial web equivalent, most of it does not, and the partial ones tend to be exactly where the browser support matrix is worst.
5. Does it have to be in a store?
Sometimes the answer is commercial rather than technical. Enterprise buyers ask for an App Store listing. Consumers look there first. If distribution through the store is part of how the product gets found or trusted, that is a reason on its own — and it is an honest one, as long as everybody knows it is the reason.
6. Is the interaction latency-sensitive?
Continuous gestures, drawing, camera overlays, anything at sixty frames a second where a dropped frame is felt rather than measured. Most business software is not this. The software that is, is unmistakably so.
What happens when all six come back negative
We tell you to build a web app, and we explain what you get for it.
- One codebase instead of two. The comparison that matters is rarely native-versus-web; it is two native apps versus one web app, because iOS alone is usually not a strategy.
- Ship when you want. No review queue between finding a problem and fixing it for everybody.
- No install step. For a tool people use occasionally, the install is the funnel.
- Lower run cost. No annual platform migrations, no SDK deprecations forcing work you did not plan.
The cost difference is not subtle. Our published ranges put a web application at $25,000 to $150,000 and a native app at $40,000 to $150,000 per platform. Two platforms and you have roughly doubled the build and permanently doubled the maintenance. Those numbers, and three worked examples, are on the pricing page.
The failure mode we see most
A web view in a native shell, shipped to the store to satisfy test five, with none of the first four ever having applied. It is cheaper on day one and more expensive every day after, because it fails at exactly the moments users judge an app: offline, on a bad connection, when the keyboard appears, when a notification arrives. You now own an app store listing, a review process and a native release cycle, and you got none of the capability those things exist to deliver.
If distribution really is the only driver, there are better answers than a wrapper — and they start with being honest that the requirement is commercial rather than technical.
The part nobody budgets for
Native has a maintenance tail that web does not, and it is not optional work. Apple ships a major iOS release every year and Google ships Android on its own cadence. Every year something you depend on is deprecated, a permission model changes, a screen size arrives, or a store policy tightens and your listing needs updating to stay published.
None of that adds a feature. It is the cost of remaining shippable, it recurs annually per platform, and it lands whether or not you are actively developing. A web app has an equivalent — browsers change too — but it is smaller, it is continuous rather than annual, and nothing gets removed from a store because you did not do it in time.
When we quote a native build we quote the retainer alongside it, because a native app without one is a product with an expiry date that nobody has written down.
How this usually goes
More than half the time, someone who came asking about an app leaves with a plan for a web application and a smaller number. That is not us being modest. A product that did not need native and got it anyway is a product carrying two codebases, two release processes and two sets of platform deprecations for no gain, and it will be doing that for years.
When native is the answer, we say that too, and we build it properly: Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android, with the backend designed alongside rather than bolted on afterwards. What we will not do is let the wrapper decision get made by default, because that one is very hard to walk back.
