Is Microsoft going to support Firebase.IOS and other bindings for iOS?

[prok155]

As a former Xamarin/MAUI developer I'd like to ask the .net MAUI team if you are going to support Firebase bindings for iOS? We still have few Xamarin/Maui apps and I need to decide if we're going to stay with .NET Maui, or move them another platform.

https://github.com/xamarin/GoogleApisForiOSComponents - iOS bindings are not updated for over 2 years. Current version is 8.10.0.3, which was released in December 2021!!! The latest version is 10.20.0.

https://developers.google.com/admob/ios/deprecation?hl=en - here is the deprecation list of Admob SDKs for iOS, as you can see, sunset date for version 8.x.x is in Q2 this year, so from April 2024 we will not be able to show ads on iOS anymore...

xamarin/GoogleApisForiOSComponents#647 - from 20 of June, firebase notifications will not work anymore because it requires iOS SDK version >= 10

@davidortinau Could you tell me and the community if MAUI will support iOS bindings?

[giuseppenovielli]

@davidortinau iOS Push Notifications, are very important for a lot of apps!

[jkommeren]

Wow that's not good, they are crucial for my app too!

[developer9969]

@davidortinau @Redth Push notification are vital to us. The ecosystem around .net maui does not seem to have anything that we can use like a plugin etc.. that we can use. if those xamarin.firebase components are not going to be updated , is there a blog on how to implement using Azure Hub? Documentation is so dated... any suggestions?

[giuseppenovielli]

@davidortinau why stop update iOS firebase plugins?

[borrmann]

Push notifications using Azure Notification hub still work the same way they used to work in Xamarin.Forms.

[vitorelli]

Is it possible to move to FirebaseAdmin? https://www.nuget.org/packages/FirebaseAdmin

[AdamEssenmacher]

That library is meant to be used in server environments.

[AlleSchonWeg]

This is a very important question. I asked this several times but i never get an answer.
Because nobody answer i think MS support for Apple/iOS development will stop soon. Also VS for Mac is stopped, xamarin/maui bindings are not maintained and apples shift to xcframeworks in nugets are not addressed. Some other ios questions are open as well.

[giuseppenovielli]

@davidortinau @maddymontaquila @Redth @rolfbjarne @SotoiGhost @dalexsoto @jfversluis @jamesmontemagno @mandel-macaque

We can expect last Firebase.iOS.CloudMessaging version and as possibile also others Firebase.iOS Binding before June 2024 when our apps's stop sending push notifications with current SDK version?

xamarin/GoogleApisForiOSComponents#647

Thanks!

[AlleSchonWeg]

Has somebody found an alternative for firebase cloud messaging which runs on android ans ios?

[prok155]

I decided to migrate my app to Flutter. MAUI is dying because the most important libraries/bindings are not supported, and without firebase support it will be definitely dead.

As you can see, I asked this question almost a month ago and no one from MAUI team can't even respond.

My app has whole backend on firebase, so without firebase support I had no choice and I had to abandon Xamarin/Maui and move my app to native or flutter (I chose Flutter finally). I highly recommend you to do the same, using MAUI as a mobile app framework is the worst choice right now.

[borrmann]

Yes, Azure notifications hub works fine!

[developer9969]

What about Azure Notification hub? Has anyone tried this and has a working sample, wouldnt this solve the issue as we would not have a dependency on xamarin? Am I missing something here?

Has anyone used any paid 3rd party Push notification provider that works with Maui? we were thinking of onesignal but their support on .net is really really bad.

[borrmann]

Yes Azure Notifcation hub works! I followed the old Xamarin Forms docs.

[giuseppenovielli]

Some resources that can help:
xamarin/GoogleApisForiOSComponents#645 (comment)

Make Binding yourself:
Firebase -> https://github.com/firebase/firebase-ios-sdk

