Publish a Base44 App to Google Play: AAB and 12 Testers

Short answer: Base44 builds the AAB, but your 14-day closed test sets the launch date

Base44 can generate a Google Play-ready Android App Bundle from inside its app editor. You open your app, click Publish, switch to the Mobile app tab, run the store-readiness scan, then generate the Google Play files and download the .aab. Uploading it and everything after that happens by hand in Play Console: Base44's own documentation states that Customer Care "does not track the progress of your submission, contact Apple or Google, or manage conversations with the review teams."

The build step takes minutes. The waiting does not. If your Play Console account is a personal one created after 13 November 2023, Google requires that you "run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" before you can even apply for production access (Play Console Help). That rule does not care what your app was built with — Base44, Replit or Android Studio, the 14 days are the same 14 days.

What is a Base44 mobile app, technically?

Start here, because it decides everything downstream. A Base44 Android app is not a compiled build of your code. Base44 documents it plainly: "Your mobile app runs your published Base44 app inside a secure web view. This is a lightweight native wrapper around your web app that opens only your app's URL." Two consequences follow immediately.

First, most of your work reaches users without any store release. Content and layout changes you publish in Base44 appear in the installed app as soon as they go live, because the app is loading your live URL. Second, the app needs a stable public URL. Base44 confirms a custom domain is not required for submission — the default Base44 URL is accepted by both stores — but the app must be published, not a draft or a preview.

You only need a new store build when the wrapper itself changes: the app name, icon or splash screen, a new device permission, or push notifications. Knowing that boundary saves a lot of pointless build-and-resubmit cycles after launch.

The package name is assigned and permanent. Base44 sets it to com.base[app-id].app — for example, if your editor URL contains the app ID 69e0c4bdd31bdu8fda51775g, your package name is com.base69e0c4bdd31bdu8fda51775g.app. There is no setting to pick a com.yourcompany.app name. That is not just a Base44 limitation; it mirrors Google's own rule: "Once you upload an artifact, the package name for that app is fixed and cannot be changed" (Play Console Help). Every Firebase project, Google sign-in configuration and OAuth client you wire up must use this exact value, and it stays with the listing forever.

What do you need before generating Google Play files?

Base44's checklist is short, but two items on it catch people.

