What to Do When Apple or Google Rejects Your Build (Without Losing a Day to Email Archaeology)
A practical rejection workflow for mobile teams — clear ownership, fast handoffs, and posting store reasons where your team already works instead of buried in email.
At a large e-commerce company I worked with, mobile releases were always urgent. A spring campaign, a payment provider switch, a loyalty feature tied to a press date — the business needed the app live, and the mobile team was under pressure to deliver. What made rejections especially painful wasn't the rejection itself. It was how long it took anyone to find out.
The developer who submitted the build would eventually notice a red status in App Store Connect — or spot an Apple email buried under CI notifications. By then, half a day had passed. The PM had been telling stakeholders the release was "in review." QA had moved on. Context had leaked out of everyone's heads.
If that sounds familiar, the fix isn't "check the dashboard more often." It's treating a rejection like any other release step: visible, owned, and routed to the right person immediately.
Why rejections disappear in email and dashboards
Store review is asynchronous by design. You submit, you wait, and eventually Apple or Google sends a decision. For iOS, that often arrives as an email with a subject line easy to skim past. For Android, the Play Console shows a rejection reason, but only people with the right permissions see it — usually the same developer who is already juggling three other tasks.
Meanwhile, the team lives in Slack — where QA reports bugs and marketing asks if checkout is live. The rejection reason sits in a different system. The gap between "rejected" and "the team knows why" is where releases lose a day.
The loop is predictable: reject, fix, rebuild, resubmit, wait. Without a shared view of where you are in it, people duplicate work or chase the wrong person.
Split ownership: who fixes vs who resubmits
A common failure mode is treating rejection as purely a developer problem. In practice, the fix and the resubmission are often different jobs.
The fix owner depends on the rejection reason. A Guideline 2.1 crash on launch is engineering. A missing privacy nutrition label might be engineering plus legal. A screenshot that doesn't match the build could be design or marketing. A metadata issue might sit with the PM. Assigning "rejection" to whoever submitted the build guarantees a bottleneck.
The resubmit owner is usually the person with store console access and signing credentials — often a senior mobile dev or release manager. They don't need to write every fix, but they do need to know when the fix is verified and ready to go back up.
Make both roles explicit the moment a rejection lands. "Sarah owns the privacy manifest fix; James owns resubmission once QA signs off on build 847." That sentence, posted where everyone can see it, prevents the silent assumption that someone is already on it.
Post rejection reasons in your release channel
The highest-leverage change most teams can make is simple: when a build is rejected, post the reason in the same Slack channel (or thread) where the release was opened.
Not a vague "we got rejected." The actual text — guideline number, reviewer note, affected binary. Link to the console if helpful. Tag the fix owner. Move the release status back to the appropriate step: build, QA, or awaiting resubmission.
This does three things at once. The PM gets an honest status without pinging the dev. QA knows a new build is coming and what to regression-test. Leadership stops hearing "still in review" when the truth is "blocked on a metadata fix."
If you're polling App Store Connect and Play Console manually today, consider automating that notification into Slack. The goal isn't another dashboard — it's one less place people have to remember to check when a release is already in flight.
Run the loop without resetting context
Each trip through the rejection loop should preserve what the team already decided: scope, target date, which tickets are in the build, who signed off on QA. Starting a fresh email thread or a new DM chain wipes that context.
Keep the discussion in the release thread. Log each rebuild number. When resubmission happens, update the status so nobody asks "did we resubmit yet?" twelve times.
For e-commerce teams, a rejection during a campaign window is a direct hit on revenue. The teams that recover fastest are the ones where rejection is visible within minutes, ownership is clear, and the loop doesn't depend on one person checking their inbox.
Make rejection a first-class release step
Most release checklists jump from "submitted to store" to "approved" as if nothing happens in between. Rejection is a normal outcome, not an exception. Design your workflow accordingly: a defined state, a named owner for triage, and a path back to build or QA.
ReleaseSteps was built for exactly this kind of friction — store status, including rejections, posted into the Slack channel where your release already lives, with steps you can route back to the right person. If your team is still losing hours to email archaeology every time Apple or Google pushes back, see how ReleaseSteps handles store notifications or start with one change: post the next rejection reason where your team already is.