Android AAR and JAR
We add the Java dependencies the SDK needs, fix the generated C# and expose the calls your app uses.
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.
Many hardware SDKs ship an Android AAR and an iOS xcframework, so one job can cover both.
We add the Java dependencies the SDK needs, fix the generated C# and expose the calls your app uses.
Objective-C frameworks bind through a C# API definition. Swift SDKs go through a thin Objective-C compatible wrapper.
C and C++ code called from C# through P/Invoke, with a native library for each CPU architecture.
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.
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.
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.
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:
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.
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.
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.
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.
Client and SDK names stay private.
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.
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.
We start with one SDK running in a sample app on your device.
Send us your SDKAv. de los Diamantes 53–9
Residencial Esmeralda Nte.
28017 Colima, Colima, México