Architecture·August 2024·9 min read

PWAs: Bridging the Gap Between Web and Mobile Apps

Progressive Web Apps close most of the gap between a website and an app, but "most" is doing real work in that sentence. Push notifications on iOS, deep OS integration, and app-store distribution still push teams toward React Native or fully native. Pick based on what your product actually needs from the OS, not which option sounds more modern.

The web-versus-mobile question isn't a technology debate anymore. It's a checklist of specific OS capabilities your product needs, weighed against a single codebase's worth of savings.

Three real options exist: a Progressive Web App (PWA), a cross-platform framework like React Native, or fully native Swift/Kotlin. Each trades something specific for something specific, and the trade is knowable in advance.

What each option actually is

Progressive Web App

A Progressive Web App is a website that meets a specific set of browser criteria (HTTPS, a web app manifest, a service worker) that let it behave like an installed app: it can be added to a home screen, launch full-screen, and work offline for previously cached content.

It ships from the same codebase as the desktop site, deploys the way a web page deploys, and requires no app-store review to update.

React Native

React Native compiles a single JavaScript/TypeScript codebase into components that render through each platform's native UI toolkit, not through a webview. Since React Native 0.76, the "New Architecture" (Fabric renderer) is the default, replacing the old asynchronous bridge with a synchronous native interface that removes a longstanding source of jank on lists and gestures.

The result runs as a real native app, distributed through the App Store and Google Play, while sharing most business logic between iOS and Android.

Fully native (Swift / Kotlin)

A fully native app is built per platform, in each platform's own language and toolkit, with direct access to every OS API the day it ships. Nothing waits on a bridging layer or a third-party framework's release cycle to catch up to a new OS feature.

Where a PWA is the right call

A PWA wins when the product's core value is content or a transactional flow that doesn't need deep OS integration: a storefront, a booking flow, a news reader, an internal tool. Shoppers arrive from a search result or a shared link, and a PWA lets that arrival convert without an app-store detour.

The real constraint: iOS

Safari's PWA support has closed most of the historical gap (offline caching, add-to-home-screen, full-screen display all work), but installability criteria differ by browser. Apple now documents web push notifications for installed home-screen apps, which closed a real gap, but it only fires for apps the user has explicitly added to the home screen, not for a tab open in Safari.

Android has no such restriction: the W3C Push API works in Chrome for both installed and non-installed PWAs. If push notifications are core to retention, test the actual current behavior on the specific iOS version you're targeting before committing to a PWA-only plan.

A PWA isn't "the web app version" of your product. It's a real distribution channel with its own installability rules, its own offline model, and its own platform-specific gaps that don't show up until you test on the actual device.

Where React Native earns its complexity

React Native earns its place when the product needs native navigation feel, camera or sensor access, background processing, or push notifications that work identically and reliably on both iOS and Android. A single team ships one codebase instead of two, which is the entire economic argument for choosing it over parallel Swift and Kotlin builds.

What changed with the New Architecture

Before Fabric, React Native's old bridge serialized every call between JavaScript and native code asynchronously, which caused visible frame drops on complex lists, gesture-heavy screens, and rapid state updates. The New Architecture's JSI-based synchronous interface removes that serialization step, which is why frameworks built on top of React Native (Expo included) now default to it.

The trade that remains: any native module your app depends on (a payment SDK, an analytics SDK, a barcode scanner) needs a maintained New Architecture-compatible version, or someone on the team writes and maintains that bridge themselves.

Where fully native still wins

Fully native is the right call when the product's differentiator is a capability React Native can't yet reach cleanly: ARKit-level AR, complex background audio processing, deep widget or Live Activity integration on iOS, or anything requiring same-day access to a new OS API. It's also the right call for a single-platform product where cross-platform sharing buys nothing.

The cost is real and ongoing: two codebases, two release cycles, and two sets of platform-specific bugs, maintained by developers who need real Swift and Kotlin depth rather than JavaScript depth.

Release cycle cost, not just build cost

Every App Store or Google Play release, whether the app is React Native or fully native, goes through Apple's App Review process before it reaches users. A critical bug fix that would deploy to a PWA in minutes has to wait on review turnaround for a native or React Native app, which changes how a team plans hotfixes.