• A published Base44 app with a stable URL. The mobile app wraps the published version, so fix and publish everything important first.
• The Builder plan or higher. Free plans can run the store-readiness scan, but downloading the generated .aab requires Builder or above. Check this before you plan a launch week.
• A Google Play developer account you control (the one-time registration fee is US$25, per Google's account types page). If it is a personal account created after 13 November 2023, the 12-tester closed test applies to you.
• An app logo that meets Google's icon requirements — or generate one with AI inside the flow. The logo you confirm there becomes both the Play listing icon source and the splash-screen logo.
• A privacy policy and terms of use, reachable from your app's entry pages before a user signs up. Both stores require this, and Base44 flags it as a common review problem when the links only exist inside a members-only area.
• Firebase project files, if you want push notifications or if your app logs in with Google (more on both below).

Step 1: Scan your app against Google Play guidelines

In the Base44 app editor: Publish (top right) → Mobile app tab → Check Your App → Run App Scan → choose Google Play guidelines. The scan returns a Readiness Score with passed, partial and failed checks.

Base44 is explicit that you do not need a score of 100 to submit; what it recommends is no unresolved critical issues before you generate files. Each failed check offers two paths: Apply with AI, which opens the AI chat with a fix prompt built from the scan, or Copy Fix Prompt, if you would rather review the change yourself first. Publish the fixes, re-test sign-up, login and checkout in preview, then run the scan again.

One honest caveat: this readiness score is Base44's own proxy, not a Google review. Base44 states it cannot guarantee approval even with a high score, and Play review still evaluates your app, your listing and your answers separately.

Step 2: Generate the Google Play AAB

Same tab, next action: Publish → Mobile app → Build Store Files → Create Google Play files. Confirm or regenerate the logo, toggle Add push notifications if you need them, then Generate Files and Download. The result is a signed Android App Bundle — the format Google has required for new apps since August 2021 (Android Developers) — which you upload yourself in Play Console when you create the closed testing release. Base44 configures the signing key automatically; you do not create or manage a keystore.

Push notifications need your own Firebase project. The free Spark plan is enough. Register an Android app in Firebase against the exact package name Base44 shows you, then upload two files in the generation window: google-services.json (so the app can receive notifications) and a service account key (so Base44 can send them). Treat the service account key as a secret. Note the catch Base44 documents: people who already installed your app only start receiving pushes after you generate new files and submit an updated version to Play.

Google sign-in needs Play's signing fingerprints. If your app offers Sign in with Google, it will work on the web and fail in the installed app until you add the SHA fingerprints: in Play Console go to Test and release → App integrity → App signing, copy the SHA-256 fingerprint (or download the certificates .zip if the page shows a quantum-ready badge), then in Base44 open the More actions menu next to the Google Play files and choose Add Google Play SHA. If you ever change signing settings in Play, update it here too.

The ADI snippet, if Google asks for it. Google is gradually rolling out a package-name ownership check: when Play Console prompts you, it shows an ADI registration snippet that must be added to the app. Base44 has Add Google Snippet in the same More actions menu; saving triggers a fresh Android build, ready in about five minutes. If you are never prompted, skip it.

Step 3: Run the closed test with 12 testers for 14 days

This is the step that decides your launch date. Google's requirement, verbatim: "Developers with personal accounts created after November 13, 2023 must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" (Play Console Help). Your Base44 AAB does not change any of this.

Mechanics, in order: upload the AAB to a closed testing track, finish app setup, then in Test and release → Testing → Closed testing → Manage track → Testers tab, create an email list or a Google Group and share the opt-in link. Google allows up to 200 email lists with up to 2,000 users each and 50 lists per track (track setup documentation). Your 12 testers must each accept the invite themselves — adding an address to a list is not an opt-in.

Counting is where launches slip. At the moment you apply, 12 testers must have been opted in continuously for the preceding 14 days — so the 14-day clock effectively starts when your twelfth opt-in lands, and one person opting out on day 12 puts that slot back to zero. Recruit meaningfully more than 12. Based on our analysis of 1,500+ closed-testing campaigns, the recurring failure pattern is not dishonest testers; it is people who accept the invite, install once, and quietly drift out of the habit — see do testers need to open the app every day? and what happens if a tester uninstalls during the 14 days for what actually keeps a slot alive. If your count reads zero for no visible reason, 0 testers currently opted in covers the fixes.

Step 4: Apply for production access and publish

Once 12 testers have held their opt-in for the preceding 14 days, the apply control appears on your app's Dashboard. You answer questions about your closed test, the app and its production readiness — here is what each question asks and how to answer it. If the button is missing or greyed out, the causes are enumerated in Apply for production button not showing.

Google's timeline for the decision: "Review usually takes seven days or less, but can occasionally take longer." You get an email when it completes; meanwhile track what the status page is telling you and how long each stage really takes. If the answer is more testing, keep the closed test running and do not remove testers — your next application is judged on the same continuous enrollment.

After approval, the Production page (and open testing) unlocks. Before the public release, finish what review will look at: store listing and screenshots, content rating, Data safety form, and — because your app is a web-view wrapper — working reviewer credentials. Set up app access test credentials with a seeded account, and complete device verification if prompted. A reviewer who cannot log in is the most avoidable delay in the whole process.

How updates work after the app is live

This is where the web-view architecture pays off. Fix a typo, redesign a page, ship a new feature in Base44, publish it — installed apps pick it up immediately, with no Play review. You only return to Play Console when the wrapper changes.

For those updates, go to More actions next to the stored files and choose Create New Files, not Download. Base44 increments the build number automatically each time you generate a fresh set; clicking Download again reissues the same file with the same build number, and Play rejects it with a version-code-already-used error. You cannot set version or build numbers manually — Base44 notes that asking the AI chat to change them does not work, because they are not part of your app's code.

One migration trap to know before you start: if a previous version of this app was uploaded to Play from Android Studio or another tool, the Base44 build's package name and signing key will not match the existing listing, and the stores will block the update. Base44's documentation is blunt that these values cannot be changed inside the generated files — the only route then is a new app entry, which means a fresh listing and, on a new personal account, a fresh 14-day clock.

What can still get a Base44 app rejected?

Web-view wrappers are not banned on Google Play; unstable, unusable or policy-breaking apps are. In our reading of campaigns that cleared review on the first or second attempt, the apps that passed shared three things: a live URL that loaded on a slow connection, a reviewer account with seeded data, and privacy terms visible before sign-up. The rejections we see trace back to a short, predictable list.

• The billing permission request. Play Console asks for com.android.vending.BILLING, the app does not support it, and there is nothing to toggle. Remove the digital-content checkout from the mobile app and answer review with what you changed.
• Pay-on-our-website buttons. Even without a formal billing request, a button or webview link that sends Android users to pay on your site violates Google's payments policy for digital content. Selling physical goods or services is unaffected.
• Login that only works on the web. Missing Play SHA fingerprints break Google sign-in in the installed app; your own email/password auth can break on session handling the web never exposed. Test cold-start login on a real phone over mobile data, not just preview.
• Terms and privacy behind the login. If a first-time visitor cannot reach them from the sign-up screen, both stores treat that as a rejection reason.
• A wrapper built from a stale listing. Package or signing mismatch with a previous native upload — covered in the previous section.

Target API level is Google's requirement, not Base44's: since 31 August 2026, new apps must target Android 16 (API level 36), with an extension available to 1 November 2026 (Play Console Help). Base44 does not publish which API level its generated AAB targets, so check the build warnings in Play Console after your first upload — if Play flags it, that is a question for Base44 support, not something you can set yourself.

FAQ

Does a Base44 app still need 12 testers for 14 days? Yes, if your Play Console account is a personal one created after 13 November 2023. The requirement is scoped to the account, not the technology. Base44's role ends at producing the AAB.

Can Base44 submit my app to Google Play for me? No. It scans your app, helps fix issues and generates the AAB; the upload, the closed test and the production access application all happen in your own Play Console.

Can I choose my own package name? No. Base44 assigns com.base[app-id].app and there is no setting to change it — consistent with Google's rule that the package name is fixed once an artifact is uploaded.

Do I need a custom domain? No. Base44 confirms the default Base44 URL is accepted for store submission. A custom domain is a branding and SEO choice, not a requirement.

Can my Base44 app sell subscriptions on Google Play? Not yet. Base44 apps do not include Google Play Billing, and Google requires it for digital content sold inside an Android app. Physical goods, bookings and services can take payment through any provider.

How often will I need to upload new AABs? Rarely. Content and design changes published in Base44 reach installed apps immediately. Generate new files only for wrapper-level changes: name, icon, splash, permissions or push notifications.

What if I already have a Play listing built natively? Then this is not an update path. A Base44 build's package name and signing key will not match your existing listing, so the move means a new listing — check that cost before you start.