Swift .NET Bindings: The Objective Sharpie Replacement for .NET MAUI and iOS

Justin Wojciechowski — Thu, 02 Apr 2026 15:53:47 +0000

Objective Sharpie is no longer maintained. It doesn't work with modern Xcode without workarounds, and it has zero support for Swift-only frameworks — meaning StoreKit 2, SwiftUI, WeatherKit, Swift Charts, and the growing list of Swift-first Apple APIs are completely out of reach for .NET developers.

If you're building .NET MAUI or .NET iOS apps today and need a native Swift library, your options have been to write fragile proxy libraries by hand, fight with Objective-C bridging headers, or simply go without.

swift-dotnet-bindings changes that. One command. Any xcframework. Ready-to-use NuGet package.

What Is swift-dotnet-bindings?

It's an open-source binding generator that takes compiled Swift or Objective-C frameworks (.xcframework) and produces complete, ready-to-compile C# binding projects. No manual intervention, no proxy layers, no bridging headers.

One command to go from xcframework to NuGet package:

# Install the template
dotnet new install SwiftBindings.Templates

# Create a binding project
dotnet new swift-binding -n MyLibrary.Swift.iOS

# Copy your xcframework in, then build + pack
dotnet build
dotnet pack
# → Produces a fully documented NuGet package ready to drop into any .NET MAUI or .NET iOS project

That's it. From xcframework to usable NuGet package in minutes, not hours.

Why Replace Objective Sharpie?

Objective Sharpie was the standard tool for creating iOS bindings in Xamarin and early .NET MAUI. But it has serious limitations that make it increasingly impractical:

	Objective Sharpie	swift-dotnet-bindings
Swift support	None — requires manual proxy libraries	Full — classes, structs, enums, protocols, generics, async, closures
Output quality	Littered with `[Verify]` attributes requiring manual cleanup	Clean, ready-to-compile C# with no manual fixup
Xcode compatibility	Broken on modern Xcode without workarounds	Works with current Xcode and toolchains
Maintenance	Unmaintained	Actively developed, MIT licensed
SwiftUI	Not possible	Automatic UIHostingController bridge generation
Mixed frameworks	Objective-C only	Handles mixed Swift + Objective-C (e.g., Stripe)
Project generation	Partial — still requires manual setup	Complete .csproj + NuGet packaging
Documentation	Limited, outdated	Auto-generated XML doc comments from Swift source
Time to first binding	Hours to days of manual cleanup	Minutes — generate, build, pack

What About NativeLibraryInterop?

The .NET MAUI Community Toolkit NativeLibraryInterop is another approach developers turn to for consuming native libraries. It provides scaffolding to help you write Swift proxy code that bridges to C# through Objective-C interop. However, it also hasn't been updated in over a year.

While NativeLibraryInterop makes the proxy approach more structured, it still requires you to manually write and maintain Swift wrapper code for every API you want to expose. For large libraries with hundreds of types and methods, that's a significant amount of hand-written boilerplate — and it needs to be updated every time the native library changes.

swift-dotnet-bindings eliminates this entirely. There's no proxy code to write or maintain — the generator reads the compiled framework directly and produces the complete binding automatically.

SwiftUI Interop for .NET MAUI

Unique in the ecosystem: swift-dotnet-bindings can automatically generate UIHostingController wrappers for SwiftUI views, letting you embed SwiftUI components directly in your .NET MAUI app. No manual bridging code, no Objective-C intermediaries.

This opens up Apple's modern UI framework from .NET — something that was previously impossible without writing significant Swift proxy code yourself. As Apple continues moving toward SwiftUI-first APIs, this capability becomes increasingly critical.

See the SwiftUI Interop guide for detailed setup instructions.

What Swift and Objective-C Features Are Supported?

The generator handles the full breadth of Swift's type system, not just the basics:

Classes with automatic reference counting (ARC) and inheritance
Structs — both frozen and non-frozen, with full value semantics
Enums including associated values and raw types
Protocols with interface generation and witness table dispatch
Generics with proper C# generic constraints
Async methods mapped to Task<T> with full cancellation support
Closures as Action<T> / Func<T> with proper memory management
Optional types mapped naturally to C# nullable types
SwiftUI Views automatically bridged via UIHostingController
Properties, subscripts, operators, and static members
Objective-C frameworks with [Protocol], [Model], [Export], argument semantics — everything Objective Sharpie does and more

Type Mapping

