One issue that sometimes comes up in app development is keeping your app alive and running during long running processes. In my case with My Stream Timer, when the user starts a timer, it needs to keep running no matter what. My first solution was to simply turn on Screen Saver mode.

var appDelegate = ((AppDelegate)NSApplication.SharedApplication.Delegate);

appDelegate.MainWindow.Level = NSWindowLevel.ScreenSaver;

This solution "works" but has the side effect that the app will always be on top all the time, no matter what.  As you could imagine this is not an ideal solution. Then out of nowhere Frank told me about starting and stopping Activities with NSProcessInfo. We then did a full podcast on it:

I of course ignored his advice until this morning when I wrote 40 lines of code that solved all of my problems.

What are Activities?

According to Apple:

"The system has heuristics to improve battery life, performance, and responsiveness of applications for the benefit of the user. You can use the following methods to manage activities that give hints to the system that your application has special requirements."

What this means when you Begin or Perform and Activity is that:

"the system disables some or all of the heuristics so your application can finish quickly while still providing responsive behavior if the user needs it."

This is pretty awesome! There are also two distinct categories of activities based on what you app is looking to do.

• User-initiated activities are explicitly started by the user. Examples include exporting or downloading a user-specified file.
• Background activities perform the normal operations of your application and aren’t explicitly started by the user. Examples include autosaving, indexing, and automatic downloading of files.

In my case I have a "User-initiated" activity where I want to keep the screen on, app alive, and the processor going. There are several different types of NSActivityOptions that you have fine grain control over to specify this:

• NSActivityIdleDisplaySleepDisabled- Flag to require the screen to stay powered on.
• NSActivityIdleSystemSleepDisabled- Flag to prevent idle sleep.
• NSActivitySuddenTerminationDisabled- Flag to prevent sudden termination.
• NSActivityAutomaticTerminationDisabled- Flag to prevent automatic termination.
• NSActivityUserInitiated- Flag to indicate the app is performing a user-requested action.
• NSActivityUserInitiatedAllowingIdleSystemSleep- Flag to indicate the app is performing a user-requested action, but that the system can sleep on idle.
• NSActivityBackground- Flag to indicate the app has initiated some kind of work, but not as the direct result of user request.
• NSActivityLatencyCritical- Flag to indicate the activity requires the highest amount of timer and I/O precision available.

In my case this is a NSActivityUserIntitated, which includes NSActivityIdleSystemSleepDisabled, but I also want NSActivityIdleDisplaySleepDisabled. I also have multiple activities running at the same time, so I created a small manager to handle this.

Start Activity

Dictionary<string, NSObject> Activities { get; } = new Dictionary<string, NSObject>();

public void StartActivity(string id)
{
    if (Activities.ContainsKey(id))
    return;

	try
	{
		var options = NSActivityOptions.UserInitiated | NSActivityOptions.IdleDisplaySleepDisabled;

		var activity = NSProcessInfo.ProcessInfo.BeginActivity(options, "User has inititiated a timer that is a long running process.");

	Activities.Add(id, activity);
	}
	catch (Exception ex)
	{
		Debug.WriteLine($"Unable to start activity: {ex}");
    }
}

Now, when the user starts a timer, I kick off an activity and I am good to go.

End Activity

Now, I need to stop it when the timer ends or the users stops or pauses the timer.

public void StopActivity(string id)
{
    if (!Activities.ContainsKey(id))
        return;
    try
    {
        var activity = Activities[id];
        NSProcessInfo.ProcessInfo.EndActivity(activity);
        Activities.Remove(id);
    }
    catch (Exception ex)
    {
        Debug.WriteLine($"Unable to start activity: {ex}");
    }
}

That is it! Easy peasy, and now the system will keep My Stream Timer will continue running without having to stay on top.

It has been nearly 3 weeks since I put together my DIY spin bike and I have now clocked in over 25 rides! Let's just say I am really enjoying have the bike at home now that it is chilly and more rainy outside. Last week I wrote a blog on my experience and did a full Apple Fitness+ review video, in which I mentioned one of the issues I had was the lack of Cadence sensor integration into the app. Knowing your cadence is really important during a ride because it is your RPM that you are spinning the pedals. A number is often called out during rides and you are set to match it. The Peloton digital app has the ability to connect to a sensor such as the Wahoo or moofit, but Apple Fitness+ does not. So like I always do I set out to fix this problem and build a mobile app! Today, I am proud to introduce My Cadence for iOS & Android available for free on the App Store and Google Play.

