Slashdot Mirror
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.
> Finally, Bitcode. Instead of uploading pre-compiled binaries, developers upload what Apple calls an âoeintermediate 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â(TM)t bothered to tag their code, downloading only the 32- or 64-bit code as required.
That will bring up a nice amount of Heisenberg bugs.
bash$
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).