

Bitcode (iOS, watchOS) - comex
https://developer.apple.com/library/prerelease/watchos/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html#//apple_ref/doc/uid/TP40012582-CH35-SW2

======
arcticbull
In case y'all are curious it would make sense if this is LLVM bitcode:
[http://llvm.org/docs/BitCodeFormat.html](http://llvm.org/docs/BitCodeFormat.html)

Seems like a very smart way to keep things binaries up to date without
developer intervention -- and possibly even allow re-targeting to different
CPU architectures after the fact. That would eliminate the need for something
like Rosetta if Apple ends up switching major CPU architectures again some
day.

I really think that LLVM is one of the best things to happen to computer
science in a long, long time.

~~~
hamstergene
I remember a letter from some time ago saying that LLVM IR format is private
to specific version of LLVM, and is not guaranteed to be compatible with other
versions in the future or in the past. Does this announcement mean that is not
the case anymore, and LLVM IR is backwards compatible now?

~~~
bsurmanski
LLVM is a great tool, but I've had trouble in the past with version
compatibility. I wrote a compiler that used LLVM as a backend (I used LLVM
versions 3.4-3.6). The problem was that each minor version of LLVM slightly
changed the API. It was things like removing parameters from methods, renaming
methods, removing the need for some methods completely, or adding/removing
some static-link libraries. If you only wish your tool to be compatible with a
single version of LLVM, its not a problem, but attempting to support a
selection of minor versions ended up being a pain. These minor versions would
come out 3-4 times a year and I would need to find what broke each time, and
if there was even an equivalent solution in the new version.

I didn't work on the level of IR, so I didn't come across any problems there,
but I wouldn't be surprised if the IR syntax changed slightly across minor
versions.

~~~
legulere
I guess you used the C++ API? There's a C language subset available that has
way more stability.

------
CrLf
So Apple is following following the footsteps of IBM, huh?

[http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set](http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set)

~~~
pjmlp
Everyone is.

I got to understand better the whole concept of having a bytecode format for
executables, with JIT/AOT deployment options when I started delving into the
old mainframe world.

I used to do AS/400 backups, but never coded for it. So it was quite
interesting to discover the all TIMI concepts.

Also other similar environments like the Burroughs B5000.

The old is new again. :)

~~~
sudioStudio64
That's true...MS has been doing this for phone and windows store apps (the few
that there are) that are written in .Net to improve performance. The get AOT'd
from CIL to target binary when uploaded to the store.

I wonder why this isn't bigger in the FOSS world...maybe because the source
and toolchain are already available...I don't know, it might be a neat idea to
have an IR userland that compiles on install.

------
unsigner
They seem to be preparing for something in the 2-5 years timeframe, but what?

Least grandiose theory I can come with: two ARM cores in the Watch, one big,
one small, with different instruction sets, for active/standby modes.

~~~
jkestner
They're preparing for anything. Apple has a dislike for relying heavily on any
partner in their DNA, thanks to PowerPC.

~~~
TazeTSchnitzel
Not just that. Apple also switched from 68k to PowerPC.

~~~
jkestner
True, though nominally the same partner. Motorola was the M in AIM, though
yes, IBM did the heavy lifting. (Remember Motorola made a Mac clone? How
weird.) And the situation wasn't as dire then.

------
fra
This is going to spell the end of all 3rd party crash reporting tools.

~~~
jrazavian
I'm not sure I understand what you are implying. How so?

~~~
chedabob
Possible issues with symbolicating the crash logs if you don't have the debug
symbols as they're generated on Apple's side.

------
th0br0
I'm honestly surprised that noone has commented on the security implications
of this, yet. After all, allowing Apple to recompile your "bitcode"
essentially means, that the user can in no way validate that the version he's
running is the version the developer published. It would be fairly
straightforward to perform MITM attacks on apps this way. (And, sure,
Android's APKs are faced with quite the same issue - but AFAIK Google doesn't
modify your bytecode (yet?))

~~~
0x0
They could already do that. They sign and encrypt the (plaintext) code segment
you submit so they could easily insert a JMP to their own payload at the head
of your code any time

~~~
vbezhenar
Why do they encrypt code segment? Signature is essential, of course, but
encrypting looks unnecessary.

~~~
0x0
It's their fairplay DRM implementation that is supposed to prevent piracy.

------
freewizard
If to put Swift on Linux and Bitcode together, I'd take a wild guess that an
apple powered PaaS is on its way.

~~~
tomwilson
They kind of have that already with CloudKit - it's not suitable for all use
cases though.

~~~
Osmium
They've just announced a major new addition to CloudKit though to basically
allow integration into CloudKit via web apps, which seems like a pretty big
deal.

------
m_mueller
I'm thinking that Apple sees a new threat to their mobile (profit) dominance:
Fully portable Mobile+Desktop OS enabled through Core M, i.e. Windows 10.
"Bitcode" is them preparing to unify their OSes just in case Win10 is
successful and buyers suddenly want to have one device to rule them all (i.e.
MS Continuum). This could very soon be a reality - and Apple seems to be
preparing themselves. Smart move [1].

