1) What is the purpose of the new mobile release schedule?
Our goal is for the Mobile team to reach a cadence of seamless releases in which the process is uniform and transparent for all stakeholders. Predictable and continuous code releases provide fewer feature launches in each release and lower-risk deploys. This process will also allow for:
Sufficient time for the Mobile team to prepare and ensure a smooth release;
Reduced amount of time dealing with merge conflicts;
Decoupling QA from the submission process to mitigate last-minute bug finds;
Pre-submission beta testing among select users.
2) How are mobile releases different from web releases?
The nature of mobile native apps requires a single binary file to be compiled, built and packaged for submission. Once a new version is released in the AppStore, we cannot make code changes to that version.
The submission review process requires at least 24-48 hours between submission and release, and the unpredictability of the review process can delay the app release. For this reason, we need as much time as possible between app feature submissions and go live dates.
Unless we force upgrade users (which we avoid since it hurts the user experience), we cannot guarantee the timeline in which users update to the newest app version.
3) What are the logistics of the new release schedule?
We will be submitting a new version of the app every other week.
Any features in the released version waiting for go live dates will be behind feature flags.
If bugs are discovered post-release, we will evaluate the impact on a case-by-case basis. We generally employ a roll forward strategy rather than having to revert to a previous version of the app, unless the release causes a truly critical issue.
4) How can other teams best coordinate with Mobile?
While actively working on an app-related ticket, keep the ticket status up-to-date (i.e. “Dev in Progress”, “Ready for QA”, “QA in Progress”) so that the Mobile team can keep track of a feature’s status for each release.