Progressive web app (PWA) vs native app: what's the difference?

What is a Progressive Web App?

A Progressive Web App, or PWA for short, is a web application that behaves like a native app. Under the hood it is simply HTML, CSS and JavaScript, the same technologies used to build any modern website. What sets a PWA apart are a few extra layers that let it do things previously reserved for apps from the App Store or Play Store: installing to the home screen, working without an internet connection, sending push notifications, and running full screen without a browser bar around it.

The term was introduced by Google around 2015 to signal that the web had matured enough to compete with native — not in every respect, but for a large share of what everyday apps do. A typical example: you open an online shop in Chrome or Safari on your phone. In the menu, an option "Add to Home Screen" appears. Tap it, and an icon appears on your home screen that opens in a full-screen window — no browser bar, no address bar. For the user, it feels exactly like an ordinary app, while technically you are still running a website.

The three technical pillars

A PWA rests on three pillars. The Service Worker is a piece of JavaScript that runs in the background, separately from the page. It intercepts network requests, stores pages and assets in a local cache, and serves them again later, even without a connection. It is also the channel for incoming push notifications. The manifest is a JSON file that describes the app's name, icon, colours and start screen; once installed, the operating system treats the PWA as an ordinary application. And HTTPS is a strict requirement: service workers simply do not work over plain HTTP, a sensible security measure given the access they have to network traffic.

What is a native app?

A native app is an application built specifically for one operating system, in the programming language and with the tools that the maker of that system prescribes. For iOS, this in practice means Swift (or the older Objective-C), built with Xcode and distributed through the App Store. For Android, it means Kotlin (or the older Java), built with Android Studio and distributed through the Play Store.

Native apps run directly on the operating system, with no browser in between. They have full access to what the device can do: camera, microphone, GPS, NFC, Bluetooth, biometric authentication (Face ID, Touch ID), health data via HealthKit, payments through Apple Pay or Google Pay, contacts, calendars. Anything a user has to grant permission for through system dialogues can be accessed by a native app once that permission has been given.

Distribution runs through the official stores. Apple reviews every iOS app manually before it appears; Google does the same for Android, though somewhat more leniently. A user searches the store, reads reviews, sees the star ratings and then downloads the app. For brands with a broad audience, that App Store presence is in itself a channel — a route to discoverability and trust that works differently on the web.

The price of that depth

Set against that depth is a price in development effort. A genuine native app for both iOS and Android means, in principle, two separate codebases, in two different languages, built by specialists for each platform. A feature you want to offer in both apps has to be built twice, tested twice and maintained twice. On top of that comes the overhead of the App Store process: review times, regular updates to keep pace with SDK requirements, and annual developer account fees.

For more in-depth strategy around app development (when a custom mobile application pays off, how the process runs, and what it involves), see our app development service page.

Cross-platform as a middle ground

Between "pure PWA" and "two separate native apps" lies a third category: cross-platform native. With frameworks such as React Native, Flutter or .NET MAUI, you write a single codebase that compiles to both an iOS and an Android app, and which runs on the device itself as native code rather than as a web page.

A React Native app appears in the App Store, gets its own icon and has access to the same hardware APIs as pure Swift or Kotlin. The difference is that logic and screens are written in JavaScript, and a bridge translates those instructions into native components on the device. For most organisations, this is the practical middle ground: one team, one codebase, App Store presence and native behaviour. We explore that trade-off in more depth on our page about building a React Native app.

Comparison across six dimensions

The choice between a PWA and a native app is rarely absolute. It depends on which dimensions weigh heavily for you. Below are six that prove decisive in practice.

1. Offline capabilities

On paper, a PWA can work offline perfectly well: the service worker stores pages and data locally and serves them when there is no connection. In practice, this requires design discipline: which pages are precached, how changes are temporarily stored, and what you show when something is unavailable.

