Introduction
Hi 👋. This is @manoj, an iOS engineer from the XB client core team.
This article is part of our blog series Behind the Scenes of Developing Mercari’s First Global App where we share about the inner workings of the Mercari Global App. Do check out the posts in the series, if you haven’t already.
Overview
Everyday, our developers add new changes to the app. They can be about fixing bugs, improving existing features or implementing complete new functionality for the app.
For all these changes to reach out to the users, it is not as straightforward.
Today, I’ll walk you through how we designed our mobile app release strategy to deliver updates from developers to users faster.
Our Release Schedule
We follow a predictable weekly release schedule to keep all stakeholders informed about our releases.
Here’s what our current release cadence looks like:
- We aim to have a weekly release schedule (except for a few occasions).
- The release process takes less than 2 days on an average.
Overall, it can take anywhere from 3 – 7 working days for a change to be live on production, depending on the day it is implemented.
Why Speed Matters?
Fast releases aren’t just about moving quickly. They fundamentally change how we work, especially in the case of adding new functionality. Some benefits include:
- Shorter experimentation cycles → We can test hypotheses with real users and gather feedback faster.
- Rapid iteration → Quick feedback loops mean we can refine features and fix issues faster.
- Faster time to value → Users get new features and improvements as soon as they’re ready, improving their experience continuously.
Also, it is not enough to just be faster, but the releases we make need to be stable and shouldn’t break any experience for the users.
How We Make It Work
Our codebase is hosted on GitHub, and we use GitHub Actions to automate workflows, generate builds, run tests, and handle deployments.
We use a monorepo structure that includes code for both our marketplace and global apps. This setup helps us share and reuse code more easily. My colleague, Shingt will soon share more about our codebase as a part of this blog series in his upcoming article. Do check it out to know more.
To ensure stable releases, we follow trunk-based development.
Throughout the week, as we work on building new features, we ensure that all the changes are hidden behind individual feature flags. This allows us to merge the changes to the master branch incrementally, without worrying about broken functionality.
Once a feature is developed, developers and QA test it to ensure there are no issues. Then, the feature is gradually released to users by rolling out the feature flag.
Since all changes on the main branch are expected to be stable, we can release at any time without worry.
When we’re ready to release, we cut dedicated release branches from the master. This allows development to continue uninterrupted without affecting the ongoing release.
Release Process
iOS and Android releases operate independently, but we keep the same branch cut schedule for both platforms to maintain clarity across the teams.
Automated branch cuts are performed every Tuesday.
The below flowcharts explain the overall release flow.
 |
 |
|---|---|
| iOS Release Flow | Android Release Flow |
Branch Cut
Once we cut the release branch, builds are generated using fastlane and are shared to QA for release judgement. Release judgement tests are mostly automated E2E tests, with few manual ones. These checks helps us ensure our critical flows are working as expected.
In the case of iOS, after the branch cut, the builds are also uploaded to the app store and directly submitted for review to Apple. This allows us to save time while we simultaneously conduct release judgement.
Once the app is approved for release from both release judgement and Apple, we conduct phased release for the apps.
On Android, we wait for release judgement to be successful, before submitting for review to Google. Android reviews are typically faster, so it doesn’t delay us by a lot.
In case of any issues from the reviews, we fix those problems and merge changes into the release branches, which would re-trigger the above flows.
Usually, these steps finish on the same or the next day for both the platforms.
If a feature is implemented by Monday, it can be rolled out to users starting Thursday, which is pretty fast, compared to 1-2 weeks that is typical for most apps.
Post-Release Monitoring
Phased release doesn’t just end our work. The release also needs to be monitored to ensure that nothing is wrong with the build.
We have a crash monitoring setup for the apps using Firebase, and every new crash triggers an alert in our slack channels. Firebase Velocity alerts are also configured, which alerts our on-call engineers in case of frequent crashes.
Our customer support team monitors user feedback and shares it with product teams. We also collect feedback from the App Store and Play Store, which helps us prioritize new functionality. If you’re a user, please leave a review. Your feedback directly shapes what we build next.
If any issues are found at this stage that seriously affect users, then the only thing we can do is to roll out a hotfix to the users.
Hotfix Rollout
Once we identify that we need to conduct a hotfix, the phased release of the ongoing release is halted.
In the case of Android, it is now possible to rollback an already released version to the users, which makes it much more safer.
The process for hotfix is similar to an individual release.
We cut a branch from the last release branch, and merge our fixes into this hotfix branch. All the changes from the release branches are backmerged into the master branch automatically.
The changes are thoroughly tested and submitted to Apple/Google for reviews.
Once the changes are reviewed, we release the changes.
Future Works
We’re currently using Fastlane and GitHub Actions to automate most of our release processes. Looking ahead, we plan to evaluate tools like Xcode Cloud to reduce dependency and ensure we have a reliable fallback in case of failures.
As the app is still new, we haven’t integrated performance monitoring yet. We’re aiming to implement end-to-end performance tracking for critical user flows, including launch times and scroll performance on a per-screen basis. These metrics will help us identify bottlenecks early. By incorporating them into our release pipeline, we can catch regressions proactively and maintain a high-quality user experience.
Conclusion
Our release strategy balances speed and stability. By combining trunk-based development, feature flags, automated submissions, and phased rollouts, we’ve built a pipeline that gets features to users faster while maintaining high quality standards.
We understand that release timelines depend heavily on Apple and Google review times. However, our process remains flexible and can adapt to any issues we may face.
Want to learn more about building the Mercari Global App? Check out the other articles in this series!
