With the release of Windows 10 and all the talk before hand, I’ve heard a lot of terms that I’m...let’s say...less familiar with. These include Projects Islandwood and Astoria (which are something about iOS and Android apps, respectively, running on Windows), Project Centennial (which has to do with putting classic Win32 apps in the Windows store), and Project Westminster (same thing, but with web apps). Those are related, but there are also other terms, like Continuum and Universal Apps that we should care about too. On our podcast earlier this week, we tried to talk about it, but it turns out none of us have much of an idea of what they all mean, at least not that we could string together into a cohesive sentence. While some of you surely know more than we do, I felt it was a good opportunity to delve into these terms so that we can all be on the same page.
We’ll dive in more in a bit, but to get started, Islandwood, Astoria, Centennial, and Westminster are the members of what Microsoft calls the Universal Windows Platform. Each of the projects is called a “Bridge” (as in a “bridge” between technologies), and with the release of Windows 10 they’ve been given real names:
- Windows Bridge for Android (Project Astoria)
- Windows Bridge for iOS (Project Islandwood)
- Windows Bridge for Classic Windows (Project Centennial)
- Windows Bridge for Web (Project Westminster)
The other names we were talking about were Continuum and Universal Apps, which a lot of us are more familiar with. I’ve added them to this discussion both for completeness (They are part of the Universal Windows Platform) and because part of our challenge on the aforementioned podcast was putting it all together.
Windows Bridge for Android
The one sentence description of Windows Bridge for Android is this: You can run .apk apps on Windows 10 Mobile.
Windows Bridge for Android works as a subsystem in Windows, much like the POSIX subsystem that you might recall from back in the day. Essentially, Microsoft implemented certain APIs from the Android Open Source Project (AOSP), for example, the filesystem, camera, security, and networking. Being based on AOSP means that any .apk app that was written for use on a device that uses only AOSP should work on Windows without modification. The problem is that while AOSP includes a lot of the base Android functionality, it does not include any of the Google Mobile Services functionality which adds in features like Gmail, Chrome, Google Maps, and so on.
Because of this limitation, any app that relies on GMS will probably require some modifications. Microsoft has replicated some of those features on their own (like in-app purchases), but you’ll probably have to tweak the code to support it (like to add support for geo-location or Cortana). It also means that any old app from Google Play isn’t going to work, either, because you need access to the source code.
Last, it’s worth pointing out again that this is only for Windows 10 Mobile, which is ARM-only. You’re not going to be able to use Android apps natively on your desktop, laptop, or 2-in-1 convertible.
So what does this mean for us? If in the final release Microsoft has made it exceptionally easy to onboard Android apps into a Windows environment, I’d think it would deter people from making apps for Windows (not that there needs to be any more of a deterrent). If you can make it for Android and it works on Windows, you’ve just covered two platforms. Still, the limitations of only working on Windows 10 Mobile and only working easily on AOSP might make this a non-starter. That’s a pretty narrow group of users.
Windows Bridge for iOS
At first blush it might seem like this is a short section: “Pretty much what the Windows Bridge for Android does, but for iOS.” In reality, the Windows Bridge for iOS is very different in both how it works and where it works.
Windows Bridge for iOS works not by creating a subsystem and running apps natively, but by extending Visual Studio to support development and compilation of Objective-C code. Developers can import Xcode projects into Visual Studio and then compile them to run on Windows. This isn’t running the same compiled app as you are on an iOS device, it’s running the same application source code that’s been compiled for, or ported to Windows. That means that you can run iOS apps on ANY Windows platform as opposed to just Windows 10 Mobile. You can literally recompile an iOS app for Windows 10 x86 and 64-bit, or for Windows 10 Mobile on ARM.
There are, of course, limitations. To enable the use of native Obj-C code, Microsoft had to implement a subset of the iOS APIs in Windows. They support lots of low level stuff like hardware interfaces and 3D graphics, but also add in some higher-level stuff like in-app purchases. Because Microsoft had to basically make their own iOS-like environment for the apps to execute, there will have to be more modifications to the source code than there would be with an AOSP-based Android app (which, as you recall, should just work).
Once you tweak an app, though, it should be able to take full advantage of the Windows interface, including things like live tiles and NFC, as well as integration with the rest of Windows. In fact, Candy Crush Saga in the Windows Store is using Windows Bridge for iOS, which means that you can go download and play it and still be “working."
Microsoft has made Windows Bridge for iOS an open source project under the MIT license. It’s hosted at GitHub, and you can check it out today if you’re into that sort of thing.
The cross-platform utility of Windows Bridge for iOS is more appealing to me than the Windows Phone-only approach to Android Apps. Still, the iOS apps that we’re talking about aren’t the same ones you get from the app store. Microsoft isn’t sandboxing iOS apps, they’re adding broad support for Obj-C and giving you tools to tweak the apps to work natively on Windows. What’s more, we’re talking about a language that’s being phased out by Apple in favor of a new platform called Swift. Microsoft has said that Swift support is in the plan, but as of now the only focus has been on Obj-C. So yeah, it’s cool that you can make your home-grown iOS app run on Windows (talk about App Refactoring!), and it’s about time Microsoft acknowledged that people aren’t only developing Windows apps anymore, but I’m dubious about any prospects of widespread adoption.
Windows Bridge for Classic Windows
Formerly called “Project Centennial,” Windows Bridge for Classic Windows leverages something like App-V to create application packages that can be delivered via the Windows Store and managed as “apps” instead of “applications.” Tim Mangan wrote about this back in May, so rather than re-hash what he said, I’ll direct you to the article from the master himself.
To sum it up, though, Windows Bridge for Classic Windows is a way to turn a classic Win32 application into a “Universal” application that can be delivered via the Windows Store (read on to learn about Universal Apps). It’s intended for use by ISVs, though, and not random customers. Though it sounds a lot like App-V (and Tim speculates that it’s probably a subset of App-V), it’s not identical since there are also components in there to make the app Universal. Check out Tim’s article for more information, but I like this a lot.
Windows Bridge for Web
The last member of the Universal Windows Platform is Windows Bridge for Web. This is the easiest to explain because by now you get the gist. Microsoft is all about delivering apps made for one platform to other platforms via the Windows Store, and Windows Bridge for Web does just that. An ISV can create an app with content based entirely on a web app and deliver it from the Windows Store. Developers specify a URL mask that the application can work within so that users can’t link their way to unauthorized sites, and access to the web apps can be managed as if they were singular entities.
That’s it for the “bridge” features of UWP, but there are two more elements of UWP that I want do delve into: Universal Apps and Continuum.
Universal Apps have been around since Windows 8 came on to the scene, but since nobody really used Windows 8, the meaning and use of Universal Apps has remained sort of enigmatic. In essence, Universal Apps are apps that are designed to be delivered via the Windows Store to multiple form factors and multiple platforms.
Universal Apps are designed with the understanding that certain APIs are available on all platforms, PC, tablet, or phone. You can, however, target your applications for specific device families, such as tablets, so that you can take advantage of features that might be unique to that family. If your Universal App is designed with more than one device family in mind, you can include multiple user interfaces so that the same application code is running behind whatever the appropriate UI happens to be for that form factor. That’s where Continuum comes in.
Most of us have heard of Continuum as the feature that allows Windows to auto-detect whether or not you’re using a device as a desktop/laptop or as a tablet. I don’t know the actual mechanism behind the scenes for sure, but from what I can tell Windows uses the connection of a display and/or keyboard to determine which UI of a Universal App to display. For example, if you have a tablet with a keyboard and a display connected, you’ll automatically get the desktop UI of an app. If you remove the keyboard, you’ll be prompted to switch to the tablet UI.
Continuum doesn’t just apply to those fancy 2-in-1 devices that can double as both a laptop and a tablet. It also applies to phones. Since Universal apps can have multiple UIs, even apps designed for the mobile device family can have a desktop interface. With Continuum, you can plug your phone into a monitor and keyboard and use the full desktop interface for an application that resides on the phone. While you’re not given a Windows Desktop, you are presented with a menu that lists the applications you can run in that mode.
That’s not all. With Continuum on Windows 10 Mobile, you can use the phone as a trackpad or keep it for use as a phone. If you continue to use it as a phone, any apps you launch from the touchscreen will appear on the phone in the phone UI, and any apps you launch from the desktop will launch in the desktop UI on the monitor. It’s basically the Nirvana Phone concept that Chris Fleck came up with at Citrix many years ago, but with local applications and variable UIs. While I'm still not the biggest believer in that concept (I want my phone to be my phone and my computer to be my computer), this implementation seems somehow better to me.
With all this information in one place, it’s pretty easy to see where this is going. The ability to deliver apps intended for any platform to Windows via the Windows Store is a valiant attempt at keeping Windows relevant for many years to come. Devices that are aware of their environment and show the appropriate UI is very interesting, especially when you consider the implications of tweaking an iOS app so that it also can shift UIs depending on the platform it’s running on. Though Android apps are limited to only Windows 10 Mobile, they too can be tweaked to run in the desktop form factor when the phone is used with a monitor & keyboard.
All of that sounds cool, but it also sounds relatively complex. Any time you require developers your onramp gets longer, and Microsoft has to convince people that there is enough value here to justify the complexity of the overall solution. This is exactly what Microsoft needed…in Windows 8. The timing would have been better, and there would have been two or three more years of maturity behind all of these features.
Researching this article answered a lot of questions that I had, but it created one more: Is it too little, too late?