How to publish a web app on Google Play (2026)

Why a Google Play listing matters for a SaaS

A browser tab competes with every other open tab. An installed app has its own icon on the home screen, in front of the user each time they unlock their phone. For a SaaS people come back to every day, that difference is not cosmetic: it shows up in retention.

What the Play Store actually checks

Google Play's automated review for web app packages checks four things:

• Target API level — must be 36 (Android 16) for all new apps and updates since 31 August 2026.
• Minimum functionality — under Google's rules on spam and minimum functionality, the app must do something useful. A single-screen static page fails; a multi-screen app, a SaaS dashboard, or a content platform passes.
• Data Safety form — you must declare what data your app collects (even if it's just analytics). Required for every app.
• Valid signature — the .aab must be signed with a keystore. The same keystore must be used for every future update of that package name.

TWA vs Capacitor: picking the right build for your web app

The build method you choose affects app size, PWA feature access, and Play Store compatibility. Both produce a valid .aab — the difference is what happens at runtime.

The practical rule: if your site is already a PWA, TWA gives you a smaller, lighter app that shares the user's Chrome session. If your site has no web manifest or you want native push notifications, use Capacitor. SaasToStore recommends one based on your PWA check result, and you choose in the build selector.

Step-by-step: from web app URL to Play Store

1. 1. Run a PWA check

   Paste your URL into a free PWA checker. This tells you your manifest score, whether you have a service worker, and whether TWA or Capacitor is the right build path. Takes 10 seconds.

2. 2. Configure your app identity

   Set a package name in reverse-domain format (com.yourcompany.appname). This is permanent — it identifies your app in Play Store forever. Set it once; never change it. Also choose an app name (≤ 30 chars for Play Store) and upload a 512×512px icon.

3. 3. Build the signed .aab

   A paid SaasToStore build generates the signed Android App Bundle. Your keystore is created at the first paid build, stored encrypted and reused for every update; its password is emailed to you once. The build targets API level 36 (Android 16) automatically and takes a few minutes.

4. 4. Create a Play Console account

   Register at play.google.com/console and pay the one-time 25$ developer fee. Identity verification is required (Google checks ID against the account). Approval usually takes 1–2 days.

5. 5. Create a new app and upload

   In Play Console, create a new app → Production track → upload the .aab. Complete the required sections: app content, target audience, Data Safety declaration, content rating questionnaire, privacy policy URL. Then submit for review.

   The store listing itself needs a 512×512 icon, a 1024×500 feature graphic, at least two phone screenshots, a short description of up to 80 characters and a full description of up to 4,000. SaasToStore can generate the icon, the feature graphic, the screenshots and a first draft of the descriptions for you.

What it costs to publish

On Google's side, the developer registration from step 4 is a one-time 25$ fee, and it covers every app you publish from that account. The other cost is producing the signed bundle. By hand, the tools are free: Google's Bubblewrap CLI for a TWA, the Capacitor CLI for a native shell. The price is your time: you install and maintain the Android SDK and Java, debug the build failures and keep a signing key you can never lose. A hosted builder runs all of that for you and keeps the key safe for every update.

With SaasToStore, the free test build is an APK with the SaasToStore logo, to see the app on your own phone. The .aab you upload to Google Play comes with a paid build: see pricing.

2026 compliance: what changed

Common rejection reasons for web app packages

• Minimum functionality — under Google's rules on spam and minimum functionality, your site must have real interactivity. A marketing landing page with one CTA gets rejected. A SaaS dashboard, a productivity app, a content platform all pass.
• Broken deep links — if tapping a link inside your app opens the system browser instead of staying in-app, reviewers flag this as low quality. Keep all navigation inside the WebView shell.
• Wrong keystore on update — updating an existing app with a different keystore causes an upload error. Always store your keystore securely and reuse it for every update.
• Missing privacy policy — required for all apps. Link a public URL in your Play Console listing.
• Digital goods sold outside Play Billing — if your app sells digital content or subscriptions, Play Billing is mandatory in most countries. Don't send users from the app to a web checkout instead: Google Play's payment rules restrict it.

SaaS specifics: sign-in and push notifications

Sign-in: mostly nothing to change

Your existing auth (Supabase, Auth0, Clerk, your own sessions) keeps working in the app. Email and password and one-time codes behave as on your site; magic links too, once deep links send them to the app. In a TWA, the app shares Chrome's cookies, so a user already signed in on Chrome on that phone is often signed in in the app as well. A native Capacitor build keeps its own session: users sign in once in the app. The exception is Google: it refuses its sign-in inside an embedded web view, so the native app sends "Sign in with Google" to the system browser and brings the user back. That return needs one address allowed in your auth provider, explained in the sign-in docs.

Push notifications for retention

Push is the main retention lever a store app gives a SaaS. The messages that work best:

• — Trial ending in 3 days, with a link to upgrade
• — New activity on something the user follows: a comment, a mention, an update
• — A weekly summary, or a usage milestone reached
• — A new feature, sent to active users
• — A nudge after 7 days without a visit

In the native build, notifications come from the app itself: your site's browser notifications don't carry over into it.

Keeping the app up to date

One of the main advantages of a web app wrapper: your content is always live. When you deploy a fix or a new feature to your website, every user sees it immediately — no Play Store update required. You only rebuild and resubmit when:

• — You change the app name, icon, or splash screen
• — You add a native capability (push notifications, biometric auth)
• — Google raises the minimum target API level
• — Your package version code needs to increment for a store policy reason

For everything else — UI changes, new pages, feature releases — deploy to your website and the app updates itself.

Beyond Google Play

The same build session that produces your Google Play AAB can also generate a Windows .msi, macOS .dmg, and Linux .AppImage — published to the Microsoft Store, the Snap Store, Flathub, and GitHub Releases. If you're going to package your web app once, there's no marginal cost to reaching all 7 stores in the same build.

On Android, the same app also goes to the Amazon Appstore and the Samsung Galaxy Store, and the same URL builds an iPhone app for the App Store. Built your site with a no-code tool? See the guides for Lovable, Bubble and Webflow.