Build Xamarin iOS App in the Cloud

While developing an app using Xamarin, you want it to work on your iPhone but you don’t own a Mac. At work we have a old outdated iMac which is slow and remote-desktop is horrible. So how do you build an iOS Xamarin app in the cloud? Using Azure DevOps.

So how do we tackle this?

Note: In this tutorial I’m making an iOS Disitribution App as an Apple Enterprise Developer. However the steps are similar if you intend on publishing your app to the App-Store, except you have to manually upload it.

Requirements

For this to work, you need the following already setup;

  • An Apple developer enterprise account with a iOS Distribution profile and have registered your app.

1. Configure your Library

We don’t want our secrets inside our git so we will store them in Azure DevOps, as we do need them during the build proces. So first go to Library in Azure Devops under Pipelines. Then select the tab Secure Files, then upload the files below. (I used that old Mac from work to export my certificate to a p12 format, with a password. But you can also do that using command-line tools; see stackoverflow.)

  • Your iOS Distribution profile: a p12 certificate (from the Apple developer portal).
  • Your app’s mobile-provision profile (from the Apple developer).

Then go back to the tab Variable Groups and create a Variable Group with your secrets; (Note: you can rename your file names in DevOps.)

  • DistributionCertificateFileName: File name of your p12 certificate.
  • DistributionCertificatePassword: Password for the p12 certificate.
  • ProvisioningProfileFileName: File name of your mobile-provision profile of your app.

2. Change your Pipeline script

Next we will setup our pipeline. Most important; we want to use a Mac to do this so set the vmImage to macos-latest. Next we define a parameter to either build Release or Debug, by default we build a Release. Of course you could also add triggers, for that see the manual. I do this to be able to manually create a Debug build (which has some different settings from my Release build).

pool:
  vmImage: macos-latest

parameters:
- name: buildConfiguration
  displayName: Build Configuration
  type: string
  default: Release
  values:
  - Release
  - Debug

As variables we want to add our created VariableGroup from step 1. And we also add a ProjectName variable. This is the name of your application, we use it to find the correct paths to search. We can do this because most Xamarin projects have the same project structure. In the example we below we thus use ExampleProject.

  • ExampleProject
    • ExampleProject
      • ExampleProject.csproj
    • ExampleProject.iOS
      • ExampleProject.iOS.csproj
  • Solution.sln

Replace the <<VariableGroupName>> with the name you chose in step 1.

variables:
- group: <<VariableGroupName>>
- name: ProjectName
  value: <<ProjectName>>

Install the iOS Distribution certificate. This uses the variables from the variable group and downloads the certificate from the secure files.

- task: InstallAppleCertificate@2
  displayName: Install iOS Distribution Certificate
  inputs:
   certSecureFile: '$(DistributionCertificateFileName)'
   certPwd: '$(DistributionCertificatePassword)'
   keychain: 'temp'
   deleteCert: true

Install the app’s provisioning profile, this works similar.

- task: InstallAppleProvisioningProfile@1
  displayName: Install $(ProjectName) Provisioning Profile
  inputs:
   provisioningProfileLocation: 'secureFiles'
   provProfileSecureFile: '$(ProvisioningProfileFileName)'
   removeProfile: true

Build your iOS app using the Xamarin tasks. This uses our build-configuration parameter. And uses the generated Environment Variables (in blue) by the previous tasks.

- task: XamariniOS@2
  displayName: Build iOS
  inputs:
    solutionFile: '**/*.sln'
    configuration: '${{ parameters.buildConfiguration }}''
    clean: true
    buildForSimulator: false
    packageApp: true
    signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)'
    signingProvisioningProfileID: '$(APPLE_PROV_PROFILE_UUID)'

Now we have build our iOS app and generated an IPA file.

3. Upload your App

We could upload the app as a Build Artifact, but then we would have to download it and manually distribute it. There is however an online-service for enterprise app distribution called Diawi. To use their REST-api to upload an account is required.

Add extra variables to your variable group (from step 1);

  • DiawiAccessToken: generate your own access-token.
  • DiawiCallbackEmail: the receiver of an email with the Diawi-link.

First we copy the artifacts to the staging directory; (This is not required, but makes somes paths easier in the following step and can enable you to still store your artifacts in DevOps.)

