If you spend any time listening and talking to Windows developers, you’ll know that there’s a lot of confusion and frustration about the direction of the platform, especially around .NET and UWP (Universal Windows Platform). Microsoft is attempting to draw a line under the differences between UWP and older Windows SDKs, while trying to bring everyone into a .NET 5 future with the Build 2020 announcement of Project Reunion, but it’s still going to take time to deliver a unified platform.
A lot of that has been down to how Windows platform updates have been delivered in the past: coupled to operating system releases. Project Reunion builds on the work with the WinUI user interface components, decoupling them from the underlying operating systems and allowing the developer platform to evolve much faster than before.
Building on an open source approach to the platform gives more opportunities to bring the .NET development model (and your code) to as many platforms as possible. One example of how this will work is the Uno Platform’s WinUI implementation, which recently launched its third major release.
Introducing the Uno Platform 3.0
If you’ve not looked at the Uno Platform before, it’s perhaps easiest to think of it as an alternative to Xamarin that allows you to build .NET code that runs on iOS, Android, macOS, and the Web. I’ve written about Uno before as a way of delivering familiar user interfaces over the Web using WinUI with WebAssembly and Microsoft’s Blazor development framework.
Uno Platform 3.0 is being developed to support WinUI 3.0 alongside WinUI 2.0. This way you can mix and match new and current controls, an approach that should work well alongside the phased rollout of both WinUI 3.0 and the system-level Project Reunion APIs.
There’s a lot to like in Uno, especially that there’s little to no learning curve. Code can be built in your favorite IDE and use existing tools and frameworks, providing a common UI layer for all your code versions. You only need to write your C# and XAML once, with WinUI code running directly on Windows, and through Uno on other platforms, building on top of Xamarin’s native tools for iOS, macOS, and Android, and using the Mono-WASM implementation on the Web.
Using Uno to bring .NET apps to macOS
Under the hood, Uno’s macOS implementation builds on the similarities between macOS’s AppKit and iOS’s UIKit. This allows the development team to post their existing iOS control implementations. Although this works, some controls still have issues, so it’s worth experimenting before deploying any code to your users. Even so, it’s an effective way to bring existing .NET apps from Windows to macOS. By building on core macOS libraries, Uno should hopefully allow your code to run on the recently announced ARM-based Apple silicon.
Mac support in Uno is relatively new, launching in May 2020, with a re-implementation of the Windows Calculator app on macOS and published through Apple’s macOS store. Building a macOS release of your existing code requires using a set of new Uno templates and the Windows .NET command line tool. Once you have installed the new templates for either Uno 2.3 or 3.0, you can create an app scaffolding for a macOS application with the same name as the project you want to target.
You can then move that project into the same folder as the rest of your application files and add the new project to an existing Visual Studio solution. Compile your code for macOS, using Visual Studio for Mac and configure its iPhone simulator settings to target your development macOS device.
As you can’t use Visual Studio for Mac to work on Windows WinUI apps, it’s a good idea to use Git or a similar source-code control platform for your complete solution so you can manage code changes for macOS and for Windows. If you’re working on a WebAssembly version of your app, use Visual Studio Code to build it with the C# and JavaScript debugger extensions. MacOS support is available in both Uno 2.4 and 3.0, with the latest version demonstrating a WinUI-based cross-platform video player application that’s available in all the main app stores.
Using WinUI 3.0 in Uno
If you’re planning on working with WinUI 3.0, you must use Uno’s recent 3.0 release. Again, use the Uno Platform’s .NET templates to set up scaffolding for your code. If you’re moving existing code to WinUI 3.0 you need to change the namespace you’re using, both for the Microsoft controls and for your Uno code—something that’s easy enough to do using the refactoring tools built into Visual Studio.
One interesting aspect of the Uno Platform is support for dual-screen devices. By taking existing code to Uno and adding its dual-screen controls, you should be able to port apps from Windows to the upcoming Android-based Surface Duo with minimal changes. With Microsoft prioritizing dual-screen mobile applications and collaborating with Google to improve support to upcoming Android releases, tools like Uno will be an important route to taking existing large-screen and tablet experiences from Windows and bringing them to folding and dual-screen Android hardware.
Uno Platform and the future of .NET application development
It’s clear that Microsoft is aiming to remove confusion about how to build applications in the .NET ecosystem, using WinUI and Project Reunion to provide much-needed clarity about the future. But as quickly as Microsoft promises they will be delivered, they’re still likely to be too slow for many developers. Both the Uno Platform and Xamarin’s MAUI are ways to get access to these technologies more quickly, on top of your existing .NET code.
By adding macOS and Web UI support to .NET, the Uno Platform looks to be a better choice for targeting as many users as possible with the least amount of code change; it’s a road to the .NET future that should save a lot of development time and keep support load to a minimum.
Using Uno should future-proof your existing .NET code in other ways, too. In-browser WebAssembly and stand-alone WASI (WebAssembly System Interface) applications should simplify the process of bringing your code to a new generation of edge hardware, especially small form factor and small-screen devices based on ARM and other low-power processors.