The hidden risks of manual App Store and Play releases
· 8 min read
Plenty of teams still release by hand. Someone archives in Xcode, uploads, fills in the version page in App Store Connect, clicks submit, then does the same in Play Console with a staged rollout. It works most of the time. The trouble is in the hours and days after the click, when nobody is watching, and in the way access to the store accounts gets shared to make it all possible.
This post goes through the risks that come with manual release work, where automation removes them, and where it does not.
Risk 1: nobody notices the review status changed
After you submit, an App Store version moves through states such as Waiting for Review, In Review, then either Pending Developer Release, Ready for Distribution or Rejected. Apple sends emails, but they go to whoever is on the account's notification list. In agencies and small teams that is often one person, or a shared inbox nobody reads on a Friday.
The cost is time. A version approved with manual release set sits unreleased over a weekend. A version rejected on a Thursday night gets looked at on Monday. For a fix that customers are waiting for, those are lost days with nothing technically wrong.
Risk 2: rejected or broken builds are noticed late
A rejection is not the only way a build stalls. Some problems arrive before review:
- A build stays in Processing, or fails processing, and the version page cannot pick it.
- An email with ITMS-91053 or ITMS-91061 says the privacy manifest is missing a declaration.
- Play Console refuses the upload because the target API level is too low, or flags a policy declaration that needs an answer.
- A TestFlight build waits for beta review and external testers never get it.
When the person who uploaded the build has already moved on to the next task, each of these adds a round trip. Most of them are visible in the build file before upload, which is why we wrote up the common rejection reasons and how to check for them.
Risk 3: a staged rollout is halted and nobody knows
Staged rollouts are a good safety net. On Google Play you release to a percentage of users and raise it over time. On the App Store, phased release for automatic updates runs over 7 days (1, 2, 5, 10, 20, 50 and then 100 percent) and can be paused for up to 30 days in total.
The safety net has a gap. When someone halts a Play rollout because of a crash spike, users who already got the update stay on it, and the rest stay on the old version. If the halt is not communicated, the team may think the release is out, support answers questions about features most users do not have, and the fix waits. The same goes for a paused phased release on iOS that nobody remembers to resume.
Risk 4: reviews go unanswered
Store reviews are the most public feedback an app gets, and in manual setups they are usually read in bursts, when someone remembers to open the console. A one star review about a login bug, answered two weeks later, does more damage than the bug. On Google Play, the reviews API only returns reviews from the last 7 days, so a team that relies on tools reading it needs to check at least that often or the review is no longer in the feed.
Risk 5: store access shared by password
This is the one with the largest downside. To let a freelancer, an agency or a new developer release, teams often share the Apple ID password of the account holder, or add someone as Admin in App Store Connect or Owner in Play Console because it was the quickest role that worked. Problems that follow:
- Two factor codes go to one person's phone, so releases depend on that person being awake.
- A former contractor still knows the password months later.
- Admin roles can change banking, agreements and user access, not just releases.
- There is no record of who did what.
Both stores have better options. App Store Connect supports team API keys with a role chosen at creation, and App Manager covers most release work without Admin rights. Play Console supports service accounts with permissions per app. Neither involves sharing anyone's password, and either can be revoked on its own without changing the account holder's login.
Where automation helps
Most of the risks above are about steps a person forgets or does in a hurry. Moving the release into a pipeline removes many of them.
| Task | Common tools | What it removes |
|---|---|---|
| Build and sign the release variant | CI (GitHub Actions, GitLab CI, Bitrise, Codemagic, Xcode Cloud), fastlane gym or Gradle | Uploading a debug variant, building on a laptop with an old Xcode |
| Manage certificates and profiles | fastlane match, Xcode automatic signing on CI | Certificates on one person's Mac, expired profiles |
| Upload to TestFlight | fastlane pilot, Xcode Cloud | Manual Transporter uploads |
| Upload to App Store and set metadata | fastlane deliver | Copy and paste errors in What's New and screenshots |
| Upload to Play tracks | fastlane supply, Gradle Play Publisher | Wrong track, wrong rollout percentage |
| Share test builds before the store | An install link service, for example the AppForShare CLI in CI | Builds sent by chat, testers on the wrong version |
All of these tools use API keys or service accounts, which also fixes risk 5 as a side effect. The keys live in CI secrets instead of in someone's head.
What automation does not cover
Pipelines are good at pushing builds out. They are not built to watch what happens next. A CI job finishes when the upload succeeds; it does not wait three days for review, notice a halted rollout, or read new reviews. Teams fill that gap with a mix of console emails, a person checking in each morning, and sometimes scripts that poll the store APIs and post to chat. The scripts work, but someone has to host them, keep the credentials safe and fix them when an API changes.
How AppForShare store connections fit in
AppForShare is a test build sharing service first: upload an .ipa or .apk, get an install link and QR code. On the Pro and Team plans you can also connect your store accounts to see what happens after submission. It is read only. AppForShare does not submit builds to the App Store or TestFlight and does not publish on Google Play. Your pipeline or your team still does that.
What it does:
- Release status page: for each app you share with AppForShare, the App Store version states (preparing, waiting for review, in review, rejected, approved, live) and the last 5 builds with processing state and TestFlight beta review. For Google Play, each track's releases (draft, rolling out with the percentage, halted, released) and Play's review state.
- Alerts: changes are emailed to the workspace owner and can go to Slack, Discord or your own webhook through the
store.statusevent. Apple updates arrive through a webhook AppForShare adds in App Store Connect when the key's role allows it. Otherwise, and for Google Play, status is checked every 30 minutes, with a refresh button for an on demand check. - Reviews inbox: App Store and Google Play reviews of the shared apps, checked every 6 hours, with needs reply, replied and all views. An AI draft can suggest a reply, but a person always presses Post reply. New reviews can go to Slack, Discord or webhooks through the
store.reviewevent.
Access works the way the stores intend: an App Store Connect team API key (we recommend App Manager, never Admin) and, for Google Play, either an invite to the workspace's own service account or a service account JSON. No passwords. Keys are encrypted with Google Cloud KMS and never shown again. Every store API call is logged, and disconnecting deletes the key at once. Pro includes one App Store Connect and one Google Play connection. Team allows up to 10 per store, plus a one time invite link a client can use to connect their own account, which suits agencies that release for clients (see AppForShare for agencies).
A practical setup
- CI builds, signs and uploads to TestFlight and Play tracks with fastlane or your provider's steps, using API keys.
- The same pipeline shares each test build with an install link so QA and clients test the exact binary. See uploading builds from CI.
- Release status and review alerts go to the team channel, so a rejection, an approval or a halted rollout is seen within the hour, not on Monday. Our post on Slack and Discord build notifications shows the setup.
- Nobody outside the account holder knows the account password.
Get started
Store connections are part of Pro at $12 a month and Team at $39 a month. The first Pro subscription comes with a 7 day trial. Details are on the pricing page, or create an account and connect a store from the dashboard.
