By Mehdi HassanShould you build a native app, a PWA or a responsive web app first?
Most startups should build a responsive web app first, because it reaches every device through a link, ships updates instantly and costs the least to change while you're still learning what users want. Build a native app first only when the core value depends on something the web can't do well, such as background location, Bluetooth hardware or reliable daily notifications on iPhone.
A progressive web app (PWA) sits between the two: it's a web app with extra capabilities, such as being installed to the home screen, working offline and sending push notifications. It's usually a step you add once people come back regularly, not a separate product. This guide gives you a decision framework based on budget, distribution and device access. For design across all three, our mobile app design guide covers the full process.
What is the difference between a native app, a PWA and a responsive web app?
A native app is built for iOS or Android and installed from the App Store or Google Play. A responsive web app runs in the browser and adapts its layout to any screen. A PWA is a responsive web app that also registers a service worker and a web app manifest, which lets it be installed, cache content for offline use and receive push messages.
Factor | Responsive web app | PWA | Native app (or cross-platform) |
|---|---|---|---|
How users get it | A link, search, ads | A link, then optional install | App Store and Google Play |
Updates | Instant, no review | Instant, no review | Store review for each release |
Codebases | One | One | One with React Native or Flutter; two if fully native |
Offline use | Limited | Yes, with caching | Yes |
Push notifications | No | Yes; on iPhone only after install to the Home Screen | Yes, fully supported |
Hardware and background access | Basic (camera, location in use) | Basic, varies by browser | Full: background tasks, Bluetooth, health data, widgets |
Search engine visibility | Yes | Yes | Store search only |
Relative cost to build and change | Lowest | Low | Highest |
Support for web features differs between browsers, and Safari on iOS is usually the limiting case. Check MDN's documentation on progressive web apps for current capabilities before you commit to a feature that needs one.
When is a responsive web app the right first build?
A responsive web app is the right first build when your riskiest assumption is demand: whether people want this, will pay for it, or will come back. The web lets you put a working product in front of users through a link, change it daily without store review, and measure everything with standard analytics.
- B2B tools that people use at a desk first and on the phone second.
- Marketplaces and booking products where most traffic arrives from search and ads.
- AI products where the experience is mostly text, files and streaming responses. Our guide to building AI features in a web app covers the technical side.
- Anything you expect to change weekly in the first few months.
The trade-off is reach after the first visit. A browser tab is easy to forget, and on iPhone you can't send push notifications until the user installs the PWA. If retention depends on reminders, plan for that limit. We build web products in Next.js, and our comparison of Next.js vs Remix vs a Vite SPA explains how the framework choice affects speed and SEO.
When should you add PWA features?
Add PWA features once users return often enough that installing the app or using it offline makes their life easier. A PWA uses the same codebase, so the cost is a manifest, a service worker, an install prompt and some offline states, not a new product.
PWAs are a good fit for field tools used with patchy signal, internal apps you don't want in public stores, and consumer products that want an app-like icon without a store release cycle. On Android you can also publish a PWA to Google Play through a Trusted Web Activity. Apple's App Store doesn't offer an equivalent, and its review guidelines reject apps that are little more than a wrapped website.
The design work is real, though: install prompts, offline banners, sync conflicts and the empty states when cached data is stale all need screens. Treat them as part of the product rather than a technical afterthought, and keep the app fast; our web app performance checklist covers what to measure.
When do you need a native app?
You need a native app when the product's value depends on features or distribution that only the app stores and native APIs provide. If you can't describe your core experience without one of the items below, go native, or cross-platform native, from the start.
- Background location, background audio or long-running background tasks.
- Bluetooth, NFC, health data, or other hardware integrations.
- Home-screen widgets, Live Activities, watch apps or deep system integrations.
- Daily-habit products where reliable push notifications on iPhone are the retention loop.
- Audiences that discover products through app store search and charts more than through the web.
Native also has costs that founders underestimate: two store listings, review times for every release, platform-specific bugs and a slower loop for changing things. A cross-platform framework cuts the build cost, which we compare in React Native vs Flutter, but the release overhead stays.
Native app vs PWA: how do budget and distribution decide it?
Budget and distribution usually decide this faster than features do. A tight budget favors one web codebase that serves every device. A product that will be found through app store search, or whose competitors all live on the home screen, favors native despite the cost.
Your situation | Build first | Then |
|---|---|---|
Pre-product, testing demand | Landing page and waitlist | Responsive web app |
Early product, users arrive from search or sales | Responsive web app | PWA features when repeat use grows |
Daily-habit consumer app, notification-driven | Cross-platform native | Web companion for sign-up and sharing |
Hardware or background features are the product | Native (or cross-platform native) | Web for marketing and account management |
B2B tool with a mobile field component | Responsive web app | PWA for field use; native only if offline needs outgrow it |
For example, suppose you're launching a dog-walking marketplace
For example, suppose two founders are launching a dog-walking marketplace in one city. Their riskiest assumption is whether owners will book and pay strangers, not whether the app can track a walk in the background.
The cheapest path is a responsive web app: owners find it through local search and social posts, book and pay on the web, and walkers use the same app on their phones. Once repeat bookings grow, PWA install and web push help retention. Live walk tracking, which needs background location, is the point where a native walker app becomes worth the cost.
This is a hypothetical example, but the sequence, demand first, then retention, then native features, applies to most marketplaces.
Design costs follow the same pattern: one responsive design system is cheaper than two platform variants. Our guide to app design cost breaks down how scope moves the budget.
Can you move from a web app to a native app later?
Yes, and it's a common path. If you design the web app with a clean component system and a separate API, a later native or cross-platform app can reuse the design tokens, the content and the back end. What you rebuild is the interface layer and the platform-specific behavior.
The things that make the move painful are a back end tangled into page code, designs that only exist as one-off screens, and copy scattered through components. Hand off responsive specs properly from day one, as we describe in responsive design handoff, and the step to native is an addition rather than a rewrite.
