CodeVerse Creatives
Esc
React Native Syllabus / Phase 8 · Publishing & Capstone / Week 20

Week 20: App Store Connect & Google Play Console

A signed build from Week 19 is not a published app — it has to clear a real review process on each store, with its own metadata, screenshots, and rules. This week sets up both consoles, submits a build to each store's internal testing track, and covers the review pitfalls that catch first-time submitters most often.

Phase 8 of 8 Week 20 of 22 ~4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Create an app record in App Store Connect with the metadata and screenshots it requires
  • Create an app record in Google Play Console and submit to an internal testing track
  • Recognize the most common reasons each store rejects a first submission
  • Explain what a staged rollout is and why it matters for a production release
1 App Store Connect 2 Google Play Console 3 Common Rejection Reasons 4 Versioning & Staged Rollouts 5 Exercise 6 Knowledge Check

1. App Store Connect

An App Store Connect record needs, at minimum: an app name, a bundle identifier matching your build, a support URL and privacy policy URL, a content rating questionnaire, and at least one screenshot set per required device size.

terminal — submit a build with EAS
eas build --platform ios --profile production
eas submit --platform ios --latest

eas submit uploads the build directly to App Store Connect, using the same credentials EAS already manages from Week 19 — from there, the build appears under TestFlight first, where it can be shared with internal testers before ever being submitted for full App Store review.

2. Google Play Console

Google Play's structure is similar but stricter about the path to production — every app must pass through at least one testing track (internal, closed, or open) before production is available at all, and a fresh developer account faces additional review requirements for its first production release.

terminal
eas build --platform android --profile production
eas submit --platform android --latest

A store listing needs a short and full description, a feature graphic, at least two screenshots, a privacy policy URL, and a completed Data Safety form describing exactly what data the app collects — inaccuracies here are a common source of rejection independent of the app's actual functionality.

3. Common Rejection Reasons

  • Broken core functionality — a reviewer hitting a crash, a login wall with no way to demo the app, or a feature that simply doesn't work in the submitted build.
  • Missing or incomplete privacy disclosures — both stores require an accurate accounting of what data is collected and why; the Week 9 SecureStore token, the Week 14 push token, and the Week 8 location reads all count.
  • Placeholder or Lorem Ipsum content — screenshots, descriptions or in-app content that reads as unfinished.
  • Guideline-specific issues (iOS) — sign-in-only apps without a demo account provided to the reviewer, or use of a private API.
  • Metadata mismatch — screenshots or descriptions depicting functionality the submitted build doesn't actually have.

Providing reviewer notes (App Store Connect has a dedicated field for this) with a working demo login and a short explanation of what to test heads off a large share of first-round rejections.

4. Versioning & Staged Rollouts

A version number has two parts that mean different things: a user-facing string (1.2.0) and a build number that must strictly increase with every submission (handled automatically by autoIncrement in Week 19's eas.json).

A staged rollout releases a new version to a small percentage of existing users first (say, 10%), monitored for crash rate or reviews, before widening to everyone — both stores support this natively for production releases. For anything beyond a first launch, it's the safer default: a bad release affects a fraction of users, and is trivial to halt, rather than landing on every user at once.

5. Hands-on Exercise

Hands-on

Submit the capstone-in-progress to both stores' testing tracks

Get a real build from Week 19 through each store's submission flow, up to (not necessarily past) full review.

Requirements:

  1. A complete App Store Connect record: app name, bundle ID, support and privacy policy URLs, content rating, and at least one screenshot set.
  2. A completed Data Safety form and Play Console listing (short/full description, feature graphic, screenshots).
  3. Submit the production build from Week 19 to TestFlight (iOS) and an internal testing track (Android) using eas submit.
  4. Write reviewer notes including a working demo login (or an explanation of why one is not needed) for the iOS submission.
  5. Document, in a short README, the version numbering scheme you'll use for the capstone (e.g. 1.0.0, build auto-incremented) and what a staged rollout would look like for its first real production release.
Hint

You do not need a paid Apple Developer or Google Play Console account to complete most of this exercise — set up as much of the metadata, screenshots, and Data Safety form as you can, and treat the actual eas submit step as something to run once you (or your organization) has the relevant developer account; the configuration work is the same either way.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

Why does a build have to clear TestFlight or an internal testing track before it's eligible for full store review?

Both stores use testing tracks as a lower-stakes staging area — a place to catch obvious problems (crashes, broken core flows) with a small, controlled group before the app is exposed to a reviewer or the public. It's also simply required infrastructure: Google Play in particular requires passing through at least one testing track before production is unlocked at all.

Q2

Why does providing reviewer notes with a demo login reduce first-round rejections, specifically for an app with a sign-in wall?

A reviewer with no way past a login screen cannot verify the app actually works, which is grounds for rejection on its own — providing working demo credentials (and, where relevant, a short note on what to test) lets the reviewer evaluate real functionality instead of stopping at the login screen.

Q3

What is the practical difference between the user-facing version string and the build number, and why does the build number need autoIncrement?

The version string (1.2.0) is what users see and communicates meaningful releases; the build number is an internal identifier both stores require to strictly increase with every single submission, including ones that don't bump the visible version (a resubmission after a rejection, for instance). autoIncrement in eas.json handles that bookkeeping automatically so a forgotten manual bump doesn't block a submission.

Q4

Why is a staged rollout safer than releasing a new version to 100% of users immediately?

A staged rollout exposes a new release to only a small percentage of users first, giving you a chance to catch an elevated crash rate or a wave of bad reviews while the blast radius is still small — and to halt the rollout before it reaches everyone. Releasing to all users at once means any problem the testing tracks missed reaches the full user base immediately, with no way to contain it after the fact.

← Previous Week 19: EAS Build & CI/CD Next Week 21: Capstone — Plan & Build