The application works by connecting to to any sensor that is broadcasting the Cadence & Speed Bluetooth service. This includes Wahoo, moofit, and other sensors that are popular for indoor cycling bikes. In addition the app fully supports light and dark mode, adjustable font sizes, and is completely free with no time restrictions at all. Here is a quick look at how the app works with me setting it up on my spin bike.

The app is completely free, but I also introduced a Pro mode for $2.99 that helps support independent development and unlocked custom theme colors :)

You can grab the app on the App Store and Google Play today. I will have another blog and video on my YouTube explaining how I built the app soon.

Settings up continuous integration can be tricky when there are new versions coming out. Recently Visual Studio 2019 updated to support Xcode 11, iOS 13, Android 10, .NET Core 3, and C# 8. What a whirlwind of new updates that CI servers got all around the same time! This means that as you were updating your apps your hosted machines also got updated and probably broke your builds :(. My good friend Jonathan Peppers wrote an amazing tool called Boots that allows you to manually install dependencies and previews of Xamarin and Mono.

This is great, but it also means that your build takes a little bit longer to manually install items. Did you know that Azure DevOps has all of the latest bits installed on their hosted agents and even have simple scripts enabling you to decide what version of Xamarin and Mono to run? Here is what you need to know to build your apps in Azure DevOps with C# 8, iOS 13, and Android 10.

Use macOS 10.14

Be sure that you select the latest version of macOS to build your iOS and Android apps on. You can simply specify macOS-latest or macOS-10.14 in your Pipeline settings.

You can find what software is installed here.

Install .NET Core

This may sound funny to install .NET Core for a Xamarin build, but the latest reference assemblies and build system require it. You can find what version of .NET Core is compatible with Visual Studio for Mac on the docs site.

You can add the Use .NET Core task to install .NET Core 2.2.x or 3.0.x. Either work just fine.

Set Xamarin & Mono Version

This next task is very important as it will tell the build agent what version of Xamarin and Mono to use when compiling the app. I like to define a variable with the version number in the format Major_Minor_Revision. For the latest we will use 6_4_0:

Then we will add a task to run a bash script to set the version of Xamarin. This is done with the following inline script:

sudo $AGENT_HOMEDIRECTORY/scripts/select-xamarin-sdk.sh $(MonoVersion)

That is it! Now you are good to go to build your apps with C# 8, iOS 13, and Android 10!

More DevOps!

Looking for more DevOps? Checkout my Channel 9 series on DevOps for Mobile Developers where I walk you through everything you need to know about DevOps with my friend Abel.

It seems as though Apple has finally fixed the keyboard on the latest MacBook 16-inch and as a bonus, brought back the escape key! This seems to be what everyone is talking about, but what is really important is the return to PRO for the MacBook Pro. What I mean by this is that finally we can fully spec out a MacBook Pro with as much RAM and SSD space that we could ever want and at a decent price. If you head over to the configuration page you will be able to spec out your MacBook Pro with up to 64GB of RAM and 8TB of SSD! That is right 8TB!!!!!!!!

This is a big deal for developers that need a super powerful laptop on the go, especially if you are doing mobile development for iOS and Android. More importantly, is that for the first time I think we have a MacBook Pro that can actually handle running macOS and Windows (in Parallels) without compromise! Yes, you will be sharing the GPU, but there are 8-cores built into this puppy! I actually don't think you need to fully spec out the machine either. Here is the build I would go for:

That is the upgraded 8-core i9, 64GB RAM, and 2TB SSD, all for just around $4,000! That does seem expensive, but it is basically 3 laptops in 1! I am very impressed with this offering and could feel very confident dedicating 32GB of RAM to Parallels, for that super butter smooth development experience between macOS and Windows!

Yes, $4,000 is very expensive and obviously you do not need to spend this much on a machine. However, if you are looking for a machine to last the next 6-8 years and do all of your heavy lifting on macOS and Windows 10 then it is a pretty solid option.

What do you think? Leave a comment below if you think this is genius or if I am crazy.

