Publishing a Mobile App on the App Store and Google Play: What You Really Need to Know in 2026

Publishing a mobile app — we think it's a "submit" button at the end of sprint 12. In practice, it's a real parallel workstream that starts 4 weeks before release and replays at every version. Here is what we wish we knew before publishing our first app — and what we set up on every new product at MAG&Cie.

Developer accounts: cheaper than said, longer to obtain

Apple Developer Program. $99 excl. VAT per year, auto-renewing. Take it under a legal entity if you are a company (with a DUNS number — 2 to 5 business days to obtain for free via Dun & Bradstreet). The personal account costs the same but blocks you from setting a company name as publisher — impossible to change afterwards.

Google Play Console. $25 excl. VAT, one-time, for life. Personal or business account. Since 2023, Google requires identity verification (ID + address). Since 2024, new personal accounts must show they have tested their app with at least 12 testers for 14 days before first production release. That's a real barrier — plan ahead.

The hidden time: legal validation. Publisher name, Support URL, Marketing URL, publicly hosted privacy policy URL, PEGI/ESRB rating, categorization. Budget half a day cumulated for a first account.

Guidelines: what blocks, what passes

Rejections almost never come from code. They come from presentation or policy. Three critical zones:

1. Description and screenshots. Apple guideline 2.3: "Accurate metadata." Your screenshots must show what the app actually does — no marketing mockup with fake data, no features that don't exist. Any divergence = 2.3.1 rejection. Google is more tolerant but can retroactively remove the app.

2. Permissions. Every permission the app requests (location, contacts, camera, notifications) must be justified in code (NSLocationWhenInUseUsageDescription on iOS, <uses-permission> with justification on Android) AND in screenshots. Requesting a permission you never visibly use = rejection 5.1.1.

3. User-generated content. If your app lets users publish content, Apple requires (guideline 1.2): (a) a reporting mechanism, (b) a user-blocking mechanism, (c) a way for you to ban abusive accounts, (d) a clear policy in the ToS. Missing one of the four = rejection, even if technically flawless.

Preparing visuals: the real bottleneck

What the stores require (as of 2026, subject to ongoing adjustment):

App Store (iOS):

• Icon 1024×1024, PNG with no transparency, non-rounded corners (Apple rounds).
• Screenshots 6.7" (iPhone 15 Pro Max) and 6.5" (iPhone 11 Pro Max) minimum — the rest (iPad, Apple Watch) only if you target those platforms.
• 3 to 10 screenshots per size. The first 3 are shown without scroll — they carry 90% of the install rate.

Google Play:

• Icon 512×512.
• Feature graphic 1024×500 — mandatory, often forgotten. It's the banner at the top of the listing.
• Phone + tablet screenshots based on targeted form factors, 2 minimum, 8 max.

Classic trap: generating screenshots from a simulator with dev data. Result: 2.3 rejection on Apple side, 50% CTR loss on Google side. Plan a 2 to 4 hour mini-shoot in Figma / Rotato, once, with a reusable template for future versions.

TestFlight and Internal Testing: non-negotiable

TestFlight (iOS). Build with Xcode or EAS Build, upload via xcrun altool or App Store Connect API, activate TestFlight for the version. Internal testers (up to 100 on your Apple Developer team): instant access. External testers (up to 10,000, invited by email or public link): go through a TestFlight review — 24 to 48 hours. Many ignore this: TestFlight is not "free and instant" on the external side.

Internal Testing (Google Play). Upload an AAB (Android App Bundle, not APK since 2021), assign to an "Internal test" track with the Google email list. Instant access, no review. Useful to validate real-world crashes before the closed track and production.

Closed Testing on Google Play: that's what triggers the "12 testers × 14 days" counter for new personal accounts. Without it, no production release.

Our rule at MAG&Cie: no production update that hasn't spent at least 48 hours on TestFlight/Internal. What breaks in production would have broken in testing — but in testing, it's fixed at zero cost.

First submission: the checklist

Before clicking "Submit for Review", verify:

• Version number monotonically increasing: buildNumber (iOS) and versionCode (Android) must be strictly greater than the last published version, even if you bumped the semver version.
• Signing. iOS: distribution certificate + provisioning profile App Store up to date (renew every year, forgetting means 12 months of waiting). Android: upload key in Play App Signing (Google manages the final signing key).
• Data safety (Play Console). Manual form, to fill in at every new version that changes data collection. Google cross-checks this form against static analysis of your APK — a mismatch blocks publication.
• Privacy Manifest (iOS). Since May 2024, iOS 17.4, mandatory for any app using SDKs on the "required reason APIs" list (UserDefaults, filesystem timestamp, etc.). PrivacyInfo.xcprivacy file to include in the bundle, plus a declaration in App Store Connect.
• Age rating consistent with content.
• Support URL returning HTTP 200 (not a parked domain).

Versioning after publication

Once published, the real discipline begins. At MAG&Cie, on Lirix and MyOpenSpot, we hold these rules:

• Strict semver on marketing side (1.2.3), monotonic increments on store side (buildNumber iOS, versionCode Android). Automation via GitHub Actions + EAS.
• Localized release notes systematically: nothing worse than a user seeing "Bug fixes and improvements" at every update.
• Phased release (iOS) enabled by default: Apple ramps the new version to 1%, 2%, 5%, 10%, 20%, 50%, 100% over 7 days. Lets you pull the update on massive crashes detected on the first 10,000 users.
• Staged rollout (Android): Google equivalent, enable manually, channel by channel.
• Sentry or equivalent connected to native + JS crash reports. A crash > 0.1% of sessions = rollback before waiting for the Apple email.

What actually costs the most

Not publication itself. It's:

1. The iOS + Android double gymnastics — two stores, two capture formats, two signing systems, two privacy forms, two consoles to keep up to date. The lazy fix — a single EAS Build pipeline that pushes to both — costs 2 days to set up, then pays off at every version.
2. The first Apple rejection — 3 to 5 days lost, often at the worst moment (right before a marketing event). Countermeasure: submit for review 14 days before target release, with buffer.
3. Account maintenance — DUNS expiration, certificate renewals, Privacy Manifest updates at every new SDK, Google data safety form format changes every 6 months. Budget half a day per quarter just to hold compliance.

Who to trust with this

If you are publishing your first app and don't have a dedicated technical team, the math is simple: an agency will charge €2,000 to €6,000 for the full first setup (accounts + pipelines + first publication) — the price of avoiding the 3 to 5 classic rejections and getting a reusable template. Starting from the 3rd or 4th app, automation amortizes and you internalize.

MAG&Cie offers exactly this format: full setup + first publication + skill transfer to your internal teams. See our application development service or our mobile case studies (Lirix, MyOpenSpot).

Publishing is easy. Publishing without being blocked on launch week is a craft.