Full Binding:
https://learn.microsoft.com/en-us/xamarin/ios/platform/binding-objective-c/
https://learn.microsoft.com/en-us/dotnet/maui/migration/ios-binding-projects?view=net-maui-8.0

Smart Binding:
https://github.com/Redth/MapboxSlimBindingDemo
https://github.com/Redth/Microsoft.Maui.Platform.Channels
https://github.com/Redth/MAUI.Slim.Bindings

[nll]

The MAUI.Slim.Bindings looks empty, there was a point in sharing that particular repository ?

[giuseppenovielli]

I hoped that @Redth uploads code

[nll]

it seems that the new code is here: https://github.com/Redth/DotNet.Platform.SlimBindings

[developer9969]

@giuseppenovielli thanks for those links! Have you managed to get Push Notification working in maui? what do you use? which option have you gone for? did you consider Azure Hub? sorry for all these questions but very desperate at the moment on push notification.

[giuseppenovielli]

Hi @developer9969, I haven't migrated to .NET MAUI yet, but it's close.

Try some binding technique, that i have mentioned, if i create some binding or if i find some last firebase's binding i will link you.

[developer9969]

ok thanks

[nacompllo]

Shiny is the way to go in .NET Maui, it is one of the best maintained libraries available today, it offers many different functionalities, including support for push notifications (Firebase and Azure Notification Hubs). I personally used this library 1 year ago on a project I worked on in particular I used push through Azure Hub Notifications and everything worked correctly.

https://github.com/shinyorg/shiny
https://www.nuget.org/packages/Shiny.Push.FirebaseMessaging

The GitHub repository has examples of all use cases, I recommend anyone looking for a way to integrate push into their application to try the library.

[giuseppenovielli]

Same issue!

[AlleSchonWeg]

We need new bindings. Every library based on the old xamarin.ios package.

[developer9969]

Sorry if I am missing the obvious but if we use azure hub notification there no xamarin.firebase messaging involved is there?

[aritchie]

You can take the dependency on Shiny because when I update the firebase messaging stuff, you'll only need to update your nuget package, nothing else.

[developer9969]

@aritchie hi it looks like shiny is the only working alternative at the moment.I not familiar at all with Shiny and hopefully there are some working sample using azure hub notifications where I just have to change the azure details and should work, also if they are people in the community that have implemented it and would like to share their finding that would be great.

But you have a dependency on Xamarin too so unless they do something , shiny would be not use either as you depend on them.. Ideally we need a push notification library that does not depend on xamarin..

.

[nacompllo]

Sorry, you're right, I had only read the last few comments of the discussion and thought it was another debate.

It's a pity that Microsoft is not giving proper support to such relevant libraries. Hopefully this situation will change soon for the good of the community.

Until then an alternative on iOS could be to use Apple Push Notification service or if you want to have the same provider on both operating systems you could opt for OneSignal which is a serious push notifications provider that has been around for a while and has support for MAUI and nuget has more maintenance than Microsoft's Firebase:

https://github.com/OneSignal/OneSignal-DotNet-SDK
https://www.nuget.org/packages/OneSignalSDK.DotNet

And then Amazon SNS if I'm not mistaken has a free limited version and has SDK for .NET as well (very up to date by the way):
https://github.com/aws/aws-sdk-net
https://www.nuget.org/packages/AWSSDK.SimpleNotificationService

I hope these alternatives to Firebase can help someone, best regards!

[AlleSchonWeg]

I think Microsoft will force us to use Azure and pay for it.
Not maintaining iOS firebase bindings and keeping android firebase up to date is the way they go.
The iOS firebase bindings are not needed for Azure. Only the android bindings.
Ms will earn some money. 🤪

[khalil2099]

