Build Windows apps from your Objective-C code(dev.windows.com) |
Build Windows apps from your Objective-C code(dev.windows.com) |
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...
Here's more info: http://www.slashgear.com/video-project-astoria-microsofts-an...
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.
Edit: I meant to talk about Swift, not Swipe.
Now the tables are turned, and Microsoft is building an "iOS Yellow Box" of their own.
It's a sad route to follow, if you truly care about your users.
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.
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.
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.
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.
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.
It's more about compatibility with an existing ecosystem than copying.
>It's more about compatibility with an existing ecosystem than copying.
Wink, wink. Right.
Will be interesting see how they implemented it and whether they used Apportable's Foundation (which looks really well written).
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
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.
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.
Another interesting thing is Apportable's Foundation implementation, it's really nice and is LGPL'd. I wonder if MS licensed that.
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.
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.
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.