| name | mega-release-workflow |
| description | MEGA iOS release workflow commands and scripts. Use when the user asks about code freeze, release preparation, Monday release checklist, creating a release branch, release candidates, hotfixes, or finalizing and merging a release. |
| disable-model-invocation | true |
MEGA iOS Release Workflow
Phase 0: Monday — Prepare Code Freeze (Manual Checklist)
Walk the user through each item below. These are all manual tasks — do not automate them. Present them as a checklist and confirm completion before moving to Phase 1.
1. Create Release Management Ticket
- Create a Jira ticket for the current release
- Link it to the iOS Release Management Epic to log work time
2. Prepare Release Notes (Change Logs)
If this is a hotfix (e.g. v16.20 → v16.20.1):
- Use the default changelog:
Bug fixes and performance improvements.
- No further action needed for release notes
If this is a minor release (e.g. v16.20 → v16.21):
-
Post the following message in the #mobile_platform Slack channel:
Hi team(@iosdevs-urgent), we are preparing release notes for upcoming release <vXX.YY> on <XX XX 202X>, if you have highlight features to announce to our end user in your responsible area, please reply in this thread before tomorrow. Thank you.
Fill in <vXX.YY> with the version number and <XX XX 202X> with the release date.
-
Check all tickets included in this release — if you spot a user-facing highlight, confirm the wording with the developer responsible
3. Check Weblate Setup
- Confirm you have a Weblate account and your
translate.json is configured
- Re-read the Setup section of the iOS L10n (localisation) Process if in doubt
- If
translate.json is missing or misconfigured, download the sample config from: https://mega.nz/fm/iyhV0ARY
- See the
/weblate skill for full setup details
4. Create JIRA Package Search List
- Create a package search list in Jira for this release version (e.g.
iOS 8.25)
- Include tickets across all relevant Jira projects: IOS, AP, BAC, CC, CU, MEET, TRAN, SAO, etc.
5. Add JIRA Package Link to iOS Release Plan
- Open the iOS Release plan - 2026 document
- Add the JIRA package link for this release to the correct row
6. Start Release Process for iOS Shared Repo
- Follow the
/mega-shared-repo-release skill for the full Shared Repo Monday checklist
Phase 0.5: Tuesday — SDK & MEGAChat Releases (Manual Checklist)
Before starting: Ask the user to confirm all Monday tasks (Phase 0) are complete before proceeding.
1. Notify SDK Team in #sdk Channel
- Go to the #sdk Slack channel and find the latest message that says:
"A new Release Train is coming — Release Captains of the apps who are planning to consume the new release of the SDK, please, can you post the target version of the app in the thread? Thanks in advance."
- Reply in that same thread:
Hi team, iOS <X.Y> release will be our next release. Would you please prepare the new SDK and MEGAChat releases? Thanks!
2. Create Release Notes and Upload to Weblate
Skip this step if using the default release notes.
3. Notify Content Team
- Once the changelog string has landed in Weblate, post in the #ios channel:
- Mention @Jeraiza Molina (@content) to prepare the translation
Phase 1: Wednesday — Create the Release Candidate Build
Before starting: Confirm with the user that ALL of the following are done:
- Monday tasks (Phase 0) ✅
- Tuesday SDK & MEGAChat tasks (Phase 0.5) — SDK and ChatSDK releases must be out (you need their commit hashes) ✅
- Shared Repo Tuesday tasks (
/mega-shared-repo-release) ✅
Step 1 — Check Ticket Statuses
- All tickets in this release must be in one of:
QA, QA Awaiting Dev Fix, Resolved, or Closed
- Use the Jira filter to find tickets with incorrect status (remember to check
fixVersion)
- Contact the relevant engineers and QAs to fix status or move tickets to the next release
Step 2 — Notify HelpDesk in #release Channel
Post in the #release Slack channel:
Hi @hdleads, in iOS vX.Y, we will have these highlighted changes.
• <CONTENTS OF THE RELEASE NOTES>
Step 3 — Check Next Version Type
- Check the latest Release Train announcement on #mobile-platform
- Determine if the next version will be a minor release (e.g.
9.3) or major release (e.g. 10.0)
Step 4 — Run PrepareRelease Script
⚠️ Close Xcode before running any scripts. Leaving it open can interfere with git and SPM.
Make sure you are on the latest develop branch. Run from the project root:
cd Modules/MEGASharedRepo/scripts/PrepareRelease && \
swift run PrepareRelease \
--version-number <<version-number>> \
--sdk-commit-hash <<SDK-Commit-Hash-Here>> \
--chat-sdk-commit-hash <<Chat-SDK-Commit-Hash-Here>> \
--shared-repo-commit-hash <<Shared-Repo-Commit-Hash-Here>>
- Opens an MR in GitLab against
develop called Prepare v[major].[minor]
- This script exports strings from Weblate — if any keys disappear from
Base or en .stringsdict files, revert those deletions or the build will fail
Step 5 — Run CreateRelease Script (after Prepare MR is merged)
Once the Prepare v[major].[minor] MR has been reviewed, pipeline passed, and merged, switch to the latest develop branch and run:
cd scripts/ReleaseScripts/CreateRelease && ./run.sh
- Opens an MR in GitLab against
master called Release [major].[minor]
Step 6 — Trigger TestFlight Deployment
Comment on the newly created Release [major].[minor] MR:
deliver_appStore --announce-release true --first-announcement true
This triggers:
- Deployment to TestFlight for the QA team
- Creation of the next iOS release version
- Code freeze and release candidate notifications on Slack
Phase 2: QA Testing Cycle (Ongoing — Days to 1–2 Weeks)
Before starting: Confirm ALL of the following with the user:
After the first TestFlight build is live, QA begins regression testing. The release captain monitors progress and keeps iterating until QA signs off.
QA Monitoring (daily)
Generating a New Release Candidate Build
Repeat this whenever QA finishes a round and all failed cases have been fixed.
1. Update SDK (only if a new SDK release is available)
git -C Modules/DataSource/MEGASDK/ fetch && \
git -C ./Modules/DataSource/MEGASDK/Sources/MEGASDK checkout <<SDK-Commit-hash-here>>
2. Update MEGAChatSDK (only if a new MEGAChatSDK release is available)
git -C Modules/DataSource/MEGAChatSDK/ fetch && \
git -C ./Modules/DataSource/MEGAChatSDK/Sources/MEGAChatSDK checkout <<Chat-SDK-Commit-hash-here>>
3. Commit and push SDK/MEGAChatSDK changes to the release branch — only if at least one of the above two steps was executed.
4. Shared Repo fixes — If there are any fixes in the shared repo, follow the /mega-shared-repo-release checklist to create a new tag. Then ensure the release branch points to the new tag by pushing a commit that references it.
5. Trigger new TestFlight build — Comment on the code freeze MR:
deliver_appStore --announce-release true
6. Add to external TestFlight group — Ask @Harry Yan or @Javier Navarro to add the new build with the official release notes to the external TestFlight group for beta testers.
⚠️ Warning: Before scheduling the next TF build, make sure the previous build has already been reviewed in App Store Connect (if it has a new version number). The CI job will fail at the upload stage if the previous build is not yet reviewed.
Repeat Steps 1–6 until a build has no failed test cases and QA signs off.
Phase 3: App Store Submission (After QA Sign-Off)
Before starting: Confirm ALL of the following with the user:
⚠️ Mission-Critical Pre-Check
Before doing anything else:
- Confirm the build number in App Store Connect matches the exact TestFlight build QA signed off on
- Thoroughly check the changelogs — verify all fixed test cases and expected changes are included
- Confirm the updated app description looks correct in all languages
- If in doubt, ask a former release captain for a second opinion
Step 1 — Notify #devops-cicd to Submit to App Store
Post in the #devops-cicd Slack channel:
Hi team and @eu-mobile-release & @nz-mobile-release, the QA team has approved our latest MEGA iOS Release Candidate Build v<X.Y> in TestFlight and the build is now ready to be submitted to the App Store.
Job: https://controller.cibuild.mega.co.nz/job/iOS/job/iOS-Submit-App-Store/
MR Number: { Release MR Number e.g. 7556 }
Version Number: { iOS Version Number e.g. 16.2 }
Build Number: { iOS Build Number e.g. 2406101618 }
Please help to run the release script that we have configured, and reply to this thread if there's any failure or errors along the way. Thank you!
Note on @nz-mobile-release: Only tag them if sending between 7am–7pm NZST.
For hotfix only: Add this extra line: 7-day phased: false
Step 2 — Upload Demo Videos to App Review
- Upload demo videos to App Store Connect → App Review Information → Attachment
- Reason: MEGA ads are available in specific countries only; the IDFA message won't be visible to Apple reviewers in other regions — demo videos let them see the flow
- If you cannot upload the demo videos, contact @Harry Yan for help
Step 3 — Verify Localized Metadata
- Confirm release notes are applied to all localized languages in App Store Connect
- Confirm the updated app description is applied to all languages
- Confirm the correct build is selected for review submission
Phase 4: Merge the Release Branch
Before starting: Confirm ALL of the following with the user:
Step 1 — Tag and Sync from Master
Comment on the release MR:
create_tag_and_sync_from_master
This creates a tag for the new release and syncs from master using the -s ours strategy to resolve any conflicts.
⚠️ Do NOT merge the MR manually on GitLab. The MergeRelease script handles the merge. Just make sure the MR is approved.
Step 2 — Merge the Release
Once the release MR is approved, all MR discussions are resolved, and CI has passed, comment:
merge_release
This command will:
- Merge the release MR on GitLab
- Create a release on GitLab
- Push current
master to GitHub
- Create a release on GitHub
- Mark the current version as released in all Jira projects
Step 3 — Notify SDK Team
Reply to the corresponding release thread in #sdk and #megachat_native (reply in thread, not a new message):
Hi team, the iOS RC build <X.Y> is signed off by QA and is now being released. You can also merge your release branches when you are ready. Thanks!
Step 4 — Notify iOS Shared Repo Team
Reply to the corresponding release thread in #mobile_shared_module (reply in thread, not a new message):
Hi team, the MEGA Cloud iOS RC build <major>.<minor> is signed off by QA and is now being released. You can create your final release tag when you are ready. Thanks!
Step 5 — End iOS Shared Repo Release Process
- Remember to end the iOS Shared Repo release process once all dependent apps (MEGA Cloud, VPN, Pass) have completed their releases
- See
/mega-shared-repo-release for the Shared Repo release steps
Phase 5: Release to App Store (After Apple Approval)
Before starting: Confirm ALL of the following with the user:
Step 1 — Set Up Crash Monitoring Reminders
Run both commands in Slack (replace X.Y with the actual release version):
/remind #mobile-dev-team to check new & velocity crashes in the new iOS X.Y release in 4 hours
/remind #mobile-dev-team to check new & velocity crashes in the new iOS X.Y release in 8 hours
Step 2 — Notify #ios and #apps_release_updates
Reply to the corresponding release thread (reply in thread, not a new message):
Normal release:
Hi team, iOS <X.Y> (<build-number>) is approved by Apple and is on a 7 days phased release now.
Hotfix:
Hi team, iOS <X.Y.Z> (<build-number>) is approved by Apple and is released to all users now.
Step 3 — Update iOS Release Plan
- Open the iOS Release plan - 2026 document
- Fill in the actual release date for this version
Step 4 — Publish Remote Feature Flags
- If you have a remote feature flag for this release, request a release percentage (e.g. 10%) before publishing
- Publish the flag
- Update the Remote Feature Flags Tracking page
Phase 6: Hotfix (If Needed After Release)
If a critical crash or bug is found in production after the release, use the dedicated hotfix skill:
Use /mega-hotfix for the full hotfix workflow — stopping phased release, running the PrepareHotfix script, fixing issues, triggering the build, and releasing.
