DEV Community

Cover image for Mobile App Launch Checklist — 25 Things to Verify Before You Hit Publish
Famitha M A
Famitha M A

Posted on • Originally published at fami-blog.hashnode.dev

Mobile App Launch Checklist — 25 Things to Verify Before You Hit Publish

#expo #reactnative #mobile #ios

Mobile App Launch Checklist: 25 Things to Verify Before You Hit Publish

You're staring at the "Submit for Review" button. The icon looks right. Screens feel good on your phone. But something is nagging at you.

That feeling is usually accurate. Most apps don't get rejected for bad code — they get rejected for a missing privacy disclosure, a wrong-resolution screenshot, or a forgotten test build that just trapped your brand-new Google Play account in a 14-day waiting period.

Here are 25 items I run before every submission, grouped into five categories. Save the post, print the list, then hit publish.

Reality check before you start

Apple averages 24–48 hours review in 2026 for repeat developers. Google Play, 1–3 hours. First-time submission from a brand-new dev account? 7–14 days. Always add a 2-week buffer between target launch and first submission to handle one rejection cycle.

A. Build & Bundle (1–5)

  1. Sign a production build — iOS .ipa from your distribution profile; Android .aab (the old .apk is no longer accepted for new apps). On Expo, use EAS Build. On bare RN, generate a keystore and back it up to two locations — losing it kills your ability to update.

  2. Increment version + build numbers — Each upload must bump CFBundleVersion / versionCode. A lower number is the #1 silent rejection.

  3. Test on at least 5 device classes — Old iPhone, current iPhone, budget Android, mid-range Android, tablet. Simulators lie about gestures, network, and performance.

  4. Strip dev code — console.log, hidden gesture menus, hardcoded test users, __DEV__ branches. App Store reviewers actively search for "test" or "demo" strings.

  5. Wire up crash reporting — Sentry, Crashlytics, Bugsnag. Force a crash in a production build and verify it lands in your dashboard before you submit.

B. App Store Metadata (6–10)

  1. Lock app name + subtitle — iOS: 30 + 30 chars. Google Play: 50 + 80 chars. Apple weighs the name field higher than anything else.

  2. Write a real long description — Lead with the value prop. Google Play shows first 80 chars on the card; iOS shows ~170 chars before the "more" tap. Don't waste those characters.

  3. Pick primary + secondary category — Most specific honest fit, not most popular.

  4. Honest age/content rating — Self-assessment for both stores. Lying about UGC or unfiltered web views is the most common second-round rejection.

  5. ASO keyword strategy — iOS keyword field is 100 chars, comma-separated, never duplicate words from your name. Score keywords by relevance × volume ÷ difficulty. Place top 40 only.

C. Visual Assets (11–15)

  1. App icon 1024×1024 PNG, no alpha — Test it at 60×60. If it's unreadable, the icon needs work.

  2. Required screenshot sizes —

    • iOS: 6.7-inch (1290×2796), 6.5-inch (1242×2688), iPad 12.9-inch if supported.
    • Android: phone (1080×1920 or 1080×2340), 7" and 10" tablets.
    • Frame each with a one-line value prop. Bare UI shots convert 20–40% worse.

  3. App preview video (15–30s) — Silent by default on iOS. Show the outcome in the first 3 seconds, not the onboarding flow.

  4. Splash screen = first screen — Apple's guidance. Never gate it on a network call.

  5. Google Play feature graphic (1024×500 PNG) — No iOS equivalent. A blank one screams "amateur."

D. Privacy, Legal & Account (16–20)

  1. Public privacy + support URLs — Must load from anywhere, no auth wall. Use /privacy and /support.

  2. iOS Privacy Nutrition Label — Declare every data type, including what your third-party SDKs collect. Apple maintains an SDK list of trackers needing disclosure.

  3. Google Play Data Safety form — Mismatches with your real SDK behavior are caught silently weeks after launch. App gets unlisted.

  4. ATT prompt (if you use IDFA) — Apple reviews your pre-permission "context primer." Generic copy like "Tap Allow" gets rejected. Explain why the user benefits.

  5. Closed test before production — iOS: 50–200 TestFlight testers, 5–7 days. Android personal accounts: 12 testers, 14 continuous days. This rule traps every solo founder. Plan 3 weeks, not 3 days. (Docs.)

E. Launch Day & Post-Launch (21–25)

  1. Release strategy — Manual (iOS) vs. automatic, plus phased rollout (iOS) or staged rollout (Android). Always phased for first release: 1% → 5% → 20% → 100% over a week.

  2. Analytics + remote-config kill switch — Mixpanel/Amplitude/PostHog/Firebase. Ship a remote flag that disables a broken feature without resubmitting. First time you use it you'll wonder why you didn't always.

  3. Real release notes — "Bug fixes and performance improvements" is malpractice. Three honest bullets. Users actually read these.

  4. Day-one comms — Product Hunt (Tue/Wed), LinkedIn post, X thread, demo video, email to pre-signups, Show HN if technical. Plan it before you submit, because approval arrives at 3 a.m.

  5. Review-reply + crash-triage rotation — Reply to every 1-star within 24h (other users read your reply). Daily 5-min crash triage in Sentry/Crashlytics for two weeks. Keep crash-free rate above 99.5%.

Where an AI app builder compresses the list

Items 1, 4, 11, and 14 — production-clean code, signed bundles, framed visuals, splash screens — are the unglamorous infrastructure that consumes the last two weeks of a launch. If you generated your React Native + Expo app with RapidNative, the codebase ships clean by default (no leftover logs, no debug UI), and EAS Build picks it up first try.

Items 16–20 (privacy + legal) and 21–25 (launch plan) are still on you. Always will be.

TL;DR

Print the 25 items. Run them top-to-bottom. Two-week buffer between target launch and submission. Phased rollout for v1. Reply to every 1-star review. Ship it.

What's the one item that bit you on a previous launch? Drop it in the comments — I'd bet it's #2 or #17.

Top comments (0)