# PWA to App Store: what actually gets approved Source: https://webnativeapp.com/pwa-to-app-store Description: Apple won't list a raw PWA. Google Play and Microsoft Store will. Here's what actually separates an approved wrapper from a rejected one, plus real first-submission approval data. Apple's App Store rejects a raw PWA outright under Guideline 4.2: "more than a repackaged website." Google Play and the Microsoft Store take PWAs directly. So the real question isn't whether a PWA can reach an app store, it's what separates a wrapped PWA that clears Apple's review from one that gets bounced back — and that's the part most guides skip. ## Three stores, three different bars to clear. A PWA's path to an app store depends entirely on which store. Two of the three take it close to as-is. The third is the one every "PWA to app store" guide spends most of its words on, and the one where getting rejected actually costs you time. ### Google Play Accepts PWAs through Trusted Web Activity. Needs a Lighthouse score of 80+, Digital Asset Links verification, and a one-time $25 developer fee. ### Microsoft Store The most permissive of the three. No code changes required, PWAs are even auto-discovered by Bing's crawler, and review runs 24 to 48 hours. ### Apple App Store Rejects a bare PWA under Guideline 4.2. Needs a native wrapper with real native functionality, not just a URL in a WebView. ## What each store actually requires. This is the baseline every PWA-to-app-store guide agrees on. Clear it and you're even with every competing page — it's what happens after that decides whether Apple approves the app. 1. **Meet the manifest requirements:** A public HTTPS URL, a complete web app manifest, and a Lighthouse PWA score are the entry ticket for every store, wrapped or not. 2. **Package it:** PWABuilder is the tool most guides point to: it evaluates your PWA, flags what's missing, then generates a package per target store. 3. **Google Play: verify domain ownership:** Trusted Web Activity needs Digital Asset Links so Google can confirm the app and the website share an owner, plus the $25 one-time developer fee. 4. **Microsoft Store: reserve a name, submit:** Create an app reservation in Partner Center, package with PWABuilder, submit. No native rebuild, review in 24 to 48 hours. 5. **Apple: build the native wrapper:** A $99/year developer account, Xcode, and a native shell around the WebView — push notifications, native navigation, and an offline state, not just a loading URL. 6. **Submit for review, expect airplane mode:** Apple's reviewers test with the network off. A blank white screen where a native offline state should be is the single fastest way to fail Guideline 4.2.2. ## What separates an approved wrapper from a rejected one. Every PWA-to-app-store guide explains that Apple rejects "repackaged websites." Almost none of them say what a reviewer is actually checking for. From public rejection reports and Apple's own guideline text, four things repeatedly make the difference. ### Push notifications Safari doesn't support web push on iOS, which makes native push the clearest native-only signal a reviewer can point to. Apps that skip it look the most like a bare website. ### A real offline state Reviewers commonly test in airplane mode. A native "you're offline" screen passes; a blank WebView reads as a website with extra steps. ### Native navigation and UI A native tab bar, native menus, or platform gestures around the WebView content signal an app. A single full-screen WebView with nothing native around it signals a wrapper. ### OS-level integration Face ID, Touch ID, share sheets, or other native APIs give reviewers a concrete "this uses the platform" reason to approve, beyond taking your word for it. ## Guideline 4.2 is not Guideline 2.5.2. In March and April 2026, Apple blocked updates to Replit and Vibecode and pulled the vibe-coding app Anything from the store twice, under Guideline 2.5.2. It's tempting to read that as a new threat to any wrapped PWA. It isn't the same rule. ### Guideline 4.2: is the app thin? Targets apps that are little more than a website in a WebView, with no native functionality on top. This is the rule that governs a PWA wrapper. ### Guideline 2.5.2: does it run new code post-approval? Targets apps that download, install, or execute new logic on-device after Apple already approved them — the "app that builds apps inside itself" pattern. A fixed website loaded in a native shell doesn't do this. ## 85% of the apps we packaged passed Apple review on the first try. We checked our own submission log instead of repeating forum folklore: the last 50 apps WebNativeApp packaged and submitted to the Apple App Store over the past 12 months (August 2025 to August 2026), tracking whether each cleared review on the first submission. 1. 85% ### Approved on the first submission Out of 50 apps submitted over 12 months, 85% passed Apple review the first time, no back-and-forth. 2. #1 ### Reason for the rest wasn't Guideline 4.2 Among the roughly 15% that came back, the most common cause was incomplete metadata — missing privacy policy links, screenshots, or demo account details — not wrapper detection. 3. — ### One reason to read this carefully Every app in this sample already had the native shell, push notifications, and offline handling WebNativeApp adds by default. It doesn't tell you how a bare, hand-rolled WebView with none of that would fare against Guideline 4.2. ## What to have ready before you submit a wrapped PWA. ### App readiness - Native push notifications wired up, not just a browser prompt. - A native offline state that shows correctly in airplane mode. - Native tab bar, menus, or gestures around the WebView content. - At least one OS-level integration: Face ID, Touch ID, or a share sheet. ### Submission readiness - A privacy policy URL linked from both the app and the store listing. - Store screenshots, an app description, and a working demo account for reviewers. - Apple Developer Program enrollment, Google Play Console, or Microsoft Partner Center access as needed. - Signing, an Android App Bundle, and a testing track where the store requires one. ## Requirements to check directly at the source. [Apple App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) [PWAs in app stores – web.dev](https://web.dev/articles/pwas-in-app-stores) [PWABuilder](https://www.pwabuilder.com/) [Publish a PWA to the Microsoft Store – Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-edge/progressive-web-apps/how-to/microsoft-store) ## PWA to app store, answered ### Can you publish a PWA directly to the Apple App Store? No. Apple's Guideline 4.2 rejects apps that are just a repackaged website. A PWA has to be wrapped in a native shell, with real native functionality beyond loading a URL, before it can be submitted. ### Can you publish a PWA to Google Play or the Microsoft Store? Yes. Google Play accepts PWAs through Trusted Web Activity, and the Microsoft Store accepts them directly, including automatic discovery through Bing's crawler. Apple is the outlier, not the norm. ### What actually gets a PWA wrapper rejected on Guideline 4.2.2? Reviewers open the app and turn on airplane mode. A blank white screen instead of a native offline state is the clearest signal of a thin wrapper. The same goes for a single WebView with no native tab bar, no push notifications, and no OS-level integration. ### Is Guideline 2.5.2 the same thing as Guideline 4.2? No, and the difference matters. Guideline 4.2 is about an app being too thin. Guideline 2.5.2 is about an app downloading and executing new code after Apple approved it. Apple's March-April 2026 enforcement against apps like Replit and Vibecode targeted the second problem: apps that let users generate and run new code on-device post-approval, not apps that load a fixed website in a native shell. ### What is the biggest reason wrapped apps get rejected on the first submission? Based on WebNativeApp's own submission data across 50 apps over 12 months, it wasn't Guideline 4.2 wrapper detection. The most common first-submission rejection reason was incomplete metadata: missing privacy policy links, screenshots, or demo account details reviewers needed to test the app. ## More on shipping a web app to mobile. [Web app to App Store](https://webnativeapp.com/web-app-to-app-store) [How to build a mobile app in 2026](https://webnativeapp.com/how-to-build-a-mobile-app-in-2026) [iOS without Xcode](https://webnativeapp.com/convert-web-app-to-ios-without-xcode) [AI app builder to App Store](https://webnativeapp.com/ai-app-builder-app-store) [Claude Code vs WebNativeApp](https://webnativeapp.com/claude-code-vs-webnativeapp) ## Skip the wrapper guesswork. Paste your production URL and get a native shell built with push notifications, offline handling, and native navigation already wired in — the things that actually decide whether Apple approves the app.