
Build Windows apps from your Objective-C code - yconst
https://dev.windows.com/en-US/uwp-bridges/project-islandwood
======
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](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...](http://blog.neonto.com/2015/04/29/android-is-the-new-
win32-the-new-java-and-the-new-flash/)

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

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

------
kyberias
When I shared a link to this article in Facebook, Facebook recommended this
"related link":

[http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

~~~
Devid2014
Is this not something that Google is truing to do with Android ?

~~~
kyberias
I've never thought about it. My answer is no.

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

~~~
FreakyT
Source? I didn't think they had released any example screenshots of
"converted" apps yet.

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

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

~~~
lukeh
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).

------
mhuffman
Microsoft has been on a tear lately! I am really impressed with the direction
they are going.

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

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

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

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

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

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

~~~
jfuhrman
Would you say the same for WINE or ReactOS? Or Pages, OpenOffice and Google
Docs 'copying' the docx format? Samba and SMB?

It's more about compatibility with an existing ecosystem than copying.

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

Wink, wink. Right.

