6 ms·

"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 w

by Entalpi 11y ago

"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

0x0 11y ago
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?
- terhechte 11y ago
  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 https://twitter.com/siracusa/status/608029277963972608
  - 0x0 11y ago
    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 11y ago
      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 11y ago
      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.
- Someone 11y ago
  http://llvm.org/docs/BitCodeFormat.html 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.
  - 0x0 11y ago
    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 11y ago
      Would iOS32 be supported at all?
      - 0x0 11y ago
        They say iOS9 will support iPhone4s so it must be?
  - grrowl 11y ago
    > 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 11y ago
- pjmlp 11y ago
  Apple is just following Microsoft footsteps. http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and... https://msdn.microsoft.com/en-us/library/dn584397%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/dn584397%28v=vs.110...
nekitamo 11y ago
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.
- 0x0 11y ago
  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.
- beagle3 11y ago
  > 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 11y ago
    I would agree. They're relying on things they don't have control over. That's bad.

by Entalpi 11y ago

0x0 11y ago

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?

terhechte 11y ago
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 https://twitter.com/siracusa/status/608029277963972608
- 0x0 11y ago
  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 11y ago
    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 11y ago
    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.
Someone 11y ago
http://llvm.org/docs/BitCodeFormat.html 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.
- 0x0 11y ago
  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 11y ago
    Would iOS32 be supported at all?
    - 0x0 11y ago
      They say iOS9 will support iPhone4s so it must be?
- grrowl 11y ago
  > 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 11y ago
pjmlp 11y ago
Apple is just following Microsoft footsteps. http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-Sollich-Inside-Compiler-in-the-Cloud-and-MDIL http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and... https://msdn.microsoft.com/en-us/library/dn584397%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/dn584397%28v=vs.110...

nekitamo 11y ago

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.

0x0 11y ago
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.
beagle3 11y ago
> 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 11y ago
  I would agree. They're relying on things they don't have control over. That's bad.