So is this just LLVM IR?

johntb86 · on June 9, 2015

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 · on June 9, 2015

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?

nekitamo · on June 9, 2015

Yep. I hope they leave this optional for iOS, as we use some proprietary libraries which we don't think the vendor will ship a new version of :(

pgeorgi · on June 9, 2015

You may get by with a decompiler as laid out in http://llvm.org/devmtg/2013-04/bougacha-slides.pdf

And since you'll certainly not be the only one with that problem, Apple making it mandatory for iOS would probably spur development in that area.

ponytech · on June 9, 2015

I am not so confident : they now require that you ship a 64 bits version of your apps, which can be also be a problem if you use 32 bits only proprietary libraries.

coob · on June 9, 2015

There's a good reason for that requirement. Loading 32bit apps on a 64but device requires loading all the 32bit version of shared libs, massively increasing the memory footprint.