Your App Uses Xamarin.Forms, but That Tech is Going Away. Don’t Panic! 😱

You may be hearing a lot of chatter about Xamarin.Forms going away. If your app is built in Xamarin.Forms, this is probably concerning news to hear. Our advice? Don’t panic! 😱

We recently sat down with Adam Livingston, Staff Software Engineer, and Charles Tippett, Engagement Manager, to get the scoop on the upcoming transition from Xamarin.Forms to .NET MAUI. Read on to learn what you should know and what it means for your business that Xamarin.Forms is going away.

Which types of functionality are built on Xamarin.Forms?

Adam: Xamarin.Forms is a cross-platform development framework. By building your mobile app in Xamarin.Forms, the app can run on multiple platforms, like iOS and Android, from a single code base. It’s not just for mobile apps, but is often used this way because you can theoretically create an app that looks and behaves the same on different devices. The benefit of this is easier maintenance, so you are fixing bugs or adding features in one spot that pushes out across the platforms.

The downside is that the app is not designed for a specific device, such as an iPhone. The product doesn’t look like it belongs on a specific platform. When you write a framework meant to deploy to multiple targets, you end up limited by the limitations of all the targets simultaneously. You’re not limited in a technical capacity but a design limitation. So you do get platform-specific functionality, but if you customize too much, it defeats the purpose of cross-platform. Because of the limitations to design, it often finds itself most used for prototyping.

How would someone know if their software uses Xamarin.Forms?

Adam: It would be surprising if you didn’t know! This is a decision made when you start the code base. If you inherited it, you could check the list of third-party libraries. Xamarin will appear.

And where does .NET MAUI enter the conversation?

Adam: MAUI is a continuation of Xamarin.Forms under a different banner. You could look at MAUI as a new version of Xamarin. Microsoft owns the .NET MAUI framework, whereas Xamarain.Forms was a largely community-supported framework. Theoretically, the only difference a user would see is that they had to run an update. This is important for product owners because support for Xamarin.Forms will end (currently scheduled for November 2023).

So, what would a Xamarin.Forms → .NET MAUI software development project look like?

Charles: Knowing Xamarin.Forms is going away, you’d likely want to start with Discovery and then component analysis. Before jumping into code changes, you want to know which pieces must change and what’s supported. Then, it’s time to get a basic build running for the changes you have to make. Next would be performance questions and analysis so we know what the application is supposed to do. This is key to the project’s success, and we would have determined this in the early stages of Discovery.

Key milestones in the transition project might include:

• Discovery: Understand what the application is supposed to do
• Testing: Make sure the new code options will still do the same things
• Component Analysis: Looking at the components you’re using and if they are supported (wrapping or existing standardized component)
• Development: Get the basic project converted over to the new language (not long, but it does take time), then get all of the components built
• Performance and Speed Testing: Put the new version of the application through its paces, and assess if some packages we’re using are slow
• MAUI Roadmap: Understand when the components we have to wrap will be done
• Full Conversion: Wholly convert the libraries and the applications to the MAUI framework, including that all the tests run correctly
• Delivery & Launch: If it’s already in place in the app store, there’s a conversion of what gets released to the app store
• Maintenance and Evolution: Monitoring feature changes and updates to keep you in the loop, plus keeping a manifest of manually wrapped components to update to a fully MAUI-ized version as the components become available

That seems like a lot of work! I thought the .NET MAUI switch was a one-to-one mapping. Why are there so many steps involved?

Adam: There are supposedly one-to-one converters you can use to move your application from Xamarin.Forms to .NET MAUI. So far, these tools are slapdash at best. Microsft’s tooling is not robust enough yet, as there are several flavors of Xamarin, so it requires a bit of tweaking to work properly. Also, custom changes can cause problems here, too.

MAUI does not have a one-to-one mapping of all existing Xamarin libraries and most likely never will. We have found workarounds by wrapping some components in an MAUI framework after initially finding which libraries weren’t truly a one-to-one match. This leads us to either wrap it or hope that the Xamarin library author will eventually write a matching MAUI library.

As we get deeper into this transition work, we’re uncovering a lot of little tweaks to get things running, to make sure things compile, and to address the speed and performance issues we’re running into. We’re doing a lot of diagnosis and testing. A good testing framework is necessary for this transition work.

This sounds like it could be an expensive project to hire a software development partner. Could we do this work internally or hire a freelancer?

Charles: Cost could be a sticking point, I agree. If you can have someone internal do it, you could definitely go that route. If you don’t have someone internal, get someone who knows to look for the edge cases and has intimate logic of what Microsoft is doing right now. And keep in mind that going with an internal or freelance solution may seem more affordable upfront but may not be the most cost-effective in the long run. Some cost considerations would be:

• Internal costs: There will be a learning curve and the investment of time and resources.
• Freelancer costs: Depending on your history with the freelancer, it could be risky to assume they have the right skills.

In either scenario above, you’ll also want contingency plans for if that person leaves or is unavailable at any point in your project. Also, incorporate a plan to transition your app(s) safely, including testing to find and address performance issues.

At SEP, when we can start with Discovery, it helps us figure out what the application is supposed to do, what problems we are solving, and where you’ve had problems in the past so we can build your software right the first time.

Another advantage to working with a software partner is a deeper bench of talent and experience. Since we have multiple makers working on your project, and others who can get up to speed quickly and efficiently, you mitigate the risk of costly project delays.

Last but not least, we’re already doing this work! We have experience helping clients with this exact transition, which minimizes client risk from the outset of their project with us.

Ready to talk about your project? Let’s go! »

What would happen to our app if we didn’t make this switch by Nov 2023 (support deadline)?

Adam: If you don’t make the deadline of Xamarin.Forms going away, it’s not the end of the world. There’s no pressure to make the transition by the time MAUI officially releases. They will not add any new features to Xamarin, but they are making minor bug changes. Plus, MAUI is not ready! I suspect they may even push back the deadline for ending support.

The real limitations won’t materialize for a couple of years. Because they aren’t doing updates, you will no longer get support for the newer versions of iOS and Android. At that point, it’s about when Google and Apple will cut off the previous versions from their stores.

When we’re ready to move from Xamarin, what ducks should we have in a row?

Charles: To set yourself up for success in your Xamarin.Forms → .NET MAUI transition project, know the answers to the following:

• Where is your source code stored?
• What’s your level of testing on the platform now? Is it manual or automated?
• Do you have the right stakeholders to talk through what the product does and its intended uses are?
• Do you have up-to-date documentation?
• Was the tool built internally or by outside vendors?
• Do you have a dev team overseeing maintenance and feature work for this?

Adam: You should also know that Microsoft has released resources about how to do it with this transition. There are some good YouTube videos as well. With these changes, you’re going from a largely community-supported framework (Xamarin.Forms) to one that is owned by Microsoft (.NET MAUI). And with Microsoft’s ownership, it remains to be seen if the transparency will be as available after the official release.

Also, if you’re working with an internal or freelance developer, I recommend standing up a MAUI app from scratch before making this transition. It might help during the transition process. We have created and deleted a new MAUI project several times, particularly as it relates to setup because the project files are different.

You Might Also Like:

• Is Your Xamarin.Forms Project Ready For Migration To MAUI?
• Think Software Maintenance is Expensive? Here’s Why It’s Worth the Investment.