Skip to content
Schedars

Schedars · Resource

Mobile App Pre-launch Checklist

The two-week playbook from Schedars — what we run before every mobile launch so day one isn't the source of bugs and bad reviews.

Print this, share with the team. Cmd/Ctrl + P → Save as PDF.

TL;DR

14 days out: QA on real devices, store metadata ready, analytics + crash reporting wired. 7 days out: closed beta to 20–50 hand-picked users. Launch day: phased rollout, war room for 4 hours. Don't launch on a Friday.

Timeline — two weeks to launch

  1. T-14

    QA + setup

    Real-device QA on iPhone SE, iPhone 15 Pro, iPad mini, mid-tier Pixel, budget Galaxy. Store metadata complete and reviewed. Analytics events wired and validated. Sentry symbol upload working.

  2. T-7

    Closed beta + store submission

    TestFlight / Internal Testing build to 20–50 hand-picked users from your ICP. Daily triage. Submit to App Store / Play Store 5–7 days early — buffer for review iterations. Support team trained.

  3. Day 0

    Launch day

    Tuesday morning, never Friday. Phased rollout on Android (5% → 25% → 50% → 100% over 48h). iOS all-at-once with Phased Release option in App Store Connect as fallback. Active monitoring for first 4 hours. War room: dev + design + support + PM all online.

  4. T+7

    Post-launch — first 7 days

    Daily review of: app store reviews (respond < 24h), crash rate (alert if > 1%), conversion funnel, top user complaints. At least one bug-fix release in week 1 — App Stores reward responsiveness.

Checklist — 70+ items

☐ untouched · ☐→☑ shipped · prefix with date when done.

T-14: QA on real devices (not just simulators)

  • iPhone SE 3 (small screen + low-RAM proxy)
  • iPhone 15 Pro (latest mainstream)
  • iPad mini (small tablet)
  • Mid-tier Android (Pixel 7a or similar)
  • Budget Android (Galaxy A14 or similar)
  • Each device: 60-min smoke pass through top 5 user flows
  • Biometric auth (Face ID / Touch ID / Android biometrics) tested where relevant
  • Low-RAM behavior verified (kill background apps to simulate)
  • Real network conditions (LTE / 3G throttle in dev tools)
  • Keyboard quirks (autocorrect, predictive text) on all platforms

T-14: Store metadata

  • App name (30 chars) — descriptive + branded
  • Subtitle / short description — value prop in 30 chars
  • Description (4000 chars) — first 2 lines are conversion-critical
  • Keywords (100 chars iOS) — researched via App Store search hints
  • Screenshots: 6 per device class with overlay text explaining value
  • Preview video (15-30s) — optional but +20% conversion typically
  • Privacy nutrition label (iOS) — accurate, audit by hand, not generated
  • Data Safety section (Android) — same standard
  • Categories chosen + secondary category if applicable
  • Pricing / In-App Purchase configuration tested in sandbox

T-14: Analytics + monitoring

  • Analytics tool wired (PostHog / Mixpanel / Amplitude — pick one)
  • 5 critical events tracked: app_open, signup, activation, purchase, churn-signal
  • Validated by triggering each event in dev and confirming dashboard receipt
  • Sentry on both iOS and Android with proper symbol/dSYM upload
  • Alert configured: crash rate > 1% or any new crash type
  • Crash alerts route to a Slack / Discord ops channel
  • Performance monitoring (Firebase Performance, Sentry Tracing) for slow networks
  • Funnel events for top conversion paths (onboarding → activation → first purchase)

T-7: Closed beta

  • 20–50 hand-picked users from your ICP — not random sign-ups
  • TestFlight (iOS) external link or Internal Testing track (Android) configured
  • Beta acceptance terms (privacy, NDA optional, feedback expectation)
  • Daily 15-min check-in calls with each beta user (or async chat)
  • Triage rotation: dev / design / PM rotate the bug-triage role daily
  • Feature flag system in place to ship 2–3x per week to beta only
  • Beta-only Discord/Slack for community feedback
  • Anything below "minor cosmetic" gets fixed before public launch

T-7: Store submission + support

  • Submit to App Store / Play Store 5–7 days before public launch
  • Buffer for 1–3 rejection cycles (24–48h each, especially first submission)
  • Common rejection reasons reviewed: vague usage descriptions, broken demo account, ATT prompt without context
  • Backup launch date 7 days after announced public launch in case of rejection
  • FAQ doc covering top 15 anticipated questions
  • Support email + auto-responder ("we read every message, reply within 24h")
  • In-app help link to public knowledge base or chat
  • Support team has admin tools: user lookup, password reset, refund
  • Pre-written response templates for top 5 issues

Launch day

  • Day choice: Tuesday morning, NOT Friday or before a holiday
  • iOS: launches all-at-once OR via Phased Release in App Store Connect
  • Android: phased rollout 5% → 25% → 50% → 100% over 48 hours
  • Active monitoring for first 4 hours: crash rate, server load, signup conversion
  • Slack war room channel: dev + design + support + PM all online and reachable
  • Pre-written social posts and press releases ready to fire on confirmation
  • Status page (StatusPage.io / Atlassian) live for transparency on issues
  • Backend infra scaled and monitored (DB connections, queue depth, error rate)
  • CDN / image-cache prewarmed on hero assets
  • "Pull rollout" plan documented for emergency halt (Android) or app removal

Post-launch (first 7 days)

  • Daily review: app store reviews, crash rate, conversion funnel, top complaints
  • Respond to app store reviews within 24h (especially negative ones)
  • At least one bug-fix release shipped within first 7 days
  • Public changelog or "What's new" page populated
  • Support response time targeting < 4 hours (definitely < 24)
  • Postmortem doc within 7 days if anything significant broke during launch
  • Track first-week metrics: D1 retention, D7 retention, conversion rate, refunds
  • Identify the top 3 user complaints and triage them for next sprint

Things to triple-check before submitting

  • No console.log / NSLog / print statements in production code paths
  • Privacy policy URL, terms URL, support URL all 200 OK
  • Demo account credentials work and have realistic data
  • In-app purchases tested in sandbox AND with real money on TestFlight
  • Push notification permission prompt has context BEFORE triggering it
  • App Tracking Transparency (iOS): pre-prompt explains why before system prompt
  • Deep links work from email + social shares + universal links
  • Sign in with Apple wired correctly (Apple requires it if you offer 3rd party social login)

Ready to launch a mobile app?

This checklist is what we run ourselves. If you want us to run it with you — get in touch.

Ask a question