The question of whether to build a native app or a progressive web app surfaces in almost every mobile product discussion, and the answer changes depending on who you ask and when you ask them. PWA advocates point to lower development costs and no app store friction. Native advocates point to superior performance and device integration. Both groups are partially right, and the choice depends on factors specific to your product and your users.
The goal of this guide is to give you the information to make the right call for your specific situation rather than a universal recommendation that might not apply.
What Each Approach Actually Means
Before evaluating, it helps to be precise about what you are comparing.
Native apps are built specifically for one platform using that platform's development tools and language. iOS native apps are built with Swift or Objective-C using Xcode. Android native apps are built with Kotlin or Java using Android Studio. Each runs on its own platform only. To cover both major platforms, you need two codebases (or a cross-platform framework like React Native or Flutter, which is a middle ground covered below).
Progressive Web Apps (PWAs) are web applications built with standard web technologies (HTML, CSS, JavaScript) that use a set of modern browser APIs to provide app-like capabilities. They run in the browser but can be installed on the home screen, work offline via service workers, receive push notifications, and access certain device APIs. A single PWA codebase runs on any platform with a modern browser.
The framing of "PWA vs native" can be misleading because PWAs are not a single technology but a collection of capabilities layered onto a web application. A PWA that only implements the manifest file for home screen installation is very different from a PWA that implements full offline support, background sync, and push notifications. The capabilities you need determine how much a PWA can actually replace a native app for your use case.
Photo by Phong Thanh on Pexels
Performance: Where the Gap Is Real and Where It Is Not
The native performance advantage is real but narrower than it was five years ago. Modern JavaScript engines and hardware acceleration have closed most of the gap for standard UI interactions. For most business applications - forms, lists, dashboards, content consumption - a well-built PWA is indistinguishable from a native app in daily use.
The gap remains significant in specific categories:
Computationally intensive operations: Graphics processing, video encoding, AR/VR rendering, complex animations with many concurrent elements - these require native code running on GPU and CPU at low levels. Web APIs do not currently provide equivalent access to hardware for these workloads. Game development and creative tools are the clearest cases where native performance still matters significantly.
Startup time: Native apps start from a local installation. PWAs load over a network (with caching for subsequent loads). The first load of a PWA, even on a good connection, is slower than launching an installed native app. Service worker caching improves subsequent loads dramatically, but the cold start difference remains.
Memory and battery efficiency: Native apps have more granular control over memory allocation and can use platform-specific efficiency APIs. For apps that run continuously in the background or process significant data on-device, native apps typically use less battery and memory than comparable web implementations.
For the majority of business and consumer applications - e-commerce, content, productivity tools, communication apps - modern PWAs are performant enough that users do not notice the difference in daily use.
Device and Platform API Access
This is where native apps have their clearest advantage, and where you need to evaluate your specific requirements carefully.
What PWAs can access: Camera and microphone (via browser permissions), GPS and location, push notifications, background sync (limited), offline storage, Bluetooth (Chrome only), NFC (Android Chrome only), accelerometer and gyroscope, file system access (limited), clipboard.
What requires native: Deep OS integration, advanced Bluetooth profiles, USB device communication, Apple Pay and Google Pay native flows, ARKit/ARCore augmented reality, HealthKit/Google Fit health data, background audio with lock screen controls, HomeKit and smart home integration, Face ID / Touch ID (though WebAuthn provides some of this), widgets and lock screen features, and platform-specific notification features.
If your product requires anything in the native-only category, that determines your platform choice for that feature, regardless of other considerations.
Development and Maintenance Costs
The cost advantage of PWAs comes from code reuse. A single web codebase serves desktop browsers, mobile browsers, and the installed PWA experience. Changes deploy instantly - no app store review, no user update required.
Native development for both iOS and Android requires maintaining two separate codebases with separate teams (or generalist developers who context-switch between platforms). This roughly doubles the development cost for any new feature that affects both platforms, and it doubles the surface area for platform-specific bugs.
Cross-platform frameworks (React Native, Flutter): These are the middle ground - build once, deploy to both platforms. React Native uses JavaScript and React patterns, producing native UI components for each platform. Flutter uses Dart and its own rendering engine. Both produce apps that feel native and access native APIs, while sharing a significant portion of the codebase between platforms.
The trade-off: cross-platform frameworks add a layer of abstraction that sometimes surfaces unexpected behavior, particularly around platform-specific UI conventions and edge cases in native API access. They also require following the framework's upgrade path, which introduces maintenance overhead. But for most applications, the development cost savings outweigh the complexity costs.
App store distribution adds recurring overhead for native apps: developer account fees, app review processes (particularly on iOS, where reviews take 1-3 days and rejections require resubmission), and app store compliance requirements. PWAs avoid all of this for web distribution, though users can still install them to their home screen without app store involvement.
Photo by Akshar Dave🌻 on Pexels
Discoverability and Distribution
App stores are discovery channels as well as distribution mechanisms. Approximately 65 percent of app downloads come from app store search, which means native apps benefit from discoverability that PWAs do not have access to through the same mechanism.
For consumer apps where discoverability from cold audiences is important - games, entertainment, lifestyle apps - app store presence is a meaningful distribution advantage. Users browsing the App Store or Google Play will not find your PWA.
For B2B applications and apps where users arrive through other channels (sales process, email invitation, web search), app store discoverability is less relevant. Users who are told to download your app can be directed to the install flow whether that is an app store page or a PWA install prompt.
Google indexes PWA content for search, which provides web search discoverability that native apps do not have. For content-heavy applications where organic search traffic matters, this is a meaningful distribution advantage for PWAs.
Offline Support: A Closer Look
Offline capability is one of the most compelling PWA features on paper and one of the most often misimplemented in practice. Understanding how it actually works helps teams decide whether it applies to their use case.
PWA offline support is built on service workers - JavaScript files that run in a background thread and intercept network requests. When a user visits your app, the service worker can cache assets (HTML, CSS, JavaScript, images) and API responses. If the user later goes offline, the service worker serves cached content instead of returning a network error.
The complexity is in deciding what to cache and how to handle stale data. A news app can cache articles and serve them offline without significant data integrity concerns. A banking app that serves cached account balances offline creates user confusion when the displayed balance is hours old. A chat app that stores outgoing messages in a local queue and syncs when connectivity is restored is technically complex but genuinely useful.
The key question is: what does your application need to do when there is no network, and does serving stale cached data meet that need or create problems? For read-heavy content applications, offline support is straightforward and valuable. For applications where data freshness is critical, offline support requires careful design of what gets cached, when it expires, and how conflicts are resolved when the client reconnects.
Safari's service worker implementation, which affects all iOS browsers (iOS forces all browsers to use the WebKit engine), has historically lagged Chrome's implementation. Apple has improved PWA support significantly in iOS 16 and 17, but feature parity with Chrome on Android is not complete. If your target platform is iOS, verify that the specific service worker APIs you need are supported on the iOS version your users are running before committing to them.
When to Choose Each
Choose a PWA when: Your users primarily access from desktop or web contexts, you need fast iteration without app store review cycles, device API requirements are covered by web APIs, your audience is on Android (Chrome PWA support is stronger than Safari), and development budget is a significant constraint.
Choose native when: Performance is critical to your product's core experience, you need deep device API access, your audience is primarily iOS (Safari PWA support lags Chrome), you need app store discoverability, or brand perception requires the premium feel of a native app.
Choose a cross-platform framework when: You need native device access and performance, you need to serve both iOS and Android users, and you want to minimize duplication of development effort.
The mobile app development team at 137Foundry has built across all three approaches and can help evaluate which is right for a specific product. The right answer depends on your users, your feature requirements, and your operational constraints - not a general philosophical preference.
For technical reference on PWA capabilities specifically, the Web.dev PWA documentation at web.dev/progressive-web-apps is the most comprehensive and current resource. Mozilla's PWA documentation at developer.mozilla.org/en-US/docs/Web/Progressive_web_apps covers browser compatibility differences in detail. For cross-platform native development, the React Native documentation at reactnative.dev/docs/getting-started and Flutter documentation at docs.flutter.dev are the authoritative starting points.
The 137Foundry app development page covers our experience building mobile applications for clients across industries, including cases where we recommended PWAs and cases where native was the right call.