yeah, currently im using this way, send push notification to APNS (Apple Push Notification Service) from ASP.NET server using dotAPNS (https://github.com/alexalok/dotAPNS) library, and exclude Firebase library on iOS build/compilation.

[AdamEssenmacher]

This is probably the 6th or 7th time I'm putting this out here (no direct response from the MAUI/Microsoft team though...)

I've managed to upgrade a subset of the Xamarin.iOS Firebase/Google bindings to current versions. I'm prepared to help the team transition these bindings to community support if that's what needs to happen.

[JoacimWall]

Hi
We are using this package for Firebase notification and it works well.

Plugin.Firebase.CloudMessaging

//Joacim

[davidortinau]

@AdamEssenmacher where are your bindings and what's the subset? /cc @dalexsoto

[AdamEssenmacher]

@JoacimWall I'm a contributor of that plugin. It is built on the bindings we're discussing here and will eventually break if they're not updated.

@davidortinau the subset includes AB Testing, Firebase Analytics, Firebase Auth, Cloud Firestore, Cloud Functions, Cloud Messaging, Firebase.Core, Crashlytics, Realtime Database, Dynamic Links, In-App messaging, Installations, Performance Monitoring, Remote Config, Firebase Storage, AdMob, and Google SignIn.

My fork is here: https://github.com/AdamEssenmacher/GoogleApisForiOSComponents

[davidortinau]

Here's an update on what we are currently doing about these bindings for iOS. We have been working with companies to understand what APIs they are using, and validating that a slim bindings approach is a good solution. It is proving well for companies using libraries like Facebook and others. Samples and guidance on this pattern are being created, and will be published when they are ready.

Where other libraries (Shiny, Plugin.Firebase.*, etc.) take a dependency on the Xamarin bindings today, this would introduce a change. Ultimately the slim binding approach puts more flexibility and control into developers' hands, along with inheriting responsibility, of course.

[Picao84]

@AdamEssenmacher by that assessment Xamarin and MAUI should not exist at all then, as Xamarin.Android, Xamarin.iOS and their .Net counterparts are essentially bindings to 3rd party SDKs. On the other hand, if all these additional 3rd parties bindings had never existed, Xamarin would not have been picked up by anyone as most do not have the patience, time or skills to make their own. Microsoft obviously knew that, they weren't just being generous and helpful from the kindness of their hearts. It was absolutely essential to get people onboard their platform! Stopping to maintain them is a complete betrayal of the tacit understanding and expectations of their clients. That is why this is damaging beyond the practicality of having to switch platforms, as it leads to a downward spiral and dead of anything Microsoft in the mobile area. Even if you and other people generously try to maintain this alive, it will be a waste of your time, as no one in their right mind will use MAUI forward.

[AdamEssenmacher]

Xamarin.Android, Xamarin.iOS and their .Net counterparts are essentially bindings to 3rd party SDKs

In the sense that AppKit and AndroidX are '3rd party' with respect to Microsoft, sure. Firebase and Google APIs are a step beyond that though. I think the team's point is that it's unrealistic for them to be expected to maintain bindings for SDKs outside of the bare minimum required for native platform compatibility. I don't agree with this point for the APIs in question; I'm just recognizing their position.

most do not have the patience, time or skills to make their own. Microsoft obviously knew that, they weren't just being generous and helpful from the kindness of their hearts

Well... Xamarin obviously knew that, but those thought leaders are gone. Microsoft is just doing what they do... embrace, expand, extinguish.

The funny/sad thing is, it doesn't even seem to be intentional in this case. The sister Android binding libraries are really well-maintained, despite it being a less popular platform. I can't fathom a product-driven reasoning behind this, leaving me to guess that the backlog is at least somewhat driven by the whims of individual engineers.

[mofdaddy]

One can argue that the richest company in the world by market cap, who purchases a well established Xamarin platform with all that comes with it, should be able to find a few developers in-house to keep those commonly used libraries maintained and up to date, in order to continue encouraging developers to use the platform they decided to aquire.

Another one can argue that those libraries are '3rd party' with respect to Microsoft which essentially is true, and that the community could maintain these libraries.

Then there is the Slim binding approach, pushing towards the second argument.
Slim bindings sounds appealing if you're a developer who just need to make a partial binding that suits your own needs, but I think it will lead to larger fragmentation of various nugets floating arround with different API's exposed.

A full official binding - a single source of truth - of those libs should exist IMO!!

Bottom line is - whatever the strategy turns out to be, MS- or community maintained - there should have been an official announcement instead of this deadly silence!

[tranb3r]

I vote for the full official binding strategy!
Unfortunately, MS maintaining Android bindings while abandonning iOS bindings is proof they do not have a strategy.

[developer9969]

They have now via their monthly community stand up said that the way to go is slim bindings.
The reality is simple they are deprecating the iOS library and the offering is an half baked solution. A "wash my hands" "your problem now" scenario and not even a nuget might be offered.I bet no one in the community toolkit org want to take this responsibility and they will wash their hands too as they are happy just doing quick stuff.why is it that the android team are up to date and iOS team are not and let it slip so badly that there is no return?

It will be a case of each us will need to build our own based on some starting point code as Microsoft could not give a damn about Maui-mobile etc.. and looking azure hub officially they don't support Maui either.what a mess!!!

[davidortinau]

We are going to be talking about slim bindings on the .NET MAUI Community Standup this Thursday (March 7, 2024) at 10 Pacific for anyone that would like to learn more. https://www.youtube.com/dotnet

[rjhind]

Has this been published? I can't see a community standup video on the YouTube channel from Thursday?

[rjhind]

OK, found it now but unless I missed it, nothing on slim bindings.

[gabsamples6]

Watched it too and nothing on slim binding or push notification implementation with slim binding

[AdamEssenmacher]

I've put a lot of effort into upgrading AdMob, Google Places, Firestore, Firebase Analytics, Firebase Storage, Cloud Messaging, Google SignIn, Firebase Auth, Firebase Storage, and other Xamarin.Google.iOS.* / Xamarin.Firebase.iOS.* packages to modern versions.

Having gone through this effort, I'm highly skeptical that 'slim bindings' are the answer for these libraries. If you examine the diff from my fork, you'll find that very few API changes were actually needed over the past 2 years of Google/Firebase updates, and coding them is (relatively) straightforward.

The real challenges are in native dependency resolution and native reference configuration (e.g. linker flags, framework references). I don't think slim bindings will be very helpful in these areas, but I'd love to be proven wrong.

[tranb3r]

@tom-b-iodigital
Thanks for clarifying the slim bindings.
But still... why do they maintain android bindings, but not ios bindings? For a cross-platform framework, it's a weird decision.

[tom-b-iodigital]

@AdamEssenmacher well that just sucks, thanks for your effort anyway

[tom-b-iodigital]

@tranb3r I would assume because it's part of the google play services components and those are essential in building apps for android, so they just service the firebase part of those components with all the rest. Dunno though, that's just a guess

[AdamEssenmacher]

@tranb3r

But still... why do they maintain android bindings, but not ios bindings? For a cross-platform framework, it's a weird decision.

I've been hesitant to bring this up publicly, because I don't want to have to maintain the Android bindings myself as well!

...but you're asking a great question. I think, if you read into the situation, you'll find two truths. 1) The Android binding libraries are easier to maintain and 2) The Android binding libraries are maintained by a surviving Xamarin dev/hero with no equivalent present on the iOS side.

