PWA (Progressive Web App) is a website that behaves like a native app. Users access it through the browser, add it to their home screen and use it like a native app, with icon, full screen, offline support and automatic updates.

Can a PWA replace a native app?

In most cases, yes. PWAs work on any device with a browser, don't need App Store approval, update automatically and cost a fraction of a native app. Native apps are only necessary for heavy games, Bluetooth/NFC or when App Store presence is an acquisition channel.

How much does a PWA cost compared to a native app?

A PWA costs the same as a webapp: R$ 15,000 to R$ 50,000. A native app for iOS and Android costs R$ 40,000 to R$ 150,000+. The difference can be 3x to 5x, with practically identical results for the end user in most cases.

Does PWA work on iPhone?

Yes. Full screen, home screen icon and offline support all work. Push notifications on iOS still have limitations compared to Android, but Apple has been improving PWA support with each iOS version.

PWA: does your business need an app or a webapp?

The reflex of asking for an app

When a client says “I need an app”, most of the time what they actually need is a system that works well on mobile. Not an application published on the App Store and Google Play.

The confusion makes sense. “App” in most people’s minds means “thing that works on my phone”. But between what the client needs and a native app published in the stores, there’s a faster and cheaper path that delivers practically the same result.

The difference between these paths is huge in cost and timeline. I’ve seen a client spend R$80k on a native app that could have been a R$25k PWA with the same experience for the end user.

The problem goes beyond the initial cost. A native app creates an ongoing dependency: every iOS or Android update can require adjustments, Apple’s annual Developer Account fee is US$99, and every new version has to go through the review process. With a PWA, you update the site and everyone gets the new version instantly.

What PWA actually is

PWA stands for Progressive Web App. In practice: a website that behaves like an application. The user opens it in the browser, adds it to the home screen, and uses it as if it were a native app.

What works:

Home screen icon (looks like a native app when the user glances at their phone)
Full screen without browser bar (opens like an app, not a website)
Works offline or with weak connection (cached data stays available)
Push notifications on Android (iOS has limitations but it’s getting better)
Camera and GPS access
Automatic, transparent updates (no need to visit the store to download an update)

What still doesn’t work well:

Bluetooth and NFC (limited in some browsers)
Deep integration with specific hardware (advanced sensors, native AR)
Presence in Apple’s App Store as a native app (you can publish, but it’s not the natural path)

For 80% of the use cases I work on, what works is more than enough.

From a technical standpoint, a PWA comes down to three components: a manifest.json file that describes the app (name, icon, background color, screen orientation), a Service Worker that manages cache and offline functionality, and the responsive webapp itself. It’s under 100 lines of configuration on top of a site that already exists. It’s not a new framework — it’s a layer on top of what you already have.

The real math

I’m going to lay out the numbers because this is the comparison that matters when it’s time to decide.

Native app (iOS + Android)

Requires two separate development tracks. Swift/SwiftUI for iOS, Kotlin for Android. Or React Native/Flutter, which is a single codebase but still mobile development with its own complexities
Submitting to Apple’s App Store can take days or weeks. And it can get rejected for reasons ranging from interface issues to business rules. Google Play is faster but has its own rules
Every new version needs to be submitted, approved, and downloaded by the user. If the user doesn’t update, they’re running the old version with bugs that were already fixed
iOS and Android updates can break things. A new iPhone with a different screen size might need adjustments. OS API deprecations require updates
Cost: R$40,000 to R$150,000+ for a functional app on both platforms. With backend, design, and integrations, it can easily exceed R$200k
Timeline: 3 to 6 months until the first published version

PWA

One development track. It’s a responsive webapp with a PWA layer (service worker, manifest, offline support). Works on any device with a modern browser
Deploy the site, it’s live. No store approval, no review, no waiting
Automatic, transparent updates. The service worker detects the new version and updates in the background. The user always has the latest version
It’s a website. Update the site, update the “app”. No worrying about iOS or Android versions
Cost: same as a webapp. R$15,000 to R$50,000 depending on complexity. Detailed ranges here
Timeline: 4 to 12 weeks, same as a webapp

