Beyond the WebView: What’s Next?

WebViews are like training wheels or stabilisers if you're British. They kept apps upright, got them into the Play Store, and helped teams ship quickly across devices. But training wheels are not built for speed. They wobble, drag, and hold back the ride. Today the web is balanced on its own. PWAs and TWAs are racing bikes - fast, responsive, and able to go where WebViews never could.

For a long time, wrapping a website in a WebView was the default way to get a mobile app into the Play Store. It was pragmatic, cross-device, and allowed teams to “ship an app” without maintaining separate code. But the web has matured. Between Progressive Web Apps (PWAs), Trusted Web Activities (TWAs), and differential builds, we can now deliver web applications that feel native, update instantly, and tap into features once exclusive to bespoke native code.

This is especially true on Android, where WebViews lag behind Chrome and hold back performance. On iOS the picture is different: Safari’s WKWebView underpins every browser, so performance is more consistent. The benefit there is less about speed and more about avoiding duplicate logic across two codebases. On Android, it’s both: better performance and a single implementation.

From WebViews to the Web Itself

A WebView is essentially a cut-down browser embedded in a native shell. It works—but comes with baggage: inconsistent performance, missing APIs, and the need to ship APK updates for every change. Heavy web apps—full of JavaScript and dynamic UI logic—often falter under this approach.

PWAs let your app run with purpose: enhanced by a manifest, service worker, offline support, installability, and background sync. Package that PWA for the Play Store with a TWA, and it runs in full-screen Chrome—free of browser UI. You inherit Chrome’s performance optimisations, security, and modern APIs.

The PWA is your enhanced app. The TWA is the means of distribution, delivering it with native-quality experience.

Native Where It Matters

You may worry that PWAs and TWAs forego native integrations. They don’t. A TWA is still an Android app project. That means tools like AppsFlyer (for attribution), GeoComply (for regulatory geolocation), or Firebase Crashlytics (for crash reporting) work exactly as they would in a native app — side by side with your web UI.

In effect, the PWA maintains the user-facing experience, while the TWA wrapper quietly supplies native hooks for apps where compliance, measurement, and analytics still matter just as much as performance.

The Modern Web Can Do More Than You Think

Misconceptions persist—teams often underestimate what PWAs can achieve. Today, they can:

• Authenticate with biometrics, using WebAuthn and device-level features
• Send push notifications and leverage background sync
• Provide haptic feedback with vibration APIs
• Accept payments through Google Pay and Apple Pay
• Function offline thanks to intelligent service-worker caching

It isn’t second-class—it’s first-class, even before you consider how much performance you can unlock with modern build strategies.

Even Faster: Differential Builds + TWA = Near-Native Speed

That’s not just theory. Moving Beyond the Lowest Common Denominator: Differential Builds for Near-Native Web Performance explains how single-build strategies—targeting ES2015 for compatibility—punish modern devices. Instead, serving ES2022 bundles to Chrome (and therefore TWAs) unlocks near-native execution speeds.

Running modern bundles in TWAs means faster parsing, lighter JavaScript, quicker time-to-interactive, and smoother UI rendering. On capable devices, web apps feel as fluid as native.

The Performance Case on Android

On real-world Android devices—around the 75th percentile, not the latest flagships—moving from a WebView wrapper to a PWA inside a TWA delivers a conservative 20% improvement in perceived performance.

That 20% shows up as faster start-up, smoother navigation, fewer frame drops, and snappier responses. With differential builds layered on top, the experience pushes further still: near-native smoothness on mid-range hardware.

On iOS, the equation is different. Every browser is powered by WKWebView, so performance is less of a concern. The gain there is simplicity: a single web implementation powering both platforms, rather than mixing separate web and native logic.

When WebViews Still Belong

WebViews still serve narrow use cases: ultra-strict native–web bridging, apps that must be fully offline from day one, or full control over the network stack. These are edge cases. For most consumer-facing web apps, the advantages of PWA + TWA with modern builds are overwhelming.

Conclusion

PWAs + TWAs let web teams deliver applications that are faster, safer, more capable, and more future-proof than their WebView equivalents. The PWA is your enhanced, installable web app. The TWA brings it into the Play Store, while preserving access to native SDKs like AppsFlyer or GeoComply. Differential builds on top of that unlock near-native speed.

In short: on Android, moving beyond WebViews makes your app feel ~20% faster for most users, while on iOS it avoids duplication and ensures a single implementation of logic across platforms. For web teams at scale, the future isn’t in wrapping the web—it’s in embracing it.

And if you’re wondering what this shift means for native developers, the answer is not redundancy but re-focus. Their work is becoming more important in a different way: embedding products into the surfaces of the operating system itself. That’s the subject of the next essay: Why Native Still Matters.