I have a confession to make, I'm working on a new cross platform app and we're using Xamarin.Forms rather than .NET MAUI.😲 Xamarin.Forms will be unsupported after November 2023 so why did we make this choice?
Background
First a little background...
For the last two years I've been maintaining three iOS apps written with Xamarin.iOS and MonoTouch.Dialog (anyone remember MT.D?). These apps are part of a larger compliance management product used internationally to solve complex asset management, auditing, permitting & compliance challenges and had previously been languishing without any love for a while. I've been working to get them back in-step with the rest of the product and following the latest Apple guidelines.
This has been an interesting experience since I hadn't actually used MonoTouch.Dialog before but fortunately it is easy to learn and surprisingly powerful. I've even written several custom controls for it. Kudos to Miguel de Icaza and the original Xamarin team that MonoTouch.Dialog not only works well for our purpose but is still working 12 years and many versions of iOS later!🙇♂️ Genius. Now that our existing iOS apps have achieved parity with the rest of the product the time has come to create the first cross platform version of the most used app.🎉
The app itself is used for on-site data collection on civil engineering projects like road, railway and airport construction. It needs to connect to an existing backend web service to sync data, take photos, get the device's location and process different types of customisable data entry form using the same business logic as the existing app. Nothing out of the ordinary for an enterprise app so why did we choose the older Xamarin.Forms rather than the new .NET MAUI hotness?
Deciding Factors
A number of factors fed into our decision to use Xamarin.Forms over .NET MAUI.
The tooling for .NET MAUI still requires a preview version of Visual Studio 2022 and there is no UI for archiving and publishing an app. Although the Windows tooling should be updated in August, the macOS version won't be ready until November (hopefully) and we have concerns about what will be included and it's stability. We don't want to get to the end of development only to run into problems publishing our app.
Library Support
Although library developers are working towards a .NET MAUI release some of the libraries I normally use for Xamarin.Forms apps are not ready yet and a few don't have plans for a .NET MAUI version which means waiting, finding alternatives or creating our own libraries before we can start developing the app.
Experience
We have a small team of developers with Xamarin.iOS and Xamarin.Forms experience and a larger team of .NET developers with no Xamarin experience but only one developer has any experience with .NET MAUI. (me!👋)
Documentation
While the .NET MAUI documentation is improving it is still quite sparse, especially when compared to the wealth of documentation for Xamarin.Forms. There are also a lot more books, blog posts, FAQs, Stack Overflow answers, videos, podcasts, etc to help with Xamarin.Forms than .NET MAUI which will help the members of the team with less experience.
Time
This is the most important consideration and contributes to several of the other factors I already listed. Due to wider business goals and customer requests we need an Android version of this app as soon as possible. Preferably next month, or sooner.😉 Development needs to be fast and we can't wait for Visual Studio & .NET MAUI to mature.
In a lot of ways we've been unlucky with the timing of events. If .NET MAUI had released with .NET 6 last year or if the tooling had been complete with the GA in May or if we had more time for development we probably would have picked MAUI.
Technical Debt
Given the support dates for Xamarin.Forms we will need to move this app to .NET MAUI some time next year so how can we manage this technical debt and reduce the time to repay it? I've proposed several strategies based on my knowledge of both platforms.
MVVM Framework
I made the decision not to use a third-party MVVM framework in our Xamarin.Forms app. Instead we will use the in-built MVVM features of the platform with base classes to handle INotifyPropertyChanged and the required boilerplate code. Not using a third-party framework means no-one on the team has to learn it before they can contribute. We also don't run the risk of picking a framework that doesn't get ported to .NET MAUI. And, we're not restricted in our choice of dependency injection library.
Dependency Injection
By using the Microsoft.Extensions.DependencyInjection library for dependency injection and inversion of control, the code we write for Xamarin.Forms should be compatible with .NET MAUI with minimal changes.
JSON Library
The existing apps use the old System.Json namespace to serialise and deserialise data. System.Json was designed for Silverlight and is not the most performant way to work with JSON in .NET today. Until recently I would have suggested we replace it with the familiar Newtonsoft.Json. But, having read Jon Pepper's post about Perfomance Improvements in .NET MAUI and the reduction in app size they were able to achieve with the .NET Podcasts sample app by switching from Newtonsoft.Json to System.Text.Json, I proposed we use System.Text.Json instead. This might take us a little more time now but we should see similar improvements in app size and it will save us time when moving to .NET MAUI.
Vector Images
.NET MAUI can generate an icon, splash screen and all the required images for an app from SVG images. Using the FFImageLoading library we can also use SVG images in Xamarin.Forms so I've requested all image assets in SVG format. This should reduce the time spent worrying over images when developing both versions of the app and when we must use a PNG in Xamarin.Forms (e.g. for the Android splash screen) we can export the necessary resolutions from the vector image.
Final Thoughts
I'm still excited about the future of .NET MAUI but we felt the platform needs to mature a little more before we can commit to it. I think with the release of .NET 7 and the tooling for macOS in November the picture will look better and I can start to plan moving all our apps to .NET MAUI next year.
Cover image includes a vector created by upklyak - www.freepik.com
