From PWA to Native: What You Need to Know
Progressive Web Apps were supposed to be the future. Install a website to your home screen, get push notifications, work offline — all without the App Store middleman.
That vision was compelling. And for some use cases, PWAs deliver. But if you’ve tried to build a serious product as a PWA, you’ve probably run into the walls.
Where PWAs Work Well
Let’s give credit where it’s due. PWAs are great for:
- Content-heavy sites that benefit from home screen access (news, blogs, recipes)
- Simple utilities that don’t need background processing (calculators, converters)
- Internal tools where you control the device and browser
- Markets where app store access is limited or where users have low storage
If your product fits one of these categories, a PWA might be all you need. Don’t over-engineer it.
Where PWAs Hit the Wall
For everything else, the limitations stack up fast.
Push Notifications on iOS
Apple finally added web push notification support to iOS in 2023 — but with significant restrictions. The user must add the PWA to their home screen first, and the notification UX is noticeably different from native apps. Delivery reliability is lower, and there’s no way to badge the app icon the way native apps can.
For products where notifications are critical to engagement, this gap matters.
No App Store Discovery
PWAs can’t be listed in the App Store or Google Play (with limited exceptions via TWAs on Android). This means you miss out on the entire app store discovery funnel — the search rankings, the featured lists, the “Similar Apps” recommendations.
For consumer products competing for attention, app store presence isn’t optional. It’s a primary acquisition channel.
Background Processing
PWAs can use service workers for basic background sync, but they can’t run persistent background tasks. Need to sync data in the background, process uploads, or maintain a WebSocket connection while the app is minimized? Native apps can do this. PWAs can’t — at least not reliably across all platforms.
Device API Access
Despite the progress of Project Fugu and other web capability initiatives, PWAs still can’t access many device APIs that native apps take for granted:
- Bluetooth (limited)
- NFC (limited)
- HealthKit / Google Fit
- Contacts (read-only on some browsers)
- File system (limited via File System Access API)
- Background location
- Widgets
If your product roadmap includes any deep device integration, you’ll eventually need native code.
Storage and Persistence
Browsers can and do evict PWA data when storage pressure is high. There’s no guarantee that your locally stored data will survive. Native apps get dedicated storage that persists until the user explicitly deletes the app.
For apps that store important user data locally — offline-first tools, editors, health trackers — this is a dealbreaker.
The Hybrid Path: Web App in a Native Shell
There’s a middle ground that gives you the best of both worlds: keep your web app as the core, but wrap it in a native container that provides:
- App store distribution and discovery
- Reliable push notifications
- Native splash screens and app icons
- Access to native APIs via bridges
- Proper offline handling with native storage
This is the approach that companies like Basecamp, Notion, and Slack have used — a web view backed by native code where it matters.
The challenge has always been the setup and maintenance overhead. Configuring Xcode projects, managing signing certificates, handling store submissions, keeping up with platform requirements — it’s a lot of work that has nothing to do with building your actual product.
Where shipable Fits In
shipable automates the entire web-to-native pipeline. You point it at your web app, and it handles the native wrapper, compliance checking, store asset generation, and submission process.
No Xcode. No Android Studio. No second codebase.
Your web app stays your web app. You just get the native distribution and capabilities on top.
Making the Decision
Here’s a simple framework:
| Factor | PWA | Native (via wrapper) |
|---|---|---|
| Development cost | Low | Low (with tooling) |
| App Store presence | No | Yes |
| Push notifications | Unreliable on iOS | Reliable |
| Offline support | Basic | Full |
| Device API access | Limited | Full |
| Maintenance overhead | Low | Low (with tooling) |
If app store distribution, notifications, or device APIs matter for your product, the web-to-native path is worth it — especially when tooling removes the setup burden.
The era of choosing between web and native is ending. The smart move is to ship both from the same codebase.