Saltar al contenido
Schedars

Schedars · Resource

Mobile App Pre-launch Checklist

El playbook de dos semanas de Schedars — lo que ejecutamos antes de cada lanzamiento móvil para que el día uno no sea la fuente de bugs y reviews malas.

Imprímelo, compártelo con el equipo. Cmd/Ctrl + P → Guardar como PDF.

TL;DR

14 días antes: QA en dispositivos reales, store metadata lista, analítica + crash reporting cableados. 7 días antes: beta cerrada a 20–50 usuarios elegidos. Día de lanzamiento: phased rollout, war room por 4 horas. No lances en viernes.

Timeline — dos semanas al lanzamiento

  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+ ítems

☐ 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)

¿Listo para lanzar tu app móvil?

Este checklist es lo que ejecutamos nosotros. Si quieres que lo hagamos contigo, escríbenos.

Hacer una pregunta