Custom Native App vs PWA: An Honest Build Decision

Custom native app or PWA: what you are actually deciding

The choice is rarely about which technology is better in the abstract. Both ship real products used by millions of people every day, and both are the right call for someone. The decision is about where your product does its hardest work: inside the browser sandbox that a progressive web app lives in, or inside the native runtime a custom mobile app gets. Match that correctly and either path succeeds. Match it wrong and you either overpay for native capabilities you never touch, or you hit a wall in the browser that no amount of clever code will get you past.

A PWA fits teams whose product is mostly content, forms, dashboards, commerce, or a SaaS front end that people reach through a link and occasionally install to the home screen. A custom native app fits products where the phone hardware is the product itself: continuous location, camera pipelines, offline data capture in the field, tight animation, health data, or a store presence customers expect before they will trust you with money. Most buyers who say "we need an app" actually need the first one and quote the second one. This guide is written to help you tell which you are.

Where a PWA wins

A PWA earns its place by removing whole categories of cost and delay, and it does this honestly, not as a compromise.

• Speed to launch. One codebase serves iOS, Android, desktop, and the open web. You are not staffing two native teams, writing the same screen twice, or running duplicated QA. Focused PWAs reach real users in weeks, not quarters.
• No app store gate. Ship a fix at 2pm and every user has it minutes later. There is no review queue, no rejection over a metadata technicality, and no waiting on Apple or Google to approve a hotfix while your users sit on a broken build.
• Lower build and maintenance cost. One codebase means one thing to patch, one dependency tree to keep current, and no second platform to chase through every OS release.
• Distribution by URL. A PWA is shareable, indexable, and installable with no download friction. For products people use a few times a month, that first tap from a search result or a shared link beats a 60 megabyte install every time.
• Payments without the store cut. A web checkout can process payments without the app store commission on digital goods, which matters a great deal once volume is real.

Concrete cases where a PWA is simply the correct answer: an internal operations tool for a field team, a booking or ordering front end, a media or news product, a B2B dashboard, or an early product that needs to be in users' hands fast so you can learn. In all of these, a native app would be spend without a return.

Where custom native wins

Native is not nostalgia. There is a specific list of things the browser still cannot do well, and if your product lives on that list, native stops being a preference and becomes a requirement.

• Deep device APIs. Bluetooth Low Energy, NFC, background geolocation, HealthKit and Google Fit, the secure enclave, fine camera control, and ARKit. A PWA can reach a few of these, but the reliable, always-on, background versions are native.
• Notifications as a core loop. iOS added web push for installed PWAs and it does work, but for a product where notifications are the engine, native is still more dependable, especially for background delivery and rich, actionable notifications.
• Performance-heavy work. High frame rate animation, real time graphics, on-device machine learning, video processing, and games all want the native runtime.
• Offline-first at scale. Large local datasets, real sync engines, and field apps that must keep working for hours with no signal are far easier and safer to build native.
• Store presence as a channel. For consumer brands, being in the App Store and Play Store is a marketing and trust channel, not only a distribution method. Some customers will not believe you are a real company until they see your listing with reviews.

The threshold is easy to state: when a named item on this list sits on your near-term roadmap and drives revenue or retention, native is worth building. When it does not, native is a larger invoice for the same outcome.

The honest cost and total-cost-of-ownership comparison

Here is how the numbers actually shake out, using published prices for the fixed costs and our own delivery experience for the build.

Build cost. A focused PWA typically lands at the lower band, roughly $50k to $130k in 10 to 16 weeks, largely because it is one codebase. A contained native app on a single platform can sit in that same $50k to $130k range. A full cross-platform native platform, with two OS targets and meaningful device integration, runs $150k to $350k. The gap between the two is not the framework. It is the second platform, the deeper device work, and the store release machinery.

Ongoing maintenance. Budget 15 to 20 percent of the build per year for either path. Native quietly carries more inside that band, because you are tracking two operating system release cycles and submitting to two stores every time you ship.

Published fixed costs. The Apple Developer Program is $99 per year and Google Play charges a one-time $25 developer registration, both public list prices. The app stores also take a commission on digital goods, publicly cited between 15 and 30 percent depending on the program and your revenue tier. A PWA that sells through the web avoids that commission entirely.

The crossover point. For a product that is mostly screens, forms, and data, a PWA is cheaper to build, much cheaper to maintain, and stays cheaper for years. The crossover arrives when your roadmap needs capabilities the browser cannot reach reliably, or when store presence and native performance measurably lift revenue. At that moment the native premium is buying something you can point to. Before that moment, it is not.

Migrating from a PWA to native without the pain

This is the quiet advantage almost no one mentions. Because a PWA and a custom native app are both code you own, there is no vendor to escape and no lock-in to unwind. Moving from a PWA to native is not a data export or a contract fight. It is a re-platform of the front end while the rest of the system stays exactly where it is.

What comes with you: your entire backend and API, your database and every record inside it, authentication and user accounts, all of your business logic, and your design system. If the PWA was built in React, a React Native rebuild reuses a real share of that logic and component structure, so you are not starting from a blank page.

The low-pain path is to keep the PWA live while the native app is built, point both at the same backend, and release native to the store for the users who need it. An intermediate step is to wrap the existing PWA in a native shell using a tool like Capacitor, which buys you a store listing and some native APIs without a full rewrite, then replace individual screens with native code only where performance demands it. You migrate the parts that need migrating and leave the rest alone.

The honest recommendation

Default to a PWA. Start native only when a specific, named requirement forces the decision.

The signals that tip toward a PWA: your product is content, commerce, dashboards, or a SaaS front end; you need to launch fast; your team is small; you want one codebase; you deploy often; and store presence is not a condition of the sale. If most of those describe you, a native app is money spent on capability you will not use.

The signals that tip toward custom native: your product depends on background location, Bluetooth, NFC, health data, heavy camera or augmented reality, on-device machine learning, or high frame rate animation; notifications drive your core loop; you sell to consumers who expect a store listing with reviews; or you need offline-first behavior over large local data. When even one of those is central, the native premium is justified.

If you are genuinely on the fence, ship a PWA now and go native later. That order is almost always cheaper than the reverse, because you validate the product on the lean path and pay the native premium only once you know exactly which native capabilities have earned it. The expensive mistake we see most often is the other direction: a company builds native first, spends the full $150k to $350k, and then discovers that a $90k PWA would have done everything their users actually needed.