- task: CopyFiles@2
  displayName: Copy IPA
  inputs:
    SourceFolder: '$(ProjectName)/$(ProjectName).iOS'
    Contents: |
      bin/iPhone/${{ parameters.buildConfiguration }}/*.ipa
      bin/iPhone/${{ parameters.buildConfiguration }}/*.plist
    TargetFolder: '$(build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}'
    flattenFolders: true

Then we run a script (bash on macos) using curl to upload our IPA file, using the REST-api of Diawi using our variables from the variable group from step 1.

- script: >-
    curl https://upload.diawi.com/
     -F token='$(DiawiAccessToken)'
     -F file=@$(build.ArtifactStagingDirectory)/${{ parameters.buildConfiguration }}/$(ProjectName).iOS.ipa
     -F wall_of_apps=1
     -F callback_emails='$(DiawiCallbackEmail)'
  displayName: Upload to Diawi

You can add more parameters, see the API description (you need an account to access it).

Conclusion

As you can see the proces is quite easy, with existing tasks from the Azure DevOps library.

Allium available on NuGet

My package Allium has been made available on NuGet. At my work we use it internally to track usage and runtime of a tool that generates documents. Together with Google DataStudio I’ve created several Dashboards to monitor it. The latest version is v1.2.3. For more check out the source on GitHub.

For credits see my original post.

Things I Mean to Know

I regularly listen to podcasts in the car. One of the podcasts I follow is This American Life. Sometime ago they put out an episode titled “Things I Mean to Know“. This triggered me into creating a list for myself. Not necessarily to blog about it, but to have a grand feeling of what technologies I can say I do know something about and what not.

Funnily the podcast goes into quite the opposite opinion; that such lists are just a burden. During my work I regularly speak to customers, partners and other technical people. Usually new technologies come up and I want to be able to have at least a general idea what it is about!

So here a broad list of Things I Mean to know; mostly pulled from Gartner. (story behind)

  • Data science and big data
  • Quantum computing
  • Digital twin
  • Serverless, edge computing and IoT platforms
  • Volumetric displays (Holograms)
  • Deep learning, machine learning

This post is a reminder for myself to report back to you, my readers, about what I’ve learned and to explain what is worth diving into or what can be ignored.

In another future post I will dive into things I’ve already digged into last year (2017) and that I’m currently experimenting with; Things I’ve Learned About.

Quick FBX Inspector

This week I came across a simple option to inspect FBX files, something I’ve always wanted to have. It’s not a native solution or does not have fancy GUI or has a 3D viewer. It’s a framework to use the FBX SDK using .NET. The sample that comes with it, does just what I need!

At Soltegro we’re working with BIM models in the form of Revit, Navisworks or AutoCAD files. Each of these pieces of software can transform these files into FBX files, however they all do it differently. And to that end I’m looking for a way to inspect the FBX files, and it’s internal tree, before importing them into Unreal Engine 4.

You can find the tool on GitHub; https://github.com/Kolky/ManagedFBX. Thanks to returnString for the first version. 

I’ve modified it slightly to support the FBX SDK 2016 v1.1 used by Unreal Engine 4.16. And made it support FbxProperties and expanded the sample to be more versatile. I might add a WPF version of the Sample and also more FBX info in the future. But for now it does what I need!

Managed FBX Sample

AnyStatus ‘support for Jenkins MultiBranch’

Two weeks ago I came across a plugin for Visual Studio; AnyStatus. It gives you the ability to keep track of all kinds of services/servers while working in Visual Studio. It lacked the ability to track Jenkins MultiBranch projects, what we use a lot at my work; Soltegro. Since the API was straightforward and freely available in GitHub, I decided to develop it myself. And as of this week it has been merged into the Plugins dll; Pull Request 4.

The code could use some extra work, when the API introduces a better way for managing and creating sub-items. There is still discussions going on about this; Issue 2.

Allium ‘Google Analytics v3 Tracker in C#’

Lately I’ve been looking into NuGet packages and libraries on GitHub to add Google Analytics tracking in .NET WPF applications. There are quite some that offer ways to do this, see the links at the end. They all however have their limitations; either they lack support for WPF (and it’s hard to add) or they use older versions of the Google Measurements Protocol. It’s a shame that Google hasn’t released a tracking library itself! Their Analytics Reporting API is quite good!

So I’ve decided to create my own solution, Allium. As of right now, it is still WIP and untested.

Here is however an extremely simple usage example, which will not change much during development;


using (var session = new AnalyticsSession("UA-XXXXX-YY"))
{
  session.TrackScreenViewHit("ThisWindow");
}

Inspired by;