A native app has more built-in tools for offline scenarios: a local SQLite database, file system access, and background synchronisation through OS services. For apps where offline is genuinely a first-class scenario, such as field work, shipping, or warehouses without coverage, that difference can be decisive. For a typical app where offline is a nice-to-have, the PWA approach is more than sufficient.

2. Push notifications

This is historically where the greatest difference between the two worlds lies, and it is a difference that long worked against PWAs. Native apps have sent push notifications via Apple's and Google's central push services from the very beginning. For PWAs, this had long been possible on Android too, but not on iOS, until Apple added web push support for PWAs installed on the home screen in iOS 16.4 (early 2023).

Since then, web push has been possible on iPhone and iPad, but under conditions: the PWA must first be installed (ordinary Safari tabs do not receive push), the user must explicitly grant permission, and the available functionality remains more limited than on Android or in a native app. For those who place push at the centre of their product, such as chat applications, real-time alerts or transactional confirmations, native is often still more predictable.

3. App Store distribution

A native app or a cross-platform native build appears in the App Store and the Play Store. That provides access to a discoverability channel, ratings and reviews, and an installation flow that many users find familiar. For mass-market B2C brands, that presence is sometimes indispensable: a brand without an app in the stores can seem less credible to some audiences.

You distribute a PWA via your own URL. That is quicker, more flexible and free of review processes, but it lacks the ratings system and the natural discoverability of the stores. Some stores now accept PWAs as wrappers (the Microsoft Store does so generously, Google Play via Trusted Web Activities, the Apple App Store not yet), but that remains a separate step.

4. Hardware access

Native apps have full access to what the device offers: camera with advanced settings, biometric sensors, HealthKit and Google Fit, NFC for contactless payments or access passes, Bluetooth Low Energy for wearables and IoT, AR frameworks for augmented reality. PWAs have gained considerable ground in recent years through web APIs such as Web Bluetooth, Web NFC, WebRTC for camera access and Web Share, but support depends on the platform and is considerably more limited on iOS than on Android.

For an app that needs access to Apple Pay, HealthKit or a specific sensor not available through web APIs, the choice automatically falls to native or cross-platform native. For an app that only needs to take a photo with the camera and read the location, a PWA is perfectly suitable these days.

5. Performance

The performance gap between PWAs and native apps has shrunk considerably. For most apps — displaying content, completing forms, scrolling through lists, confirming transactions — a well-built PWA is barely, if at all, noticeably slower. For demanding graphics, intensive animations or complex interaction patterns, native (and cross-platform native) remain faster, as they communicate directly with the device's graphics layer. Note: the first time a user opens a PWA before the service worker has been able to cache anything, it feels like a website. Only after installation does the user experience the "app feel".

6. Development costs and maintenance

This is often the deciding factor for SMEs and scale-ups. A PWA is in principle a single codebase that runs on anything with a modern browser. Changes are immediately available to everyone — no review, no update that has to be rolled out, no old versions lingering on devices. A native app for two platforms requires two builds, two test suites and two release processes. Cross-platform native reduces those costs to a single codebase, but adds its own complexity: a bridging layer, platform-specific exceptions, framework upgrades. Maintenance is ongoing in every form.

iOS limitations on PWAs

The biggest caveat in any PWA story remains Apple. On Android, PWAs have been working almost entirely for years: web push, background sync, install banners offered by the browser itself, and generous web APIs for hardware. On iOS, Apple has always been more restrained. A few concrete points:

• No automatic install prompt: where Android browsers can display a banner, an iOS user has to open the share menu manually and choose "Add to Home Screen". Many audiences never find that route without help.
• Limited storage: iOS imposes stricter quotas on what a PWA may store locally, and it clears storage of rarely used PWAs without notice.
• Web push only from iOS 16.4: push notifications on iPhone and iPad have been available since March 2023, for PWAs installed on the home screen. Before that, push on iOS was simply not possible for years — a dealbreaker for many use cases.
• No access to certain sensors: NFC for reading, a number of Bluetooth profiles, Apple Pay outside Safari — Apple reserves this functionality for native apps.
• Safari as the only rendering engine: on iOS, every browser runs on WebKit under the hood. A PWA in Chrome on iPhone is technically still a Safari PWA.

