Hi All--
I have read through a lot of documentation about the App Thinning feature of "Slicing", and I keep seeing conflicting information. I think the following is true:
This sounds right to me, but I am looking for some confirmation that it is correct. Let me know if you have seen this happen, or have a different impression.
Will
From everything I have read, Slicing has nothing to do with Bitcode.
If you don't use Bitcode, you will build a binary with all the architectures. When delivering it to someone running iOS 9, Slicing in the App Store will deliver only the architecture in the binary that they need.
If you use Bitcode, you will upload the Bitcode representation. Apple will compile that into binary for each architecture, and when delivering it to someone running iOS 9, Slicing in the App Store will deliver only the architecture that they need.
I have a weird feeling that nobody really knows how exactly it is going to work except for Apple.
Judging by the documentation currently available bitcode is not needed for binary slicing. It is only needed for future proofing of your builds (in case if a new architecture becomes available).
However, judging by the way how slicing currently works in Testflight with iOS 9 builds, it is actually the opposite. Your assets are always sliced, however, your beinary will not be sliced unless it is uploaded with bitcode.
>Your assets are always sliced, however, your beinary will not be sliced unless it is uploaded with bitcode.
Right, the store is effectively already slicing, but I think your statement is a good summary going forward.
It also look like iOS8 is slicing assets in TestFlight, are you seeing the same thing?
Will
I thought the idea was to create intermediate bytecodes for unspecified future architectures, so that developers would not have to generate new binaries whenever a new device or architecture is released. That's good for Apple, since it means millions of old binaries "just work", (simplifying the approval process, among other things), and it's good for [a lot of] developers who don't want or require the maintenance headaches of supporting multiple configurations.
Maybe i'm confused, but doesn't app thinning also mean apple will only be pushing down architecture-specific (armv7 for iphone 5, arm64 for iphone6, etc) binaries to end users? That most certainly would require bitcode....
>also mean apple will only be pushing down architecture-specific
The app store has already been doing that for a while now as I understand it. 'App Thinning' is just a different means to the same end.
What does that have anything to do with Bitcode? The developer has always been buiding all the architecture-specific binaries, and then storing them into one FAT binary file.
Interesting bit of info from Apple on this today:
"App slicing is currently unavailable for iOS 9 apps due to an issue affecting iCloud backups created from iOS 9 where some apps from the App Store would only restore to the same model of iOS device.
When a customer downloads your iOS 9 app, they will get the Universal version of your app, rather than the variant specific for their device type. TestFlight will continue to deliver variants for your internal testers. App slicing will be reenabled with a future software update. No action is needed by you at this time."
Meaning that they have to figure out how to re-download the app with the appropriate slice after you've upgraded a device, since presumably what's being restored is an incompatible slice that will not run on the new architecture? Interesting problem.
Seen the Xcode 7.0.1 update yet?
"Fixes bugs related to app thinning..."
