Explore

FAQs

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?

Look at the

Broken link⁠

and determine which app version coincides with your feature launch timeline. Please be in constant communication with the Mobile team and convey any changes in acceptance criteria and/or timeline.

Mobile Devs on Call are expected to prioritize any on call work over feature work. All teams, please be aware of the

Broken link⁠

and help plan feature work accordingly.

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.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.