Apple's reluctance is not a technical oversight but a commercial trade-off. A strong PWA ecosystem makes the App Store less essential as a channel, and with it the commission Apple charges on store transactions. That tension largely determines how far iOS PWA support goes.

When should you choose a PWA?

Not every app needs to be native. A PWA performs particularly well when one of the following patterns applies:

• Content-heavy products: news, magazines, knowledge bases, documentation portals. The primary task is reading, navigating and searching, areas where a well-built PWA is every bit as capable as a native app.
• Web-first organisations: you already have a strong website and a team experienced in JavaScript and modern web stacks. A PWA built on top of the existing platform is a natural extension, without starting a second team.
• Broad reach, low installation barrier: you want anyone who clicks your link to get something useful straight away. No hurdle to the App Store, no mandatory installation, and for users who return regularly you can offer "Add to Home Screen".
• Need for rapid iteration: you change the UI regularly, add features and don't want to lose weeks to App Store review. With a PWA you can roll out the same day.
• Wanting to avoid App Store restrictions: if your product doesn't fit Apple's or Google's guidelines (some categories around finance, gambling or content), or you prefer not to pay commission for commercial reasons, a PWA offers a legitimate way forward.
• Simple hardware needs: your product only needs the camera, location and notifications, not deeper hardware integrations.

A common borderline case is the customer portal. An authenticated environment in which a customer views their file, pays an invoice or reschedules an appointment can almost always work excellently as a PWA: installable for those who use it daily, and still accessible through the browser for those who open it only occasionally. We cover the specific choice between a customer portal app and a responsive website separately in our guide to customer portal app versus responsive website.

When should you choose native?

On the other hand, there are patterns where native (whether or not cross-platform) is by far the stronger choice:

• Daily use with strong retention ambitions: your app lives on the home screen and is opened regularly. The icon, push notifications and presence in the app switcher are marketing tools in their own right.
• Hardware-heavy features: AR, advanced camera controls, HealthKit, NFC payments, biometric authentication as core functionality, and intensive Bluetooth integrations with wearables. These are areas where native is the only route, especially on iOS.
• App Store presence as a marketing channel: you expect installs from organic store searches or invest in App Store advertising. For some audiences, "not being in the store" is equivalent to "not existing".
• Performance-critical: games, real-time graphics applications, video editing, audio production. Not the typical business app, but the scenario where every frame counts.
• Branding and feel: you want a brand experience that stands out from the web. Animations, gestures, custom typography — everything the web can do too, but which in native often comes out a touch more refined, without compromise.
• Distribution via app stores as a trust signal: in healthcare, finance or certain B2B segments, "we're on the App Store" is a formal signal that an arbitrary URL does not provide.

For those who lean towards native without wanting to maintain two separate codebases straight away, React Native is often the starting point. One JavaScript codebase, two platform builds, and where a specific feature needs to go deeper, it can be supplemented with platform-specific code. For less app-heavy products with a strong web origin, building a PWA on top of an existing Single Page Application is often a logical evolution, since that SPA architecture lends itself well to adding a service worker and a manifest.

Hybrid strategies

The choice doesn't have to be binary. A common pattern: the entire product is reachable via a PWA for occasional users and search traffic, while a native app appears for the heavy daily user with features that only work natively. On Android, you can also publish a PWA to the Play Store via a Trusted Web Activity in a thin wrapper. Under the hood it remains the PWA, but users download it like a regular app.

Costs and maintenance

With a PWA, you are in principle paying for a single codebase that runs on all modern browsers and operating systems. The effort lies in feature development, designing offline behaviour, and setting up the service worker and manifest. Maintenance is largely limited to what you would also do for a high-quality website: keeping up with modern JavaScript, following browser quirks, and occasionally debugging a service worker issue.

