Building cross-platform Xamarin.Forms apps in VSTS

The other day I wanted to create a DevOps CI / CD pipeline for a simple Xamarin.Forms app that I’d created. The Visual Studio solution contains project files for the PCL, Android, iOS, and UWP projects. The CI / CD pipeline would include VSTS for source control, build, and release, my Mac for the actual compile and packaging of the iOS app, and HockeyApp for beta version management and beta user management. It’s not that difficult to set up, but there are a few places where it would be easy to get hung up.

For my Xamarin.Forms project I created three VSTS build definitions, one for each platform. This allowed me manage the pipeline for each platform separately. Two separate build agents are required to build the solution. The Hosted Pool and Agents can build for UWP, Android, and a number of other platforms, but they can’t build for iOS. A different Pool and Agent has to be set up for iOS, pointing to a Mac environment such as MacInCloud, or to your local Mac.

The solution in Visual Studio needed three Build Configurations: one for Android (without UWP or iOS), one for UWP (without Android or iOS), and one for iOS (without Android and UWP).

VSTS Agents and Build Definitions

So with that, let’s take a look, first with the VSTS Build setup. . . (FYI, I’m currently not using Release Management to publish the app to HockeyApp. I’m going to add that process later.)

I downloaded an Agent to my Mac and configured it to run using a pool other than the Hosted pool. I chose to use default pool. In the following image you can see that I have a number of Agents defined in the “default” pool. “MIC_VSTS_snow…” is set up to use MacInCloud. The other three point to different Agent configurations on my local Macs. (I’m going to write a future post about how I configured the Agent on my Mac.)


I defined a User Capabilities variable for each Agent so my build definitions could demand which particular Agent to use from the default pool. For instance, I created a User Capability called MacinCloud for the agent associated with MacInCloud. I created a Capability called NewMac for one of the agents that lives on my MacBook Pro.

image image

In the VSTS build definition I added a Demand for “NewMac” “exists” so it will run a particular agent on my MacBook Pro. (You can have multiple agents running on your Mac if you want to, and point to them this way.)


In my build definition I also created a variable called BuildConfiguration so I can identify which which Build Configuration in the VS solution I want the VSTS build to use. (I’ll show those settings in VS in just a bit.)


I pointed the build to my Xamarin project repo and set it to have a continuous integration trigger. In the Build Task I used the $(BuildConfiguration) variable for the Configuration.


I set up the Android and UWP VSTS build definitions similar to the iOS definition. Biggest difference was that I was able to use the Hosted agent.

Visual Studio Build Configuration

Let’s take a look at the Build Configuration in Visual Studio next.

As I mentioned I created three VS build configurations to be used by the three VSTS builds, “iOS Release”, “Android Release”, and “UWP Release”. In the VSTS build definition for iOS above, I used the “iOS Release” configuration. Here’s the definition in Visual Studio. The “XamarinFormsIosAndroid” project is the PCL project, and the “XamarinFormsIosAndroid.iOS” project is, yep, the iOS project. Notice that the Droid and UWP projects are not set to build (checkboxes are unchecked) in this configuration.


For the Android and UWP build configurations I took the same approach: build the PCL project and the .Droid or UWP project as appropriate. Here’s the screenshot for the Android build. Notice that I left the “Deploy” checkkbox unchecked for the .Droid project. There’s no need to deploy it during the Build task in VSTS.


And that’s pretty much it…. at least as far as setting up the build goes.  : )

I haven’t shown it here, but you can add a step for Xamarin Test Cloud (automated testing) and a step for deployment to HockeyApp (for beta distribution and user management). Or even better, create a Release Management definition to handle the deployment to HockeyApp. More about those topics in a future blog posts.


Here are some references you’ll probably find useful when setting up your VSTS builds for Xamarin.Forms.


Universal Windows Platform app development resources

A client recently (as in a couple of minutes ago) asked me about resources for building apps on the Universal Windows Platform. For your reading pleasure, here’s the list I quickly compiled (thank you BING):


Windows Dev Center:

Get started with Windows apps:

UWP platform guide:

Microsoft Virtual Academy free training on mobile development:

UWP code samples:

Dev Center developer programs:

How-to guides for Windows 10 apps:

Move from iOS to UWP:


Identifier field in Xamarin iOS app project properties

I’ve been working with Xamarin.iOS for Visual Studio for a while now, and I’ve always wondered what the “Identifier” field really does. I heard something about using reverse domain name naming convention, but didn’t know why. Not having an iOS device, I’ve always tested on the iOS simulator, and I’d make up some random Identifier, such as “”. The simulator didn’t complain, so I carried on in ignorance.

(Even though I simply made up an Identifier, while working in VS 2012 with Xamarin.iOS I quickly learned to always populate that field, plus the Application name and Version fields. If they’re empty when you send the app to the simulator, the simulator will barf all over you. Then you’ll have to dig around in Finder to weed out the bad app from the simulator folder structure. Ick. Nice recent update with Xamarin.iOS — it now will give a compiler error if those fields are empty when you build. Thanks, Xamarin!)

I found out this evening while digging around that the Identifier field is important when you want to test your app on a physical device, or want to publish the app to the App Store.

To use a physical device or publish to the App Store, you have to register an app profile in the Apple Developer site and download / install the profile on the Mac that has the Xamarin Build Host and Xcode. There are 2 ways to go when creating an app profile – one is explicit, defining the app name you’re going to use; the other is “wildcard” which allows you to use a single app ID to match multiple apps.

I create lots of demo apps, so I chose to go with a wildcard app id. That way I don’t have to create a new profile for each and every app I want to demo on a device. I created the app ID using the domain I own, as “com.snowstormlife.*” which allows me to use “com.snowstormlife” followed by any app name I want to give an app.

iOS Identifier property

The Xamarin site has a pretty good set of instructions about all this here:

Note that if you’re simply going to use the simulator instead of a device, it doesn’t really matter what you use in the Identifier property. It’s only important when you’re sending to the physical world or the app store.

Happy cross-platform coding,


Curious about Xamarin for Win8, IOS, and Android?

Here are some notes about downloading and setting up Xamarin’s Field Service sample app in Visual Studio. (It’s one of Xamarin’s cross platform sample apps. It includes a project for WinRT, iOS, Android, all of which leverage the same core set of business logic.)

I assume you already have Visual Studio 2012 and Xamarin installed on your Windows 8 dev box (and Xamarin on a Mac if you’re going to build / run the app on an IOS simulator).

Download Xamarin’s prebuilt apps from their public git repository
c:\repos> git clone xamarinPrebuilt

Also download SQLite-net from their public repo
c:\repos\xamarinPrebuilt\fieldservice\dependencies\sqlite-net> git clone

Open the VS version of the Field Service solution (FieldService.VisualStudio.sln).

Set the WinRT project as the startup project.
Build and deploy the app and kick the tires.
Looks nice, eh?

You’ll have to manually add the IOS project to the FieldService solution. (Not sure why it wasn’t already a part of the solution, but it’s easy to add.)

If it’s not open already, open the Field Service solution (FieldService.VisualStudio.sln)
Add the FieldService.IOS project to the solution
Add the Bing Maps SDK for Windows RT via NuGet

Before you run the IOS version in the simulator, be sure to enter something in the IOS project’s properties for application name, identifier, and version. Otherwise the simulator may go crazy.
Set the IOS project as the startup project
Debug toolbar should have Debug, iPhoneSimulator, iPad 6.1

Run it.

Yep. It really works. C# and Visual Studio for Windows 8, IOS, and Android.

Handy reference for the IOS Simulator gestures: