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.
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.
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:
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.
Its not exactly as you describe. The android support is just like the IOS support. You have to rebuild your app for it. Still pretty neat, but it is a recompile.
It seems to me that you don't have to compile your app in Visual Studio, though? The video on the Project Astoria page shows an Android app being built for Windows Store using Eclipse on a Mac.
That's a key difference compared to the iOS support. To port an iOS app to Windows, you need to build it in Visual Studio. To port an Android app to Windows, you use your existing toolchain and just produce another .apk with some different dependencies.
I saw project astoria first time on nokia X website developer. It seems microsoft keep continue the project and re marketing again and call it universal windows app. If you have apk file and not connect to google service, all you need is just upload it from the website. And also if you change the icon asset, people almost cannot see the different
While technically impressive, I wonder how much economical sense does it make for an iOS developer to go this route. For a small install base you open up a support front and now your code needs to work against the UIKit implementation of Windows Phone that by all likelihood will have its own bugs and limitations. You also might have planned to use Swift on iOS and this isn't possible when you want to compile your code for Windows Phone.
Is there any likely technical reason Microsoft won't be able to do the same with Swift in the future? As I understand (not an Apple developer) doesn't it use the same frameworks, so they can reuse that? Its syntax also looks way more similar to c# than obj c does from a quick look.
The technical reason is probably that Obj-C has multiple stable implementations (which agree almost entirely), the GNU or Clang frontends, which makes it easy to write your own implementation because you can study what those two do (in the worst case; the Obj-C part they could just do by compiling either of those two compilers).
With Swift, the compiler is closed source, so you either have to examine the code it produces or the programmers manual, which is legitimately more difficult technically.
Then there's the fact that the lawyers will have to be all over any Swift implementation, and it gets even harder.
None of this would have happened if Clang didn't exist :P The whole reason that Microsoft can do this project now is because Clang didn't exist when Apple/NeXT started development on Obj-C.
> None of this would have happened if Clang didn't exist :P The whole reason that Microsoft can do this project now is because Clang didn't exist when Apple/NeXT started development on Obj-C.
This paragraph is a few kinds of incorrect. I built objc code on Linux with GCC before clang existed. (gobjc is the name of the package.) Clang therefore was not the only free software objc frontend at the time of introduction. GNUstep even ran on Windows using that. There is no reason Microsoft could not have also based its efforts on GCC's objc frontend, without clang.
I believe also NeXT used GCC back in the day - I read somewhere that even then they were displeased with the fact that GPL forced them to contribute back. Also objc existed before NeXT, the were just the only notable player using it and de facto took it over.
In 1996 I ported a large bunch of code from NEXTSTEP to Windows using the GNU runtime. That was all pre-OpenStep (OK, it wasn't, but the code didn't use Foundation, had no UI, etc, so it didn't depend on any class libraries beyond the runtime itself). But it has been possible for at least twenty years! (And there was always GNUstep.)
Another interesting thing is Apportable's Foundation implementation, it's really nice and is LGPL'd. I wonder if MS licensed that.
That's my entire point; if Clang did not exist then Apple would have had to contribute the Swift frontend back with the GPL or write an entire compiler backend, as they did for Obj-C.
Now, Clang is competitive and they can keep the frontend under wraps.
Had Clang existed when Apple were implementing Obj-C, they'd have used that, there'd be no open source Obj-C frontend Microsoft wouldn't be able to do this without considerably more work.
In short, they used one of the available open-source frontends (clang, the other being gcc). In addition, Objective-C is almost completely trivial to implement if you have a C compiler. Heck, a 17 year old kid with nothing but a C compiler, access to the Brad Cox book and no formal training in CompSci in general or compilers in particular managed to pull it off back in 1986 or so.
Swift is closed-source, so unless or until that changes, it is a reverse-engineering effort. It is also a vastly more complicated language to implement. It is hard to even begin to describe the difference. It leans on the compiler and optimizer by what I consider to be an insane amount, just the rules for initializers and named keyword arguments are bigger than the entire Smalltalk language spec (which is the part Objective-C adds to C). The optimizer is required if you want performance greater than Ruby interpreting a Python program. etc.
On the other hand, it is in many ways similar to C#, so probably not that hard a feat for MS to pull off.
And it's possible Apple will open source it - although if they do I imagine it will be more work to integrate with a foreign runtime (if indeed that is what MS has done) than to use Apple's own.
It is my understanding that Microsoft approaches the makers of popular software titles and offers them money to put their software in the Windows store. In the past I think a lot of companies turned them down. If the barrier to entry is lower, maybe those companies will take the offer.
For games this approach can make a lot of sense, for other types of apps that make heavy use of UIKit it's certainly worth considering if it's the best approach.
The weird thing is that such a product -- AppKit on Windows -- existed and was made by Apple itself. It was called "Yellow Box for Windows" and shipped as part of WebObjects at one point.
Now the tables are turned, and Microsoft is building an "iOS Yellow Box" of their own.
I wonder if part of the reason for last year's Swift announcement was that Apple got whiff of Microsoft's Obj-C Cocoa clone.
Swift was obviously half-baked when it came out. It's still far from production quality IMHO. But as a deterrent for this kind of compatibility action, Swift's existence is quite effective.
- Swift support s in Xcode and if Microsoft doesn't watch out their implementation might be miles ahead at their first try
- Swift 1.0 was a marketing 1.0, technically maybe a 0.2 release. I hope I don't need to touch it again in the next year even though I like the language principally
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 adaptation of another platform layout, add "minimal changes" and presto: UI work is done.
It's a sad route to follow, if you truly care about your users.
I don't think you need a source to know that either a) they do some automatic "adaptation" of the layout elements; or b) they render it as iOS does. Neither of these scenarios is optimal, nor prone to great UI work.
Anyway, my point concerns more the concept/approach than the exact implementation. "Converting" is proposed as an easy path to have your product on other platform, as opposed to doing all the due work to address differences and specificities.
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.
They don't have a good reputation, do they. But, it depends on how much engineering resource Microsoft dedicate (and of course, how quickly Apple evolve their APIs/applications make use of them).
They've taken proven over and over again for the past 30 years that they never follow through on anything that involves cross platform compatibility so I'd take it with a healthy dose of skepticism. It just fundamentally isn't in their culture and they have a lot of old-timers there.
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.
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.
The difference is that J++ was an attempt to prevent other people from simulating a “better” computer/platform on top
Of Windows.
This new thing is Microsft trying to simulate a “better” computer/platform on top of iOS and Android. In this case, “better” means that it also includes Windows.
The new thing is exactly what J++ was about. Support some set of Java features, extend it with incompatable, "better" features, and finally, ensure that those features were non-portable. We're seeing the first two now, the third follows when strategically beneficial - maybe that will never happen because they've lost too much momentum.
Microsoft loves to show how they are a team player, but consistently breaks those relationships at the moment that is most beneficial to them.
What's most amazing to me is that people have been falling for it for 30 years.
In any flourishing ecosystem, parasites eventually emerge.
This is so crass of Microsoft. I would be ashamed to work in the group that did this.
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.
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.
I'd say take those on a case by case basis. When Microsoft was an abusive monopoly and there were few choices out there (hardly the case for Apple today, which has vigorous competitors who offer plenty of working alternatives), some of these made sense, although superior products made from the ground up would have been better.
>It's more about compatibility with an existing ecosystem than copying.
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.
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:
https://dev.windows.com/en-us/uwp-bridges/project-astoria
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.
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: http://blog.neonto.com/2015/04/29/android-is-the-new-win32-t...