Native library bindings

[AmSmart]

Will there be improvements for native library bindings in MAUI?

One of the main selling points of XF (at least for me) is that I can grab a native library and integrate it into the project. Are there going to be improvements in this process? It's quite daunting and buggy right now.

[DamienDoumer]

This is a good question. I find it very difficult too. Making It easier will make Maui more reliable for sure. This point is also very important for me.

[davidortinau]

That's more of a .NET thing. We have this sample from @Redth proposing a simplified wrapper binding in order to reduce the complexity of binding an entire library. https://github.com/Redth/XamarinEncapsulateNativeSample

I'd be interested to hear what anyone feels about the complexity of doing that approach, and especially what parts seem "hard".

Sure, we'd all like to just point VS at a Swift/Java library and have it magically work. Short of that, let's talk about how we can make bindings easier.

[DamienDoumer]

Thanks for sharing a link to the sample, I didn't know about it. From my experience, what was the most challenging while binding native libraries was;

• Though there are some docs (example: https://gist.github.com/JonDouglas/dda6d8ace7d071b0e8cb) indicating how to troubleshoot and solve some of the errors you get when building the native binding project after linking the .aar or a file, the process is still kind of confusing, cause the errors you get come in divers forms and there can sometimes be some ambiguity. though solving such errors over and over makes the dev see patterns between the type of errors and the appropriate solution to apply, It is still kind of difficult to know which solution to apply to which error in some cases.

• Also, when the library you are trying to bind depends on an external third party library, adding the process of integrating this external dependency is kind of tricky. Once I succeeded in making the native bindings with the dependencies, linked it to my main project without any issues, just to find out that at runtime, the dependency was wrongly linked.

Now, how can we make bindings easier ? This is not easy to answer,
Already, I guess C# 9 with its covariant return types feature will make translation from java a lot easier, there by making the process of creating bindings from java libraries easier. Since most of the errors we get come from this fundamental difference between C# and java.

May be making the error messages less ambiguous will help ?
Or, maybe making class generation from the native library more accurate will help too ? In one case, I remember I noticed the "api.xml" file contained metadata about classes which were not generated automatically by the tool so I had to go through it to update my "Metadata.xml" manually.

[brabebhin]

Isn't this essentially building a wrapper around some functionalities in the library and binding to that wrapper instead to reduce the API surface? similar to how you'd wrap winRT with C++/CX before consuming in .net?

I don't think that is particularly easy thing to do. For many libraries this requires quite a bit of logic to be behind the wrapper and that logic becomes hard to debug, and you will essentially need to maintain 2 code bases, in 2 different IDEs, in 2 different languages.

I think this will not really replace better tooling support.

[softlion]

I agree that C#9's covariant return type will make things much simpler.

[ghost]

Binding to Swift/Java library is easier by automatically building a C library that wraps over the Swift/Java library, and exposes C interface to .NET.
Using existing native interop in .NET is much better than interop to Swift/Java library directly.

[softlion]

Then a full documented example + a vs template that create the ios/android projects would be ideal.

[WiproSarthak]

There should be tool or an easy way to bring all the dependencies of any library.Right now we need to create a seperate bindings of all the dependencies sometimes and include them as a refrence and for creating each bindings we have to solve numerous issues like fixing name ,type , return type,remove few nodes and all so it's really tedious and sometimes long process right now

[MickBadran]

Hey folks - where are we up to on this? about to start a proj that uses several native libraries on both iOS/Android and would REALLY love to use MAUI (as opposed to straight native dev - which others in the team are keen on)

Love an easier way to do the interop back to .NET MAUI land.

??

[SarthakGz]

Select platform wisely if you are required to integrate multiple native libraries.I would say first check flutter or react native as most of the libraries support these two platforms.Xamarin is somehow lacking in terms of popularity and usage unfortunately :(.Microsoft should support NAXAM team to maintain the bindings they are providing or hire them I guess
Creating binding can be very painful and mostly didn't work if libraries are big with lots of dependencies.If you still have doubts then go for native

[sjordanGSS]

I echo the sentiment of the OP: I recently bound to an Android library containing (what felt like) 50+ dependencies, and while I could've manually created binding libraries for each of them, I ended up adding them to a project in Android Studio, using a Gradle plugin to stuff them all into a single .aar file and then creating a Xamarin.Android binding for that, which worked well enough and saved me a heap of time and tears. Is there any way that Xamarin could automate/facilitate the creation of binding libraries e.g. by processing the .pom files that often accompany Java libraries hosted on Maven etc? It'd certainly make my life a lot easier, and would remove the need to fall back on esoteric hacks or extreme tedium to get bindings working.

[SarthakGz]

@sjordanGSS could you do video for how you combine everything on android studio and then create binding or any reference links.I would like to know about this

[sjordanGSS]

Here's the plugin I used: https://github.com/kezong/fat-aar-android. I don't have the time or knowledge to make a video on it, but there are instructions in the README which should be enough to get you going.

[vhugogarcia]

The firebase libraries are the ones I will keep an eye. I am very interested into.

[logeshpalani30]

Firebase-related libraries have been migrated to .Net and support MAUI.

The following is Firebase Analytics Nugets:

• Xamarin.Firebase.Analytics .
• Xamarin.Firebase.iOS.Analytics.

For more information on how to use these packages, you could refer to the following official documentation.

GooglePlayServicesComponents.
Get Started with Firebase Analytics for iOS.

For more info: Microsoft Forum

[juepiezhongren]

support gradle and cocoapod would be nice

[SarthakGz]

If Microsoft wants MAUI to be successful as Flutter they need to make native binding creation as smooth as possible and needed to be updated as well

[MhAllan]

asking this since 2014

[KSemenenko]

Is there any limitations for create bindings in MAUI?
It can't find [Static] attribute.

this is xamrin iOS binding project and I can't find any docs about buildings for MAUI.

[davibittencourtome]

Hi, were you able to generate the AgoraRtcEngnie_iOS bindings for MAUI?

[MhAllan]

The answer to this question is that there are all kinds of limitations and bugs and errors

[KSemenenko]

So I can't find
StaticAttribute and BaseTypeAttribute in MAUI

[MUN1Z]

@KSemenenko Hello man, i am try bind the agora library to maui too, do you have any progress on it?

[SarthakB26]

Some references

https://medium.com/@tema.denisoff/how-to-use-swiftui-components-in-maui-f43c54d2173c
https://www.youtube.com/watch?v=oibfI-ZsmzQ

[KSemenenko]

oh my friend, we switch to react native =(

[SarthakB26]

@MUN1Z you might also try flutter or react native, I checked agora officially providing sdk for both. You can learn easily any crossplatform framework in couple of weeks if you have knowledge of any single mobile development framework.

Sticking to a single technology always have its demerits.

[KSemenenko]

We were only able to run this sample project https://github.com/DreamTeamMobile/Xamarin.Agora.Samples and only as a Xamarin version. So it seems that video and audio communication is possible, but screen sharing is not. The MAUI tooling is broken, so it is unlikely that you will be able to build the binding project.

[ivmirx]

Were binding tools for Swift discontinued after all? So, in theory, we're forever bound to Obj-C bridges to Swift, right?

[SarthakB26]

Its hopeless

[yurkinh]

There is a new concept in .NET MAUI called Platform Channels. It is still in preview, as everything else))
https://github.com/Redth/Microsoft.Maui.Platform.Channels

[SarthakB26]

Still binding are required to create before reference those in Maui right. I checked the sample

[Xyncgas]

I remember a programmer once answered me
"Why is something not implemented" "Because no one cared to"
I see two ways features like this can happen, because they are not fundamental, It's either microsoft do it all by themselves or have people really like using MAUI so there's some competitions in the market for creating better experience

[SarthakB26]

This is correct. I have seen most of the sdk vendors like chat, payment gateways etc provide first party UI sdk support for ReactNative and Flutter but never tried to Support Xamarin/MAUI because they are not getting enough request to do so.

[brabebhin]

To be fair, flutter's and others' interop with native platforms still suck, worse so then xamarin. Flutter requires serialization of data on every call, so this absolutely destroys performance. Maui/xamarin still have the best fundamental approach, it's just that tooling sucks and it doesn't seem to be getting better any time soon.

Payments gateway are a bad example. These are easy to port.

The only reason these other platforms are more successful is because the companies behind them actually try to make them successful and don't outright lie when it comes to production readiness, as microsoft did when maui.

[MhAllan]

@davidortinau @Redth This is a promising work https://github.com/Redth/Microsoft.Maui.Platform.Channels

I think the most complex scenario is when the native library needs native views (like render them or interactive with them) and also when it needs to do callbacks to our Maui application. The most complex native library I struggled to bind and keep asking for Maui/Xamarin binding for, is Azure Communication Services Calling. It needs native objects, native devices, native views rendering, callbacks, really complex one! If you could give us a demo for using Platform Channels with such complex library that would be amazing!

[brunck]

If you're trying to bind a large and complex SDK, the "slim binding" pattern is probably the best way to get up and running. Redth has a repo of an example of how to do this.
This approach is very powerful, using types that you define yourself for your use case(s), using types Xamarin/.NET already know about and binding only what you need in the API surface that you create yourself. The native views can be exposed in iOS, for example, as UIView.

[brunck]

The so-called MAX_PATH error on Windows is a huge problem for NuGet packages of bindings for 3rd party SDKs, and especially for iOS versions using .xcframeworks. It seems to be a Visual Studio-specfic problem, and it may be a long time until that is fixed, if ever.
What can be done in the short term is that the NuGet package authors/maintainers really need to squash down the names of these packages. Having names like Xamarin.Google.Firebase.Something.SomethingElse fails no matter how short your path is to your Git repository that consumes these dependencies.
With the end of VS for Mac, your only option there is to use VSCode which is apparently quite an adventure to get working (currently). If you want/need to do much of the dev work on Windows in Visual Studio and pair to a Mac, the MAX_PATH problem is coming for you. It's just a matter of time before you hit it.

[softlion]

You can now use a "dev drive" in Windows 11 which does not have this limitation. Its format is "ReFs".