For many years, the answer was simple: if you want a real app, you build natively. In 2026, the map will look different. The web platform has received WebGPU, on-device AI, gigabyte-sized local storage and push notifications on both Android and iOS. At the same time, there are still hard limits, especially on Apple's platform, which mean that native is sometimes the only way. This guide goes through the differences that actually make the choice, without hype and without pretending that one technology always wins.
What's the difference, really?
Anative appbuilt specifically for a platform (Swift/SwiftUI for iOS, Kotlin for Android) or with a cross-platform framework like React Native or Flutter. It is distributed through the App Store and Google Play and is installed as a regular program.
Aprogressive web app (PWA)is a website built with modern web technologies that behaves like an app: it can be installed on the home screen, run offline via a service worker, send push notifications and reach hardware like camera and GPS. The user does not have to go through an app store but can install directly from the browser.
The important difference in 2026 is that the technology gaps have narrowed considerably, but distribution and platform policies still create real constraints, especially on iOS.
App Store presence: this is where the biggest dividing line goes
If you want to be seen in the app stores, the situation looks different depending on the platform.
Google Play:A PWA can be packaged and published via a Trusted Web Activity (TWA), for example with Microsoft's free tool PWABuilder that generates an Android App Bundle. Your PWA thus ends up in the Play store with relatively little extra work.
Microsoft Store:PWAs can be submitted directly and with minimal customization.
Apple App Store:Here the door is closed. Apple's review rules specifically reject apps that are just "repackaged websites", and a pure PWA falls under that category. It has been in place for several years and is still in place in 2026.
So if you need to be in Apple's App Store, be searchable there and be able to take payment via Apple's purchase flow, then in practice you need a native or hybrid app. Do you neednotthat, one of the strongest historical arguments for native disappears: distribution can be done directly via the web without store review and without an update queue.
Offline and local power: the web has caught up
Offline was long native territory. Today, PWAs use service workers with Cache API and IndexedDB to work offline, and background sync to send data when the connection is back. It goes a long way for the vast majority of business apps: read cached content, fill in forms offline, work in a dashboard.
In 2026, the web platform has also received heavy tools:
WebGPUfor high-performance graphics and local AI inference directly in the browser.
Origin Private File System (OPFS)which allows a PWA to handle gigabytes of data with near-native disk performance, making it realistic to run video editors or large data sets entirely within the web app.
WebAssemblyand on-device AI APIs that run models without server calls.
The limit is at the really heavy: extensive offline maps, large media libraries, advanced background processing or maximum squeezed graphics and sensor performance are still handled more smoothly natively. For a typical web service, e-commerce or internal tool, however, the web's offline support is quite sufficient.
Push notifications: possible on both, but with an iOS caveat
Push today works on both Android and iOS for PWAs, which was long one of the trump cards of the native camp.
On iOS, however, there is an important condition: the Push API is only available to web apps added onhome screen(via Share → Add on the home screen). An open tab in Safari has no access to push. Support arrived with iOS 16.4 (2023), and with iOS 26, any page added to the home screen opens as a web app by default. Safari 18.4 also introduced Declarative Web Push, a simpler scheme that doesn't even require a service worker.
The practice is that your actual push reach on the iPhone is limited to the users who actually installed your PWA on the home screen, which is usually a smaller percentage of visitors. If you need to reach all users with notifications with high reliability, native is still stronger on iOS in particular.
The EU factor: a moving target
There is a regulatory complication here that is worth knowing. During the DMA process, Apple first tried to remove home screen web apps in the EU, but backed down after strong protests. The result in 2026 is that PWAs on iOS continue to run on WebKit, and the technical limitations that existed before DMA remain in practice.
iOS formally allows third-party browser engines in the EU since iOS 18.2, but Apple's implementation via BrowserEngineKit has created so much friction that no browser had adopted it by early 2026. In October 2025, the British CMA gave Apple "Strategic Market Status" and singled out the engine requirements as anti-competitive. The bottom line: regulatory developments may benefit web apps in the long run, but you shouldn't plan architecture based on promises of future ease.
Cost in time and complexity
Here we do not mean kroner but engineering time, number of codebases and maintenance burden.
PWA
A code basefor all platforms and the web. Same code, same deploy.
Faster iteration:you publish updates immediately, without store review and without waiting for users to update.
Lower threshold:the team can often build on existing web skills.
Native
One or two more codebases(iOS and Android), or a cross-platform framework that still requires platform-specific fine-tuning.
Store process:review, release cycles, certificates and provisioning as ongoing maintenance.
More specialized skillsper platform.
The 2026 rule of thumb for most business apps: PWA is the default, and you need concrete reasons to go native, rather than concrete reasons to go PWA. Those reasons are real when they exist, but they should be specific, not force of habit.
Maintenance over time
A PWA is maintained like any modern web app: a pipeline, an environment, a place to fix bugs. A native or hybrid app involves parallel maintenance of platform versions, OS updates that may break APIs, and recurring store submissions. Over the life of a product, this is a significant, often underestimated, item. At the same time, with native you get a more stable foundation for deep hardware integration and performance that is not dependent on the pace of browser vendors.
How to choose: a short decision guide
Choose PWA when:
Reach via the web, rapid iteration and a code base weigh the most.
Offline needs are moderate (cached content, forms, dashboards).
You are not dependent on being seen in Apple's App Store.
It is about e-commerce, content, internal tools or SaaS.
Choose native (or hybrid) when:
App Store presence on iOS is business critical.
You need maximum performance, advanced sensor or hardware integration or heavy offline scenarios.
Reliable push to all iOS users is a must.
You build games or graphics-intensive experiences where every millisecond counts.
Many also end up right in the middle: build the core as a strong PWA and package it for Google Play via TWA, and add native only where it's really needed.
How ZORC thinks
We always start with the business goal, not the technology. What devices are your customers using? How important is the App Store? How often do you need to release something new? The answer determines whether a PWA will get you all the way or whether native is worth the added complexity. What a project requires in time and maintenance depends on these very choices, scope and integrations, rather than on a standard template. If you want an estimate for your particular case, you will get one quickly this springquote calculator, or we take it directly viacontact.
Ready to build your app with the right skills behind it?ZORC's app development in Stockholmcovers everything from native iOS/Android and PWA to advanced web apps — with EU-safe backend and modern architecture.
