Microsoft supports UIKit

By uliwitness


This week’s Build conference held a big surprise: Microsoft announced that they’ve built a UIKit compatibility layer for their various flavours of Windows.

Now I’m mainly a Mac developer and only hear of Windows things from friends and colleagues at the moment (the last time I did Windows work was around Windows XP), but my impression so far was that MS was frantically searching for a new API.

I don’t remember all occurrences, but I remember them announcing Silverlight, and .NET with WPF, and Windows RT that only supported the new APIs, and all sorts of things to then cancel them again.

So my impression as an outsider is that new APIs weren’t trustworthy and MS would always fall back to supporting their old API main-line that they carry around for compatibility reasons anyway.

Announcing UIKit and Android support actually makes a lot of sense in that context:

Although it appears to acknowledge that Windows Phone really didn’t take off, it does solve the catch-22 that MS found themselves in: Lack of apps. In an ideal case, they’ll now get all iOS apps Apple sells, plus the ones Apple rejected for silly reasons, plus those Android apps that iOS users long for.

If this gambit pays off, MS could leap-frog Apple *and* Android.

It also increases trust among developers who are sticking to ancient API: iOS and Android are the only modern APIs that Microsoft could implement that developers would confidently develop against after all these false starts, because even if MS dropped support for them, they’d still have the entire iOS/Android ecosystem to deploy against. So coding against UIKit for Windows Phone is a reasonably safe investment.


Of course, the elephant in the room here is Apple’s recent move to Swift. Now, given that Apple’s frameworks still all seem to be Objective-C internally (even WatchKit), I don’t think MS have missed the train. They might even pick up some Swift critics that are jumping Apple’s ship by supporting Objective-C.

But Swift damages the long-term beauty of MS’s “just call native Windows API from Objective-C” story. They will have to bridge their API to Swift (like Apple does with some of their C-based API right now), instead of getting people to use more and more classic Windows API in their Cocoa apps until the code won’t run on iOS anymore.

Still, that’s a small aesthetic niggle. MS already have a code-generator back-end that they can plug any parser onto, and Swift doesn’t appear to be a particularly difficult language to parse. In any event, parsers are easier than good code generation. For MS to create a Swift compiler is a solved problem, and I’d be surprised if they weren’t already working on it.

Of course, if MS had known about Swift when they started their UIKit for Windows, would they still have written it in Objective-C? Or would they have just written it in Swift with a bridging header?

So given the situation MS have managed to get themselves into, this sounds like it might be a viable solution to survive and, maybe, even come back from again. Still, it is an acknowledgement of how MS has fallen, that they need to implement a competitor’s API on their platform.

2 Comments Leave a comment

  1. Internally, I’m sure they have a Swift compiler (or transcoder, it doesn’t matter anymore) that produces Win32 applets. If not, it’s just because they considered the execution to be basically solved and didn’t bother to do it.

    I don’t think there will ever be a new user interface API. Windows is nothing without the compatibility. Same with iOS and OS X. Apple could only get away with ditching Classic and PowerPC because no one important had anything that needed to keep running.

    Microsoft has always frantically tried to keep up with the appearance, if not the ideals, of what its competitors are doing.

    Then they put no effort into eating the dog food they just produced. Whoever takes over ignores it until it can be strategically yanked to create internal (or external) opportunities. .NET turned into nothing I’ve heard of except a marketing trademark and C#, a copy of Java.

    Where is MacOS9.Emulator.Org? Where is WindowXP.Emulator.Org? We could have an abandonware party.

  2. It seems as hot as Swift is, and as fast as it is being adopted. Most iOS code is in Objective-C right now. Even new apps that are mainly written in Swift will have some library or utility code written in Objective-C, so there is no pathway that would have involved not writing an Objective-C shim.

Share your thoughts