With Windows 10, some of the biggest changes coming to Windows don’t even have to do with its features and functionality, but on how those are delivered. Windows is moving towards Windows-as-a-Service, and this might just have a huge impact on how software targeting Windows is developed and delivered in the future.
The first impact is that Windows once installed on a device will continue to update to the latest version of Windows for the rest of the life of that device. For those running Home versions of Windows 10, these updates are even automatic and mandatory. Even for ‘Pro’ users the only control they have is to switch to a slower release cycle
and even that should update every 8 months or so. Combine that with a free upgrade to Windows 10 for any computer running Windows 7 and above – which is any computer from the past five years. For a software developer this means that targeting the latest version of Windows (and only the latest version of Windows) is now a whole lot more feasible. Currently targeting Windows can be somewhat of a mess. If you want to reach all Windows users, you need to target Windows XP, Windows 7 and Windows 8.1. However, these three operating systems couldn’t differ more in their design sensibilities. Windows XP with its blue bubbly UI, Windows 7 and its glassy aero look and Windows 8.x’s ‘Modern’ UI.
With Windows constantly updated with new features, and no major releases every few years for users to pay for and install, developers can more reasonably expect the majority market share to be at the release. Will things really work out as well? Only time will tell, but there is more reason to expect this then there was before. The changes under the hood are as no less massive. There are sweeping changes to Windows as a platform that can really simplify developing Windows apps and that is the new Windows Core.
Windows Core
Windows Core is Microsoft essentially realising that they own the most popular operating system in the world, and that they should probably use it in more places. In the past Microsoft’s different platforms have had rather different APIs and even different kernels.
Universal Windows Apps can run on any Windows platform and use techniques such as adaptive UIs to run on different form factors and with different kinds of interactions patterns.
Before Windows 8, the mobile, desktop and the Xbox’s OS stacks were very different. Windows for desktops used the Windows NT kernel, phones used the CE kernel and the Xbox used its own special kernel. Windows Phone 8 finally switched to the NT kernel making it a lot similar to Windows for desktops. Xbox One further converged these platforms by switching to the same kernel as Windows 8.
The application platforms and APIs above the kernel level were of course still quite different across platforms. While converging these kernels might have made things easier for Microsoft, it didn’t benefit other developers as much.
The new model for Windows APIs tries to as many APIs in common as possible. The only APIs missing should be those that are of no value on other platforms.
With Windows 10 comes a true convergence of all devices to the same Windows kernel, ‘universal hardware drivers’, and ‘standard network and I/O’. This in essence is what Windows Core is. Not only has Windows Core expanded to all devices that already supported Windows, but the breadth of devices that support Windows has also expanded. For instance, other than PCs, tablets, and phones, the Xbox One will also soon update to use the Window 10 core, it is already available for the Raspberry Pi 2, and of course Microsoft’s new HoloLens also runs Windows 10 core.
Consolidation and convergence are huge themes with Windows 10. After unifying the Windows core across platforms Microsoft has also unified the development SDKs across platforms into what they call the Universal Windows Platform (UWP).
Universal Windows Platform
UWP is a layer of APIs that are guaranteed by Microsoft to be available on any device that is running Windows, whether it be a mobile phone, a PC, the Xbox, an embedded device like the Raspberry Pi or even a device that hasn’t been released yet.
There are still platform-specific features, that can be layered on top of the UWP via extension SDKs. These SDKs extend the feature set of Windows for a particular family of devices. For example, the mobile family of Windows might power phones and phablets, while the desktop family on Windows will power tablets, laptops and desktops.
They both have their own extension SDKs that can be used to implement platform-specific features. Microsoft estimates though that over 85% of Windows APIs are available universally. The same application can now support multiple device families more easily, not just by using only the common UWP APIs, but by detecting and using only the features available on that platform. There is now an API to check for the presence / absence of platform-specific features and APIs.
This is different from earlier versions when such checks could only be performed at compile time in order to build different binaries for different platforms. Now runtime checks allow developers to have the same application code adapt to mobile or desktop.
Consider that Windows 10 now makes it possible to have a phone power a full desktop experience if docked to a station that has a larger screen, a keyboard and mouse. Of course this will need a very powerful phone, and might not be feasible today, but the possibility of such a thing is eminent. Microsoft’s new modular approach means that the OS for such a phone could simply be a composition of the Universal Windows Platform with Mobile and Desktop extensions. With such future devices it will be important for applications to adapt at runtime from a mobile form factor, to a desktop form factor, to even a television form factor. For this Microsoft has provided new adaptive UI elements that can work across form factors. Developers can also embrace the principles of responsive design for desktop applications – already a popular approach for web apps.
Universal Windows Platform Bridges
It’s quite a mouthful, but these bridges – as we will refer to them as for brevity – are toolkits designed to make it easier for developers to bring their existing Android, iOS, Web, and even old Windows apps and development experience to Windows 10 and to sell such apps on the Windows store. These bridging technologies are: Project Astoria for Android, Project Islandwood for iOS, Project Westminster for web applications, and Project Centennial for ‘Classic Windows apps’. Microsoft has yet to fully explain how these work, however they claim at least for Android that existing applications will need few code changes. For cases where your application uses Google services Microsoft has an interoperability layer that can map those functions to Microsoft’s technologies. For instance, it has API mappings for Ads, Analytics, In-app purchases and Notifications.
With minimal code changes it can make your code automatically use Bing Maps on Windows while using Google Maps on Android. These bridges also give developers access to Windows features such as Live tiles while still being able to target competing platforms. In fact, you can even target Windows Phone using your IDE on an OS X system. Essentially this means Android developers can continue to code in Java, iOS developers can continue to code in Objective-C (they plan to support Swift as well), web developers can continue to code in web technologies and Windows developers used to older technologies can still continue to use them. And they can still have their application running on Windows platforms and sold on the Windows store. It’s already possible to start using their compatibility layer for web applications, which allows you to have websites present as native apps in native windows. Developers can sign up for access to the other compatibility layers while they are still in development.
