When you run your first build on WebToAppConvert, two things appear almost immediately. A debug APK is free and arrives in minutes. A signed AAB takes a little longer, costs credits, and has a different file extension. If you are new to Android, the distinction matters more than it might seem.
The Debug APK
APK stands for Android Package Kit. It is the traditional file format for Android apps: a single archive containing the app's code, resources, and a manifest describing what the app needs from the device. A debug APK is signed with an automatically generated debug certificate, a credential Android creates for development and testing. It is not a real production signing key.
What a debug APK can do: install directly on any Android device with USB debugging enabled or with "install from unknown sources" turned on in settings, then run and behave exactly like the final app. Every navigation, every WebView interaction, every permission request: it all works the same as it would in production. For WebToAppConvert builds specifically, the debug APK includes a small watermark identifying it as a test build.
What a debug APK cannot do: be submitted to Google Play, be distributed to users, or serve as the basis for future update submissions. Google Play rejects debug-signed builds outright. This is by design: the debug certificate is not your identity as a publisher.
The Signed AAB
AAB stands for Android App Bundle. It is the format Google Play has required for all new app submissions since August 2021. The difference from an APK is how it is packaged: an AAB contains your app's code and resources in a modular structure, and Google Play uses it to generate optimized APKs tailored to each device. A user downloading your app gets a version compiled specifically for their screen density and processor architecture, rather than one large file that covers every possible combination.
A signed AAB is signed with your actual production signing key, not a debug certificate. This is the file you upload to Google Play Console. The signature establishes your identity as the publisher: only future uploads signed with the same key can update the same listing.
The Right Workflow
Always run the debug APK first. It is free, fast, and shows exactly what your app will look and behave like before you spend credits on a production build. Install it on a real Android device. Check that your website loads correctly, that navigation and the back button work as expected, that your icon and splash screen look right on an actual screen, and that any checkout or login flows behave properly. Find problems in the debug phase.
Once you are satisfied, run the production build for the signed AAB to submit to Google Play.
Signed APKs for Direct Distribution
WebToAppConvert also offers a Starter build tier that produces a signed APK rather than an AAB. This is for situations where direct distribution makes more sense than the Play Store: enterprise internal deployments, closed beta groups, or distributing to a specific audience that installs apps directly. A signed APK from the Starter tier is production-signed and can be installed without the Play Store, provided the device has "install from unknown sources" enabled. It does not include the Professional tier features (push notifications and AdMob).
Versioning
Every build you submit to Google Play must have a higher versionCode than the previous submission. This is an integer Google Play uses to determine which version is newer. Submit two builds with the same versionCode and Play Console rejects the second one.
WebToAppConvert handles versionCode incrementing automatically. The versionName, the human-readable string like "1.2.0" that users see in the Play Store, you can set to whatever fits your release cadence. The versionCode just needs to go up with each submission.
Run a free debug build and see your app before you commit to anything →