PWA to APK — Turn Your PWA Into a Signed Android App

How PWA to APK conversion works

Your app is a Trusted Web Activity (TWA): a lightweight Android app that opens your PWA fullscreen in the browser engine already on the phone — usually Chrome — with no address bar. It is the approach Google recommends for publishing a PWA on Google Play. Your code stays on your server, so every change you deploy to your site shows up in the installed app right away: no new release, no store review. No PWA, just HTML files on your computer? Start with HTML to APK, which shows how to put them online for free first.

Convert your PWA to APK in 4 steps

1. 1. Check your PWA

   Paste your URL in the checker above. In about ten seconds it tests your manifest, icons, service worker and HTTPS, and tells you exactly what to fix — with instructions for Lovable, Bubble, Webflow, Framer and more. Free, no account needed.

2. 2. Set your app identity

   Choose the app name, your package name — for example com.yourcompany.app — and your icon. Theme color, background and splash screen come from your manifest, and you can adjust them.

3. 3. Build

   A paid build gives you a signed AAB for Google Play and an APK to install on a device, both targeting Android 16 (API 36); the free test build is an APK with the SaasToStore logo. Your signing key is generated with your first paid build, stored encrypted and reused for every future update.

4. 4. Publish

   A paid build delivers the signed files each store asks for, starting with the AAB for Google Play. Put the generated assetlinks.json on your site so Android hides the address bar.

Which file for which job

The rule of thumb: the APK is for installing, the AAB is for publishing on Google Play.

• Testing on your own phone → APK

  Open the file on an Android phone and install it. That is also what the free test build gives you: an APK with the SaasToStore logo, so you can see your app before you publish it. An .aab cannot be opened on a phone.

• Sharing with a few testers → APK

  Send the file or a download link; each tester allows installs from that source once. For larger groups, the Google Play testing tracks use the same AAB as the public release.

• Publishing on Google Play → AAB

  Required for every new app since August 2021. Google Play builds an optimized APK for each device from it, and your users never notice the difference.

• Amazon Appstore, Samsung Galaxy Store or your own website → APK

  Outside Google Play, the APK is the file you upload or offer for download.

• Every update → the same key

  Whatever the format, an update must be signed with the same key as the first version. SaasToStore generates that key once per app, keeps it encrypted and reuses it on every paid build, for the APK and the AAB alike.

Is your PWA ready? The checklist

An APK built on a TWA starts from the web app manifest of your PWA. Before you build, check that you have:

Six mistakes that break PWA-to-APK apps

• The address bar shows up inside your app

  Android only hides it once it can verify that the app and the site belong to you, through a /.well-known/assetlinks.json file listing your package name and signing fingerprint. A paid SaasToStore build generates that file for you. Once your app is on Google Play, also add the fingerprint of Google's app signing key: Google re-signs your app, and without that line the bar comes back for everyone who installed it from the store.

• Losing the signing key

  Every update must be signed with the same key. Lose it and you have to go through Google's key reset process before you can ship again. Your keystore is generated with your first paid build, stored encrypted and reused automatically for every paid build.

• Changing the package name after launch

  On Google Play, a package name can never change. A new name means a new app, starting again from zero installs and zero reviews. Pick your own — com.yourcompany.app — from the very first build.

• Targeting an outdated Android version

  Since 31 August 2026, Google Play requires new apps and updates to target Android 16 (API 36). Tools that have not kept up produce builds that get rejected at upload. Every SaasToStore build targets API 36.

• Icons that get clipped

  Android shows icons inside a circle or a rounded square. Without a maskable icon — one with safe padding around the logo — your logo gets cropped or framed in white. Add a 512×512 maskable icon to your manifest.

• A start page on another domain

  If your app opens on a page outside the verified domain — a login hosted elsewhere, for instance — Android shows the address bar on that page. Keep your start_url and your main flows on the domain declared in assetlinks.json.

SaasToStore or doing it yourself with Bubblewrap?

Bubblewrap, Google's open-source command-line tool, produces the same kind of app, and it is a fine choice if you are at home in a terminal. The difference is everything around the build:

Updates without republishing

Because the app loads your live PWA, the changes you deploy to your site reach every installed app immediately — no new build, no store review. You only rebuild when the app shell changes: its name, icon, colors, or a new Android requirement. Rebuilds reuse the same signing key, so Google Play accepts them as updates.

The same PWA on iOS and desktop

The URL you convert to an APK can also become an iOS app for the App Store and desktop apps for Windows, macOS and Linux — from the same project, in the same dashboard.

Online converter: what runs where

The build runs on our servers, not on your machine. You need a browser and your URL — no Android Studio, no JDK, no Bubblewrap, no Gradle cache to keep warm. Nothing to install and nothing to keep up to date. It works the same from Windows, macOS, Linux or a Chromebook, because none of that toolchain ever touches your computer. What comes back from a paid build is the signed AAB and the APK, ready to upload.