A workflow for mobile apps

Gitflow, trunk-based flow, commit-to-master-and-pray flow, GitHub flow, and all the other workflows are generally aimed at web development projects. If you search online, none of them mention how it would work for a mobile app.

In mobile app development, the main factor that alters the workflow is how long it takes for a version to become available to the public. This is because the stores, both on Android and iOS, need time to review the app.

This waiting time makes it much harder to apply workflows that involve testing features in production and rolling back if something fails.

To solve these problems, at the company I work for we've adopted a different workflow for Android and iOS apps.

This workflow is a combination of GitHub flow and a flavor-based flow.

We generally use the following naming convention for branches:

develop

feature/<some-feature>

bugfix/<some-bug>

As you'd expect, the develop branch must contain everything that goes to the Google Play Store. The problem is that sometimes there are features that need to be tested in the internal and beta channels for a good while; however, we can't neglect the production channel with other fixes and features.

So we propose using a naming convention for features that are unstable and need to be tested across the different channels — these will be the flavor branches.

Flavor branches will contain everything that's stable in develop, plus a feature we're trying to test.

The difference between feature branches and flavor branches is that you can ship a version to the Play Store from a flavor branch, and its lifetime can be longer.

Ideally, a flavor branch's lifetime should be as short as possible, and once the functionality has been tested correctly it can be merged into develop.

Also keep in mind that not every feature needs to be tested separately — it's up to the developers to decide whether a feature is large enough to warrant a flavor.

In summary:

• develop: Main branch. Versions can be shipped from here.

• feature/<some-feature>: Branches created for new functionality. They make it into releases once merged into develop.

• bugfix/<some-bug>: Branches with fixes. They make it into releases once merged into develop.

• flavor/<some-big-feature>: Branches created for features that are too large and possibly unstable. They must contain the code in develop plus the additional functionality. You can ship a version from these branches while they're being tested.

The advantages of this are:

• The production channel stays stable.

• You can test functionality in the other channels, even with a percentage of users.

• If a bug occurs during testing, you'll always have develop.