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).

Can anyone explain in actual meaningful terms?

[mattdm]

I thought it might be just the summary, but I read TFA. What in the world are we talking about here? This is slashdot, not the evening news or something. Is "app slicing" a fancy word for "we only give you the bits you need for your architecture?"

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:Can anyone explain in actual meaningful terms?

[LocalH]

I'm confused about all this.

iCloud Backup doesn't actually back up the app bundles themselves. It only backs up purchase history. When you restore a backup from iCloud, you are essentially redownloading the app bundles from the App Store in the process. This makes me wonder why they can't implement the app slicing functionality in that situation. Unless it has to do with data created by an app that may be missing resources for other devices? Not sure how that would be the case, but I'm not an iOS expert, just a seasoned user.

Source: iCloud storage and backup overview

Your iCloud backup includes information about the content you have purchased, but not the purchased content itself. When you restore from an iCloud backup, your purchased content is automatically downloaded from the iTunes Store, App Store, or iBooks Store.

Re:Can anyone explain in actual meaningful terms?

[Hognoxious]

I did the same, it wanted far too much access to my shit so I bailed.

Even though I didn't complete it I get about 20 spam mails a day.

Pity, because some of the content looks interesting.

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?

[gpoul]

Yes, at least partially. I think the most important component is that you'll only get application resources (like graphics, but potentially others depending on the application) that are required for the device you have. This means you'll not get graphics that aren't even targeted for your device, which is easy and a good thing, because you'll not have resources for retina screens on non-retina devices or vice versa. It basically rips out stuff you'll never need on your specific target device. And as far as I understand it this is not Apple doing magic, but the app developer defining in XCode which resources are targeted at which type of device.

DIsclaimer: I'm not a mobile app developer, I just watched the presentation and demo showing the XCode screens for defining this :)

Re:Can anyone explain in actual meaningful terms?

[wonkey_monkey]

On the other hand, they could not do that, and not decrease their profits by 2%.

What to do, what to do...

Re:Can anyone explain in actual meaningful terms?

[Anonymous Coward]

Apple doesn't do things that were done before. They only invent.

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?

[Rosyna]

Uhm, Apple already buys the majority of the world’s NAND. They buy so much it constrains and chokes the supplies available to other vendors. Do you really think Apple increasing the amount of NAND would be a good thing for non-Apple devices?

Re:Can anyone explain in actual meaningful terms?

[DigiShaman]

Depends on the game and device. For example, the new AppleTV (tvOS) has an imposed limit of 200MB per app. Game developers are supposed leverage ODR . And yes, I know, not likely to be using an AppleTV on an airplane. But the point is that ODR in game development could, in theory, break your gaming stride if an internet connection can't update the dynamic content when needed. But perhaps if you stay in that one level or area, you're fine until an Internet link is established?? I'll leave that up to the game designers to answer if it's doable.

Resource Limitations

There is no persistent local storage for apps on Apple TV. This means that every app developed for the new Apple TV must be able to store data in iCloud and retrieve it in a way that provides a great customer experience.

Along with the lack of local storage, the maximum size of an Apple TV app is limited to 200MB. Anything beyond this size needs to be packaged and loaded using on-demand resources. Knowing how and when to load new assets while keeping your users engaged is critical to creating a successful app. For information on on-demand resources, see On-Demand Resources Guide.

Your app can download the data it needs into its cache directory. Data downloaded will not be deleted while the app is running. However, the data may be deleted while your app is not running and the Apple TV needs the space. Do not use the entire cache space as this can cause unpredictable results.

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.

Re:Can anyone explain in actual meaningful terms?

[windwalkr]

Anecdote:

My previous phone was 16GB. I was coming up against the limits of that device and wanted to upgrade for my next purchase.

I bought my current phone when it was newly released. My carrier had messed up my preorder and I was in a hurry, so I walked into an Apple Store with the intent to purchase. I didn't want the 16GB. I would have been happy with 32GB but of course they don't make them. They didn't have a 64GB in stock of the model I wanted. I walked out with a 128GB.

That's at least one person where the existence (and/or availability) of a 32GB model would have affected 128GB sales.

Re:The problem is the ...

[Daemonik]

If Apple enabled SD cards, how could they expect to keep selling those larger capacity phones at such a markup? SD cards cut into profits, it's why Samsung dropped them from the S6.

Re:The problem is the ...

[Mal-2]

If they did that, they wouldn't be able to force users to upgrade due to limited capacity. Apple is not in the business of selling microSDXC. They sell whole phones. Therefore they will do what they can to make sure people keep buying whole phones.

Re:...exFAT patent

[MtHuurne]

As much as I dislike exFAT because of the patent situation, I don't think this is the reason: iPhones have never had SD slots, not even before 64GB cards were available.

Re:Sheesh

[PopeRatzo]

But let me be frank - this is so goddamned fscking ridiculously friggin stupid that only a true idiot would think it was remotely an intelligent idea. Memory is cheap, so what kind of retard would want to store their applications in the fail-inevitble cloud bubble?

Think about it. You bought an app. You think you own an app. But you just get the parts that Apple thinks you need right now, not the whole app.

It's a brilliant late-capitalist business strategy, really. Keep a wall between your customers and the stuff your customers think they bought. And now you control the gate.

I guess this is why, when I updated my wife's iPad to OS9.1, it insisted so hard that she have an iCloud account. And I do mean "insisted", as in "certain features of your device will not work without an iCloud account" and, "Are you SURE you want to continue without connecting to iCloud?" and "DANGER WILL ROBINSON, YOU ARE ABOUT TO MAKE THE BIGGEST MISTAKE OF YOUR FUCKING LIFE IF YOU DON"T GET YOUR iCloud ACCOUNT!"

Fuck off, Apple. This iPad has 64gig of memory, and it doesn't need your app baloney slicer.

Live by the cloud, die by the cloud.

[sethstorm]

Perhaps higher capacity and SD cards aren't a bad idea after all. They don't die if your provider goes south.

Re:Sheesh

[BronsCon]

Certainly, though I doubt you'd find drivers for the VGA adapter. I've had 2 SSDs attached via a hub before, to copy files between them, worked fine. A bit slower than optimal, being USB2, but it was enough to get my buddy's laptop working again without another PC handy.

Re:Oh dear god no ...

[Princeofcups]

Are they seriously thinking about a scheme in which your device is like needing to have virtual memory? And your device has to "page out" parts of it?

So basically they're morons who think everybody has unlimited data and they can keep re-downloading the same shit all the time?

What a stupid damned feature.

Please reread the feature. I do not think you are understanding what they are trying to do, which actually does make some sense. Although it is a pretty lame excuse to keep selling a phone with 16GB.

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:The problem is the ...

[rjstanford]

Actually, your app images aren't part of your iCloud backup. They get re-downloaded separately after the fact. The vast majority of space taken up by peoples backups are pictures.

Re: App slicing?

[rjstanford]

even if your app and another app use the same version of the same library both need their own copy and you can't upgrade just the library. (Delta updates? What are those?)

The cost of that approach is a relatively small amount of memory (after all, most applications don't share most non-system things with most other applications). The benefit of that approach is never, ever experiencing DLL conflicts, and having the capability to have single-package applications that don't even need to have an installer for the most part. It turns out to be a pretty good tradeoff.