PWA vs Native App: Which to Build and What Each Really Costs
A plain comparison of progressive web apps and native apps, with the money math on build cost, store fees, installs and upkeep.
Read the solo developer app playbook
One early choice can move your app budget by thousands of dollars: build a progressive web app, or build a native app. They can look almost identical on a phone, yet they differ in reach, upkeep and what they can do. This guide puts them side by side with the money math, so you can choose before you pay anyone.
What each one actually is
A progressive web app, or PWA, is a website built with standard web tools plus a few extras. A small manifest file gives it a name and an icon, and a service worker (a background script) can save files so the app still loads on a weak connection. People open it from a link, and on many devices they can add it to the home screen, where it opens in its own window.
A native app is built for one operating system with that system's own tools, typically Swift for iPhone and Kotlin for Android. It is packaged, reviewed and delivered through an app store. Because it is written for the device, it can reach almost everything the phone offers.
Performance and device access
For most business apps, such as booking, ordering, forms, catalogs and dashboards, a modern browser is fast enough that customers cannot tell the difference. Native pulls ahead when an app is heavy on graphics or animation, or has to keep working in the background. Games, augmented reality and real-time video are the classic examples. Device access splits roughly like this.
- PWAs usually handle: camera and microphone (with permission), location, sharing, saved drafts, offline reading and, on many devices, push notifications.
- Native adds: reliable Bluetooth, health and fitness data, background location tracking, home screen widgets, and watch and car integrations.
- It varies by device: iPhones have historically given web apps less freedom than Android phones, so a feature that works on one may fail on the other.
Build cost and time to market
The biggest cost driver is how many separate codebases you need. A PWA is one codebase that runs wherever there is a modern browser. Going native usually means one build for iPhone and another for Android, each with its own testing.
As a rough planning range, not a quote, native for both platforms often takes about one and a half to two times as long as a simple PWA. Payments, accounts, real-time features and custom back-end work push every path higher. To see the math, assume a hypothetical $60 an hour and a PWA that takes 300 hours.
| Path | Hours | Cost at $60 an hour |
|---|---|---|
| PWA, one codebase | 300 | $18,000 |
| Two native apps, lower estimate | 450 | $27,000 |
| Two native apps, higher estimate | 600 | $36,000 |
Those hours also set your time to market. At a full-time pace of 40 hours a week, 300 hours is about 7 to 8 weeks, and 450 to 600 hours is about 11 to 15 weeks. A PWA can then go live the moment you deploy it, while a native app waits on store review, which often takes a day or two but can stretch after a rejection. First-time account setup and identity checks can add days or weeks.
Distribution, fees and the install hurdle
App stores versus the open web
A native app lives in a store, where many people go looking for apps and where ratings build trust. The price is a review process and fees. Apple charges an annual developer fee of about $100, Google charges a smaller one-time fee, and both stores have historically taken roughly 15% to 30% of digital sales, with lower rates for smaller developers and subscriptions. Rules differ by country and keep changing, so check current terms.
A PWA is shared by link, so search engines can find its pages and no store has to approve it first. On the open web you pay a payment processor instead of a store, but you also take on the billing, refunds and sales tax paperwork that the stores mostly handle for you.
Why installs are hard to win
Every extra step loses people. Suppose, purely for illustration, each step keeps 7 of every 10. A store install takes four steps (find the listing, tap install, wait, open and sign up), which leaves 0.7 × 0.7 × 0.7 × 0.7, or about 24 of every 100 visitors. A web app with two steps (tap the link, sign up) keeps 0.7 × 0.7, or 49 of every 100.
A PWA lowers the first hurdle because people can try it in the browser right away. Installing it is less obvious, though: on iPhone it usually takes a trip through the Share menu, and push notifications there generally require the app to be on the home screen.
Updates and upkeep
A PWA updates when you deploy new files, and users typically get the new version soon after they reopen the app. There is one codebase to fix and test. Native updates go through store review, users choose when to install them, and several old versions can be in use at once.
Native apps also have to keep pace with the phone makers. New phone software arrives every year and can break things, and the stores raise their technical requirements from time to time, so an app nobody maintains slowly decays.
Whichever path you choose, budget for upkeep. As a planning assumption, set aside 10% to 20% of the build cost each year. On the $18,000 PWA that is $1,800 to $3,600 a year. On two native apps that cost $27,000 to $36,000, it is $2,700 to $7,200.
Which one should you build?
A quick decision table
| If this matters most | Lean toward | Why |
|---|---|---|
| Lowest build cost | PWA | One codebase, not two |
| Fastest first release | PWA | No store review |
| Search traffic and shareable links | PWA | It is a website |
| Frequent small updates | PWA | Deploy once, everyone gets it |
| Deep hardware and system features | Native | Direct device access |
| Heavy graphics or background work | Native | Higher performance ceiling |
| Discovery inside the app stores | Native | That is where those shoppers look |
The verdict by scenario
- A local service business or small shop, such as a salon, clinic or corner store: a PWA. Bookings, menus, catalogs and reminders cost less to build, show up in search and are easy to change.
- An internal tool for your own team: a PWA, unless it needs a device feature browsers cannot reach.
- A product where the phone hardware is the point, such as fitness tracking or Bluetooth gadgets: native.
- A game or anything graphics-heavy: native.
- Still unsure: launch a PWA to test demand, then invest in native once real numbers justify it.
These are rules of thumb, not advice for your specific business. Whatever you choose, ask each developer for a written breakdown of what the price includes, and compare at least two.
Quick answers before you decide
Can I start with a PWA and go native later?
Yes. Your design, research and back end carry over, but the front end usually gets rebuilt, so treat the PWA as a low-cost test of demand, not a shortcut.
Can a PWA be listed in an app store?
Some stores accept packaged PWAs, and Google Play has a route for them. Apple's guidelines say an app should offer more than a repackaged website, so do not count on a thin wrapper for iPhone.
Do I pay the store's cut on everything I sell?
Generally the commission applies to digital goods and subscriptions sold inside the app, not to physical goods or real-world services such as a haircut or a delivery. Rules vary and change, so read the current terms.