React Native narrows this gap for JavaScript-only changes: over-the-air update tools can push JS bundle updates without a full store review, though any change touching native code still goes through the standard review cycle. A PWA never has this constraint, because there's no store review step at all.

Comparing the three head to head

Criterion	PWA	React Native	Fully native
Distribution	URL / home-screen install, no app-store review	App Store & Google Play, subject to review	App Store & Google Play, subject to review
Update cadence	Instant, same as deploying a web page	Store review per release (OTA possible for JS-only changes)	Store review per release
Offline support	Service worker caching, good for content and static flows	Full native offline storage and background sync	Full native offline storage and background sync
Push notifications	Supported on Android; limited/newer on iOS Safari	Full native push on both platforms	Full native push on both platforms
Team & codebase	One team, one codebase, standard web skills	One team, one codebase, React skills	Two teams or two skill sets, two codebases
Deep OS integration	Limited to what browser APIs expose	Good, via native modules; gaps need custom bridging	Complete, same-day access to new OS APIs
Best fit	Content, storefronts, internal tools, fast iteration	Most consumer apps needing native feel cross-platform	OS-differentiated apps, single-platform products

A decision sequence that actually resolves the question

Skip the framework-preference debate and answer these in order. Each one can end the decision on its own.

Does the product need push notifications as a retention lever, and does that need to work reliably on iOS? If yes, and the timeline can't tolerate iOS's more restricted web-push behavior, a PWA-only plan is risky. Move to React Native or native.
Does the product need deep OS integration (camera pipelines, background location, widgets, Live Activities, ARKit)? If yes and it's iOS-only or Android-only, native. If it needs to exist on both, React Native, with a plan for any gap that needs custom native modules.
Is the primary entry point a shared link, search result, or QR code rather than an app-store search? A PWA removes the install-friction step that kills conversion for that entry pattern.
What's the actual team? A web team with no mobile experience will ship a PWA faster and maintain it more confidently than a rushed React Native app with brittle native modules nobody on the team understands.

The framework doesn't determine the outcome. The OS capability your retention strategy depends on does. Answer that question first and the framework choice mostly answers itself.

Hybrid is a valid answer, not a compromise

Plenty of products run a PWA as the primary web experience and layer React Native (or a Trusted Web Activity on Android, which wraps a PWA in a native shell for Play Store distribution) once retention data justifies the native investment. Building the PWA first and instrumenting it properly gives the data needed to justify (or rule out) the native build later, instead of guessing upfront.

Start PWA if: the product hasn't proven retention yet, or the core flow is content/transactional without heavy OS needs.
Add React Native when: push notification reliability, native navigation feel, or specific device APIs become a proven retention or conversion blocker, backed by data from the PWA.
Go straight to native when: the differentiator is a capability that doesn't exist in a cross-platform framework yet, or the product is single-platform by design.

FAQ

Can a PWA be listed in the App Store or Google Play?

Not directly as a PWA on iOS. On Android, a Trusted Web Activity wraps the PWA for Play Store listing while still rendering through Chrome. Apple has no equivalent first-party wrapper; a PWA on iOS lives through Safari's install flow, not the App Store.

Does React Native still have a performance problem compared to fully native?

The New Architecture closed most of the historical gap for typical list-and-navigation-heavy apps. Performance-critical work (heavy image processing, complex animation, real-time audio/video) still favors native or a native module written specifically for that workload.

How much of the codebase actually gets shared in a React Native app?

Business logic, state management, and most UI components share cleanly across iOS and Android. Platform-specific UI conventions, some native module configuration, and OS-specific permissions handling still need per-platform code.

Is a PWA a good idea if most of our traffic already comes through paid app-install campaigns?

Probably not as the primary channel. PWAs win on frictionless discovery through links and search; app-install campaigns are already optimized for app-store conversion, which argues for React Native or native as the primary investment.

What's the realistic cost difference between React Native and two native codebases?

It depends entirely on team composition and how much native module work the product needs, so no single percentage is honest here. The structural savings come from one team maintaining one codebase instead of two, which compounds every release cycle, not just the first one.

Does App Store review timing actually matter for a launch plan?

Yes, for anything time-sensitive. A PWA can ship a fix the same hour it's found; a native or React Native app with a native-code change has to clear Apple's review process first, so hotfix planning needs a buffer that a web deploy doesn't.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.