Simple, Yet Powerful: How We Make Our Builds Better

Visual Studio App Center

Visual Studio Mobile Center is now Visual Studio App Center. Learn more here.   Mobile developers have a lot of challenges, and our goal is to make building and deploying your app the least of your worries. We (the Mobile Center Build team) developed a simple Android and iOS app called PomPom to ensure we’re delivering the best developer experience and making continuous integration and delivery easier for our users. In the process, we’ve identified a few ways to optimize our build processes, letting us focus on building more—and better—features.

To highlight some of our favorite simple, yet powerful, tweaks, we’re sharing how we’ve set up and configured PomPom’s iOS build processes—maybe even inspiring you to try similar in your own builds.

The project utilizes a classic branching process, where “develop” is the branch for beta testing that is distributed to the development team, while “master” is the release branch that gets distributed to the broader team.

PomPom Dashboard in Visual Studio Mobile Center.


Customize Your Build with Build Scripts

We work on PomPom side-by-side with our Mobile Center development cycles, so we’re always using the latest capabilities of the Build and Distribution services. This serves two goals: we’re testing out new features on our own projects and, as we work on PomPom, we find out where we need or want additional functionality. More often than not, our findings align with the feedback we hear from our users.

To guarantee we’re testing Mobile Center’s latest capabilities, we want to make sure we’re using the most recent Mobile Center SDK, without the help of a dependency manager. Fortunately, Mobile Center supports custom build scripts to help developers accomplish specific tasks, and this is what we use.

A build script allows you to add simple or complex scenarios, via Bash or PowerShell, in three pre-defined stages of your build process: post-clone, pre-build, and post-build.

We include the Mobile Center SDK as a Git submodule in the project’s repository and add a post-clone build script named next to the project-level file, which automatically ensures we’re getting the latest version in our builds.

#!/bin/bash # Pull the latest state of the Mobile Center SDK cd Vendor/MobileCenter git checkout develop git pull

We distribute from two different branches (“develop” and “master”), and we want it to be easy for us and our testers to quickly determine whether the beta or release version of the app is installed on our phones.

To accomplish this, we use a pre-build script named to update the name for each non-master branch release, appending “Beta” to the bundle name by modifying the CFBundleName in the Info.plist.

#!/bin/bash # Change the bundle name of an iOS app for all non-master branches if [ “$MOBILECENTER_BRANCH” != “master” ]; then plutil -replace CFBundleName -string “$(PRODUCT_NAME) Beta” $MOBILECENTER_SOURCE_DIRECTORY/MyApp/Info.plist fi

Note: When you push your build scripts to the repository for the first time, or if you’ve moved them to a different location, verify that they show up in your build configuration and make sure to save the new configuration. After applying the changes, the scripts will run with your next build.

Mobile Center Build Service UI


Auto-Increment Your Build Numbers

When setting up any branch that will be distributed to users, each build needs a unique version. Because of this, we’ve simplified version incrementing by having it managed by Mobile Center. Android and Windows require incremental version numbers to allow users to install new builds without needing to manually delete the previously installed version, and as you know, they’re useful throughout the whole development process, regardless of the platform.

This doesn’t require any scripts. Simply turn on “automatically increment build number” as you configure your build and Mobile Center takes it from there. Incremental versions streamline feedback and bug collection, since users can reference specific versions when they report issues, make suggestions, or find bugs. If the Mobile Center SDK captures a crash, we can associate the issue with the respective build.

Launch Test: Distribute to Your Users with Confidence


Mobile Center Build Service UI: Launch Test and Distribution in a few clicks.

We want to make sure that our newest version of PomPom launches smoothly before we send a new release to the team, so we run an automated test on a real device for each build with Mobile Center’s launch test* feature. The test captures the first screen that users see when “launching” (opening) the app. If the test fails, the build will fail as well, and we can investigate and solve the issue.

Once we’re confident that our build is stable, we distribute PomPom to the broader Mobile Center team and everyone automatically receives an email that a new version is available.

*Launch test uses Mobile Center’s Test service, selecting one random device from our Mobile Center Test device lab. After signing up for Mobile Center, any mobile developer can use the Launch Test capability without writing any additional lines of code. Mobile Center Test service can also be used to run more robust UI test scripts, automatically testing apps on thousands of real devices and hundreds of operating system, hardware, and device configurations.

Wrapping Up

These are just three ways we use to customize and improve our build process based on our specific needs to help us work faster. PomPom will continue to be our companion app as we add new features to Mobile Center, and we welcome your suggestions about how we can help you get more out of your build process.

Happy building!

Get started

Log in to Mobile Center or create your free account today.


Discussion is closed.

Feedback usabilla icon