LaunchLint Academy
The short answer
- A Google Play production release is more than uploading an Android App Bundle. The store listing, App content declarations, Data safety form, test tracks, signing setup, and rollout must describe the same build and resolve every blocking warning.
- This guide takes Expo and React Native teams from a frozen release candidate to a controlled production launch. It includes evidence, ownership, stop conditions, and post-release monitoring so the checklist supports an operational release rather than a one-time console exercise.
- Immediately before production, run a release rehearsal with explicit roles. One person operates Play Console, another installs only the artifact from the intended test track, and a third watches monitoring and backend health. Start with a fresh account, exercise update and clean installation, create at least one controlled failure, and confirm support and privacy destinations. Compare the visible app with its listing, screenshots, Data safety answers, and release notes. Record the time, build, devices, results, and every accepted exception. The candidate should reach production only when each mismatch has an owner and an explicit decision.
- Archive only verifiable results: console status, artifact ID, test report, approved listing matrix, and rollout decision. Never place signing secrets, keys, or personal test data in this evidence.
Freeze the candidate and version data
Mark one commit as the release candidate, then prevent silent changes to code, configuration, and native dependencies. Version code, version name, package name, and the Expo EAS profile must unambiguously identify the generated AAB.
A reproducible record keeps testing, the Play Console, and the team aligned on one artifact. Store its checksum, build link, commit, creation time, and owner in a release log.
Release record
- Record commit, version code, and version name
- Verify production profile and package name
- Store the AAB checksum and location
- Prevent unreviewed late changes
- Assign one release owner
Verify the bundle and Play App Signing
Google Play accepts Android App Bundles and produces optimized APKs for devices. Confirm that the intended bundle was uploaded and Play App Signing is configured correctly. A key problem or incorrect package cannot be treated like a small metadata edit.
Expo teams should verify the production profile, credentials, and application identifier before building. Never rotate a signing asset casually just to bypass an upload error.
Bundle and signing check
- Publish an AAB rather than a local APK
- Check Play App Signing and the upload key
- Confirm the immutable package name
- Inspect the artifact in Play Console
- Keep credentials out of logs and tickets
Reconcile the complete store listing
Title, short and full descriptions, icon, feature graphic, screenshots, contact details, and privacy link must be complete. Every claim needs to match the release candidate; prototype screenshots and retired promises create review and customer trust risk.
Inspect every maintained language individually. A complete default listing can hide missing or stale localized assets. Track locale, asset, owner, and verification date in a content matrix.
Store listing
- Copy matches current functionality
- Graphics and screenshots are current
- Privacy and support links work
- Every target locale is reviewed
- Contact details reach a monitored inbox
Finish App content and Data safety
App content covers privacy policy, ads, restricted access, target audience, permissions, content rating, Data safety, and other declarations. These answers are public, review-relevant statements about how the product operates.
Derive them from code, the SDK inventory, and backend data flows. If an analytics or advertising SDK processes data, the form must reflect that behavior. A questionnaire is not a substitute for technical evidence.
App content acceptance
- Ads and target audience are accurate
- Reviewer access instructions are ready
- Sensitive permissions are explained
- Data safety matches SDK and backend behavior
- Content rating answers are complete
Use internal and closed testing
An internal track supports fast team checks, while closed testing gives broader real-world coverage. Install the Play-distributed build rather than relying only on a local debug build so signing, bundle splits, updates, and store context are exercised.
Define acceptance criteria for first launch, sign-in, core workflows, purchases, permissions, deep links, offline behavior, and failure states. Every bug report should identify the build and device.
Test coverage
- Install the Play-distributed candidate
- Test first install and update path
- Exercise core and failure flows
- Verify purchases and deep links
- Attach device and build data to bugs
Triage the pre-launch report
The pre-launch report runs uploaded bundles on devices and may expose stability, performance, accessibility, and security problems. It is a valuable additional signal, not a replacement for product-specific tests.
Triage each result as a reproducible blocker, relevant risk, known limitation, or false positive, then document the decision. Unexplained ignored warnings recur and eventually lose their signaling value.
Report triage
- Reproduce crashes and ANRs
- Assess performance and accessibility findings
- Assign security warnings
- Explain false positives
- Close blockers before production
Control the production rollout
Create the production release only after required listing and App content tasks are complete and the console shows no blocking errors. Release notes should accurately summarize the user-visible change.
A staged rollout limits the blast radius of unknown defects. Define stop thresholds, an owner, and an observation window before increasing the percentage. Without gates, staged rollout is merely a slower full release.
Rollout gate
- No blocking console errors
- Accurate release notes
- Starting percentage and observation time set
- Pause and abort thresholds defined
- Named owner can halt rollout
Monitor and document the launch
After launch, observe crashes, ANRs, ratings, support contacts, backend errors, and critical funnels. Compare them with a known baseline so normal variance is not treated as an incident and a real regression is not dismissed as noise.
Close the release with a record of the final version, timing, rollout stages, anomalies, and follow-up work. This history makes later reviews faster and exposes recurring failure patterns.
Post-release operations
- Compare crash and ANR baselines
- Watch support and ratings
- Check backend health and funnels
- Advance only after the gate
- Feed lessons into the next release
Frequently asked questions
Do I need an AAB for Google Play?
Android App Bundles are the standard publishing artifact; Google Play uses them to generate optimized APKs for devices.
Is a successful upload enough to launch?
No. The listing, App content declarations, policy forms, test outcomes, and blocking errors also need completion.
Should I release to 100 percent immediately?
For meaningful changes, a staged rollout with predefined stop conditions reduces operational risk.
Does the pre-launch report replace manual QA?
No. It adds device and quality signals but cannot cover every product-specific workflow.
Which build should testers install?
Prefer a Play test-track build because it exercises real signing, bundle delivery, updates, and store context.