Breaking a Developer Ecosystem by Changing a Namespace

The next 6-12 months are going to be super exciting with both preview and releases planned for WinUI, Project Reunion and Maui (aka Xamarin.Forms). WinUI/Reunion represent a significant decoupling for Windows apps from the underlying OS version. Meanwhile Maui will provide a bit of a reset for Xamarin.Forms which some major improvements to the way controls are rendered. However, these changes won’t come around without causing developers a bit of pain and frustration. In this post we’re going to look at how significant these changes are and the likely impact on the developer ecosystem.

WindowsUI v UWP

When UWP was first launched it was supposed to be this unified platform on which developers could build apps for the Windows platform. Apps could target a range of devices with a single binary and there were all manner of useful features that made it easy to build apps that behaved well on Windows. Unfortunately over time this picture started to crumble – with the demise of Windows Phone there was one fewer groups of target devices and the strong bond between UWP and each release of the Windows was increasingly becoming a burden on progress.

The WinUI project started off as a repository for additional controls that the community could contribute to that sat onto of UWP. However, this transitioned into a much more ambitious project that sought to extract the entire UI layer away from UWP and its ties to specific versions of the underlying Windows OS. WinUI3.0 is the result – a native library that can be used in both native and managed applications to delivery a rich set of controls and UI framework.

So far this all sounds great – we have the best of UWP being extracted and repackaged so that it can be used by both native and managed developers. But where’s the catch?

Well, the catch is that WinUI3 is not at all compatible with either older Win32 technologies such as WinForms and WPF, nor is it compatible with UWP. You might be thinking that this doesn’t matter but it does. The lack of interoperability means that you can’t use any of the existing control libraries from vendors such as Telerik, Infragistics, SyncFusion etc. Each of these vendors has to rebuild their control libraries specifically for WinUI3 (and potentially include a Desktop and UWP version). Given how hard it was to get UWP controls in the first place, are many of these vendors going to maintain both a UWP and WinUI3 version of their controls?

The upshot of the change from UWP to WinUI3 is that Microsoft is selling this as a simple find-and-replace Windows.UI.Xaml with Microsoft.UI.Xaml. The reality is that this only works if you’re not referencing any third party controls, frameworks or other UI libraries. If you’re using Prism or MvvmCross, you’ll need to wait for them to ship a WinUI version. Same goes for any of the control vendors.

Whilst WinUI3 is an incredible investment by Microsoft, it’s going to be a long drawn out process for the industry (particularly OSS) to catch up.

Maui

Whilst the change to WinUI was driven by primarily technical needs, the decision to rebrand Xamarin.Forms to Maui is purely clever marketing . Are there substantial changes coming as part of Maui? Absolutely. Did they, in isolation, warrant a change in namespace? A change in binary compatibility? A breaking change that will cost the industry thousands of wasted man hours upgrading? No, it absolutely did not.

I’m not privy to all the factors that drove the rebranding decision but I can’t help wondering whether there was a way to avoid breaking the ecosystem so badly.

Yes, the XF/Maui team have committed to making the upgrade process as easy as possible but here’s the rub – how quickly will all the component vendors and OSS projects roll out new versions to target Maui? Surely they can just upgrade can’t they? No, and this is the problem, they can’t just upgrade because most of their users will still be on anything from XF 3-5, and expect there to be features and bug fixes without forcing them to upgrade.

Again, lets say I’m a company that invested in developing my application in XF a couple of years ago. I’ve done the right thing and periodically upgraded the version of XF – I haven’t picked up every release because I can’t afford to re-test my entire app every 2-4 weeks but I’ve at least tracked the major version steps. Recently I upgraded to XF5 and a bunch of things in my app broke – it wasn’t hard for me to read through the release notes but it was time I didn’t want to spend “fixing” my app that wasn’t broken.

Now I’m looking down the barrel at the Maui update – I already know there’s a massive namespace change coming; I know that there will be breakages but right now, I can’t even begin to try things out because the libraries that I use for graphs and navigation, don’t have a Maui version. I’m now concerned because I’m wondering whether there will be any bug fixes or features for XF 5 between now and when I can migrate to Maui (which is probably a year away = Maui release date + 2-3 months to allow for libraries to be updated and stable).

And all this “fixing” is some how adding value to my application? The answer is no, it adds nothing to my already working application but is the tax I need to pay in order to get fixes and features so that my application can improve over time.

In closing I will repeat that there is a lot of awesome improvements coming down the path with Maui. If you’re building stuff with XF today, grab the preview bits of Maui and start putting pressure on the control vendors and help an OSS project deliver a Maui compatible preview.