# Google Play Store submission checklist for web apps Source: https://webnativeapp.com/google-play-store-submission-checklist-web-apps Description: A complete 2026 Google Play submission checklist for web apps, covering Android packaging, AAB signing, API 36, testing, store assets, data safety, and review. Publishing a web app on Google Play takes more than uploading your URL. You need a production-ready website, an Android package, a signed App Bundle, a complete store listing, accurate policy declarations, real-device testing, and a release that Google can review without getting blocked by your login screen. ## The three things every web app submission needs. Your live website remains the product, but Google reviews an Android app. The submitted app must be technically valid, accurately disclosed, and usable by both testers and reviewers. ### A release-ready web app HTTPS, mobile layouts, stable authentication, working uploads, clear error states, privacy information, and an account deletion flow when required. ### A signed Android App Bundle A permanent package identity, current target API, version code, release signing, tested WebView behavior, and an uploadable.aab file. ### A complete Play Console record Store assets, app access, Data safety, content rating, audience, ads, permissions, testing, and production release details. ## Complete these seven gates before production. Work through them in order. Account verification and web-app fixes can take longer than the final upload, so do not leave them until release day. 1. **Create and verify the right developer account:** Choose Personal only when publishing as an individual. Choose Organization when the app belongs to a registered business; organization accounts require a D-U-N-S number. Verify the identity, email, phone, address, and payments profile requested by Google. Full distribution has a one-time $25 registration fee. 2. **Make the web app production-ready:** Use a stable HTTPS production domain instead of a preview URL. Test registration, login, password reset, navigation, forms, file uploads, downloads, payments, and deep links on phone-sized screens. Add intentional loading, empty, offline, and server-error states instead of leaving users on a blank WebView. 3. **Package and sign the Android app:** Choose the package name carefully, set the app name and version, configure icons and launch assets, then build a release Android App Bundle. Enroll in Play App Signing and keep the upload key secure. Every future release needs a higher version code. 4. **Meet the 2026 technical requirements:** For phone and tablet apps, target Android 15 (API level 35) through August 30, 2026. Starting August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher. If the package includes native code and targets Android 15 or later, verify 16 KB page-size support. 5. **Build the store listing:** Add an accurate app title, an 80-character short description, a full description of up to 4,000 characters, a 512 by 512 PNG icon, a 1024 by 500 feature graphic, phone screenshots, category, contact details, and a working privacy-policy URL. The assets must show the experience users will actually receive. 6. **Complete every App content declaration:** Declare app access, ads, target audience, content rating, Data safety, account deletion, sensitive permissions, and any category-specific forms shown in Play Console. Include third-party SDKs and data handled by the website, not only data collected by the Android shell. 7. **Test, review, and roll out:** Upload the AAB to internal testing first, install it from Google Play, and test the release build on real devices. Complete closed testing when your account requires it, inspect the pre-launch report, resolve policy warnings, add release notes, and submit the production release for review. ## Test what usually breaks inside an Android shell. ### Navigation and links The Android back button should navigate through app history before closing the app. Decide which external links stay inside the app and which open in the browser. ### Authentication and cookies Test email login, social providers, passkeys, redirects, session persistence, and password reset from the installed release—not only from Chrome. ### Uploads and permissions Camera capture, document selection, downloads, geolocation, notifications, microphone access, and permission denial all need explicit device testing. ### Keyboard and safe areas Verify that the keyboard does not cover inputs or buttons and that headers, dialogs, and bottom navigation remain usable on different screen sizes. ### Offline and server failures Show a useful retry screen when the website cannot load. Test airplane mode, slow connections, expired sessions, maintenance pages, and app resume. ### Payments If the app sells digital goods or in-app functionality, Google Play Billing is generally required unless an exception or an enrolled alternative-billing program applies. Physical goods and services follow different rules. ## Make the declarations match the real app. Google compares the submitted experience, your store listing, and the answers in Play Console. Review the whole system: Android shell, live website, analytics, authentication, payments, and third-party services. ### Privacy and data - Publish a public, active, non-PDF privacy-policy URL. - Name the app or developer entity in the policy. - Declare data collection and sharing by the site and every SDK. - State whether data is encrypted in transit and whether deletion is available. - Keep the Data safety form consistent with the privacy policy. ### Reviewer access - Provide a working reusable demo account when login is required. - Explain OTP, two-factor authentication, membership, and location restrictions. - Keep the test backend and account active throughout review. - Describe any steps needed to reach restricted features. - Remove placeholder screens, broken links, and unfinished flows. ### Account deletion - Add a discoverable deletion path inside the app when users can create accounts. - Provide an external deletion-request webpage. - Delete the account and associated user data—not just disable access. - Explain legally required retention in the privacy policy. - Enter the external deletion URL in Play Console. ### Content and monetization - Declare ads even when an embedded website or SDK displays them. - Complete the content-rating and target-audience questionnaires accurately. - Check Google Play Billing rules before selling digital access. - Request only permissions that support visible app functionality. - Complete any health, financial, news, or other category declaration shown. ## Use the release build—not a browser preview. Signing, minification, WebView storage, OAuth, permissions, and device behavior can differ in the bundle users install from Google Play. 1. **Start with internal testing:** Upload the release AAB and distribute it to a small trusted group. Install from the Play-generated test link so you test the same delivery path users will receive. 2. **Check the pre-launch report:** Review automated device results for crashes, display problems, compatibility, accessibility, and security findings. Reproduce important failures on a real device. 3. **Complete mandatory closed testing:** Personal accounts created after November 13, 2023 must keep at least 12 testers opted into a closed test continuously for 14 days, then apply for production access and answer Google's testing-readiness questions. 4. **Run a final reviewer test:** Install a clean copy, use the exact credentials supplied in App access, reach every gated feature, trigger a password reset, deny permissions, make a permitted test purchase, and confirm the privacy and deletion links work. ## Keep the web app. Add the Android release layer. WebNativeApp turns the production website you already control into an Android app project, so you can focus on the product while the mobile package carries the app identity, launch experience, native configuration, and Google Play build. 1. **Submit the production URL:** Start from the live web app your Android users should open. 2. **Prepare the Android project:** Add app identity, launch assets, signing information, and the mobile configuration. 3. **Test and submit:** Install the Play release, complete the console declarations, and move through the required testing track. ## Do not click Submit until every answer is yes. ### Build and experience - The production AAB installs from a Google Play testing track. - The target API meets the requirement in effect on submission day. - Login, back navigation, links, uploads, and permissions work. - Offline and server failures show a useful recovery screen. - No test content, debug menus, or placeholder screens remain. ### Console and review - Descriptions and screenshots match the submitted build. - Reviewer credentials work from a clean device. - Data safety includes the website and third-party SDKs. - Privacy and account-deletion URLs are public and functional. - All App content items show as completed with no blocking warnings. ## Requirements verified for this 2026 checklist. [Target API level requirements](https://support.google.com/googleplay/android-developer/answer/11926878) [Testing for new personal accounts](https://support.google.com/googleplay/android-developer/answer/14151465) [Prepare an app for review](https://support.google.com/googleplay/android-developer/answer/9859455) [Complete the Data safety form](https://support.google.com/googleplay/android-developer/answer/10787469) [Account deletion requirements](https://support.google.com/googleplay/android-developer/answer/13327111) [Store listing asset requirements](https://support.google.com/googleplay/android-developer/answer/9866151) [Create and set up an app](https://support.google.com/googleplay/android-developer/answer/9859152) [16 KB page-size support](https://developer.android.com/guide/practices/page-sizes) ## Google Play submission questions ### Can I publish a web app directly to Google Play? Not as a website URL alone. You must package the web app as an Android application, create a signed Android App Bundle, and submit that bundle through Play Console. A native WebView shell or a Trusted Web Activity are two possible packaging approaches. ### Does Google Play require an AAB or an APK? Use an Android App Bundle, or AAB, for a new Google Play release. Google Play uses the bundle to generate optimized APKs for each device. APK files remain useful for direct device testing. ### Do I need 12 testers for 14 days before publishing? This requirement applies to personal developer accounts created after November 13, 2023. Those accounts must run a closed test with at least 12 testers continuously opted in for 14 days before applying for production access. ### Which Android API level is required in 2026? New phone and tablet apps must target Android 15, API level 35, through August 30, 2026. Starting August 31, 2026, new apps and app updates must target Android 16, API level 36, or higher. ### Does my web app need an account deletion page? If users can create an account, Google requires a discoverable in-app deletion path and an external web resource where users can request account and associated data deletion. Enter the external URL in Play Console. ## Prepare the Android app behind the checklist. [Convert a web app to Android without Android Studio](https://webnativeapp.com/convert-web-app-to-android-without-android-studio) [Publish a Lovable app to Google Play](https://webnativeapp.com/lovable-to-google-play) [Web app to mobile app](https://webnativeapp.com/web-app-to-mobile-app) [PWA to app store](https://webnativeapp.com/pwa-to-app-store) [Website to app cost](https://webnativeapp.com/how-much-does-it-cost-to-turn-a-website-into-an-app) ## Turn your web app into a Google Play-ready Android project. Paste the production URL you already own. Keep your web product and add the Android package needed to test and submit it through Google Play.