I run a small meal-planning app called DinnerDash. It's a Progressive Web App at the core — a Flask backend, a JavaScript frontend, all the recipes rendered server-side. To get on Google Play I wrapped it in a Trusted Web Activity (TWA) using Bubblewrap. Took half a day. It's now live, signed, and being downloaded.
I figured the same approach would work for the App Store. It does not.
Google's stance: a TWA is a real Android app
Google explicitly built the TWA as a first-class way to ship a PWA on Android. Once you sign the AAB, configure assetlinks.json so the OS knows your domain owns the app, and complete the developer agreement, Play Console treats it like any other native app. Reviews are quick. Approvals are routine.
This is the right model for indie devs who already have a working PWA. Half a weekend of work and you're on Play Store with the same codebase that runs on the web. Updates ship by deploying your web backend — no store re-review needed for content changes.
Apple's stance: a TWA-equivalent is not a real iOS app
The closest iOS equivalent to a TWA is a WKWebView wrapper — typically built with Capacitor, Cordova, or a hand-rolled Xcode project. It loads your PWA inside a native container. Visually identical to the TWA experience.
Apple's App Store Review Guideline 4.2 (Minimum Functionality) explicitly addresses this:
"Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."
And Guideline 4.2.3:
"Your app should be a unified app that runs natively on iOS, not just a website wrapped in WebView."
Apple's reviewers see thousands of these submissions a year. They have a templated rejection — almost word for word: "We found that the experience your app provides is not sufficiently different from a mobile browsing experience." Submit a clean WebView wrapper to Apple and you get the rejection back within 24–48 hours, every time.
What Apple actually wants to see
To get a hybrid app (Capacitor or similar) past Apple's review, you need features that meaningfully don't exist in mobile Safari. The list reviewers look for:
- Native push notifications — not web push, the real APNs kind
- Sign in with Apple — mandatory if you have any other login method on iOS
- iOS Share Sheet integration — not a web share API call, the real one
- Haptic feedback — taps, swipes, success confirmations
- iOS Home Screen widgets — even a simple one counts
- Siri Shortcuts — voice integration
- Offline mode using native storage so it works on the subway
You don't need all seven. Three or four legitimately implemented is usually enough to get through review. The reviewer checks "is this materially more useful than the website" and ticks yes.
The three real options
Once I understood Apple's rules, I had to pick a path:
| Path | Effort | Outcome |
|---|---|---|
| Skip iOS | Zero | Play Store + web only. ~50% of US smartphone users reachable. The honest indie play. |
| Capacitor + native features | ~30–60 hours | Submit-able. Capacitor wrapper + push notifications, share sheet, haptics, Sign in with Apple, etc. ~50% first-review rejection rate even when done well. |
| React Native rewrite | ~150+ hours | Approval-safe. UI re-built natively. Backend stays where it is. Approval rate ~90% on first submission. |
How I'm actually deciding for DinnerDash
For DinnerDash specifically I'm skipping iOS for now. Three reasons:
- It's already shipped on Play Store with users — that distribution channel works
- It's a side project, not my primary income; the 30–60 hours of Capacitor work has better uses
- Apple's borderline-WebView rejection cycle takes 3–6 round-trips; I'd be in review hell for a month
If DinnerDash starts pulling real Play Store metrics — 10k+ installs, retention numbers worth defending — I'll invest the 30–60 hours of Capacitor work and submit a hybrid version. Until then, the math doesn't add up.
For my baby-name app: rebuild as React Native
The flip side of this decision is my other app, BabyNa.me. That one I'm building from the start in Expo (React Native). Two reasons:
- It's positioned for both stores from day one — App Store traffic is half the market and I'm not skipping it
- Expo apps render every component to native UIView. Apple's reviewers see "real iOS app" within seconds. Approval rate jumps to ~90% on first try
Same backend (the babyna.me web app), different client. The Expo client calls the existing API. Pixel-perfect typography because I'm using the real font, not a CSS approximation.
The decision tree
Pulling back: here's the question to ask before you wrap a PWA for the App Store.
Is your app already shipping real revenue or strong engagement on the web? If yes: Capacitor hybrid is worth the 30–60 hours. Apple will probably let you in if you implement 3+ native features properly.
Is it a side project with unproven demand? If yes: skip iOS. Ship Android only. Validate. Come back to iOS when the data justifies it.
Are you starting from scratch and want both stores? If yes: build it in Expo from day one. The same JavaScript-React knowledge ports. Apple's review treats it as a real iOS app. Skip the WebView question entirely.
The TWA model on Android is a gift to indie devs. Apple deciding not to offer the equivalent has shaped the entire iOS-vs-Android indie launch playbook for the last five years. Knowing the rule going in saves a lot of wasted submissions.