Software agency · Delivery
Mobile app store release
Get a client's app update through store review without last-minute surprises. The client supplies the listing details and account access through a shared link, and nothing is submitted until the engineering lead approves the build and the client approves the release notes.
- Duration: 1 to 2 weeks
- How often: For every app store release
- Steps: 10 steps
- AI agents: 1 AI agent
- Approvals: 1 approval
Free plan, no credit card needed.
What changes with this template
Without it
The app sits in the agency's developer account, and moving it later is painful.
Screenshots, privacy answers and texts arrive the day before submission.
A rejection only surfaces when the client asks why the update is not live.
Release notes are written in a hurry by whoever submits the build.
With it
The client's own accounts are used from the first release, with your team invited.
The client shares the listing details and privacy answers through one link at the start.
A rejection blocks the run, with the reason, until the fixed build is resubmitted.
An AI agent drafts them, the engineering lead corrects them and the client approves them.
The template, step by step
Each step says who does it: someone on your team, an AI agent, or the client through a shared link. An approval keeps every later step locked until it is given.
- Done by your team
- Done by an AI agent
- Done by the client, through a shared link
Starts when
A version of a client's mobile app is ready to release. The project manager starts a run with the app name, the version and the planned release date.
- 1
Plan the release and share the link
Day 1Project manager · Team
Agree what goes into the version, fill in the release details and send the client the shared link with what the stores need from them.
Checklist
- Release scope agreed
- Shared link sent to the client
Fields to fill in
- App name (required)
- Version (required)
- Planned release date (required)
- 2
Client provides store details and account access
Days 1 to 3Client product owner · Shared link
Through the shared link, the client confirms the app is published under their own developer accounts, invites the team there and shares what the store listings need.
Checklist
- Team invited to the Apple developer account
- Team invited to the Google Play Console
- App privacy and data safety questions answered
Fields to fill in
- Features to highlight (required)
- Link to the privacy policy (required)
- Support email (required)
- Link to new screenshots
- 3
Build the release candidate
Days 2 to 5Mobile developer · Team
Build the signed release candidate with the right version and build numbers, and send it to the test devices.
Checklist
- Version and build number set
- Signed with the client's certificates
- Sent to the test devices
Fields to fill in
- Build number (required)
- Link to the test build (required)
- 4
Test on real devices
Hidden from the shared linkDays 4 to 7QA engineer · Team
Test the release candidate on the supported devices and operating system versions, including the update from the version that is live now.
Checklist
- Tested on the oldest supported OS
- Update from the live version tested
- Store guideline checks done
- No crash on start
Fields to fill in
- Link to the test report (required)
- Known issues
- 5
Draft the store release notes
Day 7Store notes writer · AI agent
The store notes writer drafts the release notes for both stores from the features the client highlighted and the known issues, within the length limits in its instructions.
Fields to fill in
- Draft release notes (required)
Checked by: The engineering lead corrects the notes and approves the build in step 6.
- 6
Approve the build for submission
Day 8Engineering lead · Team
Read the test report and known issues, correct the release notes, then approve the build and email the final release notes to the client.
Checklist
- Test report read
- Release notes corrected
- Build number matches the tested build
Approval: The client's approval and the store submission stay locked until the engineering lead approves the build.
- 7
Client approves the release notes and date
Days 8 to 9Client product owner · Shared link
The client reads the release notes the engineering lead emailed and, through the shared link, records their decision and the date the version may go live.
Fields to fill in
- Decision (required)
- Release on (required)
- Changes to the text
- 8
Submit for store review
Day 9Mobile developer · Team
Submit the approved build and release notes to both stores, set the release to manual or phased, and record the submission date.
Checklist
- Submitted to the App Store
- Submitted to Google Play
- Release set to manual or phased
Fields to fill in
- Submitted on (required)
- 9
Handle the review outcome
Days 9 to 12Mobile developer · Team
Record the result of each store review. If a store rejects the build, mark the run blocked, note the reason and resubmit after the fix.
Fields to fill in
- App Store review result (required)
- Google Play review result (required)
- Rejection reason
- 10
Release and confirm the version is live
Week 2Project manager · Team
Release the version on the agreed date, check that it installs from both stores and let the client know.
Checklist
- Live in both stores
- Installs and opens from the store
- Crash reports checked after release
- Client informed
Fields to fill in
- Live on (required)
Done when
The version is live in both app stores under the client's own developer accounts, and the release is recorded on the run.
Make it yours. Rename steps, change owners and add checklist items, fields or approvals. The template is a starting point for the way your team works.
The AI agents in this template
An agent only works on its own steps, and a person on your team checks what it did. Anything an agent writes to a connected app waits for approval unless you allow it.
Store notes writer
Drafts the release notes for both app stores from what changed in this version.
What it does
- Reads the features the client highlighted and the known issues
- Writes short, user-facing release notes
- Keeps within the length limits in its instructions
- Completes its step, so the engineering lead can review
Checked by: The engineering lead corrects the notes and approves the build in step 6.
Questions this template answers
Publish under the client's own developer accounts with your team invited, and submit only a build that is tested and approved. In step 2 the client invites the team and answers the privacy questions through the shared link, and in step 8 the mobile developer submits the approved build.
Under the client's, so they keep the app, its ratings and its users if you ever part ways. Step 2 asks the client to confirm their own accounts and invite your team before the first build is made for release.
Test on the oldest operating system you support, test the update from the live version and check the store guidelines that cause rejections. Step 4 holds that checklist for the QA engineer, with a link to the test report.
Record the reason, fix it and resubmit, and tell the client instead of letting the release date slip quietly. In step 9 the mobile developer marks the run blocked with the rejection reason until the fixed build is resubmitted.
Let AI draft the release notes for both stores from what changed in the version, and keep the build approval with your team. The store notes writer drafts the text in step 5, and step 6 is an approval gate where the engineering lead corrects it and approves the build.
Submit early, set the release to manual or phased, and release on the date the client agreed. In step 7 the client sets the release date, in step 8 the mobile developer submits with a manual or phased release, and the version goes live in step 10.
Run this workflow in OKiDO
Set up the steps, owners and approvals once, then start a run for every new case.