The cost difference can be 3x to 5x. And the result for the end user is practically identical in most cases.

There’s a hidden cost of native apps that few people mention: maintenance. Apple releases a new iOS every September. Google releases a new Android every October. Each version can deprecate APIs, change permissions, or alter notification behavior. If the app isn’t updated, the store can remove it from listings. With a PWA, the browser is what updates — and browsers maintain backward compatibility much better than mobile operating systems.

Real cases: PWA in production

AutoPars

AutoPars is an auto parts marketplace with 3 panels (buyer, seller, admin). The seller needs to respond to orders on their phone, often at the store counter with one hand holding a part and the other on their phone.

If we had built native apps, that would be two apps (iOS + Android) per panel, totaling 6 separate builds. Six approval processes, six deploy pipelines, six versions to maintain. With PWA, it’s a responsive webapp that the seller adds to the home screen and uses like an app. Updates are automatic. If I fix a bug at 2 PM, by 2:01 PM everyone has the fix.

FitPlan

FitPlan is a platform for gyms with 6 panels. The member opens the app on their phone to see the day’s workout, watch exercise videos, and log their progress. The trainer uses it to create workout plans and track members.

PWA was the natural choice. The member installs it in 10 seconds (no App Store, no 80 MB download), and the notification system alerts them when they haven’t trained in 6 days. That notification helped reduce cancellations by 37%.

Another detail: the trainer builds the workout on the gym’s computer and the member views it on their phone. If it were a native app, we’d need to develop and maintain a separate desktop version or force the trainer to do everything on their phone. With a PWA, the same application works on any screen — desktop, tablet, phone — without building anything extra.

Mariah

The Mariah app (order management) is also a PWA. My 15-year-old sister installed it on her phone between classes. No App Store, no developer account, no setup. She opened the link, tapped “Add to Home Screen”, and that was it.

When a native app makes sense

PWA doesn’t solve everything. A native app is the right call when:

It’s a game or application with heavy graphical performance. PWA can’t run a 3D engine as smoothly as a native app
The product depends on Bluetooth, NFC, or advanced sensors. IoT device control, contactless payment, native augmented reality
It’s a B2C product with millions of users where App Store presence is an acquisition channel. If your audience searches for “delivery app” in the App Store, you need to be there. If they access via direct link, you don’t
There’s a regulatory requirement for a native app. Some sectors (banking, healthcare) have specific regulations about software distribution

What about React Native / Flutter?

They’re middle-ground options. A single codebase that generates native apps for iOS and Android. Lower cost than pure native, but still higher than PWA. And you still need store approval, a mobile deploy process, and compatibility maintenance.

They make sense when you need real native features (advanced push notifications on iOS, Bluetooth) but want to keep a single codebase. For most of the projects I work on, PWA solves the problem before that decision comes up.

Three questions to help you decide

If you’re torn between PWA and native app, answer these three questions:

1. Will your audience look for the product in the App Store? If yes, consider native or React Native. If not (if access comes from a direct link, QR code, or referral), PWA works.

2. Do you need specific hardware (Bluetooth, NFC, sensors)? If yes, native. If not, PWA.

3. Does your budget and timeline allow for dual mobile development? If not (and for most MVPs it doesn’t), PWA is the viable path.

For most projects I work on, the answer to all three is: PWA. The native app stays as a future evolution, if usage data justifies the investment.

The future of PWA

Apple has been improving PWA support on iOS with every release. Push notifications, more intuitive installation, better system integration. The trend is for the gap between PWA and native app to keep shrinking.

Google already treats PWAs as first-class citizens on Android. Installation is native, notifications work without limitations, and the experience is indistinguishable from a native app for most users.

What matters is whether your specific case needs something only a native app can deliver. Most of the time, it doesn’t.

The Web Bluetooth API, for example, already allows communication with BLE devices in Chrome and Edge. Web NFC works on Chrome Android. APIs like Web Share, Contact Picker, and File System Access are expanding what PWAs can do with every browser release. Every year, the list of “things only native apps can do” gets shorter.