[developer9969]

@tom-b-iodigital that a really good assessment,however the problem so far has been huge lack of clarity of what they want to do. They have not told us either way of their intentions and one by one they are killing the ecosystem that we are all used in xamarin.certain key components like Firebase binding should be maintained in my view by a trusted entity,too many nuget owners have left and gone and the community toolkit seems a good choice in my view.look at the fingerprint plugin for example another key nuget that is clearly no longer maintained and we forked it and we no longer use it. We cannot afford to get burned again and with MS there is an implicit trust that managers like. But this in my view is not longer the case, yes they are short stuffed and yes they don't dogfood their products but boy please be transparent with the community,silence does not help. Let's be realistic @davidortinau is not going to reply and tell us what's going on I think that boat has sailed the only hope is that an implementation of these slim bindings leaves in a place where the community can contribute and not die after a year.a single maintener is not feasible.lets hope something is sorted soon

[kpespisa]

I will shoot to have an update to share about Firebase and in particular push notifications with slim bindings by the end of this week. Several people are actively working on this.

@davidortinau it would really help to hear whatever updates you have on the subject of Firebase.IOS bindings or slim bindings. Also a clear explanation of what slim bindings mean for developers, how they help and where they differ from full bindings.

[developer9969]

We asked @davidortinau for an update so many times on push notifications but for some reasons he is avoiding the subject.