With two separate native apps, the build effort roughly doubles: every feature twice, testing on two platforms, releasing to two stores. Cross-platform native sits somewhere between PWA and pure native in terms of cost: one codebase, but still platform-specific attention for parts that differ per OS, plus the App Store overhead.

Maintenance is ongoing in every form. Apple and Google adjust their platforms every year; old APIs are deprecated; iOS and Android versions force periodic upgrades. When requesting any quote, ask explicitly about handover: what the codebase looks like, how it is documented, and what is needed to take it forward with a different team.

App Store economics and commissions

One aspect that is often underexposed in technical comparisons is the commercial model of Apple and Google. Both stores charge a commission on transactions made through in-app purchases or subscriptions: historically 30 per cent, reduced to 15 per cent for smaller developers and for subscriptions beyond the first year. For products that run entirely on store transactions, that is not a marginal cost but a structural part of the business model.

A PWA sidesteps those commissions, because transactions run through your own web payments: Mollie, Stripe, Adyen or your own merchant account. That is one of the reasons some content, gaming and news platforms actively deploy PWAs. On the other hand, an App Store presence is in itself a marketing asset: the signal of a "verified publisher", reviews and visibility in search results. For mass-market B2C brands, that is rarely something to ignore.

Common mistakes in the choice

• Choosing native because it feels more serious: a content-heavy app that nobody uses offline, poured into two native builds. Double the cost without double the value.
• Choosing a PWA and forgetting to design it as an app: a mobile website with an "Add to home screen" prompt stuck on never feels like an app. A proper PWA needs app-level attention to navigation, gestures, offline states and notifications.
• Not testing on iOS early: building a PWA that works beautifully on Android, and only discovering at handover that a critical feature is missing on iPhone. Test sooner, not later.
• Overestimating App Store presence: putting an app in the store does not mean anyone will find it. Without serious App Store Optimisation and channel investment, the icon stays invisible.
• Don't forget maintenance in your budget: building the app is a one-off investment, while maintenance is ongoing. If you only budget for the build, you may later find the app has been pulled from the store because an SDK has expired.
• App and website drifting apart: data models that diverge, features that exist on the web but not in the app (or vice versa). Both channels should run on the same architecture.

None of these mistakes are exotic, and all of them can be avoided by asking the right questions at the start: about your target audience, frequency of use, hardware requirements, distribution strategy and maintenance capacity. If you'd like to explore the wider background of modern web technology, our page on web development as a service is a logical next step.

Frequently Asked Questions

What is the difference between a PWA and a regular website?

A regular website runs in a browser and stops working as soon as you close the tab. A PWA is a website with a service worker and a manifest added, which makes it installable on the home screen, able to work offline and capable of sending push notifications.

Can a PWA do the same things as a native app?

Almost, but not quite. On Android the overlap is close, especially for content and transaction-driven apps. On iOS there are still important limitations, such as certain hardware APIs, push scenarios and storage quotas. For functionality that requires deep hardware access or distribution through the App Store, native is still necessary.

Does a PWA work on iPhone?

Yes. Safari has supported the core building blocks for years, and since iOS 16.4 also web push (provided the PWA has been added to the home screen). Installation is manual via the share menu, however, and some web APIs that work on Android remain reserved for native apps on iOS.

Can a PWA be on the App Store?

On the Microsoft Store and Google Play, yes, usually via a wrapper format. Not directly on the Apple App Store, where you would need to release a native (or cross-platform) app to get a presence there.

Is React Native a PWA?

No. React Native builds a true native app that appears in the App Store and Play Store and uses native UI components, written in JavaScript. A PWA is a website with a service worker and manifest. Both use JavaScript, but they are different delivery models.

Which option should you choose if you're unsure?

Start with a PWA if your audience is broad and your hardware requirements are limited; plan a native or cross-platform extension once usage frequency justifies it. The reverse path works less well.