Native App, Web App, or PWA? How to Choose Without Wasting Your Budget

The $40,000 Word: "App"

A client tells me they want "an app." I have learned to stop and ask a follow-up question before writing a single line of a proposal, because that one word hides three completely different products with three completely different price tags: a native app built for the App Store and Google Play, a responsive web app that lives at a URL, and a Progressive Web App (PWA) that tries to split the difference. Pick the wrong one and you either overspend by tens of thousands of dollars building something your customers never install, or you underspend and ship something that cannot do what your business actually needs.

I have built all three types for clients ranging from local service businesses to fintech platforms, and the decision almost never comes down to which technology is "best." It comes down to what your users actually do, how often they do it, and whether you can survive without the features you are tempted to add just because they sound impressive in a sales deck.

Three Products, Not One Spectrum

Native apps are built specifically for iOS (Swift/SwiftUI) or Android (Kotlin), or for both at once using a cross-platform framework like React Native or Flutter. They live in the App Store and Google Play, get full access to the device's camera, GPS, Bluetooth, and background processing, and generally feel the smoothest to use.

Web apps run in a browser at a URL, work on any device instantly, require no download, and update the moment you deploy — no waiting on anyone's approval. If you already have a responsive site, I have written about the underlying trade-offs in responsive web design, which is the foundation every good web app is built on.

PWAs are web apps enhanced with a service worker and a manifest file, letting them be "installed" to a home screen, cache assets for offline use, and in some cases send push notifications. On Android, this experience is close to native. On iOS, it is a compromise — and a shrinking one, as I will get into below.

Cost: Where the Budget Actually Goes

This is usually the deciding factor, and the numbers are not close. A single native app (iOS or Android) with a real feature set typically runs $30,000–$80,000 for an MVP, and building for both platforms separately roughly doubles that. Cross-platform frameworks like React Native or Flutter narrow the gap — I have seen total cost reductions of 30–40% compared to two fully separate native codebases — but you still pay for app store submission cycles, device testing, and ongoing OS-version maintenance twice a year when Apple and Google ship updates.

A web app or PWA, by contrast, is one codebase, one deployment pipeline, and no App Store review queue. For an SMB with a limited budget, this is often the entire argument. I would rather see a client spend on a fast, well-built web app — with the kind of front-end performance work I cover in Core Web Vitals optimization — than stretch a shoestring budget across two native platforms and end up with a mediocre version of each.

Reach and Distribution

Native apps depend on app store discovery, which means competing for search ranking inside the App Store or Play Store, plus Apple's review process, which can add days of back-and-forth if your app touches payments, health data, or anything with ambiguous guideline language. A rejected build is a lost week, sometimes more.

Web apps and PWAs are reachable the moment someone clicks a link — from Google search, a text message, an email, or a QR code on a flyer. There is no install friction and no gatekeeper. If your growth strategy depends on organic search or word-of-mouth link sharing, this matters more than most business owners initially realize.

Offline Access and Device Features

Here is where I have to be direct about a limitation that catches people off guard: PWAs on iOS are still second-class citizens. Apple requires users to manually add a PWA to their home screen through the Share menu — there is no install prompt like on Android — and in the European Union, Apple has restricted standalone PWA behavior further under the Digital Markets Act, meaning some PWAs in the EU simply open as browser tabs. Offline support through service workers works reasonably well for caching pages and static assets, but it is not a substitute for the deep background sync and unrestricted local storage a native app gets.

If your product genuinely needs reliable offline data entry (a field service crew logging jobs with no signal, for example), native is usually the safer bet. If offline support just means "the page should not break on a spotty hotel Wi-Fi," a PWA handles that fine.

Push Notifications: The Feature Everyone Assumes They Need

Every client asks about push notifications, and few actually need them. Native apps get full push capability on both platforms, no caveats. PWAs get push notifications on Android without much friction, but on iOS it only works for PWAs installed to the home screen on iOS 16.4 and later — a tab open in Safari does not count, and the realistic audience you can reach this way is a fraction of what a native app achieves, once you account for how few users complete the manual install step. If push notifications are central to your engagement strategy and a meaningful share of your users are on iPhones, budget for native or accept a materially smaller reach on iOS.

A Simple Framework

A Real Scenario

A regional home-services client came to me wanting "an app" for scheduling and technician dispatch. Their actual requirement was simpler than they thought: customers needed to book appointments and get reminders, and technicians needed a mobile-friendly view of their day's jobs. Neither group needed offline data entry or camera access beyond uploading a photo, which any modern browser handles fine. We built a responsive web app with a PWA layer for the technician side, so it could be added to their home screen and send Android push reminders. Total build cost was a fraction of what two native apps would have run, and it shipped in weeks, not months.

The Bottom Line

Do not start with the technology. Start with what your users need to do, how often, and whether they will tolerate a browser tab instead of an app icon. In most SMB and B2B scenarios I encounter, a well-built web app or PWA delivers 90% of the experience at a fraction of the cost and none of the app store friction. Native earns its cost when your product genuinely depends on deep device integration, offline reliability, or push reach on iPhones specifically — not because "app" sounds more serious than "website."

If you are trying to figure out which of these fits your situation, Let's talk through your situation.