International | Store Launch | 2026-08-16

App Store Launch Prep for Global Markets

Multi-country store submission fails on paperwork and asset gaps far more often than it fails on code, and almost all of it can be settled weeks before you press submit.

A launch delay of two weeks rarely comes from a bug. It usually comes from a missing Japanese privacy policy URL, an age rating questionnaire answered inconsistently across the two stores, or a set of 6.7-inch screenshots that were rendered in English and uploaded to eleven locales. Review teams do not negotiate on these. They reject, you fix, and you go back into a queue that runs 24 to 48 hours on Apple and can run several days on Google Play for a first-time developer account.

The work below is the checklist a Flutter build needs before the first submission, ordered roughly the way it should be done.

Decide the country list before you write a single store listing

Country selection drives everything downstream: which legal documents you need, which payment methods matter, which ratings boards apply, and how many screenshot sets you produce. Pick four to six launch countries, not forty. Each added locale costs real production time in translation review and asset rendering, and each one adds a surface for rejection.

Some countries carry extra obligations that surprise teams:

• South Korea and Turkey require a local business representative for certain app categories, and Google Play surfaces additional declarations.
• Brazil uses ClassInd ratings, which Google Play collects through the IARC questionnaire but which can produce a stricter rating than you expect for chat or user-generated content.
• China requires an ICP filing and, for games, an ISBN licence. If China is on the list, treat it as a separate project with its own timeline, not a checkbox in App Store Connect.
• EU countries now require trader status declarations under the Digital Services Act. Both stores will hide or block your listing in the EU if trader contact details are missing.

Localize metadata as three separate jobs

Store metadata is not one translation task. It splits into three, and treating them as one is why listings read like machine output.

Search-visible fields come first. On the App Store that is the 30-character app name, the 30-character subtitle, and the 100-character keyword field, all indexed per locale. On Google Play it is the 30-character title, 80-character short description, and the full long description, which is indexed as prose. Keywords do not translate. A German user searching for a scheduling app types "Terminplaner", not a translated form of your English keyword. Run a per-locale keyword pass with someone who searches in that language.

Descriptive copy comes second and can be translated conventionally, but hold it to the store's promotional rules. Apple rejects listings that reference other platforms, name competitors, or mention pricing that contradicts the in-app products you configured.

Legal and support text comes third. Privacy policy URL, terms URL, support URL, and marketing URL are per-locale fields. If your policy exists only in English, say so explicitly rather than pointing eleven locales at a page they cannot read; several EU consumer authorities treat an untranslated policy as no policy at all.

Get age ratings and content declarations consistent across both stores

Apple runs its own questionnaire and produces a single global age rating with per-territory adjustments. Google Play routes you through IARC, which fans out to ESRB, PEGI, USK, ClassInd, GRAC, and ACB simultaneously. The failure mode is answering the two questionnaires differently, usually on user-generated content and unrestricted web access. A build that has any in-app browser, any user profile field, or any chat surface should answer yes to those questions on both stores. Answering no and being caught later triggers a rating reassessment, which can pull the listing down mid-launch.

Alongside ratings, both stores now demand a data safety declaration. Apple's Privacy Nutrition Label and Google's Data Safety form ask overlapping but differently worded questions. Reconcile them against what the app actually sends. If you ship Firebase Analytics, you are collecting device identifiers and approximate location, whether or not you look at them. If you ship Crashlytics, you are collecting diagnostics tied to an installation ID. Declare it.

Export compliance and encryption declarations

Every iOS build asks whether the app uses encryption. Almost every app answers yes, because HTTPS counts, but most qualify for the exemption under US Export Administration Regulations category 5D002 for apps using only standard platform encryption. The clean solution is to set ITSAppUsesNonExemptEncryption to false in Info.plist so the question stops appearing per build. If you ship your own cryptographic implementation, proprietary key exchange, or a VPN feature, you do not qualify, and you will need a CCATS classification or an annual self-classification report to BIS. Get legal input on that before submitting, because the wrong answer here is a compliance issue, not a review issue.

Screenshots, and how many you actually need

Apple requires at minimum one 6.9-inch iPhone set and, if the app supports iPad, one 13-inch iPad set. Everything else scales down. Google Play requires a minimum of two phone screenshots at 1080px on the short side, plus a 1024x500 feature graphic and a 512x512 icon.

Localized screenshots are optional but they change conversion materially in non-English markets. The practical approach is to render device frames from a template where the caption text and the in-app screen content are both data-driven, so producing a new locale is a config change rather than a design session. If budget forces a choice, localize captions before localizing in-app content in the screenshot.

Phased rollout, and what to watch during it

Google Play staged rollout starts at 1 percent and can be halted, which is the single most useful safety mechanism in mobile release management. Apple's phased release runs a fixed 7-day schedule at 1, 2, 5, 10, 20, 50, then 100 percent, and can be paused for up to 30 days but not reversed to an earlier build. That asymmetry matters: on Android you can halt a rollout and ship a fix; on iOS a bad build in phased release means an expedited review request while the percentage keeps climbing unless you pause.

Watch crash-free session rate and payment completion rate per country during the first 72 hours, not aggregate numbers. A payment failure isolated to one market usually points at a card network or a 3D Secure flow, not at your code. Halt on a crash-free rate below 99.0 percent, and treat any single-country payment drop of more than 10 points as a stop signal until you understand it.

Rejection reasons worth pre-empting

Apple's Guideline 2.1 rejection for incomplete information is the most common one, and it usually means a reviewer could not get past login. Ship a working demo account in App Review notes, with any 2FA disabled for it, and confirm the account still works the morning of submission. Guideline 3.1.1 rejections happen when digital content is sold outside in-app purchase; a Stripe checkout for physical services is fine, a Stripe checkout for premium app features is not. Guideline 5.1.1 rejections come from permission prompts without a clear purpose string, and Flutter apps often trip this because a plugin adds a permission to the merged manifest that the app never uses. Audit the merged AndroidManifest.xml and the iOS usage description keys before every submission and delete what you do not need.