Web app vs mobile app vs PWA: which should you build?
By Matt L., Founder, Loha.dev LLC
Published
Updated
10 min read
The short answer
Build a web app first if your users work at a desk, find you through search, or you need to ship fast on a budget. Build a mobile app when the product lives on the phone: daily habits, camera, location, reliable push, or store discovery. A PWA sits in between: one web codebase that installs to the home screen, works offline, and now supports push on iOS, without store review or fees.
Founders usually ask this question too early, as a technology choice. It is really a question about your users: where they are when they need you, how they find you, and what the product has to do with their device. Answer those three and the format mostly picks itself.
Below are plain definitions, a side-by-side comparison, the cases where each option clearly wins, and the decision flow I walk clients through before we write any code.
What each option actually is
Web app
Software that runs in the browser at a URL. Think dashboards, booking tools, internal admin panels, SaaS products. Nothing to install, works on any device with a browser, and you deploy updates whenever you want. A web app is not a marketing website: it has accounts, data and workflows.
Mobile app (native or cross-platform)
An app installed from the Apple App Store or Google Play. It can be fully native (Swift for iOS, Kotlin for Android) or cross-platform (React Native/Expo, Flutter), which compiles to real native apps from one codebase. Either way, users get a store listing, an icon, full device access and dependable push notifications. If you are weighing those two approaches, see native vs cross-platform.
Progressive Web App (PWA)
A web app with extra capabilities: a manifest and a service worker let users add it to their home screen, open it full screen without browser chrome, cache it for offline use, and receive push notifications. It is still a website underneath, so it is indexed by Google and shares one codebase across every platform.
Web app vs mobile app vs PWA: side-by-side
| Factor | Web app | PWA | Mobile app |
|---|---|---|---|
| Discovery | Google search, links, ads | Google search, links, ads | App Store and Google Play search, plus your own marketing |
| Install friction | None: open a link | Low on Android (install prompt); on iOS users must tap Share, then Add to Home Screen | Store visit, download, often an account; highest friction, but the icon stays |
| Offline | Usually none | Good with a service worker cache and local storage | Best: full local database and background sync |
| Push notifications | Desktop browsers only, opt-in rates tend to be low | Android: yes. iOS/iPadOS: yes since 16.4, but only once installed to the home screen | Yes, reliable on both platforms |
| Device APIs | Camera, mic, location, files; limited | Same as web, plus some install-only features; Safari still lacks Bluetooth, NFC and most background work | Everything: Bluetooth, NFC, HealthKit, widgets, background location, biometrics |
| Payments and fees | Card processing only (often ~3% via Stripe-style processors) | Same as web | Digital goods usually require in-app purchase: 15% for small developers, up to 30% otherwise |
| SEO | Fully indexable | Fully indexable | App content is not indexed by Google; you need a separate website |
| Update speed | Instant on deploy | Instant on deploy | Store review (often a day or two); users update over days or weeks, though over-the-air JS updates help |
| Relative cost | Lowest | Low: roughly web plus 10–20% (estimate) | Highest; cross-platform cuts it substantially vs two native apps |
When a web app wins
- Users work at a desk. Admin tools, reporting, CRMs, scheduling back offices, anything with tables and long forms.
- Customers find you on Google. If acquisition depends on search, your product pages need to be crawlable, and a web app with public pages is the direct path.
- You need to learn fast. Same-day deploys mean you can fix, test and iterate without waiting for store review.
- Budget is tight. One codebase, one release process, no developer accounts or store assets.
- Usage is occasional. People book, pay or check something a few times a month. Nobody wants to install an app for that.
This is the bread and butter of our web app development work: React and TypeScript on the front end, a realtime backend, deployed to the edge so it is fast everywhere.
When a mobile app wins
- Daily or habitual use. Fitness, messaging, journaling, field work. The home-screen icon and push notifications drive retention.
- Deep device features. Bluetooth hardware, NFC, background location, HealthKit, widgets, Apple Watch, rich camera processing.
- On-the-go, unreliable connectivity. Delivery drivers, technicians, event staff who need a solid offline mode with sync.
- Trust and polish matter for conversion. For many consumer categories, being in the App Store signals legitimacy, and native gestures and performance feel noticeably better.
- Store discovery is a real channel. Some categories, like games, utilities and niche tools, get meaningful organic installs from store search.
For most clients we build mobile apps with React Native and Expo, which gives you real native apps on both platforms from one codebase. See our mobile app development page, or the platform-specific pages for iOS and Android if you only need one.
When a PWA wins
A PWA is the right answer more often than people expect, especially since iOS 16.4 added web push for home-screen web apps. It fits when:
- You want an app-like experience and offline support, but the features are standard web features.
- You sell digital subscriptions and want to avoid store commissions entirely.
- Your audience is mostly on Android, or on managed devices where you can tell people to install it.
- You want one codebase to cover desktop, tablet and phone while you validate demand.
B2B vs B2C: the patterns we see
B2B products usually start on the web. Buyers evaluate on a laptop, admins configure on a laptop, and a lot of the work is data entry and reporting. A mobile app comes later, and usually only for the role that is on the move: the field technician, the sales rep, the warehouse worker. That mobile app is often small and focused on two or three jobs.
B2C products lean mobile, with exceptions. If the product is a habit or a companion you carry, mobile wins. If it is a one-off transaction or research-heavy purchase, web wins. Marketplaces often need both: web for SEO and first purchase, an app for repeat customers.
Internal tools are the PWA sweet spot. You control the devices, you can walk staff through installing, and you skip store review for an app nobody outside the company needs to find.
Starting web-first, then going mobile
For many founders the best plan is a sequence, not a single choice. Launch a web app (or PWA), prove people use it, then add mobile apps when you know which features belong on the phone. Done right, this does not mean building everything twice.
- Put business logic in the backend and shared TypeScript modules, not in UI components. Validation, pricing rules, permissions and data models should be reusable.
- Design an API (or realtime backend) that any client can use. The web app is just the first client.
- Watch the analytics. Which features do people use on their phones? Those become the mobile app's scope.
- Build the mobile app around those jobs, not as a copy of the whole web app. A focused mobile app ships faster and reviews better.
If you want rough numbers for each step, our guide on how much it costs to build an app breaks down typical ranges for web apps, mobile apps and MVPs.
One codebase (or close to it) across web and mobile
You do not have to choose between three separate products. With a TypeScript stack, most of the work can be shared:
| Approach | What is shared | Trade-off |
|---|---|---|
| React (web) + React Native/Expo (mobile), shared packages | Types, API client, validation, business logic, state; often 50–80% of non-UI code (estimate) | Two UI layers, each tuned for its platform. Best quality, moderate extra effort. |
| Expo with React Native Web | Most screens and logic from one codebase on iOS, Android and web | Fastest to cover all three, but the web version can feel less like a native website and needs SEO work. |
| PWA only | Everything | Cheapest, but limited by browser capabilities, especially on iOS. |
| Separate native apps + web | Only the backend | Maximum platform fidelity, roughly double or triple the front-end cost. |
Our own product Star is a good example of the first approach. It runs as a tablet app that puts setlists and slides on a screen, and as a web app at app.starapp.io for working from a computer. Each interface is designed for the device it runs on.
That pattern, React on the web, Expo on mobile, shared TypeScript in the middle, is what I recommend to most teams that expect to need both eventually.
A simple decision flow
Answer these in order and stop at the first clear yes:
- Does the core feature need hardware the browser cannot reach (Bluetooth devices, NFC, background location, HealthKit, widgets)? Build a mobile app.
- Is the product used daily on the phone, and do reminders drive retention? Build a mobile app, ideally cross-platform.
- Do most users work on a computer, or do you rely on Google for acquisition? Build a web app.
- Do you want an app-like, installable experience on standard web features, or to avoid store fees on digital subscriptions? Build a PWA.
- Is it an internal tool on devices you control? A PWA, or a web app, is almost always enough.
- Still unsure? Start with a web app or PWA built on shared TypeScript, measure real usage, and add mobile when the data says so.
If you'd rather get a second opinion on your specific case, get a free app plan. You'll answer a few questions about your users and features, and I'll come back with a recommendation and a rough scope.
Mistakes that cost founders the most
- Building a mobile app for a desk workflow because "everyone has an app." Usage ends up on the website anyway.
- Assuming a PWA behaves the same on iPhone as on Android. Test install and push on real iOS devices before committing.
- Forgetting the website. Even a mobile-only product needs crawlable web pages to rank and to explain itself.
- Ignoring store fees in the business model. A 15–30% cut on digital subscriptions changes your pricing.
- Duplicating logic across clients. Every rule written twice is a future bug. Share it from day one.
Frequently asked questions
Is a PWA cheaper than a mobile app?
Usually, yes. A PWA is one web codebase that runs everywhere, so you avoid building and maintaining separate iOS and Android apps, store listings and review cycles. In our experience a PWA costs roughly the same as a web app plus a modest amount for offline and install support. The savings shrink if you later need native features and end up building a mobile app anyway.
Do PWAs support push notifications on iPhone?
Yes, since iOS and iPadOS 16.4. The catch is that push only works after the user adds the PWA to their home screen, and Safari does not show an automatic install prompt. Users must tap Share, then Add to Home Screen. Many teams add a short in-app guide to walk iPhone users through it.
Can a PWA be published on the App Store or Google Play?
On Google Play, yes: you can package a PWA as a Trusted Web Activity and publish it. Apple is stricter. A thin wrapper around a website is often rejected for lacking app-like functionality, so getting into the App Store usually means a real native or cross-platform app, for example one built with React Native and Expo.
Should a startup build a web app or a mobile app first?
Start where your users are when they need the product. If they work on a computer or find you through search, start with a web app. If the product is a daily phone habit or depends on device hardware, start mobile. When in doubt, a web app or PWA on shared TypeScript lets you learn fast and add mobile later without rewriting the core logic.
Are mobile apps better for SEO than web apps?
No. Google indexes web pages, not the content inside native apps. A web app or PWA with public pages can rank directly in search, while a mobile app relies on App Store and Google Play search plus a separate marketing website. If organic search is a key channel, you need a strong web presence regardless of what else you build.
Can I share code between my web app and mobile app?
Yes. With React on the web and React Native or Expo on mobile, you can share types, API clients, validation and business logic in common TypeScript packages, and keep platform-specific UI on each side. Expo can also target the web directly. This is how we approach products that need both, and it keeps rules consistent across every client.