[mofdaddy]

It seems they've all gone dark

[mofdaddy]

I don't see anyone discuss Analytics here.
After migrating Xam apps to .Net 8, using same nuget packages as before, and the same implementation, our iOS apps can no longer record screen_name when tracking screen_view events. Anyone else having this issue?

We are not using the constant ParameterNamesConstants.ScreenName because it returns "score_name".

Android is all good on this matter.

[maonaoda]

@davidortinau
When can give us clear answer? This will determine if it's worth it for my
customer to continue using maui or migrating to maui from xamarin.

[davidortinau]

Check out https://github.com/Redth/DotNet.Platform.SlimBindings and follow the readme to consume these bindings in your projects. Please provide feedback as issues on that repo.

[maonaoda]

@davidortinau
I can't use this from windows unless fully mac environment.
Redth/DotNet.Platform.SlimBindings#4

[yurkinh]

Here are updated samples for the slim bindings approach from Redth
https://github.com/Redth/DotNet.Platform.SlimBindings

[Picao84]

@AdamEssenmacher well said! I've updated some of the bindings myself (Admob, Analytics and Crashlytics) for my project in a very similar manner. However I didn't actually update the project. I've created my own libraries based on the xcframeworks with the generated files from building this project. It was a bit cumbersome to find out all the dependencies and it's annoying that I cannot do this on Windows but only from Mac, as far as I know, since I'm including the xcframeworks on my Xamarin.iOS project (didn't get far yet when MAUI iOS port). I will probably keep doing that as long as I can and avoid this slim bindings approach unless it's for other less complex 3rd party libraries I don't need to call much.

[maonaoda]

My current development habit is to use pair to mac from windows, but the SlimBindings only supports the complete mac environment (I think it may be temporary)
So currently I need to compile on mac, generate dll, and then use it on windows, so what is the difference between this and using the nuget packages...

[developer9969]

Oh I have no tried yet but we use windows as main development pairing to Mac and mac had a world of issues that prevented us to run our solution.ok so what is the way long term.What the plan from MS? Is it just to provide a starting point?

[davidortinau]

Good feedback everyone on the slim bindings, thank you. We are listening.

@AdamEssenmacher yes, if someone like you has a working binding and the skills to maintain it, then replacing with a slim binding provides little value. It makes sense you would just continue with your binding.

@maonaoda DLL or NuGet is up to you. The latter is more steps.

[developer9969]

@davidortinau Appreciate some clarification

• Will there be a nuget for slim binding or just some code to grab?
• It has been mentioned that possibly will live in the community org , who will take ownership?

[AdamEssenmacher]

We now have a clear direction regarding the Google/Firebase/MLKit bindings for iOS many of us depend on. Unfortunately, it appears Microsoft will no longer maintain the dozens of packages prefixed with Xamarin.Firebase.iOS.* or Xamarin.Google.iOS.*.

