Compiling Objective-C on Windows is not such a big deal. The huge thing here is that Microsoft has apparently reimplemented the Apple frameworks, because that's the only way they could port over existing iOS code.<p>I'm extremely curious to find out how much of UIKit is available on Windows Phone. It might be something disappointing like "well, if you stick to old pre-iOS7 methods and don't use new frameworks or AVFoundation or anything, most of your code will compile"... If they're really tracking the latest iOS on this, it's an amazing feat.<p>It's worth noting that Microsoft also has a companion product for Android, the "Universal Windows Platform Bridge for the Android Runtime" a.k.a. Project Astoria:<p><a href="https://dev.windows.com/en-us/uwp-bridges/project-astoria" rel="nofollow">https://dev.windows.com/en-us/uwp-bridges/project-astoria</a><p>The difference seems to be that the iOS porting toolkit is an SDK, while the Android version is a complete runtime. So you can take an existing Android app (.apk file) and run it directly on Windows Phone, whereas the iOS app will need to be recompiled in Visual Studio.<p>I find the Android bridge to be the really exciting news. Now every phone vendor except Apple supports Android apps! I wrote a blog post about it a few days ago when it was announced:
<a href="http://blog.neonto.com/2015/04/29/android-is-the-new-win32-the-new-java-and-the-new-flash/" rel="nofollow">http://blog.neonto.com/2015/04/29/android-is-the-new-win32-t...</a>
When I shared a link to this article in Facebook, Facebook recommended this "related link":<p><a href="http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish" rel="nofollow">http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish</a>
While technically interesting (assuming they ported iOS frameworks), it's no more than a hack, UI-wise. It prompts developers to consider the UI as an afterthought; just "trust" Microsoft's <i>adaptation</i> of another platform layout, add "minimal changes" and presto: UI work is done.<p>It's a sad route to follow, if you truly care about your users.
OS compatibility layers never work well. I expect this to fail within a couple of years max. It'll be used to convince people to do a quick one-time port of their iOS apps over. Microsoft won't be able to keep it with Apple's API changes so it will always be behind and crappy.
Squinting at the debugger screenshots, instance variables that are private in the 2.0 runtime are visible (e.g. instance_size). I wonder if they used the Apple runtime...
Haven't we seen this before? It was called J++ and was part of the embrace, extend, extinguish campaign.<p>I'm shocked at some of the comments, which seem identical to the sentiment 20 years ago. This isn't a different Microsoft, if anything, this is a return to their old playbook.
In any flourishing ecosystem, parasites eventually emerge.<p>This is so crass of Microsoft. I would be ashamed to work in the group that did this.<p>Technically? Sure, it's an accomplishment, akin to copying someone else's homework by typing it in by hand. Please notice I didn't say it's the same, I said it's akin to. Very nicely typed, good job.<p>But morally, it's exploitative and gutless, and it represents Microsoft giving up on the idea of finding success through innovation. Microsoft seems so pathetic now.