Dependency injection(DI) and inversion of control (IoC), have been a recurring theme in questions that I have received over the last six years. Sometimes it is around using constructor injection(), simple service containers, and often around full frameworks such as Prism or MVVM Light. I will be honest with you, I have never been a fan of DI/IoC when building mobile apps. My main reason is that there has never been any official pattern or recommendations from Google or Apple (or Microsoft/Xamarin) when building Android and iOS apps. Also, I have always been worried around startup performance in my apps and didn't want to introduce another dependency. However, it is 2019 and I think that my concerns have finally been resolved after talking with my friend Glenn Condron, and here is why:

1. There is a new official library from Microsoft that handles everything for you.
2. Using this model gives you other powerful features like logging, HTTPClientFactory, and more.
3. These devices are crazy powerful and the frameworks we use such as Xamarin.Forms, have really matured.

So, what is this magical library? It is the Microsoft.Extensions framework, but specifically the Generic Host framework that lives inside of Microsoft.Extensions.Hosting. It is a platform independent implementation of ASP.NET Core's extensibility framework.

The cool part about this library is that if you already have been building ASP.NET Core applications, then you already know exactly how to use the library. Additionally, it means that just about every other library that extends it works with your Xamarin apps like app configuration, logging, HTTPClientFactory, Polly, and more! Let's start with the basics and first setup a HostBuild, which is the base for the Extensions library and then setup some dependency injection with constructor injection.

Installation and Setup

The first thing to do is to install the v3 pre-release Micosoft.Extensions.Hosting NuGet into all of our projects. This will give our projects access to the base foundation and also includes the ability to use the built-in logging framework and application configuration via a json file.

With the library installed we will create two files in our shared code (also if you are building a single iOS/Android app this will also work):

Startup.cs

Will host all of our HostBuilder configuration and setup all of the dependencies in our application. Here is the base foundation for the file with all of the using statements we will need:

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using Xamarin.Essentials;

namespace MyApp
{
    public static class Startup
    {
        public static IServiceProvider ServiceProvider { get; set; }
        public static void Init()
        {

        }

        static void ConfigureServices(HostBuilderContext ctx, IServiceCollection services)
        {

        }
    }
}

appsettings.json

This file will need to be set as an EmbeddedResource and will host configuration properties and settings. Here is a generic default appsettings file:

{
  "Hello": "World",
  "Environment": "Development",
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  }
}

Host Builder setup

The extensions library has a few main concepts to understand:

1. HostBuilder: Acts as a builder for adding services (logging, app config, etc.) onto the app.
2. IServiceProvider: Handles all dependency injection & acts as a service locator and comes from the HostBuilder.

Our Init method must be called from either the main Xamarin.Forms or platform specific app startup. We will fill in the Init method by getting a stream to the app settings file so the HostBuilder can read it, configure services, and setup the built in logging service:

var a = Assembly.GetExecutingAssembly();
using var stream = a.GetManifestResourceStream("MyAssemblyName.appsettings.json");

var host = new HostBuilder()
            .ConfigureHostConfiguration(c =>
            {
                // Tell the host configuration where to file the file (this is required for Xamarin apps)
                c.AddCommandLine(new string[] { $"ContentRoot={FileSystem.AppDataDirectory}" });

                //read in the configuration file!
                c.AddJsonStream(stream);
            })
            .ConfigureServices((c, x) =>
            {
                // Configure our local services and access the host configuration
                ConfigureServices(c, x);
            })
            .ConfigureLogging(l => l.AddConsole(o =>
            {
                //setup a console logger and disable colors since they don't have any colors in VS
                o.DisableColors = true;
            }))
            .Build();

//Save our service provider so we can use it later.
ServiceProvider = host.Services;

Configure Dependencies

We have setup our HostBuilder and called ConfigureServices, but we haven't done anything yet. So let's do it!

Let's say we have the following code for a ViewModel and a service that it needs to use:

public interface IDataService
{
    void DoStuff();
}

public class MyDataService : IDataService
{
    // We need access to the ILogger from Microsoft.Extensions so pass it into the constructor
    ILogger<MyDataService> logger;
    public MyDataService(ILogger<MyDataService> logger)
    {
        this.logger = logger;
    }

    public void DoStuff()
    {
        logger.LogCritical("You just called DoStuff from MyDataService");
    }
}

public class MockDataService : IDataService
{
    // We need access to the ILogger from Microsoft.Extensions so pass it into the constructor
    ILogger<MyDataService> logger;
    public MockDataService(ILogger<MyDataService> logger)
    {
        this.logger = logger;
    }

    public void DoStuff()
    {
        logger.LogCritical("You just called DoStuff from MockDataService");
    }
}