[1]
[http://img2.wikia.nocookie.net/__cb20130701185217/jurassicpa...](http://img2.wikia.nocookie.net/__cb20130701185217/jurassicpark/images/e/e3/JP1_VelociraptorCurtain.jpg)

~~~
Sanddancer
My thought is more that they are going the Android route of using an
intermediary bytecode, to get both platform independence, but on-device
compilation for performance. If they can push hardware that will automatically
run faster, that makes it all that much easier to sell new product.

~~~
m_mueller
Yes, I didn't mean Apple is going the MS route from a technical point of view,
just the timing of their platform independence efforts leads me to believe
that it has to do with pressure (or the potential thereof) by Microsoft.

------
goatforce5
John Siracusa tweeted a rumor yesterday speculating/hinting at ARM Macs.

[https://twitter.com/siracusa/status/608029277963972608](https://twitter.com/siracusa/status/608029277963972608)

How fast are the fastest ARM chips compared to the lower-end Intel chips?
Could we see low-powered Mac Airs with long battery lives?

------
advanderveer
I find it interesting this hasn't gotten as much attention as other
announcements. It seems to hand over a great deal of responsibility to Apple,
at least in terms of performance. Something some might feel comfortable with
or not. I can imagine this lack of control about what instructions will
actually run on the hardware might not fair well with some developers?

~~~
pjmlp
Most likely, however this is already being done in the other mobile platforms.

~~~
nly
Not really, you can ship native code on Android and, for Java apps,
intermediate bytecode is delivered to end-user phones, not compiled in the
cloud.

~~~
pjmlp
Windows Phone 8:

[http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-
and...](http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-
Sollich-Inside-Compiler-in-the-Cloud-and-MDIL)

Windows Phone 10:

[http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-
Native](http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native)

As for Android, having ART on the phone is technicality, given the platform
fragmentation Google rather leaves to the OEMs the task of making ART
generating the proper code.

------
js2
This will affect crash reporting and symbolication. Presumably Apple strips
debug symbols when they compile. Will they make the dsyms (DWARF containing
files for stripped mach-o binaries, necessary to symbolicate crash reports)
available somehow? If not, third parties (or anyone who chooses to handle
their own crash reports directly) are in trouble.

------
ubercow
So is this just LLVM IR?

~~~
johntb86
I'm curious how that works. LLVM bitcode backwards/forwards compatibility is
quite poor, from what I've heard. Will they fix some bitcode version to
transmit, and have translators on the client/server sides? Have a bunch of
different toolchain versions on the server side? Force everyone to resubmit
with a newer version if they want to do any changes on the server side?

~~~
joosters
Presumably the backwards/forwards compatibility is poor simply because people
don't tend to have these files sitting around, they mostly exist (at the
moment) as part of a compilation framework and are tempfiles.

If needed, it wouldn't be too for someone with a few programmers (Apple could
spare a few!) to write the proper versioning to upgrade/downgrade the file
format as LLVM changes?

------
sudioStudio64
That's really cool.

I like that idea in general. The other day I was reading about OS/400 on
wikipedia. It always used an intermediate bytecode...and because of it they
were able to seamlessly (who know how seamlessly) from architecture to
architecture.

------
mirekrusin
Doesn't it open doors for proprietary LLVM optimisations hidden from others?

------
TD-Linux
So, is there any actual documentation of this anywhere?

~~~
Someone
[http://llvm.org/docs/BitCodeFormat.html](http://llvm.org/docs/BitCodeFormat.html)

------
pjmlp
Interesting to see Apple is following Microsoft (MDIL, .NET Native) footsteps.

~~~
coldtea
Is there any substantial new technology a major company gets that another
competing company wont try to match sooon?

~~~
pjmlp
Yeah, but the funny thing is how Apple's AOT compilation toolchain was being
discussed by some Apple fans as the way to go.

Now they turn around and follow what the others are doing.

~~~
coldtea
It still is AOT. There's just an intermediary step, which is what you send to
Apple, but the code is compiled in its servers, not in the runtime.

It's not like LLVM doesn't have several steps already in its pipelines.

~~~
pjmlp
I guess you don't know how MDIL and .NET Native work.

~~~
coldtea
Not sure where you're getting at.

Like Apple's .NET Native is AOT.

Like Apple's .NET Native compiles to native code in the server.

It's your comment that gave the impression that you thought Apple's new
bitcode thing is not AOT and that they follow MS in this not-AOT-ness.

It might not have been what you meant, but it's not very clear from the
phrasing:

> _" (...) Apple's AOT compilation toolchain was being discussed by some Apple
> fans as the way to go. Now they turn around and follow what the others are
> doing"_

This reads like Apple had an AOT compilation toolchain that Apple fans thought
it was "the way to go" and now Apple dones't have one (AOT compilation
toolchain) anymore following MS lead in this regard.

Whereas what you actually meant was probably that Apple fans thought that
Apple's PREVIOUS AOT compilation toolchain was the way to go, but now they've
changed course and went for an MS style AOT compilation toolchain.

(it read like you think "Apple's AOT toolchain" was a thing of the past, and
not they follow MS which doesn't have AOT).

~~~
pjmlp
> Whereas what you actually meant was probably that Apple fans thought that
> Apple's PREVIOUS AOT compilation toolchain was the way to go, but now
> they've changed course and went for an MS style AOT compilation toolchain.

Exactly.

~~~
coldtea
Yeah, took me a while to get it can mean that, I think the straightfoward
reading is the other one.

~~~
pjmlp
Well, not native speaker here. :)

