Ask
96
@blistermaps ·

app review approved 6 days before my launch date — how do people actually sequence a mobile launch

First iOS app, solo. I picked a launch date, told a small list, then submitted expecting the usual few days of waiting. It came back approved in about fourteen hours and now sits there approved and unreleased, which only works because I happened to tick "manually release this version" without really knowing what it did.

Problem: the build is now nine days old and I have three fixes in main that I would like in the version people download on day one. Do I pull it and resubmit and risk a slow review this time, or ship the stale build and patch on day two?

How do people who commit to a public date handle this?

8 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @shopvac_ghost · 3h ago · 2 replies

    Small correction to something people usually suggest in these threads. Phased release is for automatic updates going out to people who already have the app. It does not gradually roll a brand new app out to new downloaders. For a 1.0 it does effectively nothing, so do not treat it as a safety net for your launch.

    The actual safety net is a server-side kill switch for anything risky and a way to fix content without shipping a binary. If your onboarding copy is wrong or a URL changes, you do not want that to be a five day round trip.

    63
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @chmod_confused · 3h ago

      Right, and the same logic applies to your paywall and your feature flags. The first thing I regretted not making remotely configurable was the trial length, because I wanted to change it in week one and could not without a submission.

      29
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @thermal_theo · 13h ago · 3 replies

    Ship the approved build. Manual release exists for exactly this and you have already done the hard part.

    Apple's own line is that most submissions are reviewed inside a day, but that is an average across a pile of trivial updates from established accounts, and it says nothing about the week you happen to submit in. Planning a public date against it is planning against a distribution you cannot see. There have been stretches where reviews visibly slowed for everyone.

    The pattern I use now: freeze the launch build about a week out, submit it, hold it with manual release, and keep working on 1.0.1 in a branch. The day after launch you submit the patch with the fixes that accumulated. Nobody downloading on day one knows or cares that three refinements landed 48 hours later.

    84
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @zigbee_zoe · 3h ago

      Same approach, with one addition. Write down the review turnaround for every submission you make, with the date and whether it was a new app or an update. After five or six data points you have your own baseline for your account, which is far more useful than any published average. Mine sits well under a day for updates and has twice gone past three days for anything touching sign-in.

      41
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @resole_ruth · 3h ago

      Also worth knowing before you need it: there is a way to request an expedited review, and it is not something you can use routinely. Save it for a launch-day crash or something that blocks users entirely, not for three polish fixes.

      26
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @capsule_cora · 3h ago

    Release it quietly now, days before the announcement. Let it be live and unmentioned so you can install from the store yourself, check the listing renders properly, and confirm purchases work against production. Then do the launch as a marketing event on your date. A launch is an announcement, not a deploy.

    57
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @supa_okonkwo · 3h ago

    Went through this two months ago and the thing that bit me was not review time at all, it was the store listing metadata. Screenshots, description and keywords are reviewed alongside the build, so if you planned to rewrite the description on launch morning you are submitting again. Get the listing final before you submit the binary, not after.

    34
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @trace_tilly · 3h ago

    One more sequencing detail: whatever link you put in the launch post, make it something you control that redirects to the store, not the raw store URL. Then when the store link changes, or you want it going to a landing page in some countries, or you just want to know how many clicks the post produced, you can do that without editing a post that is already circulating.

    22
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report