The Go-Live Problem: Approved in the Store ≠ Ready for Your Users
Store approval is only one gate. Legal, marketing, and leadership often hold the release after Apple and Google say yes — here's how to handle the final go-live step without making dev the bottleneck.
The message lands in Slack: "We're approved." For a moment, everyone breathes out. Then someone from marketing asks the question that kills the celebration: "So we're live?"
Not necessarily. Not even usually.
At an e-commerce company I worked with, getting Apple and Google to approve a build was treated as the finish line. The project manager would update the roadmap. Stakeholders would assume customers could see the new checkout flow by end of day. Then word would come down from the CTO or CEO: don't release yet. A partner agreement wasn't signed. Legal hadn't cleared new copy on the payment screen. Marketing wanted the feature to go live the same day as the email campaign — next Tuesday, not today.
The app sat approved in the store, fully releasable, while the business wasn't ready. The developer became the accidental gatekeeper — the only person who could press the button, and the one everyone nagged about timing that wasn't theirs to decide.
Store approval answers a technical and policy question: does this binary meet the platform's rules? Go-live answers a business question: should our users see this now? Conflating the two creates confusion, delayed campaigns, and developers stuck in approval politics they were never hired to manage.
Why approved builds still wait
Mobile releases at larger companies touch legal, marketing, partnerships, and executive leadership — none of whom live in App Store Connect. They find out the app is "ready" when someone tells them, often late, because approval was invisible until a dev checked the dashboard.
Common hold reasons:
- Contractual — a feature must not appear until a partner launch date or signed agreement.
- Campaign alignment — product, email, and paid media must go live together; the app is early.
- Risk appetite — leadership wants a Monday release, not a Friday afternoon surprise.
- Regional sequencing — roll out in the UK first, US after a pricing change clears.
These are legitimate. The failure is workflow: no named owner for the final decision, no visible "approved but held" state, and no shared place where the business sees what's blocking go-live.
Phased release is a tool, not a default
Apple and Google both offer phased rollout options — releasing to a percentage of users over time. That can soften risk for large user bases. It's not a substitute for business hold.
Phased release controls how fast users get a build, not whether today is right. Manual release after approval is valid when business gates exist — but if only the developer knows the build is approved and waiting, every other function plans around guesswork.
Make the hold visible: "Store approved on 4 June. Go-live target: 9 June, pending legal sign-off on updated T&Cs. Owner: Priya (PM)." That one line in the release channel prevents a week of "is it live yet?" messages.
Add a final approval step with a named owner
Most release checklists end at store approval because engineering owns everything up to that point. Extend the checklist one step further: business go-live approval.
This step should have:
- A single named owner — usually PM or release manager, not the developer who submitted the build.
- Explicit criteria — campaign date reached, legal cleared, support briefed, analytics verified.
- A visible state — everyone in the release channel can see "waiting on go-live approval from [name]" without opening a store console.
The developer's job is to confirm the build is technically releasable and to execute publish when the owner says go. The owner's job is to coordinate stakeholders and call the time. Separating those roles stops engineers from blocking business decisions and stops business leaders from assuming approval equals launch.
For recurring patterns — always hold for marketing on major drops — bake that into the workflow template so new PMs don't rediscover it every quarter.
Developers shouldn't be the business bottleneck
When go-live authority sits with whoever has store credentials, engineers get pulled into campaign timing and CEO preferences — answering "can we release?" when they can't answer "should we?" Split credential access from decision rights. If go-live is blocked, the release should show who's being waited on, not route every ping through the iOS developer fixing an unrelated bug. Status should live in Slack — approved, held, go-live authorised, live — not in email and standup memory.
Close the gap between approved and live
Treat go-live as a first-class step, not an afterthought once the store says yes. Name an owner. Document the hold reason. Keep the team in one channel from build through to users actually seeing the change.
That clarity is especially valuable in e-commerce, where a mistimed app release can undercut a campaign or surface a partner feature before contracts allow. The store gave you permission. Your business still gets to choose the moment.
ReleaseSteps lets teams configure that final approval step — with assignees and visible status in Slack — so "approved" and "live" are two different, honest states. If your releases keep stalling in the gap between store sign-off and leadership sign-off, see how ReleaseSteps fits your workflow or add one rule to your next release: no publish until the PM, not the dev, says go.