public class MyViewModel
{
    IDataService dataService;
    public MyViewModel(IDataService dataService)
    {
        this.dataService = dataService;
    }

    public void DoIt()
    {
        dataService.DoStuff();
    }
}

Here we have a ViewModel that needs access to the IDataService and one of the implementations needs access to a ILogger. This is where the ServiceCollection comes in allowing us to configure all of our dependencies. Let's setup the ConfigureServices method in the Startup.cs again and configure these new classes.

static void ConfigureServices(HostBuilderContext ctx, IServiceCollection services)
{
    // The HostingEnvironment comes from the appsetting.json and could be optionally used to configure the mock service
    if (ctx.HostingEnvironment.IsDevelopment())
    {
        // add as a singleton so only one ever will be created.
        services.AddSingleton<IDataService, MockDataService>();
    }
    else
    {
        services.AddSingleton<IDataService, MyDataService>();
    }

    // add the ViewModel, but as a Transient, which means it will create a new one each time.
    services.AddTransient<MyViewModel>();

    //Another thing we can do is access variables from that json file
     var world = ctx.Configuration["Hello"];
}

Access Dependencies

With our HostBuilder and dependencies configured, we can now access them from anywhere. Since we only went up to the ViewModel level we will need to grab it from the ServiceProvider in the code behind from our page:

public partial class MainPage : ContentPage
{
    public MainPage()
    {
        InitializeComponent();
        BindingContext = Startup.ServiceProvider.GetService<MyViewModel>();
    }

    protected override void OnAppearing()
    {
        base.OnAppearing();
        ((MyViewModel)BindingContect).DoIt();
    }
}

When we call GetService the Microsoft.Extensions framework will handle creating and injecting any dependencies including our IDataService and the ILogger that came for free just by using the library. When we call DoIt in the OnAppering our app ill print out a message to the console using the logger that will have info of what data service it was using.

HTTPClientFactory In Your Xamarin App!

That's right, if you are using Microsoft.Extensions you can use the awesome HTTPClientFactory class that is essentially HTTPClient done right! It handles caching, retries, logging, and all other sorts of awesome! It is really easy to put into your app with just a few lines of code.

First, we will need to install the v3 prerelease Microsoft.Extensions.Http NuGet to get access to HTTPClientFactory. Then in the ConfigureServices method add the following line of code:

services.AddHttpClient();

With this single line of code in place it is now time to get access to the HTTPClientFactory from one of our classes. This is handled like our interface that was passed in as a parameter to the constructor. Microsoft.Extensions takes care of everything for you:

public class MyDataService : IDataService
{
    ILogger<MyDataService> logger;
    HttpClient client;
    public MyDataService(ILogger<MyDataService> logger, IHttpClientFactory httpClientFactory)
    {
        this.logger = logger;
        client = httpClientFactory.CreateClient();
    }

    public void DoStuff()
    {
        logger.LogCritical("You just called DoStuff from MyDataService");
    }
}

If you don't need access to the IHttpClientFactory at all this code can be simplified down to just passing in the HttpClient itself:

ILogger<MyDataService> logger;
HttpClient client;
public MyDataService(ILogger<MyDataService> logger, HttpClient client)
{
    this.logger = logger;
    this.client = client;
}

What is cool now is that when you make any calls with this HttpClient you will automatically get console logging, which is super helpful:

To top it off you can even extend the HttpClient beyond just logging and introduce Polly into the mix with the Microsoft.Extenions.Http.Polly library that will enable you to automatically setup retries and other really cool features. You can find an example of this in my "First App Example" with ASP.NET Core + Xamarin

Platform Specific Dependencies

At this point you are probably like WOW, this is amazing, but what about platform specific implementations that I may need to get access to. Do not fear because it is totally possible and pretty easy to setup. Instead of calling the Init from your shared code, you can call it from your iOS/Android project and pass in a configuration Action like this:

First, let's modify the Init:

public static App Init(Action<HostBuilderContext, IServiceCollection> nativeConfigureServices)
{
    // Resource code

    var host = new HostBuilder()
                    //ConfigureHostConfiguration
                    .ConfigureServices((c, x) =>
                    {
                        //Add this line to call back into your native code
                        nativeConfigureServices(c, x);
                        ConfigureServices(c, x);
                    })
                    // Logging
                    .Build();
}

