dotnet/macios: the Apple SDK bindings that put C# on an iPhone

Four SDKs from one repository

dotnet/macios is the main repository for four SDKs at once: .NET for iOS, .NET for Mac Catalyst, .NET for macOS and .NET for tvOS. The description puts it plainly, open source bindings of the Apple SDKs for use with .NET managed languages such as C#.

The value proposition in the README is that you get the same native UI controls you would use in Objective-C and Xcode, with the .NET base class library and first-class editors available instead. The bindings are C#, the repository has around 2,900 stars and 576 forks, `main` is the default branch, and the last push was on 2026-09-23.

Note what is not in that list: watchOS. The topics include watchos because of history and shared code, but the four SDKs named in the README are iOS, Mac Catalyst, macOS and tvOS. WatchOS has its own bindings in a separate repository.

All four are part of .NET MAUI, introduced in May 2022 as part of .NET 6, and can also be used on their own for native iOS and macOS development with .NET. That second option is the one people underrate, since MAUI is not required to write a native app in C#.

Installing the workloads with one dotnet command

Installation is a single CLI invocation naming all four platforms.

dotnet workload install ios macos tvos maccatalyst

The workload system is how modern .NET delivers SDKs that target a specific platform, and it matters here because these SDKs have to be reissued whenever Apple changes its toolchain. Legacy Xamarin.iOS and Xamarin.Mac downloads live in a separate `DOWNLOADS.md` and are marked discontinued.

A release tag tells you exactly what an install contains. The .NET 10 servicing release for Xcode 26.6, published 2026-09-08, shipped four NuGet packages at version 26.5.10318: `Microsoft.iOS.Sdk.net10.0_26.5`, `Microsoft.tvOS.Sdk.net10.0_26.5`, `Microsoft.macOS.Sdk.net10.0_26.5` and `Microsoft.MacCatalyst.Sdk.net10.0_26.5`. They install through workload set version 10.0.401.

A release for every Xcode, and a preview track beside it

The release list is where this repository tells you what it actually is: a compatibility layer with a release cadence tied to Apple's. Three releases on the same day, 2026-09-08, show the structure.

The .NET 10 servicing release for Xcode 26.6 requires Xcode 26.6, which in turn requires macOS 26.2 or later. A parallel release adds Xcode 27.0 Beta 6 support, which requires macOS 26.4 or later, at version 27.0.10539. Between them sits the .NET 11 release candidate, also built against Xcode 26.6, publishing manifests rather than SDK packages.

That means the practical rule is: your Xcode version decides which SDK package you install, and the workload set version pins it. Someone on the current shipping Xcode takes the 26.5 line, someone following the beta takes 27.0, and someone targeting .NET 11 waits for the release rather than the candidate.

For anyone debugging a binding, the release notes are also a map of what is not finished. The .NET 11 notes point at a known-issues page in the wiki alongside the full release notes, which is the first place to look when a call behaves differently than the Apple documentation suggests.

Building from source with make and a generated global.json

Contributing means building the SDKs yourself, and the repository uses a Makefile plus Arcade rather than a plain dotnet build. The tree shows the pieces: `builds/` for bootstrapping the SDK, `mk/` for make includes, `msbuild/` for the MSBuild logic, `src/` for the bindings themselves, `runtime/` for the runtime bits, and `external/` for git submodules.

The `Makefile` in the tree is worth a look because it shows the project's own assumptions. It skips directories needing native compilation when Xcode is absent via a `NO_XCODE` guard, adds the `dotnet` subdirectory only when the host is Darwin, and its `world` target resets versions, builds everything in parallel with `all -j8`, installs, and then prints the list of workloads that were built.

It also generates `global.json` rather than checking one in, so that NuGet uses the exact .NET version pinned in `Make.config`. A `check-system` target runs `system-dependencies.sh` before anything else, which is the project's way of failing early when a required tool is missing.

Xamarin support ended and the docs point elsewhere

The README states the support situation without hedging. .NET for iOS, Mac Catalyst, macOS and tvOS have been part of .NET MAUI since May 2022 and follow the MAUI support policy. Support for Xamarin.iOS and Xamarin.Mac ended on 2024-05-01 for all Xamarin SDKs including Xamarin.Forms, with Android API 34 and the Xcode 15 SDKs being the final versions those SDKs targeted.

So the lineage runs Xamarin.iOS and Xamarin.Mac, then the standalone .NET for Apple platform SDKs, then MAUI layered on top. A reader arriving from Xamarin documentation will find the same class names and a different distribution mechanism.

Contribution guidance lives in the wiki rather than the repository: how to build and run from source, the development workflow including work branches, debugging applications built from source, running the tests, coding guidelines and how to submit a pull request. The test documentation is in the repository under `tests/`. Bugs, feature requests and votes all go through GitHub issues, and design discussion happens on Discord.

What the repository does not decide for you

Here is the honest boundary. These SDKs do not remove Xcode, and the release notes make the Xcode requirement explicit in the first line of every announcement. They do not remove code signing, provisioning profiles, app review or distribution. They do not make a C# app a native binary in the sense that Swift or Objective-C would produce one without the bindings underneath.

What they remove is the impedance mismatch. Instead of writing a Swift class library and bridging it, you write a binding or use an existing one and stay in C#. The cost is that you inherit Apple's release schedule, and that a new Xcode release can mean waiting for a matching SDK build.

That trade is easiest to judge by looking at what the releases are about. Nearly every recent release is Xcode compatibility, driver fixes, and binding updates for new APIs, with the version numbers tracking Apple's SDK version rather than a .NET semantic version. If you ship on Apple's cadence, that is a feature. If you ship on your own, the workload set pinning is the thing to plan around.

Editorial conclusion

This repository is the layer that decides how quickly a .NET developer can ship against a new Apple API, and the release list answers that plainly: every Xcode release produces a matching SDK build, currently Xcode 26.6 for .NET 10 and 27.0 Beta 6 for the preview track, with a .NET 11 release candidate running alongside. That cadence is the whole product. Four workloads install from one command, the bindings are open source with the API you would write in C# or F#, and MAUI sits on top rather than being the only way in. The catch is the one Apple imposes, that a Mac with a recent Xcode is required, and that Mac Catalyst and macOS support still depend on what Apple has exposed. Legacy Xamarin downloads are handled in a separate document since that path ended on 2024-05-01. Start by installing the workloads, then read the build and run page in the wiki before touching a custom native binding.

Frequently asked questions

Official sources

1. dotnet/macios on GitHub
2. Issues
3. README
4. Releases