Apple Admits iCloud Problem Has Killed iOS 9 'App Slicing'

Mark Wilson writes: One of the key features of iOS 9 — and one of the reasons 16GB iPhones were not killed — is app slicing. This innocuous-sounding feature reduces the amount of space apps take up on iPhones and iPads... or at least it does when it is working. At the moment Apple has a problem with iCloud which is preventing app slicing from working correctly. The feature works by only downloading the components of an app that are needed to perform specific tasks on a particular device, but at the moment regular, universal apps are delivered by default.

Comments

It's delayed, not dead

[dugancent]

Nothing has been killed. Enough with the hyperbole.

Re:It's delayed, not dead

[khchung]

Nothing has been killed. Enough with the hyperbole.

I guess you would have noticed by now. After a new iPhone release in Sept every year, there would be a slew of these hyperbole troll pieces in the media to try to lure more readers by riding the iPhone bandwagon, and /. is no different.

And we have been lured in just as expected.

Re:It's delayed, not dead

[macs4all]

It sounds like a pretty interesting feature, actually, once you get past the "Haha, iOS 9 is a failure!" tone of the summary.

Back in around 1980, I created a system for "Slicing" Applesoft BASIC programs for the Apple ][, to work-around another developer creating a program that was so large, that Applesoft spent pretty much its entire time doing Garbage Collection, because there was so little free memory left. Since it was WAAAAY too late in the Project to completely re-factor and re-write the code, I created a "Segment Loader" for Applesoft.

The idea was that you could take any Applesoft program, and pretty much just divide it up willy-nilly into smaller "loadable segments". And as long as you didn't do something completely stupid, like split the program in the middle of a tight looping structure, it worked a TREAT. It could load about 8 kB/sec off of floppy (which meant that most of the time, the segment-loading delay was only around a second), and with a Corvus hard disk, the User couldn't even tell it had loaded another segment. And, unlike the typical method of "at a Menu, RUN a separate Program for each Menu Item", the Applesoft Variables were RETAINED (and even moved in memory if the segment-being-loaded was larger than the one being "vacated").

The system, which I called "Overlayer", worked through Applesoft's wonderful "&" Hook through the ONERRGOTO vector, and when my code was called, it would analyze what the error was, and if it was a "Line Not Found"-type Error, it would look back to see what line it was, then consult a Table of which line-range was in which "Segment", and then load that segment of code, readjust the memory fences, then "rewind" the execution pointer to the beginning of the statement causing the error, then RESUMEd. Applesoft then executed the (now) good statement, and went on its merry way.

Without seing that part of last week's Keynote, or any of the Developer docs for the iOS feature, I would bet that this (sort of) works the same way (although probably much more formalized than using a simple ONERRGOTO hook).

Re:Can anyone explain in actual meaningful terms?

[DigiShaman]

https://www.quora.com/What-is-...

Hello,

What Apple listed as one feature is actually three separate mechanisms, each playing its own part in reducing app size.

The primary mechanism – App Slicing – is the one that does most of the work. Because apps need to run on a variety of devices, from the 3.5-inch iPhone 4 to the 5.5-inch iPhone 6 (or 10-inch iPad, for universal apps), they contain separate assets for each of those devices – most of which your device doesn’t need.

With App Slices, developers tag assets by device, and when you download the app from iTunes, it will only download the assets your device needs. Apple has made this process pretty simple for developers, so it’s likely that many will support it.

On-Demand Resources (ODR) is the second way to reduce app sizes. ArsTechnica gives the example of multi-level games, where you typically only need the level you are playing plus the next few levels up. ODR means you can download the game with the first few levels included. As your play progresses, the app downloads extra levels and purges the levels already completed.

Finally, Bitcode. Instead of uploading pre-compiled binaries, developers upload what Apple calls an “intermediate representation” of the app. The App Store then automatically compiles the app just before downloading. This allows it to automatically implement part of App Slicing even if the developer hasn’t bothered to tag their code, downloading only the 32- or 64-bit code as required.

-Bin Sand

Re:Oh dear god no ...

[Sqr(twg)]

Nope. That's not what this is. It's about not downloading stuff you don't need, like the iPad-size bitmaps when using an iPhone.

Re:Can anyone explain in actual meaningful terms?

[gnupun]

It'll decrease your profit by less than 2%.

Are you sure about that? It'll increase their cost by a percent or two, but the profits will drop a lot as the 32 GB and higher models are priced over $200 than the 16 GB models.

If a 32GB model existed, 64GB and 128GB sales would be a lot lower, decreasing overall profits by 20-30%. Therefore, this price gouging will continue for the foreseeable future where downloading a couple of 3D games will consume all your flash space in the 16GB model. So you're forced to buy 32GB and higher.

Re:Can anyone explain in actual meaningful terms?

[Rosyna]

The description of bitcode’s purpose is just a bit wrong.

Bitcode is designed to remove the requirement of needing multiple architecture slices for architectures that are just slightly different. For example, when the iPhone 5 came out it supported an “ARMv7s” ISA. This added a few new instructions to ARMv7 like integer divide to increase performance. However, in order for developers to take advantage of it, their app had to have executable code slices for both ARMv7 and ARMv7s, increasing binary sizes. Furthermore, it required every library ARMv7s code linked to also have an ARMv7s slice.

This quickly became a pain in the ass and ARMv7s was dropped in Xcode 6.

Bitcode would address this issue. A developer would compile their app to Bitcode (a specific type of LLVM IR) and then Apple would later compile it fully into the target ISA.

This is especially relevant for ARMv8 as ARMv8.1 is the latest version with slight changes.

Re:Can anyone explain in actual meaningful terms?

[sribe]

If a 32GB model existed, 64GB and 128GB sales would be a lot lower, decreasing overall profits by 20-30%.

That's some pretty fuzzy thinking. I bet that the existence of a 32GB model would not affect 128GB sales by even 1 single phone.