A history lesson on the Xamarin.Mac target frameworks and their new names

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. To understand how there came to be three options and why they are being renamed, a bit of a history lesson will be needed first.

Fall of 2014 - Xamarin.Mac 1.10 was released which included a preview of the new “unified” profile. This unified profile allowed:

• Fixing a number of systemic issues preventing 64-bit support
• The unification of namespaces which were causing significant pain in sharing code between Xamarin.Mac and Xamarin.iOS projects
• Many backwards incompatible API improvements

Unlike classic, which built against the installed system mono, a copy of the BCL was included inside the Xamarin.Mac framework for unified. This reduced the need to upgrade mono and Xamarin.Mac in lockstep. Since this migration from classic to unified was API break, this BCL was based upon a modified version of the one powering Xamarin.iOS. It was significantly slimmer and since it did not include System.Configuration it was safe to enable linking as an option — which reduces final application size significantly by stripping dead code from the embedded libraries and the application itself.

Shortly after 1.10 went out, forum posts and bug reports came back describing the pain users were hitting when trying to port their applications to unified. Many applications depended on nuget packages or other 3rd party libraries that were built against the normal “desktop” BCL. Convincing library maintainers to add an additional build, against this new unified mac target, across the entire nuget ecosystem turned out to be a “boil the ocean” level task.

A short term bandaid was added, allowing linking to the system mono (like classic did), but we knew that for 2.0 we needed a better story, and fast. It needed to be as compatible as possible with the wide array of nuget packages customers were using, but reducing the library surface was still a major goal. Some corners of the mono class library only had partial implementations or often had breaking changes. Removing them from the “supported” BCL helped prevent customers from depending on one of these libraries, running into breakages after updating, and then feeling justifiably frustrated.

The Xamarin.Mac 4.5 (XM 4.5) target framework was the result. It trimmed down the standard “desktop” net_4_5 mono profile, and did some creative bending of the truth in msbuild to convince everyone it was really the desktop BCL everyone knew and loved.

It wasn’t a perfect solution, and the bending of the truth came back and caused a number of issues that needed stamping out, but overall it was a success.

Once we had the XM 4.5 target framework, though, we needed a name for the originally designed one. Since it was powered by the same bits as Xamarin.iOS naming it “Mobile” seemed to make sense.

Since Xamarin.Mac 2.0, the imperfections of the two names have become more and more clear. Customers tend to shy away from mobile when they see this dialog, as they are “building a desktop application, why would then need mobile”. XM 4.5 now supports assemblies with .NET 4.6 APIs, and the name will increasingly be out of sync with reality as time goes on. The mono profile it was based upon is now named net_4_x for a reason.

Naming is one of the great two hard problems in computer science (along with cache invalidation and off by one errors) and it took multiple long discussions and e-mail threads to settle on the least bad suggested names.

The planned new names and descriptions are:

• Modern (Optimized profile also powering Xamarin.iOS) replace Mobile.
• Full (Extended desktop API compatibility) replaces XM 4.5.

As the adoption of netstandard continues to spread through the nuget community, it is expected that many applications will be able to transition to the Modern target framework. The Full target framework will still be available, however, when the extended library surface of Full (such as System.Configuration) is required.