For an alternative solution, @davidortinau has pointed us to this slim binding demo project. Although this initiative is apparently not currently sponsored or resourced by Microsoft, it is a vital effort by two dedicated developers who are volunteering their free time to 'close a gap' and simplify the process of binding native libraries for all of us.

For those who find the slim binding approach insufficient—especially if you are deeply invested in the existing libraries—I have been working on updating my fork of the original project to serve as a community-driven continuation. I have published the following packages as candidates for direct replacements, upgraded from native SDK versions 8.10 to 10.24. Please check the fork's updated readme for installation instructions 10.17+, and report any issues there.

AdamE.Firebase.iOS.Core
AdamE.Firebase.iOS.Analytics
AdamE.Firebase.iOS.Auth
AdamE.Firebase.iOS.CloudFirestore
AdamE.Firebase.iOS.CloudFunctions
AdamE.Firebase.iOS.CloudMessaging
AdamE.Firebase.iOS.Installations
AdamE.Firebase.iOS.Storage
AdamE.Firebase.iOS.Crashlytics
AdamE.Firebase.iOS.ABTesting
AdamE.Firebase.iOS.RemoteConfig
AdamE.Firebase.iOS.DynamicLinks
AdamE.Firebase.iOS.Database

All of these packages are affected by Apple's new privacy requirements, which may impact your ability to publish to the App Store using the abandoned Xamarin versions.

If these packages are important to you, please consider sponsoring the project and/or contributing directly to the fork.

Over at Plugin.Firebase, we are planning to migrate the project to use these new bindings as soon as possible, though this transition may take some time.

[czmirek]

@AdamEssenmacher You sir are a gentleman and a scholar

You saved my a**. Thank you so much for investing into this and providing to the community!

[ppvictory]

This is great work @AdamEssenmacher, thanks for stepping in. I have a question for you. By using the nuget packages from your fork, will this fulfil Apple's requirement for the firebase SDK to be signed? I read about signed SDKs here: https://developer.apple.com/support/third-party-SDK-requirements/

[AdamEssenmacher]

@ppvictory I sure hope so. Working on getting the bindings upgraded to SDK versions 10.24+, which I think will be the minimum versions the App Store will accept going forward.

[Manish-Pradhan-FP]

So which project do you recommend using? https://github.com/TobiasBuchholz/Plugin.Firebase or https://github.com/AdamEssenmacher/GoogleApisForiOSComponents

Thanks

[AdamEssenmacher]

Plugin.Firebase currently depends on the Xamarin.iOS.* packages. The plan is to update Plugin.Firebase so that it uses these newer bindings.

[borrmann]

@davidortinau I was at the App Promotion Summit London today, which is known as one of the best events for app marketing.
None of the vendors (at least of those I talked to), offer Nuget packages.
Very few even knew about MAUI. At least when I mentioned Xamarin, there was sometimes some acknowledgement and one vendor said they integrate with it, but the person was not really sure about it. As a developer, I have to say, it felt a little bit embarassing.
Don't get me wrong - I think MAUI is great and I like developing with it!

However, without good monetisation SDK's I don't think MAUI will ever be taken very seriously by the big players. All those companies have their native SDK's and oftentimes some integration with .NET for backend stuff, so they probably also have some .NET devs. Considering that, it probably wouldn't take them too much effort to offer integrations for MAUI or Xamarin.ios and android.

My question is, is there anything being done to reach out to these vendors to convince them to offer Nuget packages?
It feels a little bit like a chicken egg problem to me. Without more integration options, big players won't use MAUI, but without big players using MAUI, third parties don't spend the time integrating with it. If you guys from Microsoft contact them and show them how relatively easy it is to publish their SDK's as Nugets, maybe us product devs don't have to deal with creating Slim Bindings for Major products on the market or alternatively depent on individual devs to keep up with it?

On the other hand, maybe I am wrong and just haven't understood how easy it is to create my own slim bindings. Maybe @jfversluis or @jamesmontemagno could help us developers out here with some of their great content?