Some readers with niche interests may remember Windows RT, the unpopular now-discontinued flavor of Windows 8/8.1 for ARM-based tablets.
Windows RT shipped on the first two generations of Microsoft Surface tablets (the lower-end Surface RT and Surface 2, not the Intel-powered Surface Pro line), and a tiny handful of third-party ARM tablets.
Even though it exclusively ran on touchscreen tablets and couldn’t run any of the massive library of 3rd-party Win32 software, Windows RT had the same widely-hated hybrid touch/desktop interface that laptop and desktop users encountered on Windows 8. Microsoft’s inability to port its Office suite fully to the touchscreen environment in time for Windows 8/RT’s release particularly highlighted this divide, as you had to bounce into the desktop every time you pulled up Word or PowerPoint.
It was pretty frustrating to use, and pretty frustrating to develop for — since the desktop was included, there was no technical reason why Win32 application developers couldn’t recompile their apps for ARM processors (maybe with some touch-friendly UI enhancements) like Microsoft did with Office… but Windows RT, unlike Windows 8, was locked down to require code signing approval from Microsoft on both touch-style apps and Win32 apps.
So developers had to port their apps completely to the new sandboxed ‘Modern’ API subsets and package format in order to run on Windows RT at all… and on Windows 8/8.1 desktops, those apps would only run fullscreen, not in… you know…Â windows. Overwhelmingly developers chose not to jump through those hoops, and everybody lost.
When it was announced that there would be no upgrade path for the ARM-based Windows RT devices to Windows 10, that was the final nail in the coffin.
Or was it?
The true innovation of Windows RT is that it was Windows 8’s ARM flavor. The API surfaces were the same, the source code was the same, the security updates came out together, and the major 8.1 upgrade came out together. If you were one of the few who developed ‘Modern’ apps for Windows 8/8.1, you only had to not uncheck the ‘ARM’ box when building and deploying to the Windows Store to reach Windows RT users as well.
That it was exposed to end-users in the Windows 8 ‘weird hybrid interface’ stage, and without Win32 access for 3rd-party developers, is perhaps unfortunate. But then we can say that of Windows 8 as a whole. ;)
But what this experiment enabled was the replacement of the old Windows CE + weird .NET-based Windows Phone 7 with the Windows NT + weird .NET-based Windows Phone 8, followed finally by the Windows NT-native Windows 10 Mobile and Windows 10 IoT… and even the Xbox One, which is picking up more user-facing Windows 10 features with each major update.
Like Windows RTÂ & Windows 8, Windows 10’s Mobile/IoT editions are built from the same base as Windows 10 for Intel-based desktops/laptops/servers, just in ARM flavor. Application developers targeting the Windows 10 ‘Universal Windows Platform‘ can build and deploy the exact same binary package on all flavors, with compilation targeting the CPU architectures rather than the device types.
And unlike Windows RT & Windows 8, the various Windows 10 flavors actually tailor their user interfaces to their environments. :)
Windows 10 has also reduced the lock-in requirements a bit, making it possible for any end-user to relax the code-signing requirements for Universal Windows apps to install custom apps.
Now, it may be that Microsoft has dropped the ball and will never recover in the phone market. But having a common platform base between desktop/laptop, tablet, phone, TV/game, and ‘other device’ seems like it will be an advantage in enabling cross-development now that a subset of Surface-branded tablets isn’t the only reason to touch the ‘Modern’ APIs.
The real question is going to be how hard it is to get into the Universal Windows Platform ecosystem at all — once you’re in, handling multiple devices gets easier. Rumored tools to make it easier to port Win32 apps to run within UWP should help with this, as may things like the Objective-C bridge for devs with iOS codebases.
Google seems to be doing much the same with Android, trying to expand its Linux + weird Java system from phones & tablets to smartwatches and TVs/game consoles. It remains to be seen whether Android will also push out or merge with Chrome OS in Google’s laptop/desktop market.
In comparison, Apple is pursuing a slightly different strategy where various Darwin flavors (Mac OS X, iOS, tvOS, watchOS) are closely related but slightly different, requiring separate compilation and deployment for every flavor. You can usually build from the same source using the same tools, but it feels a lot more fiddly to me.