Microsoft has just released preview 2 of .NET and MAUI with monthly releases coming until the final release. MAUI will include a target for macOS through Catalyst. I see that there is now CBL support for Catalyst with Swift:
Is it planned to add CBL support for Catalyst using .NET MAUI as well?
Any news yet on what the Couchbase Mobile/Lite plans/timeline are for MAUI?
Currently no plans for such a thing.
Now that Maui has gone GA at Microsoft and will replace XF is there any update to the plans for supporting Maui with CBL for .NET â all the supported targets of Maui (Android, iOS, macOS, and Windows)?
Iâm unclear what is actually involved in such an undertaking. Is MAUI its own target? Is it not enough to support the current targets that we support? All of the targets you have listed are supported targets at the moment.
As .NET Multi-platform App UI (.NET MAUI) | .NET says:
.NET Multi-platform App UI (.NET MAUI) is a framework for building modern, multi-platform, natively compiled iOS, Android, macOS, and Windows apps using C# and XAML in a single codebase.
A Maui .NET project contains shared code for all the platform targets, which are:
Adding Couchbase Lite NuGet 3.0.0 to the Maui project it throws a bunch of warnings because the target is not supported:
âCouchbase.Lite 3.0.0â was resolved as a dependency of âMaui2â, but the dependency is using âXamarin.iOSâ while âMaui2â is using ânet6.0-maccatalyst15.4â as its TargetFramework. There might be compatibility issues when MacCatalyst projects depend on Xamarin.iOS projects.
When running the Mac Catalyst target with the sample CB Lite C# getting started code (there is no support NuGet to install) it errors out on the new Database() call because of:
2022-05-25 11:10:41.469 Maui2[37739:5467416] warning: Canât find custom attr constructor image: /Users//Projects/Maui2/Maui2/bin/Debug/net6.0-maccatalyst/maccatalyst-x64/Maui2.app/Contents/MonoBundle/Couchbase.Lite.dll mtoken: 0x0a00001e due to: Could not load file or assembly âXamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065â or one of its dependencies.
I ran the iOS target with the same sample code as well, same problem actually:
2022-05-25 11:14:28.098449+0200 Maui2[38078:5474948] warning: Canât find custom attr constructor image: /Users//Library/Developer/CoreSimulator/Devices/A37C8213-2552-4824-8815-A779B917B0B8/data/Containers/Bundle/Application/5D10F066-7ACC-429B-804A-C3FCB30D1CE4/Maui2.app/Couchbase.Lite.dll mtoken: 0x0a00001e due to: Could not load file or assembly âXamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065â or one of its dependencies.
Oh and Maui replaces Xamarin Forms which is on maintenance only.
I see, so the problem is the lack of specifically mac catalyst support, and not macOS (which actually is supported). Itâs annoying to see that .NET 6 is not backwards compatible to Xamarin iOS and family but Iâm not sure we have the bandwidth to take on building and releasing both, so I guess the answer would be âwe will have MAUI when we deprecate and get rid of the old defunct Xamarin targetsâ. I am not aware of any users (present company excluded) who are looking into MAUI just yet but we have quite a few who are using Xamarin so that will contribute to the problem. Iâll ping @priya.rajagopal just to make sure this stays visible though. I think the end of life of Xamarin itself will come up pretty quickly (perhaps as soon as the end of life of .NET Core 3.x).
Hi,
I am in the process of migrating a Xamarin.Forms app to MAUI and the current hurdle is CouchBase.Lite.
Itâs not specifically a MacOS (catalyst) issue, itâs the entire CouchBase package that isnât supported, (well I presume iOS and Android may work but) a simple MAUI desktop app for Windows also does not work.
I wouldnât say you need to deprecate the Xamarin.Forms targets, the same NuGet package can support Xamarin.Forms and MAUI just needs a few changes.
I will pull the current packages from NuGet and see if I can create some local ones to get things moving along, I will post back with my findings.
Letting us know what you find would be very helpful indeed. Windows Desktop app you mean WinUI 3? Iâm betting on that being a simple moniker fix to point to the correct package (current UWP one). Iâd like to simply cut off everything pre .NET 6 but even previous versions reaching end of life is no guarantee we can do that (#enterprise-world-problems).
the same NuGet package can support Xamarin.Forms and MAUI
Sure, the package can but the goal is to not balloon our tech support matrix 
. I tend to advocate for trading platforms these days (i.e. we can support X but we should drop Y in its place).
I got it to work (in Windows), taking some shortcuts along the way (as I didnât want to invest a whole bunch of time).
Created a new Couchbase.Lite.Support.MAUI library, literally just added an Activate partial class for each OS (all borrowed from the github repo).
Ripped the compiled assemblies from the support packages (Couchbase.Lite.Support.x).
Used the desktop assemblies (see Couchbase.Lite.Support.NetDesktop) and not the UWP ones for Windows, I guess it makes sense as this isnât a UWP application (not entirely sure why though [Microsoft.VCLibs 14 requirement?]).
NOTES: Using the UWP assemblies you will get a Unable to load DLL 'LiteCore' or one of its dependencies: The specified module could not be found. (0x8007007E), the assembly is found just couldnât load it.
Windows Desktop app you mean WinUI 3?
Yeah, default MAUI app from a Visual Studio 2022 template, presumably WinUI 3
Sure, the package can but the goal is to not balloon our tech support matrix
Bit of a strange place at the moment, MAUI is ready (according to MS) but from my testing itâs also not quite ready, some fundamental things are still missing.
UWP will be around for a while and MS will probably add some additional life-support to .Net Core 3.1 to keep it around past itâs EoL in a few months.
Best option is to have a separate NuGet package (i.e Couchbase.Lite.Support.MAUI)
Interesting information, and our MAUI support is moving forward and I can comment on a few of these things. The VCLibs requirement is something that used to be needed a long time ago in UWP or else the C++ runtime would not be found (I think it somehow shimmed the runtime libs into the sandbox of the UWP application). I donât believe it is required in WinUI 3 and may not even be required in newer UWP builds either.
For some annoying technical details: UWP requires a special build of our C++ logic (LiteCore) in order to not use unavailable, or otherwise prohibited Win32 API calls. This is born out of a need to support the least common denominator between consumer machine, Windows phone, and HoloLens / XBox (from Microsoftâs point of view). WinUI 3 is essentially throwing up the white flag on everything except for consumer machine, and therefore the stringent restrictions no longer make sense and normal compiled C++ can be used with the system C++ runtime. This means that the desktop C++ can be reused between NetDesktop and WinUI 3 in a way that was impossible with NetDesktop and UWP.
I donât like thinking of MAUI as a platform from the CBL point of view. It really isnât, itâs just a multiplatform framework with some nice tooling. Itâs not a moniker in Nuget, and therefore continuing the separation between platforms and not just having one big âmauiâ package makes sense. Furthermore, one can use .NET 6 platforms without using MAUI at all and so therefore introducing a dependency on MAUI for implementations that do not use it seems bad. In the end, I think the most logical course of action is to forge ahead to a .NET 6 only implementation and deprecate / remove everything else (UWP, Xamarin, .NET Core) while keeping the current separation of support libs.
Hey Jim - the real issues with Maui will be supporting things like Context in Android. Any code used with that would have to change as the namespace for things like this has changed from Xamarin over to the new Microsoft namespace.
Iâve now converted a few non-CBL mobile apps to Maui, and itâs mostly a struggle with namespace changes and 3rd party libraries. The other issue is Maui is primarily only supported on Windows. VS for Mac support is in beta at best and needs a lot of work. The more significant problem is .NET 7 is now coming out in less than a few weeks, which is supposed to release much better support for Maui; with that release, I think more and more teams will be moving over to this platform. This will move CBL to be two releases behind in .NET support.
-Aaron