Most businesses quoted for a native app are buying something bigger than the problem requires. But not all of them, there are real cases where a progressive web app can't do the job, and a firm that tells you otherwise is selling rather than advising. Five questions will tell you which side you're on.
Answer all five to see your verdict.
We build progressive web apps. We don't build native apps. That's why the first three questions send you elsewhere, we'd rather you knew now.
A progressive web app is a website built so it behaves like an app. Your team opens a link once, taps "add to home screen," and from then on it has an icon, opens full-screen without browser chrome, works when there's no signal, and can send notifications.
There's no download, no store approval, no review queue, and no separate build for iPhone and Android. When you ship a change, everyone has it the next time they open it, no update to push, no fragmented versions in the field.
What it isn't: a way to get into the App Store, or a way to reach hardware the browser can't. Those two limits are real, they're where the decision above comes from, and the rest of this page is honest about them.
Most pages selling PWAs skip this. It's the most useful section on the page.
There's no listing, no store search, no reviews, no “featured” placement. If people find your product by browsing a store, a PWA doesn't participate in that at all. For internal tools, client portals, and field apps this is irrelevant, you send a link. For a consumer product it can be the entire distribution model, and no amount of technical capability substitutes for it.
Bluetooth peripherals, NFC payments, background location tracking while the app is closed, and fine-grained camera or sensor control are limited or unavailable in a browser. Barcode scanning via the camera works well. A dedicated Bluetooth scanner usually doesn't. If your workflow depends on specific hardware, tell us on the first call, it's the most common reason we say “you need native.”
Apple has narrowed the gap considerably and modern iPhones handle installed web apps, offline storage, and push notifications for home-screen apps. But iOS still lags on capability and on how obvious installation is to a non-technical user. There's also a regional wrinkle: Apple restricted standalone PWA behaviour for EU users in 2024 to comply with the Digital Markets Act, so installed web apps in EU countries currently open in a Safari tab rather than full-screen, without push, with no confirmed reversal as of writing. The precise state of all of this changes with each iOS release and each regulatory decision, we check it against your actual requirements and your users' location before quoting rather than working from what was true last year.
“Add to home screen” isn't obvious to most people, and on iOS it's a menu item rather than a prompt. For a known audience this is solved with one instruction in an onboarding email. For the general public it's real friction, and it's another reason PWAs suit known audiences better than consumer launches.
If any of these are dealbreakers, you want a native app and you want a mobile specialist. We'd rather tell you that in the first ten minutes than take a project we'd deliver badly.
Technicians, installers, inspectors, drivers, and site staff filling in paper forms or phoning things back to the office. Jobs, checklists, photos, signatures, and offline capture that syncs when there's signal again. No store approval means a fix ships the same day it's reported, which matters more in the field than anywhere else.
Typical buyer: an operations manager who has been quoted for a native app and can't justify it.
Approvals, stock lookups, time entry, quick record updates. Your team already has laptop access; they just need the phone version to not be miserable. A separate native app for this is almost always overkill. See internal business tools.
Typical buyer: a team already building an internal tool who assumed mobile meant a second project.
Your clients aren't going to install an app to check an invoice. They'll open a link. A portal that works properly on a phone gets used; one that requires a download doesn't get installed in the first place. See client portals.
Typical buyer: anyone who has watched a client-facing app sit at 4% adoption.
One codebase, one deployment, works everywhere. The moment your users span phones and laptops, building two native apps plus a web version stops making sense, you're maintaining three things that do the same job.
Typical buyer: a business where the same person uses the system at a desk and in the van.
Worth checking before any of this: if the goal is that people are told something rather than look something up, you may not need an app at all. A well-built notification from workflow automation is cheaper than every option on this page.
Six things that separate a PWA people actually use from a website with an icon.
What happens with no signal is decided per screen at the start, what's cached, what queues, what's simply unavailable. Retrofitting offline is close to a rebuild, so it's settled before anything is built.
Two people edit the same record offline. One reconnects first. What should happen? A real answer agreed with you in advance, rather than whoever syncs last silently winning.
Field apps get used standing up, in gloves, in sunlight, on a cracked screen. Large targets, high contrast, minimal typing. This is the difference between adoption and a team going back to paper.
Your field team doesn't have this year's flagship on 5G. Performance budgets are set for the worst device and connection in the fleet, not the best.
A guided prompt, clear instructions per platform, and an onboarding message people actually follow. The best PWA nobody installed is worth nothing.
Push where the platform supports it for installed apps, sensible fallbacks where it doesn't, and honesty about the difference rather than a promise that quietly doesn't hold on some devices.
The stack, process, pricing, and what you receive on handover are all the same as any other build, see web applications for the full picture.
| Progressive web app | Native app | |
|---|---|---|
| Time to build | Weeks | Typically several months |
| Cost | One build | Usually two builds, iOS and Android |
| Updates | Instant, no review | Store review, and users must update |
| App Store presence | None | Yes, and it's the point for consumer products |
| Discovery via store search | None | Yes |
| Works offline | Yes, when designed for it | Yes |
| Camera and photos | Yes | Yes, with finer control |
| Bluetooth, NFC, background location | Limited or unavailable | Full access |
| Push notifications | Supported for installed apps; varies by platform | Fully supported everywhere |
| Performance ceiling | High, and enough for most business apps | Higher, the right call for heavy graphics |
| Works on desktop too | Yes, same build | No, separate work |
| Installation | Add to home screen, needs a nudge | Store download, familiar to everyone |
| Ongoing maintenance | One codebase | Two, plus store compliance |
The honest summary: for internal tools, field apps, portals, and B2B software with a known audience, a PWA does the job at a fraction of the cost and ships in a fraction of the time. For consumer products that live or die on store discovery, and for anything needing deep hardware access, native is the right answer and we'll tell you so.
No, though the line is blurry. A responsive website adapts its layout to a phone. A PWA additionally installs to the home screen, opens without browser chrome, works offline, and can send notifications. The difference is whether it behaves like software your team opens daily or like a page they visit.
Yes, for the most part. Modern iOS supports installed web apps, offline storage, and push notifications for apps added to the home screen. Capability still trails Android in places, Apple changes this with each release, and EU users specifically have been restricted to Safari-tab behaviour without push since 2024 under the Digital Markets Act, with no confirmed reversal as of writing. We check the current state against your specific requirements, and your users' location, before quoting rather than working from what was true a year ago.
Yes, when it's designed for it from the start. Data is cached for reading and changes queue locally until there's signal. What's available offline is decided screen by screen at the start, because retrofitting it later is close to a rebuild.
Yes, camera-based barcode and QR scanning works well and is one of the most common requirements we build. Dedicated Bluetooth scanner hardware usually doesn't work in a browser, so if your team uses one, say so early.
Not as a PWA. There are wrapper approaches that submit a web app as a store listing, and they sit in an awkward middle ground, store review still applies, Apple has historically been unenthusiastic about thin wrappers, and you lose the instant-update advantage. If store presence genuinely matters, build native.
Substantially, and the reason is structural rather than a discount: one codebase instead of two, no store submission process, and no ongoing compliance with two sets of platform requirements. The maintenance difference compounds every year and is usually larger than the build difference.
Building the PWA first is often the cheapest way to find out whether you do. You'll have real usage data, a validated feature set, and an API a native app can be built against. Plenty of teams discover the native version was never needed; the ones who do need it arrive at it with far better information.
No. We build progressive web apps and web applications, and we'll tell you honestly when your requirement needs native so you can find a specialist. Taking a native project we'd deliver badly helps nobody.
Similar to any web application of comparable scope, the PWA characteristics themselves add relatively little. Offline capability is the main variable, since it affects architecture rather than being a setting. Web applications has the timelines and pricing.
You do, repository from day one, full transfer on final payment, running in your own accounts. Same terms as every build we do.
If the decision tool pointed you toward a PWA, the next thing to read is how we build web applications, process, stack, pricing, and exactly what you receive on handover.
