Apple and Google don't reject apps because AI wrote the code. They reject apps that feel unfinished, crash, or don't match their store page.
This checklist takes you from a working FluxNative project to an app submitted for review. It covers what to fix, what to test, and which steps FluxNative does for you.
Most of it happens in Publish: in the project bar, open the Editor menu and choose Publish. Each store has its own checklist, with the step to do now on top.
Key takeaways
Reviewers judge the installed app, not how it was made.
Remove placeholders and make every main button work.
Test the exact build on real phones, through TestFlight and Google Play internal testing.
FluxNative uploads, sends the store page, submits and releases when you confirm. A few steps stay in the store consoles.
1. Make it feel finished
A reviewer installs your app and tries the main tasks. Sample text, dead buttons and empty screens make an app look unfinished, even when the design is polished.
Before you build a release, check that:
No sample names, lorem ipsum or fake records are left.
Every main button does what it says.
Loading, empty and error screens look intentional.
A new user understands the app without help.
Found a gap? Ask the assistant to fix it, one problem at a time.
Publish also has a Release check and a Security check (Creator plan and up). They look for what a reviewer would reject, such as a missing privacy policy, and for keys left in the code or data anyone can read. Each finding has Fix with Build, which hands it to the Build agent, or Mark intentional when it's on purpose.
2. Test the real build, not the preview
The browser preview is great for quick changes. But reviewers install the real app, so that's what you need to test.
Build an IPA for iPhone and an App Bundle for Android with Build in the project bar. Then send them to TestFlight and Google Play internal testing from Publish, and install them on real phones. Native builds and store uploads are on paid plans (Creator and up).
On each phone, test:
A fresh install and the first launch.
Sign-up, sign-in, sign-out and password reset.
Permissions like camera, photos, location and notifications, including saying no.
A slow network and airplane mode.
Purchases in the store's test mode.
Before a build starts, the Build window lists what still needs you, such as connecting your App Store Connect key or setting your own bundle ID before the first upload.
3. Use the testing tracks first
TestFlight on iPhone and internal testing on Google Play let real people install your app before the public does. Play's internal testing has no review and takes up to 100 testers.
Two Google Play rules catch many people:
The first upload of a new app is manual. Download the App Bundle and upload it once in Play Console. After that, FluxNative sends every new build for you.
New personal accounts need a closed test. Google asks for at least 12 testers for 14 days in a row before you can release to production. Start early, because this is often the longest step.
4. Make the store page match the app
Reviewers compare your app with its store page. The screenshots should show the current app. The description should only promise what the app does today.
In Publish, Store page has Write it with AI, which drafts the text for both stores from your app. FluxNative also frames your screenshots. Check the preview, then send the page to the store. Sending updates the store page; it doesn't submit anything for review.
Answer the privacy questions truthfully, based on what your app really collects. The Checks page drafts your App Privacy and Data safety answers from your app's code and connections, so you only check each one. FluxNative sends Google Play's Data safety form for you. Apple's App Privacy answers are copied into App Store Connect.
If reviewers need to sign in, give them a demo account. Submit for review asks for it, and the password goes to Apple only.
5. Submit, release, and know who does what
When testing looks good, open Publish. Submit for review sends the iOS build you tested to Apple, and you release it once Apple approves. Release to production sends your Android build to Google Play with a staged rollout. Nothing is sent until you confirm.
A few steps stay in the store consoles, because Apple and Google offer no way to do them from outside: creating the app record, Apple's App Privacy answers, Google's App content answers, the first upload of a new Play app, and the closed test.
If a store rejects your app, read the reason, fix the problem, and send a new build.
Frequently asked questions
Does Apple reject apps that were built with AI?
No. Store review looks at the app itself: does it work, is it useful, and is it honest about what it does and what data it collects. How the code was written doesn't matter.
Can FluxNative submit my app for review?
Yes. The Submit for review step in Publish asks Apple what it still needs, then submits the build you tested. FluxNative submits free apps. A paid app is submitted in App Store Connect.
Is the browser preview enough before I submit?
No. Use the preview for quick changes. Before you submit, install the exact build from TestFlight or internal testing and walk through the main flow. Review judges the build you send.
Keep exploring
Publishing overview — Every step from a working app to the stores.
Production release — How Submit for review and Release to production work.
Google Play testing — Internal testing, the first upload and the closed test.