A couple of months ago I had the opportunity to join a new mobile app development team.

It has been really fun and interesting, but coming from a web development area, it has been quite challenging as well.
One of the first things we focused on was setting up a CI build. We wanted to create a new version at every check-in which could easily be distributed.

Thus, the overall focus of this series of posts will be setting up a CI build for Android and iOS Xamarin projects with TeamCity and FAKE.

I’ll split up the complete explanation into several blog posts.

• Setting up alpha, beta and store versions of your app
  
• Creating a build script with FAKE
• Handling app versioning
• Setting up TeamCity
• Deploying to HockeyApp

Remark: The solution I will describe here is not something I invented myself. This has been a team effort so credits to all the colleagues on the team.

Creating an alpha, beta and store version of your Android and iOS Xamarin project

What do we want to achieve?
During development every check-in in source control should create a new package (an IPA or APK file) which users can then install. This will be the alpha version.

When the sprint is finished, we create a new branch in our source control system which will be our beta version from now on.
However, the test users should also be able to test the beta version without losing the alpha version on their phone. This means that the beta version should not overwrite the alpha version.

How can we achieve this?
We need to focus on the bundle ID. Both on Android and iOS the bundle ID mostly contains your company name and project ID.

Example:

com.ctcode.wordpress.continuousintegration

This will be the ID for our production version but we need to create two other bundle IDs for our alpha and beta version.

com.ctcode.wordpress.continuousintegration.alpha
com.ctcode.wordpress.continuousintegration.beta

This will allow side-by-side installation of the different build versions because the OS actually identifies this as three different apps.
The only downside of this approach is that you will have three apps with the exact same name and icon. This makes it very hard to identify which is the alpha, beta or production version.

One solution is to create a seperate icon for each version. We’ll get back to that later on.

What is the easiest way to quickly switch between these different versions?
The solution we’ve choosen is a combination of different build configurations and MSBuild tasks.

You need to create a build configuration for the alpha version, one for the beta version and one for the store.
The naming of your build configurations is important as you will see later on.

Name your build configuration as follow and create one for AnyCPU, iPhone and iPhoneSimulator.

• Alpha
• Beta
• AppStore

Make sure to configure each build configuration correctly. You don’t want to enable DEBUG symbols for your AppStore build configuration.

Determine the app ID with an MSBuild task

The next step is to determine the bundle ID based on the choosen build configuration.
This can be accomplished with custom MSBuild tasks.

I can’t show you any code but the idea is to create two MSBuild tasks.
One task is responsibly for determing the current build configuration and outputting the correct bundle ID.

The output of this MSBuild task is then used in the second MSBuild tasks which writes the bundle ID to the Info.plist file and/or Android manifest file.

At every compile the MSBuild tasks will now write the correct bundle ID.
In a next post we will use these build configurations in an build script with FAKE so we can setup a TeamCity alpha and beta configuration.

But what about a different icon for each release version?
You can use the same approach by creating an MSBuild task which copies the correct icon from a folder based on the choosen build configuration.

Next upcoming post: Creating a build script with FAKE