Today on the forums a user asked about bindings for IOKit. IOKit is very diverse, and currently unbound in Xamarin.Mac. However, since it’s C APIs, it is straightforward to bind by hand.

There aren’t too many examples online how to approach this however, so let’s break it down here.

We are going to bind this API:

io_service_t IOServiceGetMatchingService(mach_port_t masterPort, CFDictionaryRef matching);

Let’s take a look at the header, which will be our guide.

First open up Xcode, make a test Cocoa app, and add

@import IOKit;

to pull in the framework we are binding. Then we can paste IOServiceGetMatchingService into…

When a developer hits “Run” on a Xamarin.Mac application, a large number of moving parts engage to provide the “magic” necessary to produce a final application. Understanding where the different components (compiler, class library, runtime, bindings, packaging) all fit together can be a bit overwhelming. Let’s take a somewhat simplified 10,000 foot view of the process to get a rough idea of the lay of the land.

1. Run Button — Visual Studio for Mac does a quick check, realizes that the application is either not built or stale, and asks msbuild to handle it.
2. msbuild — msbuild, previously xbuild, uses…

Today is an exciting day in the .NET community as .NET Core 2.0 was released:

However, if you try to use your new shiny netstandard2 libraries with Xamarin.Mac (or iOS) you likely will run into a few issues as official support is scheduled for our next major release d15–4 (XM 3.8 and XI 10.14).

All of them are solvable by installing the correct bits and making a minor tweak to your csproj for now.

First: Install the latest d15–3 release found in the Stable Channel

Second: Install .NET Core 2 (You want the pkg download)

Third: Due to this bug…

This morning a report came in that Xamarin.Mac Classic applications were broken on High Sierra (currently in Beta).

This was somewhat surprising, as our automated introspection tests were passing last time I checked. Thinking about it though, Beta 3 had recently dropped and we are still in the process of filing radars / fixing issues on our end, so it was rather possible.

I figured it would be a great investigation to write up.

A quick test on my laptop confirmed the crash:

2017–07–12 10:32:02.849 Classic[13505:303375] ### Failed to Soft Linked: /System/Library/Frameworks/Contacts.framework/Contacts#5: 0xa782502b libsystem_platform.dylib`_sigtramp + 43 
#6: 0xa3884183 GeoServices`initCNPostalAddressStreetKey()…

In Xamarin.Mac 3.2 one of the focuses was improving general application performance. In additional to Ahead of Time complication and the partial static registrar smaller improvements were looked into to speed up launch time performance.

Out of this work it was discovered that unlike Xamarin.iOS, Xamarin.Mac did not default to ever using the static registrar. You can read about the registrars a bit here, but the short version is that they handle exposing C# classes to the objective-c runtime. …

All .NET applications depend upon classes and methods from the Base Class Library (BCL) as part of their implementation — Strings, System.Console, System.IO.Path, System.Net.Http.HttpClient and so on.

When targeting many platforms, such as Xamarin.iOS or “desktop” console, the choice of which BCL library to link against is generally fixed and there is not much to consider. With Xamarin.Mac things are not so simple, as it ships with two different supported “Target Frameworks” and also allows unsupported linking against the system mono as well. …

As you might know, .NET applications by default do not compile down to machine code when you build. They compile down to an intermediate layer, called IL, that looks something like this:

During application launch, the mono runtime will Just In Time (JIT) compile this to machine code for you. In many use cases, this works wonderfully and magically behind the scenes.

However, it requires the ability to emit machine code (which can not be done on iOS) and takes some non-trivial amount time. That is why on Xamarin.iOS, …

When developing an application, minimizing the time between completing a change and testing it is important for efficiency. Some strategies such as modularization of codebases, unit tests, and exploration with tools such as Xamarin Workbooks can help. The Xamarin.Mac team has been researching infrastructure improvements as well.

One “low hanging fruit” was finding and fixing a number of build time bugs causing applications to unnecessarily rebuild. Full builds are increasingly expensive as the application size grows, but are not the most exciting changes to report.

One rather exciting development though, that just landed in master this week (PR), is the…