[Entalpi]

"Xcode 7 has a ENABLE_BITCODE option to embed bitcode in apps, app extensions, and frameworks. The option is turned on by default for iOS and is mandatory for watchOS projects submitted to the store.

When bitcode is enabled for a target, all the objects, static libraries and user frameworks used when linking that target must contain bitcode. Otherwise, an error or a warning will be issued by the linker. (Note: missing bitcode is currently a warning for iOS, but it will become an error in an upcoming beta release of Xcode 7.) ENABLE_BITCODE should be consistently turned on for all the targets. If you use a library or framework provided by a third party, please contact the vendor for an updated version which contains bitcode."

Dear God, do we need to wait for all libs to update? :S

[nekitamo]

Agreed, this is an insane requirement. Our app uses commercial libraries from closed source vendors, some of which are no longer distributing newer versions of their libraries. If this becomes a requirement, we will not be able to ship our app because we can't deliver the entire thing in bitcode.

[beagle3]

> Our app uses commercial libraries from closed source vendors, some of which are no longer distributing newer versions of their libraries

This is the insane part - you're relying on things you have zero control over and zero support for. Apple's requirement is no different than some fatal bug discovered or backdoor discovered in those libraries - except Apple is giving you some notice without immediately putting the liability on you.

[72deluxe]

I would agree. They're relying on things they don't have control over. That's bad.

[0x0]

That's not so much of a bitcode problem as a vendor problem. You'd have the same issue when 64bit builds became mandatory, or when uidevice.uniqueIdentifier was banned.

[0x0]

Wow, that's quite a change! Is this some kind of intermediate LLVM language? Sounds very Java/.NET-like. I can see how it's nice for future proofing (i bet you can even change from ARM to x86 then!), but you're handing a lot of control and probably something much closer to the original source code over to Apple.

Is there a fundamental change of architecture planned for future iOS devices?

[Someone]

http://llvm.org/docs/BitCodeFormat.html. Way closer to assembly than Java/.NET byte codes. Also potentially processor specific.

My guess is that it is future-proofing towards running iOS apps on Mac OS and/or running (parts of) iOS apps on the Apple Watch. It also might mean that Apple plans to make their own ARM extensions (for example, I suspect having the CPU know about tagged pointers, so that an 'add' instruction can do an indirection, if needed, might be an overall win)

Update: the release notes for the Xcode 7 Beta say:

"• Bitcode. Archive for upload to the App Store in an intermediate LLVM binary representation that the store can then optimize into the 64 or 32-bit executable to be delivered to customers."

This falls under a feature they call 'App Thinning'. It makes the App Store optimize an app for the device it gets installed on, CPU-wise and asset-wise, and also allows your app to download some resources on demand.

[grrowl]

> also allows your app to download some resources on demand.

Oh boy; if this is the start of apps lazy-loading resources and code, I'm really excited. It's the largest barrier to signing in your account from any device.

[coob]

There's new higher level stuff for downloading assets on the fly from the App Store, check out the new NSBundleResourceRequest class.

[0x0]

Oh ok. So would you need two sets of bitcodes to target ios32 and ios64? A lot of fundamental types like CGFloat have different sizes...

[coldtea]

Would iOS32 be supported at all?

[0x0]

They say iOS9 will support iPhone4s so it must be?

[terhechte]

Along those lines, John S. just tweeted "<whisper>ARM Macs…</whisper>" [1], which is interesting, as he also got the Open Sourcing of Swift right a couple of days ago.

[1] https://twitter.com/siracusa/status/608029277963972608

[0x0]

Interesting, although the open sourcing of swift feels more obvious than arm macs. Bitcode and app thinning are currently ios+watchos only. I think it sounds more likely for ios and especially the watch changing architectures in the future rather than a non-x86/64 osx. But I'm probably wrong.

What would be the selling points for an ARM MAC? Access to the iOS app store software library? (unlikely) Better battery usage? (maybe) Super cheap devices? (un-apple-like)

Changing archs has been done before but I don't see a rosetta for intel apps running smoothly on arm. Virtualizing windows and linux is another killer app for intel macs that would be missed for some.

[jfb]

You're giving up a lot of performance for that battery life, however, and I think it's probably premature to even think about ARM Macintosh for three years at the least, if ever.

[cerberusss]

You control the whole tech stack thus a good selling point would be a longer lasting battery.

Perhaps it's also a shot in front of Intel's bow.

[pjmlp]

Apple is just following Microsoft footsteps.

http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and...

https://msdn.microsoft.com/en-us/library/dn584397%28v=vs.110...