colima_mx · --:--:-- UTC−6 services / maui-native-bindings

Native SDK bindings for .NET MAUI.

When a vendor ships only a native Android or iOS SDK, we bind it to .NET. We test it on the real device and keep it building on new SDK versions. We work with Kotlin and Java AARs, iOS xcframeworks, and C/C++ libraries through P/Invoke.

iOS + Android bindings rebuilt when the
original code was lost
4 CPU architectures in one
Kotlin AAR binding
01 / Services // binding-types

What .NET MAUI native SDK binding services cover.

Many hardware SDKs ship an Android AAR and an iOS xcframework, so one job can cover both.

01 / Service

Android AAR and JAR

We add the Java dependencies the SDK needs, fix the generated C# and expose the calls your app uses.

AARJARKotlinJava
02 / Service

iOS xcframeworks and Swift SDKs

Objective-C frameworks bind through a C# API definition. Swift SDKs go through a thin Objective-C compatible wrapper.

xcframeworkObjective-CSwift
03 / Service

C/C++ native libraries

C and C++ code called from C# through P/Invoke, with a native library for each CPU architecture.

P/InvokeC/C++arm64
04 / Service

Keeping bindings alive

We move Xamarin binding projects to .NET 10. We update bindings for new Xcode versions and Android API levels. Moving the whole app? See Xamarin to .NET MAUI migration.

Xamarin.NET 10XcodeAndroid API
02 / Approach // how-we-bind

How we bind a native SDK to .NET MAUI.

A binding is a .NET library that lets your C# code call a native SDK. The vendor still owns the SDK. We write the layer between it and your app.

Most of the work is reading, testing and small fixes. The same senior .NET MAUI experts who write the binding also wire it into your screens.

Read the SDK and its license first

Before we write code, we list the SDK's dependencies, its minimum Android and iOS versions, and its CPU architectures. We also read the license. Some vendors don't allow redistribution of their files, and that changes where the binding can live.

.NET MAUI Android binding library: AAR, JAR and Kotlin

Android SDKs arrive as AAR or JAR files. The tools generate C# from the Java API, but the first build rarely works. These are the usual problems:

  • Missing Java dependencies. The tools skip any API that needs one, so methods you need are not bound.
  • Generated names that clash or don't compile. We fix them in Metadata.xml.
  • Kotlin features like suspend functions. We add a thin Kotlin wrapper for those.

.NET MAUI iOS binding library: xcframeworks and Swift

iOS SDKs usually arrive as an xcframework. For Objective-C APIs we write a C# API definition from a generated draft. The iOS binding tools read Objective-C, not Swift. So for a Swift-only API we write a thin Swift wrapper marked @objc. This pattern is called Native Library Interop. Static libraries also need the right linker flags, or the app can build and still fail at runtime.

C and C++ native libraries through P/Invoke

Some SDKs are C or C++ code. We call the C API from C# with P/Invoke, with one native library per Android ABI. A wrong struct layout crashes the app, so we test each call on a device.

Testing on the physical device

Emulators and simulators can't reach a card reader, printer or scanner. So we test the binding in a sample app on the real device, then inside your app. We bind hardware SDKs like the ones for PAX payment terminals, MagTek card readers and Star Micronics receipt printers. Some device makers ship their own .NET package, and we add that to your app instead. The device side is on our .NET MAUI POS page.

Xamarin binding migration to .NET 10

An old Xamarin.Android or Xamarin.iOS binding project doesn't build on .NET 10 as it is. It needs an SDK-style project, new build actions and often a newer native SDK. If the binding code is lost, we rebuild it from the vendor's files. If the whole app still runs on Xamarin, see moving the whole app to .NET MAUI on .NET 10. If your .NET MAUI app is late or crashing, see how we take over a project.

Have an SDK in hand? Send us your SDK and we will look at it with you.

03 / Selected work // binding-cases

Native SDKs we bound for .NET MAUI apps.

Client and SDK names stay private.

01 2026
Field-service platform · Native bindings · C/C++ SDK

A third-party C/C++ SDK, bound for iOS and Android in one .NET MAUI app.

The app needed a third-party native calculation SDK. On iOS we bound its xcframework through P/Invoke plus an Objective-C API definition. On Android we bound a Kotlin AAR that ships native libraries for 4 CPU architectures.

xcframework
iOS, P/Invoke + API definition
Kotlin AAR
Android, 4 CPU architectures
C/C++
native code, one C# app
.NET MAUIP/InvokexcframeworkKotlin AAR
02 2026
Public-sector app · Store block · Native bindings

A Xamarin.Forms app blocked by Google Play, rebuilt with new native bindings.

Google Play blocked an older Xamarin.Forms app for using old SDKs. We moved it to .NET MAUI and rebuilt its iOS and Android bindings for a third-party SDK, because the original binding code was lost. The release build was ready on May 18, 2026.

Xamarin.Forms → MAUI
migration
iOS + Android
bindings rebuilt from scratch
May 2026
release build ready
.NET MAUIC#Native bindingsGoogle Play

We start with one SDK running in a sample app on your device.

Send us your SDK
04 / Process // how-we-work

From SDK files to a binding in your repo.

01 ───

SDK review

You send the SDK files, docs and device model. We check dependencies, OS versions, CPU architectures and license terms.
Before any code
02 ───

Binding spike

We bind one SDK and call it from a small .NET MAUI sample app, starting with the calls your app needs first.
Fixed scope
03 ───

Device testing

We run the sample on the physical device, on Android, iOS or both. Then we add the binding to your app.
Real device
04 ───

Hand-off and upkeep

The binding project goes into your repo with build steps your team can run. We can update it when the SDK, Xcode or Android API level changes.
In your repo
05 / FAQ // binding-questions

Questions about native SDK bindings.

Q.01

We write the binding for your app, and it lives in your repo. We agree on ownership in the contract before work starts. The native SDK itself stays under the vendor's license.
Q.02

For a hardware SDK, yes. Emulators and simulators can't talk to a card reader, printer or scanner. A binding that builds can still fail on the device. For an SDK without hardware, a normal Android phone or iPhone is enough.
Q.03

Yes. Most Kotlin APIs bind directly, but features like suspend functions need a thin Kotlin wrapper. A Swift-only API needs a thin Swift wrapper marked @objc, because the iOS binding tools read Objective-C.
Q.04

Yes. An old Xamarin.Android or Xamarin.iOS binding needs an SDK-style project, new build actions and often a newer native SDK. If the app can't ship store updates, read what to do about the Xamarin app store deadline. For the whole app, see Xamarin to .NET MAUI migration.
Q.05

Yes. The binding is a separate project that your app references. We add it to your solution and write the C# service your screens call. Then we test it in your app on the device. For payment, printing and scanning screens, see POS apps built with .NET MAUI.
// 06 send-your-sdk

Which SDK does
your app need?

Send us your SDK
// reach-us
contact@lemonlabs.mx +1 (779) 232-9848

Av. de los Diamantes 53–9
Residencial Esmeralda Nte.
28017 Colima, Colima, México