How to publish an AI-built app to the App Store and Google Play
A practical checklist for moving from a working preview to your own store build, with accounts, environment setup, testing and review explained.
By Cicrew · Updated
Start with a working app, then prepare the release
An app that looks right in a browser preview is ready for the next round of testing. A store release also needs a signed native build, a production backend where required, an accurate listing and a review by the store.
In Cicrew, complete the main user journeys in Build, then open the Publish tool. Its checklist brings together account setup, app configuration, listing content, screenshots and builds. Store approval is a separate decision made by Apple or Google.
Connect the accounts that will own the app
Use your own Apple Developer account for iOS and Google Play developer account for Android. Complete identity and organization verification with the providers. You will also need an Expo account for the cloud build workflow.
Start enrollment early. Apple lists its program at US$99 per membership year, with regional pricing and eligible waivers. Google has additional testing requirements for affected new personal developer accounts; check the requirement shown in your Play Console before setting a launch date.
- Confirm the seller identity and app identifier before the first release.
- Connect the requested credentials through Developer accounts, not through chat.
- Keep account ownership and payment methods under your control.
Configure the environment before making the binary
Open Integrations in Cicrew. Preview uses the platform’s isolated test backend. Development and Production use your own separate database projects, so a store build does not inherit the shared preview database.
Enter the keys the app actually needs and choose the right environment. Public configuration becomes part of the mobile build. Secret API keys belong in server configuration, not in screens or client-side values. Apply server changes before testing the release; rebuild the app when a public value changes.
An app that is free and has no paid features does not need RevenueCat. If you add subscriptions, configure the payment integration and test purchases in the providers’ test environments.
Test the release on a phone
Preview testing helps catch problems quickly. Test an installable development build and the release candidate on real devices before submission, especially for permissions, camera access, notifications, purchases, the keyboard and sign-in redirects.
Use TestFlight or a Play testing track to get feedback. A useful test asks someone to complete a specific task without help, then checks that the result is saved after closing and reopening the app.
- Sign in, sign out and switch test accounts.
- Complete the main task, reopen the app and verify the result.
- Try an empty account, an invalid input and a failed network request.
- Check small screens, large text and any paid flow you offer.
Prepare a listing that matches the app
Describe what the current version actually does. Use captures of the running app, including the correct signed-in state where needed. Review the generated images before submission so a sign-in screen is not accidentally used as a feature screenshot.
Provide a working support contact, privacy policy and accurate privacy or data-safety disclosures. Give reviewers a way to try protected features where required. Follow the current store rules for your category, content and payments.
The Publish tool helps prepare the submission. You still review the listing and authorize the release. Keep time available for store questions and another build if changes are requested.