[pavlov]

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:

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...

[sudioStudio64]

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.

Here's more info: http://www.slashgear.com/video-project-astoria-microsofts-an...

[pavlov]

Thanks for the link!

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.

[bernadus_edwin]

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

[lindig]

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.

Edit: I meant to talk about Swift, not Swipe.

[mcintyre1994]

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.

[CHY872]

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.

[asveikau]

> 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.

[lukeh]

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.

[CHY872]

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.

[asveikau]

> 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.

Ah, OK... So you mean if NeXT hadn't based their 1980s effort on GCC, i.e. if there had been a decent BSD-licensed C compiler back then.

It's worth mentioning that this was a long time ago, before a fair number of HN readers were born, and also at a time when GPL vs. BSD licensing likely wasn't as much of a topic as today. Comparing GCC with Clang when we're talking about things that happened in 1988[1] just doesn't seem to make any sense to me.

[1] Per Wikipedia's article on Objective-C, the year that NeXT's GCC changes happened.

[mpweiher]

They probably will do so with Swift in the future, but at present it is much more difficult.

I did a quick summary of the talk, which had a bit more detail, here: https://news.ycombinator.com/item?id=9471204

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.

[lukeh]

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.

[MikusR]

It seems to be in the works as during the Build talk there was a "suit" that kept saying "no comments" when asked about Swift.

[bernadus_edwin]

Since microsoft remake the UIKit, theoriticaly it still support swipe. Well at least you can swipe on ui table view.

[WorldWideWayne]

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.

[supercoder]

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.

[yconst]

A related thought might be, once this is in place, how much work would it be so support Appkit (OS X) apps as well?

[pavlov]

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.

[lukeh]

Indeed. Tell any ex-NeXT person circa 1996 that MS would be effectively building their own OPENSTEP for Windows and no one would have believed you.

Will be interesting see how they implemented it and whether they used Apportable's Foundation (which looks really well written).

[pavlov]

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.

[dep_b]

- Swift uses the same compilers and frameworks

- 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