Is your AI-built app ready for real users? A 12-point launch checklist
Use this 12-point checklist to test an AI-built mobile app across devices, failures, security, source, release builds, beta access, and rollback.
AppX team ·
An AI-built app is ready for real users when one important journey works in a release build, on real devices, under both normal and failure conditions—and when the team can detect a problem, protect user data, and stop or reverse the release.
That is a higher bar than a convincing preview. A preview proves that an idea can take shape. A tested release candidate connects the interface to real accounts, data, permissions, services, and recovery plans.
Use the 12 checks below before inviting a beta group or sending a build to a store. Each check asks for evidence, not confidence.
Quick answer: what does “ready” mean?
Treat readiness as four separate states:
| State | What it proves | What it does not prove |
|---|---|---|
| Prototype | The concept and main screens are understandable | Real data, native behavior, security, or release reliability |
| Tested candidate | A specific build passed defined journeys and failure cases | Store acceptance or public demand |
| Store submission | Metadata, declarations, reviewer access, and a signed build were submitted | Approval |
| Accepted product | Real users can complete the promised job and the team can support it | Permanent compliance or future reliability |
Do not collapse these stages into “production-ready.” Record which build passed which test and what remains unknown.
The 12-point launch checklist
- One critical user journey works from start to finish.
- Empty, loading, offline, timeout, rejection, and retry states are usable.
- The candidate has been tested on real supported devices.
- Authentication and authorization boundaries resist cross-account access.
- Private credentials stay outside the distributed client.
- User data, privacy disclosures, and deletion behavior agree.
- Permissions and accessibility behavior have been tested.
- Crashes, logs, dependencies, and known limitations are recorded.
- A clean source export can be built by someone else.
- A signed release build works without the development server.
- Beta testers and store reviewers can reach the important features.
- Monitoring, support, ownership, and rollback actions have named owners.
1. Can a new user complete one critical journey?
Choose the smallest journey that delivers the app’s central value. A booking app might need to show availability, reserve one place, confirm the reservation, and display the updated state. A habit tracker might need to create a habit, record a check-in, preserve it after relaunch, and show the correct progress.
Run the journey from a new account with no prepared data. Then repeat it with an existing account and realistic data. Remove dead controls, sample labels, fake success messages, and features that exist only as visual placeholders.
Evidence to keep: the build number, device, operating-system version, test account state, expected result, actual result, and a short recording.
2. What happens when the happy path breaks?
AI-generated interfaces often make the successful state look complete before the underlying failure behavior is complete. Test the moments that interrupt the experience:
- the first response is slow;
- the network disappears during a write;
- the service returns a validation error;
- the user taps the action twice;
- the session expires;
- the app is closed and reopened mid-flow;
- a retry succeeds after a failure.
The screen should explain what happened, preserve safe user input, prevent duplicate writes, and offer a useful next action. A spinner with no timeout is not a recovery path.
3. Has the build run on real supported devices?
A browser canvas and simulator are useful, but neither reproduces every keyboard, safe-area, memory, camera, notification, biometric, background, or connectivity behavior of a phone. Expo recommends using a real device because it shows what users will see in practice.
Test at least one older supported device and one current device for each platform you intend to release. Check small screens, large text, dark mode if supported, rotation rules, keyboard overlap, interruptions, cold launch, background return, and slow connectivity.
If you are still using Expo Go, follow the AppX phone-preview guide, then move to a development build. Expo describes a development build as the project’s own native app with development tools and recommends it when preparing for store release in its development-build introduction.
4. Are authentication and authorization separate checks?
Authentication proves who signed in. Authorization decides what that identity may read or change. Test both.
Create two ordinary accounts. Confirm that one cannot view, edit, or delete the other account’s records by changing an identifier, replaying a request, opening a copied deep link, or calling the same endpoint outside the visible screen. Enforce access on the trusted backend; hiding a button in the app is not an authorization boundary.
Also test sign-up, sign-in, sign-out, session expiry, recovery, revoked access, and an unavailable authentication service. The OWASP Mobile Application Security Verification Standard provides control groups for authentication, storage, networking, platform use, code, resilience, and privacy. Use the relevant controls as a risk-based review, especially when the app handles sensitive data.
5. Are secrets kept out of the mobile bundle?
Assume users can inspect anything shipped in the app. Search the source export, environment files, build configuration, commit history, and logs for private API keys, database credentials, service-role tokens, signing material, and reusable test accounts.
Expo warns that EXPO_PUBLIC_ variables are embedded in the compiled client and are visible to end users. Its environment-variable guide says not to put sensitive information in them. Keep privileged credentials and privileged operations on a trusted server, and make the app call a bounded API.
Then test denial, timeout, rate limiting, and expired credentials. Secure placement alone does not make the user experience reliable.
6. Does the data lifecycle match the privacy promise?
List the data the app and every SDK collect. Include authentication, analytics, advertising, payments, support, crash reporting, location, media, contacts, and device identifiers. Compare the list with the privacy policy and store declarations.
Test creating, reading, changing, exporting where promised, and deleting user data. If the app supports accounts, verify what “delete account” removes, how long backups or legal records remain, and what the user sees while deletion is pending. Do not claim immediate or complete deletion if the system behaves differently.
Keep a dated data map with the owner of each service. Store rules and privacy obligations depend on the app, audience, location, and data involved; the checklist is an engineering gate, not legal advice.
7. Do permissions and accessibility work when users say no?
Request camera, microphone, photos, location, contacts, notifications, Bluetooth, health, or background access only when the current feature needs it. Test first approval, denial, later approval through Settings, limited access where the platform offers it, and revoked access after a successful session.
Test the core journey with larger text, screen-reader labels, visible focus, sufficient contrast, and touch targets that do not demand precise movement. Android’s accessibility testing guidance recommends combining manual testing, analysis tools, automated checks, and feedback from users with disabilities.
Record which accessibility checks are automated and which were completed manually. A clean automated scan does not prove the whole journey is usable.
8. Can the team explain crashes and known limits?
Run the project’s type check, linter, tests, and release build. Review warnings rather than counting only failures. Record dependency versions, unresolved vulnerabilities, native-module compatibility, bundle size, startup behavior, and known limitations.
Add crash reporting or another supportable diagnostic path before a wide release when the app’s risk justifies it. Verify that reports identify the app version and environment without leaking private user content. Trigger a controlled test event and confirm it arrives; merely installing an SDK is not evidence.
The release record should say what failed, what was accepted temporarily, who accepted it, and when it will be reviewed again.
9. Can another person reproduce the build from source?
Download the source, preserve the original export, and build from a clean directory. Document the runtime and package-manager versions, install command, environment-variable names, backend dependencies, platform identifiers, and any native setup.
Give the instructions to someone who did not create the app. They should be able to install dependencies, start the project, and identify missing configuration without access to the builder session. The AppX source-export handoff guide includes a practical handoff structure.
This check catches hidden local state and turns a generated result into a maintainable project artifact.
10. Does a signed release candidate work by itself?
Create the artifact you intend to distribute. A release candidate should open from the device home screen and complete the critical journey without a local development server, debug menu, or builder preview.
Confirm the application identifier, version, build number, icon, display name, permissions, environment, backend URL, signing owner, and update configuration. Install it through the intended distribution path. Expo’s EAS Build setup distinguishes development builds from app-store distribution builds and explains how to create the latter.
Do not substitute “it worked in Expo Go” for this result. Expo Go is valuable for early testing, while a signed candidate is the artifact beta users and reviewers actually install.
11. Can beta testers and reviewers reach the promised value?
Distribute the candidate to a small group through TestFlight or a Google Play testing track. Give testers a task, not a tour: ask them to complete the critical journey, describe where they hesitated, and report the build number with each issue.
Apple’s TestFlight guidance requires beta information and reviewer details for external testing. Google Play documents internal, closed, open, and production tracks in its testing guide.
New personal Google Play developer accounts created after November 13, 2023 currently need a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. Check the current personal-account testing requirements for your account before planning a date.
Prepare durable demo credentials, seeded sample data, reviewer instructions, a support contact, and explanations for non-obvious permissions or hardware requirements. The AppX store-publication guide covers submission and review in detail.
12. Can you observe, stop, and recover the release?
Name the people who own the store accounts, signing access, backend, domain, database, analytics, crash reports, support inbox, and billing services. Avoid a release that depends on an unavailable freelancer’s personal account or an undocumented builder session.
Define the signals that will stop rollout: repeated crashes, failed writes, incorrect access, payment inconsistency, privacy failure, or a broken central journey. Write the exact response for each signal—pause distribution, disable a feature, restore a previous backend, publish a fixed build, or contact affected users.
Practice one recovery action before launch. A rollback plan that has never been exercised is still a hypothesis.
Copy this release-evidence record
App and version: [name, version, build]
Source revision/export: [commit, tag, or untouched ZIP]
Critical journey: [start -> action -> observable result]
Devices and OS versions: [list]
1. Critical journey: [pass/fail + recording]
2. Failure and retry states: [evidence]
3. Real-device matrix: [evidence]
4. Authentication and authorization: [evidence/not applicable]
5. Client secret scan: [result]
6. Data lifecycle and deletion: [evidence/not applicable]
7. Permissions and accessibility: [manual + automated evidence]
8. Crashes, checks, dependencies, limits: [report]
9. Clean source build: [person, command, result]
10. Signed release candidate: [artifact and install result]
11. Beta and reviewer access: [track, accounts, task, feedback]
12. Monitoring and rollback drill: [owner, signal, action, result]
Known limitations: [plain list]
Decision: [continue testing / invite beta / submit / stop]
Decision owner and date: [name, date]
How this applies to an AppX project
AppX helps you turn a bounded mobile-app brief into an Expo and React Native project, preview it on a phone, and export the source. Source ZIP export is available on current AppX plans; qualifying plans also support GitHub sync. Store delivery is a separately scoped service rather than an automatic consequence of generation.
Start with one journey that a stranger can complete. Describe that app in AppX, test the generated preview, export it, and run this checklist against a named build. The checklist does not promise approval or customer demand. It gives you evidence for the next decision.
Source note: Product details and linked OWASP, Expo, Apple, Android, and Google Play guidance were checked on September 19, 2026. Policies and product capabilities can change; recheck the linked primary sources before release.