The App Store and Google Play submission checklist

Why submission is a real skill, not a formality

Most app submissions that fail do not fail because the app is bad - they fail because a required field was blank, an account was not enrolled in time, or a store rule was missed. Treating submission as a checklist you run every time, not something you improvise the night you finish building, is what keeps your first launch from bouncing back for a week over something trivial. The steps below take almost no extra effort once they are a routine.

Enroll in both developer programs early

Enroll in the Apple Developer Program and set up your Google Play Console account on day one, not the week you plan to launch. Apple's enrollment can take days to verify, and Google's account setup plus the closed-testing requirement adds real calendar time. Getting both accounts live early means the paperwork is never the thing blocking your launch. This is the single step most first-time builders leave too late.

• Enroll in the Apple Developer Program early - verification can take several days
• Set up Google Play Console early - the closed test adds calendar time
• Reserve your app name and bundle identifier on both stores
• Prepare your privacy policy URL - both stores require one
• Line up your app icon, screenshots, and description before submission day
• Confirm your app runs on a real device, not just the simulator

Clear the privacy and compliance fields

Both stores require you to answer for how your app handles data before it can go live. Apple has the App Privacy nutrition labels and Google Play has the Data Safety form, and both must accurately describe what data you collect and why. You also need a content rating and, if your app has accounts, a privacy policy URL. These are not optional fields you can skip - a missing or inaccurate privacy answer is a common reason a submission gets held. Fill them out honestly and completely before you submit.

Run Google's closed test: 14 days, 12 testers

Google Play requires new personal developer accounts to run a closed test with at least 12 testers for 14 continuous days before you can apply for production access. This is the step that surprises most first-time builders and stalls their launch, because nobody tells them until they hit the wall. Line up your 12 testers early - the club itself works as your tester pool - and start the 14-day clock as soon as your build is ready so the test finishes when you are ready to launch.

Common rejection triggers to check first

A few rejection patterns show up over and over. Recognizing them before you submit lets you fix them early. Guideline 4.3 rejects apps too similar to something already on the store, so your app must be meaningfully distinct. A crash on Apple's reviewer device fails the build, so test on a real phone. A broken or missing privacy policy link fails compliance. A paywall that does not restore purchases fails Apple's in-app purchase rules. Check these before you submit rather than after a rejection.

1. 1Guideline 4.3 - your app is too similar to an existing one, make it distinct
2. 2Crash on review - the reviewer hit a bug, always test on a real device first
3. 3Missing privacy policy - both stores require a working policy URL
4. 4Broken purchase restore - Apple requires a working restore-purchases button
5. 5Incomplete metadata - a blank privacy label or wrong screenshot size holds the submission

Submit both stores from one EAS pipeline

Once the accounts, metadata, and closed test are ready, EAS Build and Submit push your app to both the Apple App Store and Google Play from one codebase and, largely, one command - no Mac required. As the builder, confirm the build number increments, the correct signing credentials are attached, and the right build is selected in App Store Connect and Google Play Console before you submit for review. The Rejection-Fix Vault in the club covers what to do if either store bounces the build back.

Make the checklist a habit

None of these steps take long once they are routine. Accounts enrolled early, privacy fields complete, closed test passed, real-device test done, EAS build selected, and every metadata field filled. Run the same checklist every submission and shipping becomes automatic, which frees you to focus on building the app instead of scrambling the night before you launch.