Swift and Objective-C types are mapped to their natural C# equivalents. No SwiftString or SwiftBool leaking into your API:

Swift Type	C# Type
`String`	`string`
`Bool`	`bool`
`Int`, `Int32`, `Int64`	`nint`, `int`, `long`
`Double`, `Float`	`double`, `float`
`Array<T>`	`IReadOnlyList<T>`
`Optional<T>`	`T?`
`Data`	`NSData`
`URL`	`NSUrl`
`CGRect`, `CGPoint`, `CGSize`	`CoreGraphics.CGRect`, etc.

The generator also bridges to existing .NET iOS types where they exist, so CGRect from a Swift binding is the same CoreGraphics.CGRect you already use — no type mismatch headaches.

Validated Against Real-World Libraries

This isn't a proof of concept. The tool is validated against 51 libraries across 95 framework targets, including:

Image & Animation — Nuke, Lottie, Kingfisher, SDWebImage
Networking — Alamofire, Starscream, Moya
Payments — Stripe (14 mixed Swift + ObjC frameworks)
Document Scanning — BlinkID, BlinkIDUX
UI Components — SnapKit, Hero, IQKeyboardManager, Charts
Database — Realm (Objective-C)
Firebase — 28 framework targets
Utilities — CryptoSwift, SwiftyJSON, KeychainAccess, PromiseKit

This includes complex mixed Swift + Objective-C frameworks like Stripe (14 inter-dependent targets) and the full Firebase SDK (28 framework targets) — not just simple single-module libraries.

For select libraries, full end-to-end runtime testing is performed on both iOS Simulator and physical devices to verify the bindings actually work at runtime, not just compile.

Pre-Built NuGet Packages

Don't want to generate bindings yourself? Pre-built NuGet packages are available for popular libraries:

SwiftBindings.Nuke — High-performance image loading
SwiftBindings.Lottie — Lottie animation playback

More are coming soon, including BlinkID, Stripe, and others. The swift-dotnet-packages repository tracks all available packages and includes a sample .NET iOS app demonstrating real usage.

Getting Started

Prerequisites

.NET 10.0 SDK (preview or later)
macOS with Xcode installed
An xcframework to bind (or use spm-to-xcframework to build one from any Swift Package Manager dependency)

Step 1: Install the Template

dotnet new install SwiftBindings.Templates

Step 2: Create a Binding Project

dotnet new swift-binding -n Nuke.Swift.iOS

Step 3: Add Your Framework

Copy your .xcframework into the project directory (or configure the path in the .csproj).

Step 4: Build and Pack

dotnet build
dotnet pack

The output is a standard NuGet package you can reference from any .NET MAUI or .NET iOS project — complete with generated XML documentation, proper framework references, and NuGet metadata.

Ready to try it? Install the template and bind your first library in minutes, or star the repo on GitHub to follow along.

Working with Swift Package Manager Dependencies

Many Swift libraries are distributed via SPM rather than as pre-built xcframeworks. Use the companion tool spm-to-xcframework to convert any SPM package:

# Clone and run
./spm-to-xcframework https://github.com/kean/Nuke.git --version 12.8.0

This produces the xcframework files ready to feed into the binding generator.

How It Works

Under the hood, the generator:

Parses the Swift ABI JSON metadata from the compiled xcframework
Resolves types, protocols, generics, and cross-module dependencies
Generates C# P/Invoke bindings using @_cdecl Swift wrapper functions for ABI stability
Emits a complete .csproj with proper framework references, NuGet metadata, and build configuration
Produces a companion Swift wrapper that the MSBuild SDK compiles automatically

For Objective-C frameworks, it reads the module headers and generates traditional [DllImport]-based bindings with full [Protocol], [Model], and [Export] attribute support.

The full architecture is documented in the Architecture guide.

Open Source and Community

swift-dotnet-bindings is MIT licensed and actively maintained. Originally forked from Microsoft's experimental dotnet/runtimelab swift-bindings branch, it has grown from a proof-of-concept into a production-grade tool with 800+ commits, 9,000+ unit tests, and 1,200+ runtime tests.

If you're tired of fighting with Objective Sharpie, writing Swift proxy libraries, or being locked out of Swift-only Apple frameworks, give it a try. Star the repo, install the template, and bind your first library in minutes.

For the story behind how this tool was built, check out my earlier post: Building a Swift + ObjC .NET Binding Tool Entirely with AI in 6 Weeks.

DEV Community: Justin Wojciechowski