Then from inside of the Android project's MainActivity and iOS project's AppDelegate you can call this Init method:

Android Example

public class MainActivity : FormsAppCompatActivity
{
    protected override void OnCreate(Bundle savedInstanceState)
    {
        TabLayoutResource = Resource.Layout.Tabbar;
        ToolbarResource = Resource.Layout.Toolbar;

        base.OnCreate(savedInstanceState);

        //setup code

        Startup.Init(ConfigureServices);
        LoadApplication(new App());
    }

    void ConfigureServices(HostBuilderContext ctx, IServiceCollection services)
    {
        services.AddSingleton<INativeCalls, NativeCalls>();
    }
}

public class NativeCalls : INativeCalls
{
    public void OpenToast(string text)
    {
        Toast.MakeText(Application.Context, text, ToastLength.Long).Show();
    }
}

iOS Example

[Register("AppDelegate")]
public partial class AppDelegate : FormsApplicationDelegate
{
    public override bool FinishedLaunching(UIApplication app, NSDictionary options)
    {
        //Init Code:

        Startup.Init(ConfigureServices)

        LoadApplication(new App();

        return base.FinishedLaunching(app, options);
    }

    void ConfigureServices(HostBuilderContext ctx, IServiceCollection services)
    {
        services.AddSingleton<INativeCalls, NativeCalls>();
    }
}

public class NativeCalls : INativeCalls
{
    public void OpenToast(string text)
    {
        var vc = UIApplication.SharedApplication.KeyWindow.RootViewController;
        var okAlert = UIAlertController.Create(string.Empty, text, UIAlertControllerStyle.Alert);
        okAlert.AddAction(UIAlertAction.Create("OK", UIAlertActionStyle.Default, null));
        vc.PresentViewController(okAlert, true, null);
    }
}

Inject The Entire App

As you can see this framework is extremely flexible and allows for optimal extensibility, but you can go even further. As I was trying out this API Glenn challenged me to see how far I could take this dependency/constructor injection madness... so I took it all the way up to the app level. That is right, I injected the entire app, pages, and view models.... because why not! Well maybe you shouldn't do this, but it is pretty cool.

Keeping the same dependencies and view models from above all we need to do is update our MainPage, App, and Init calls:

MainPage

public partial class MainPage : ContentPage
{
    //simply pass in the view model you desire!
    public MainPage(MyViewModel viewModel = null)
    {
        InitializeComponent();
        BindingContext = viewModel;
    }
}

App

There are a few ways to do this. You could pass in the page that you desire into the App constructor or you could have some logic and grab it from the ServiceProvider:

public App()
{
    InitializeComponent();
    MainPage = ServiceProvider.GetService<MainPage>();
}

Update Init

This is where it gets pretty cool, we will create Transient and Singletons of all of the services, view models, pages, and the app itself and have the method return the App intead of being a void method.

public static App Init(Action<HostBuilderContext, IServiceCollection> nativeConfigureServices)
{
    //all of the same code from before
    return ServiceProvider.GetService<App>();
}

static void ConfigureServices(HostBuilderContext ctx, IServiceCollection services)
{
    services.AddHttpClient();
    services.AddSingleton<IDataService, MyDataService>();
    services.AddTransient<MyViewModel>();
    services.AddTransient<MainPage>();
    services.AddSingleton<App>();
}

Then, call Init from the LoadApplication method instead of calling Init randomly in the iOS/Android project:

LoadApplication(Startup.Init(ConfigureServices));

Just like that we dependency injected our entire application and that is crazy! If you want to try it yourself, you can grab my sample project from GitHub that shows off just about everything in this blog post.

Required Versions of Xamarin/VS

As of today, you should be able to develop and debug iOS/Android apps with all these goodies using any version of Visual Studio 2019 or Visual Studio for Mac 2019. However, if you want to use ship your app and turn on the Linker you will need to have a newer version of mono, which ships with Visual Studio 2019 16.2 (preview 2) and Visual Studio for Mac 2019 8.2 (preview). If you are on Windows you can easily install VS 2019 Preview side by side the normal release.

Watch The Build Session

I had the honor of presenting how ASP.NET and Xamarin can come closer in app model with Glenn in a 20 minute theater session. It is available on the Xamarin Developers YouTube channel:

Learn More

This stuff is super fun and I really hope that it takes off and we can encorporate it into user testing, and perhaps one day into the official templates! Until then it is easy to setup and can lead to some really clean and powerful code. Be sure to read through all of the great docs for Generic Host and through any of the extensions documentation. Enjoy!

This year I have made a big push towards making Visual Studio Team Services my new continuous everything for my mobile apps, libraries, and any other project that I work on. While Azure DevOps (VSTS) has a lot of built in tasks for mobile applications, there are still a few essential things missing that would really make it a joy to use. The top that stuck out was having the ability to easily bump the version/build numbers for iOS and Android. The other was to change the app's label and package name, which can be nifty when doing different build types for QA/Production. This is where my brand new and open source Azure DevOps (VSTS) Mobile App Tasks Extension comes in!

Simply install the extension and four brand new tasks are ready to take building mobile apps in Azure DevOps (VSTS) to the next level.

Here is a full breakdown of each task:

Android

Multiple tasks to update the AndroidManifest.xml file

Bump Version

Change app's version name and code at build time.

Inputs:

• sourcePath: Path to android manifest
• versionCode: code number that must be an integer
• versionCodeOffset: a specific number to increment the version code
• versionName: user visible name
• printFile: output the file before and after changing variables

Package Identifiers

Change app's package name.

Inputs:

• sourcePath: Path to android manifest
• packageName: name to replace (com.company.app)
• appLabel: application name to replace (App Name)
• printFile: output the file before and after changing variables

iOS

Multiple tasks to update the info.plist file, must be run on macOS

Bump Version

Change app's version name and code at build time.

Inputs:

• sourcePath: Path to info.plist
• versionCode: code number that must be an integer
• versionCodeOffset: a specific number to increment the version code
• versionName: user visible name (short code)
• printFile: output the file before and after changing variables

Bundle Identifiers

Change app's bundle name and identifier

Inputs:

• sourcePath: Path to android manifest
• bundleIdenifier: identiier to replace (com.company.app)
• bundleName: name to replace (App Name)
• printFile: output the file before and after changing variable

Open Source

I have to say that none of this would have been possible without the help of Andrew Hoefling who helped not only convert the bash scripts I had to powershell core, but then again to TypeScript!. He is awesome and really made this all possible. That being said, if you go over to project's GitHub page you will be able to find all the tasks written in Bash, PowerShell Core, and TypeScript. Have ideas for more great mobile specific tasks? Open up an issue on the GitHub page or send down a PR!

Azure DevOps (VSTS) is quickly becoming one of my favorite products that Microsoft creates for developers. It helps any developer writing apps in any language build, test, and deploy their applications. On top of that it has free unlimited private Git repos, work item tracking and kanban board, test, release management, and so much more! What is cool is you can use some of it or all of it, up to you. So if you have your code in GitHub, no problem, want to use Trello, no problem, because they all work great together.

Since I am a cross platform developer, Azure DevOps (VSTS) is awesome because I can build any of my iOS, Android, Windows, and ASP.NET backends all in one place. On top of that I can do complete release management straight to AppCenter Test/Distribute, Azure, or directly into the App Store. You can hear about my love and passion for Azure DevOps (VSTS) on Merge Conflict Episode 71.

Azure DevOps (VSTS) has always offered hosted Windows VMs for use and recently Linux VMs that could build apps in the "cloud", which is pretty awesome. This is nice becuase all of the tooling is installed and ready to go on demand. There was always one operating system missing, which was macOS... which is required for iOS and macOS development. This wasn't too bad because you can actually download the Azure DevOps (VSTS) build agent on your own macOS machine and point VSTS to it. This is what I normally like to do, but it is also conveinent to run stuff in the cloud, which is why I am excited that they are now offering a hosted macOS agent! It is super easy to use and has some nice scripts installed for Xamarin developers.

Setting up an iOS CI Build

It couldn't be easier to get started with Azure DevOps (VSTS) for Xamarin.iOS. In fact there is a pre-built template with everything setup that you need.

Hosted macOS Agent

Once the build is setup it is easy to use the hosted macOS agent. Under Process tap on the Agent and hosted macOS will show up!

Build with MSBuild (VS for Mac)

One little gotcha seems to be that if you are using new project structures or .NET Standard you will need to use MSBuild (this is the default now in VS for Mac anyways). So make sure you flip the switch under advanced:

At this point you are ready to go, and just like that you are off to the races building your iOS apps inside of Azure DevOps (VSTS) on a hosted macOS agent!