PWA vs Native App: Why I Stopped Recommending PWAs for Most Clients

I was a PWA maximalist. In 2021, I gave a conference talk titled "Native Apps Are Dead." Three years later, I'm building native app wrappers and recommending them to clients. Here's what changed.

The PWA Promise (It Was Compelling)

Progressive Web Apps offered something magical:

• Write once, run everywhere (web, iOS, Android)
• No app store approval process
• Automatic updates without user action
• Offline capability with service workers
• Push notifications (on Android)
• Add to home screen (with that sweet app icon)

For developers, it was the dream. One codebase. No Apple tax. No Play Store politics.

Where PWAs Actually Fail

Then I started building PWAs for real clients with real users. The gaps became impossible to ignore:

1. iOS Push Notifications Are Broken

Yes, Apple added PWA push support in iOS 16.4. In practice:

• Users must explicitly add the PWA to home screen first
• The permission prompt is buried and confusing
• Delivery is less reliable than native APNs
• Most users don't even know "Add to Home Screen" exists

2. No App Store Discovery

"But you don't need the app store!" That's what I told clients. Then I watched their competitors rank for "[category] app" searches while my clients were invisible.

The App Store and Play Store are discovery engines. People search them. "Food delivery app." "Budgeting app." "Local news app." If you're not there, you don't exist to casual searchers.

3. The "Second-Class Citizen" Experience

PWAs on iOS feel off. Small things add up:

• No smooth gesture-based navigation
• The notch/safe area handling is janky
• Pull-to-refresh doesn't feel native
• iOS kills background PWAs aggressively — your "offline" app isn't really offline

4. Biometric Auth Limitations

WebAuthn exists, but try explaining to a user why your PWA's Face ID prompt looks different from every other app. Trust erodes in small moments.

When PWAs Still Win

I'm not saying PWAs are useless. They're great for:

• Internal tools: Company dashboards where you control the device and can enforce Chrome
• Emerging markets: Where "data lite" matters more than polish
• One-time experiences: Event apps, conference schedules, menus
• Android-only audiences: Where PWA support is genuinely good

The Hybrid Approach I Now Recommend

For most clients, here's the practical strategy:

1. Build a responsive website — this is your primary product
2. Wrap it in a native shell — WKWebView for iOS, WebView for Android
3. Add a native bridge — for push, biometrics, and device features
4. Publish to app stores — for discovery and credibility
5. Add the app link on your website — "Get our app" banner

You get 90% of the code-sharing benefits of PWAs, but with native distribution and features.

The Numbers That Changed My Mind

From a real client migration (e-commerce, 50k monthly users):

Metric	PWA	Native Wrapper
Push opt-in rate	8%	52%
App Store installs/month	0 (n/a)	1,200
Session duration	2m 10s	3m 45s
Conversion rate	1.8%	3.2%

The native wrapper wasn't better because WKWebView is magic. It was better because users treat "apps" differently than "websites." Psychology matters.

My Current Stack

For new client projects:

• Website: Next.js or Nuxt with SSR for SEO
• Android: WebView wrapper with NativeBridge (Kotlin)
• iOS: WKWebView wrapper with NativeBridge (Swift)
• Push: OneSignal or Firebase (works with both native and web)
• Auth: Shared cookies between web and app

One codebase for the UI, native wrappers for distribution. Best of both worlds.