Write once, run anywhere.
The original promise of Windows 10’s Universal Windows Platform.
In 2015, Windows 10 was released, and with it came the Universal Windows Platform. The platform promised to be just as flexible as Windows 10 was, allowing developers to write their code once and run it “anywhere”.
UWP was poised as the ultimate platform for developers. Write your app in the language of your choice: C#, C++, Visual Basic, JavaScript, etc. Then, run it on every form factor: desktop, tablets, mobile devices, game consoles and even fitness and IoT devices.
Windows development and .NET have a long rich history, (which is explained in depth here). When UWP was built, it was made to take advantage of these established and mature technologies, while cleaning up and modernizing them to make them flexible and easier to use on a diverse family of devices.
The result was UWP XAML and WinRT, the core technologies behind UWP. These technologies are platform-agnostic by design and using them gave your app the ability to run on multiple platforms and form factors, as long as it ran some variant of Windows 10.
(You could still use the older Desktop “Win32” APIs, but these APIs would only work on Desktop where they were available, so to stay 100% universal, you relied on WinRT)
The Microsoft struggle
Impressive tech, poor adoption.
UWP is a very capable app platform, built on years of established standards, and modernized to offer more than the Web, Android or iOS could at the time. Surely, UWP could edge out (pun intended) the competition?
Unfortunately, that didn’t happen, and for many reasons. The biggest ones:
- Developers still felt betrayed by old Microsoft, for a multitude of reasons (just ask a Windows Phone 7 developer, if you can find one).
- Microsoft Band 2 just couldn’t compete with Fitbit and the Apple Watch.
- Xbox runs UWP apps, sure — but gamers aren’t playing Xbox for the apps.
- Windows 10 Mobile was great, and Continuum fully leveraged what UWP was capable of, but Android and iOS were already too far ahead for Mobile to gain traction.
- VR and AR (Windows Mixed Reality and HoloLens) was, and still is, too niche to make an impact in the “average joe” consumer space.
- Developers of traditional “WPF” apps, which used the original Win32 APIs, didn’t like the self-imposed limitations of WinRT. The sandboxing, which traded convenience for security, forced devs to ask the user before doing certain things to their device (but a few API issues were also to blame).
- Developers of Android and iOS apps, who were used to such limitations, didn’t see an audience on UWP to develop for, meaning it wasn’t worth rewriting their apps.
As time went on, the high promises of the ecosystem became nothing more than fond memories. UWP apps still shined wherever they could: Desktop, Surface, HoloLens / Mixed Reality, and sometimes even Xbox. But as mobile died, Electron and other web-based apps gained traction on Windows, thanks to their cross-platform nature and overabundance of developers.
Despite all their efforts, it was clear that “Universal” had become “Desktop and Windows Tablets”. The promise of “Write once — run everywhere” was broken, and while UWP didn’t die, it certainly lost something special along the way.
The four UWP Bridges
Filling the app gap…?
If you were a developer or a Microsoft enthusiast from 2016–2019, chances are that you know of the “bridges”. These were an effort to streamline porting apps from other platforms to Windows.
Centennial (Win32)
Centennial is meant to make classic Windows apps -Win32, .NET, COM- run on the Universal Platform. It doesn’t change the code, it simply repackages the installer for a Desktop app into a store-friendly, easy to install / uninstall package.
This is the one bridge that has seen some success — many, many Win32 apps are now available in the Microsoft store thanks to this bridge, and you can still install and use it today.
Islandwood (iOS)
Islandwood was the bridge that allowed iOS apps into the Windows ecosystem, with as little pain as possible. That was the original plan, and shortly after release, we even got a few apps ported from iOS by Facebook.
Unfortunately, Apple’s ecosystem was moving a little too fast for the team that maintained Islandwood at Microsoft, though they were at the mercy of Apple and were mostly able to mostly keep pace. But because developers had to go out of their way to port their apps, it didn’t see the widespread adoption Microsoft hoped for, and it fell into the shadows. The last blog post made in 2016.
Astoria (Android)
Astoria is an interesting creature. It wasn’t a way to port your Android app to Windows. Rather, it was a translation layer that allowed Android apps to run natively on Windows 10. In fact, that same translation layer was used to create the Windows Subsystem for Linux.
The Astoria team had 60–80 people (versus the 5 it took for Islandwood). It was leaked early, was tested for a few builds in the Windows Insider program, and was completely removed in build 10586 (the Windows 10 November Update).
Project Astoria forums went silent in September 2016, Microsoft stopped talking about the project (even to those under NDA), and in the end, it was discovered that technical and economic issues were the cause of Astoria’s demise. The silver lining? You can still use Astoria, but with lots of caveats.
Westminster (Web)
Westminster was an effort to retrofit Web apps with WinRT access and other UWP capabilities.
From the “in a nutshell” blog post:
This bridge enables you to publish your responsive Web App on Windows 10 as a true UWP app. Project Westminster also makes it even easier to integrate your web app with Windows features like Cortana voice commands and authentication.
Of course, given the extra steps that Web developers had to go through, Westminster suffered much the same fate as Islandwood. Unlike Islandwood, the links at the end of the blog post are dead and redirect to pages regarding PWAs and Chromium Edge. The Westminster APIs from the demo do not work in the new Microsoft Edge, and this bridge is effectively torn down.
Bonus — OSMeta (Facebook)
Not much is known about OSMeta. Facebook acquired the company in 2013, the founder is very well versed in underlying MacOS technology, and all the team members were incredibly talented, doing some complex side projects and having worked at high profile companies.
I spent several hours researching this, and you can read the details of that adventure in this Twitter thread I compiled.
Long story short, OSMeta is Facebook’s version of Project Islandwood, but acts more like Project Astoria. It started as a Posix translation layer that was made to run the same code on a vast array of devices (phones, cars, Airplanes, etc), was scooped up by Facebook, and repurposed to be a multi-platform iOS bridge.
We saw the WinRT version of this in the form of Facebook Messenger, but there is metadata in the source that suggests it was meant to work on Android, too.
Judging by the LinkedIn profiles of the OSMeta employees, the project was likely scrapped in mid-2018, shortly before Facebook announced Messenger 4, a do-over for the mobile apps. Several months later, they announced the new Desktop app, which replaced the OSMeta version.
Looking bleak
So at this point, save for Centennial, the bridges have all been torn down, and there’s still no reason for Android and iOS developers to make UWP apps. What now?
Evolving Windows development
Fixing past mistakes
When Microsoft set out to create UWP as a “modernized” app platform, they succeeded on most fronts.
UWP adheres to responsive design, handles all input methods effortlessly (mouse, keyboard, touch, pen, and gamepads), scales nicely to every screen resolution, has a powerful templating system, has performant data binding, the list goes on and on.
A few years after Windows 10’s launch, a couple of big pain points remained:
- The UI stack (WinUI) was tied to OS updates, meaning you couldn’t guarantee that some “cool new control” would work for everyone.
- WinRT still had some issues, and people wanted the choice to use the Desktop APIs.
- The modern APIs (notifications, device sensors, etc) provided by WinRT were difficult or sometimes impossible for traditional desktop apps to use.
Rather than throwing money at the bridges to close the app gap or push harder to get people onto UWP, Microsoft set out to fix the mistakes they made when Windows 10 launched.
Project Reunion
Project Reunion has one goal: Bring the new UI framework to all apps on Windows, and give easy access to both Desktop and UWP APIs, so developers finally have a no-compromises choice between the two.
When Project Reunion is shipped, there will be only one difference between UWP and Desktop apps: UWP will still be universal. If you want to target more than just Windows 10 Desktop, you build a UWP app and use the “UWP APIs”, because they are universal by design.
Taking it cross platform
Finding one framework to rule them all
In the modern app landscape, most companies and developers want to maximize the reach of their product as much as possible, with as little effort as possible. UWP was built for exactly that, but with one fatal assumption: That Windows would be the de facto standard on every form factor.
If you want to build an easy cross platform app today, you have a couple options. We’ll list a few of the ones Microsoft recommends, but there are many more.
Progressive Web Apps
These days, the platform of choice for making cross platform apps is the Web. It’s easy to update, it works on every platform that can run a browser, it’s become increasingly native-like, and has an abundance of developer talent, thanks to the approachability of JavaScript and HTML.
But by creating a Progressive Web App (PWA), you sacrifice two important things: native APIs that can’t be used in the browser, and performance.
The more important these things are to your app, the more likely you’ll need a native app, which means rewriting your app for each platform you’re targeting or moving on to another cross-platform solution.
Xamarin
One way to create a native-friendly, cross platform app is with Xamarin. You can write your app using .NET and C#, which means tapping into a pool of developer talent that wasn’t useful on Mobile before (as long as they know Xamarin).
Originally with Xamarin, you had to rewrite your UI for each platform you targeted, but Xamarin.Forms fixed this problem by sharing a single UI framework and rendering natively on all platforms. The only drawback: you can target only 3 of 6 potential mainstream platforms.
React Native
Frameworks like React Native take it one step further by allowing you to run a single codebase natively on iOS, Android, UWP and the Web.
React native is easy to pick up for existing React developers, and there’s plenty of dev talent to draw from. The drawbacks: even after all the setup to add Windows/UWP to the mix, you’re still only targeting 4 of 6 mainstream platforms, and you’re still writing platform specific code for a lot of things.
Something better?
Now imagine you’re a small team, or just a single developer. You want to maximize the fruits of your efforts by running a single codebase natively on all platforms, with a common UI and API used everywhere. No compromises, and no maintaining multiple apps. What do you use?
Enter the Uno Platform
Write once — run anywhere. For real this time.
Nventive knew that UWP was powerful when it came targeting multiple form factors. Over the last few years, they’ve been building the Uno Platform, which brings the dream of “Write once, run anywhere” back to UWP, but in a much more complete way.
The Uno Platform does something unique — using only UWP technologies (WinRT and XAML), run 100% natively, and across every possible platform, with the option to use any platform specific code you like.
It’s a dream come true for UWP developers, and something that has no equivalent on other platforms.
Hitting every target
Writing universal code, running native apps.
Using Uno, a UWP app can run on Windows, iOS, MacOS, Linux, Android, and Modern Browsers with little to no code changes. It does this by bridging WinUI and WinRT to the rendering stack and native APIs for each platform.
The result is one codebase, running natively all platforms. If you want platform specific UI or code, Uno can do that. Want the native styles instead of the Windows styles? Uno can do that, too.
In fact, after UnoConf 2020, it’s starting to look like there’s nothing Uno can’t do.
Now with SkiaSharp
More speed, more precision, and more potential.
In a nutshell, SkiaSharp is a tool that can be used cross platform to render any 2d images and pixels.
This allows Uno to render your app more precisely and (sometimes) more efficiently than mapping to the native render can, even allowing them to render in places that weren’t possible before.
Using Skia, Uno can render WinUI anywhere Skia can run. This provides a few advantages over native rendering:
- Render every pixel perfectly no matter what platform you’re on.
- In some places, it has better performance than rendering WinUI natively.
- Take full advantage of everything WinUI can offer, even as WinUI evolves.
During UnoConf 2020, SkiaSharp was shown off as the rendering engine for a few new platform targets.
Linux
SkiaSharp allows Uno to run natively on almost any flavor of Linux, from desktops to IoT devices, and even on the Tizen smartwatch.
Windows Presentation Foundation (WPF)
Yes, really. When paired with SkiaSharp, Uno can render apps natively on WPF, the precursor to UWP.
This means that Uno could reach Windows 7 and 8, rendering an entire modern UWP app with WinUI.
Benchmarks
As with all benchmarks, take with a grain of salt.
Performance benchmarks are not indicative of real-world performance, but they do give you an idea of what each technology is capable of. It’s an Apples to Oranges comparison, done with one data point.
The main takeaway: .NET Core and Skia are very fast compared to other cross-platform offerings. (Full explanation)
Web Assembly Improvements
In May 2020, Uno announced a huge step forward for Web Assembly apps.
Long story short, the code generated by Uno is now 50% smaller, making startup time twice as fast. At the time of writing, developers need to enable it manually as there are still some kinks to work out before it can be fully released.
You can take these improvements for a test drive by trying out the updated Windows Calculator app in the browser.
Even further beyond
This shouldn’t be possible, yet here we are.
Uno is capable of many things that I never thought possible, but to me, one thing takes the cake.
Devs know that Visual Studio is by far the best IDE to write your UWP app with, with JetBrains Rider as the runner up. Uno takes this 3 steps further, by allowing you to also develop your app in Visual Studio Code and Visual Studio for Mac.
Visual Studio Code is an Electron app, and was written with web technologies. Those who paid close attention to Build 2020 will know about Visual Studio Codespaces, which is an easy way to run VS Code in the browser , with the full feature set of the desktop version.
Now we have all the ingredients:
- A UWP app written in XAML and C#
- Using Uno to run on Web Assembly
- Fully featured IDE running in the browser
The end result: You can develop a UWP app in the browser.
It isn’t perfect compared to the likes of Visual Studio, but the fact that this is possible blew my mind.
Imagine you’re stuck on a low-end laptop, or an Android tablet / iPad, or maybe even Samsung Dex, and you need to quickly make changes to your app. Now, you can do that!
The future of UWP?
Absolutely
Microsoft tried their best to create the “one platform to rule them all”. The Universal Windows Platform is robust and powerful in its’ own rights, but it couldn’t keep up with the competition.
Just as the “U” in UWP started looking like a dead dream, Uno has picked up the torch and taken it to new heights. That *spark* of excitement about UWP being truly cross platform is back, and it’s exciting.
Uno is an open source project, run by a impressive team of around 20 people, between the core product, designers, and UX Engineers.
“It’s a massive undertaking, we’re trying always to balance innovation (moving fast) with stability… It’s probably the biggest ongoing challenge
Idea is we think we “suffered” enough as mobile devs that we know exactly that would help us on a daily basis, and that’s why we built Uno in the first place, why we want to build other tools and why we think we’ll be good at listening to what the community needs and wants.”
— François Tanguay, CEO and Founder of Uno Platform and nventive.
It is indeed a massive undertaking. While the core product absolutely works, a few APIs are still [todo].
Their progress on closing that gap has been massively accelerated by contributions from the dev community.
For such a small team, their accomplishments are simply impressive, and they seem to be on the perfect path to change the course of the platform for the better. Here’s hoping Microsoft will acknowledge that potential, and one day buy into their vision.
