Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Bug Cloud IOS Iphone Apple

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by dugancent ( 2616577 ) on Thursday September 24, 2015 @10:01PM (#50593931)

    Nothing has been killed. Enough with the hyperbole.

    • by khchung ( 462899 ) on Thursday September 24, 2015 @11:02PM (#50594219) Journal

      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.

      • by Skater ( 41976 )
        It sounds like a pretty interesting feature, actually, once you get past the "Haha, iOS 9 is a failure!" tone of the summary.
        • by macs4all ( 973270 ) on Friday September 25, 2015 @01:24PM (#50598639)

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

    • I agree that App Slicing is interesting, but I don't really agree with their premise on the 16GB phones. A 16GB phone is still crippled these days. Do customers want an iPhone that has so little storage for music and photos, and isn't upgradable?

      Sure, Apple will say "but you can store all your photos and music in iCloud". But that's hardly an option as wireless carriers continue to try to drive down data usage with data caps, throttling, and exorbitant overage charges.

      I like the Apple platform and I will st

      • Re: (Score:2, Insightful)

        by macs4all ( 973270 )

        I agree that App Slicing is interesting, but I don't really agree with their premise on the 16GB phones. A 16GB phone is still crippled these days. Do customers want an iPhone that has so little storage for music and photos, and isn't upgradable?

        Sure, Apple will say "but you can store all your photos and music in iCloud". But that's hardly an option as wireless carriers continue to try to drive down data usage with data caps, throttling, and exorbitant overage charges.

        I like the Apple platform and I will stick with it, but it's a bad business decision to herd people into 16GB phones they are going to be less than happy with.

        Nobody is "herding" anyone into a 16 GB phone, as there are memory options up to 128 GB. But for a LOT of (non-Slashdot) readers, 16 GB really IS ok, and this lets Apple keep a low-end model that will appeal to a lot more people than you would imagine.

        I am sure that Apple "ran the numbers", and figured that, even without App Slicing (which only affects a much-smaller group of "Those who want a cheaper phone; but still want some Apps"), that a 16 GB model was attractive.

        Conversely, they also saw that, fo

        • by KGIII ( 973947 )

          I have a rather fairly new and fancy smart phone (but it is Android - I'm not a fan of iOS). I have just checked - and this is after having it for a few months and being on the road for a while doing my typical 'wanderlust' - I have four pictures and 37 seconds of video. I have four applications installed. I did not check but I believe there's a microSD card in there with another 128 GB of space on it and I think the phone came with 128 GB but I'd have to double check and I am lazy.

          So, yeah, I could easily

  • by mattdm ( 1931 ) on Thursday September 24, 2015 @10:08PM (#50593967) Homepage

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

    • by DigiShaman ( 671371 ) on Thursday September 24, 2015 @10:20PM (#50593991) Homepage

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

      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: (Score:2, Interesting)

        by MavEtJu ( 241979 )

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

        • by Rosyna ( 80334 ) on Friday September 25, 2015 @05:14AM (#50595313) Homepage

          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.

          • by Rosyna ( 80334 )

            Err, I forgot to mention Bitcode is extraordinarily sensitive to the target ABI. So a single Bitcode file cannot be used to compile to both 32-bit and 64-bit, the ABIs re just way too different.

      • Dear Apple,

        You're making $252 profit per iPhone ($18.8 billion / 74.5 million phones [appadvice.com]). Quit playing these stupid games and just pay the damn $4.70 for an extra 16GB of NAND [trendforce.com] to bump up the base model to 32GB. It'll decrease your profit by less than 2%.
        • by gnupun ( 752725 ) on Friday September 25, 2015 @03:01AM (#50594905)

          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.

          • by sribe ( 304414 ) on Friday September 25, 2015 @10:01AM (#50596497)

            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.

            • 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

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

          What to do, what to do...

          • by AmiMoJo ( 196126 )

            You have to weigh the cost of developing and supporting these features and the extra sales that would be gained by bumping up to a 32GB base model, against the cost of the extra flash memory and the number of people who would pay for the overpriced upgrade.

            I guess Apple must have decided that the latter is slightly more that the former, and screw giving the customers a better device.

            • You have to weigh the cost of developing and supporting these features and the extra sales that would be gained by bumping up to a 32GB base model, against the cost of the extra flash memory and the number of people who would pay for the overpriced upgrade.

              I guess Apple must have decided that the latter is slightly more that the former, and screw giving the customers a better device.

              Or possibly, maybe, JUST maybe, they figured that they could improve two systems at once (iPhone and AppleTV) by giving their Customers what amounts to Cloud-based Virtual Memory; so instead of 70% of Customers having to pay a couple of hundred dollars more for a 32GB phone "Just in case 16 GB isn't enough" (which, incidentally, but importantly, could cause unknown numbers of those Customers to choose a cheaper Android phone instead), instead they made it so you could essentially have more-or-less infinite

        • by Maritz ( 1829006 )
          In other words, it will decrease the profit by more than 0%. Unacceptable. ;)
        • by Rosyna ( 80334 )

          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?

        • by Lumpy ( 12016 )

          YOU are assuming corporations and Executives are honest entities with compassion and a sense of right.

          Reality is they hate honestly, they hate being forced to follow laws, and All of them act this way. If samsung was honest they would bump up all their models without a price change. All the phone makers are eliminating memory expansion, Google even disabled most of the access to it under Android so now you have to hack the OS to use it completely. Samsung gleefully got rid of the micro sd slot.

          They al

        • by GuB-42 ( 2483988 )

          The decision not to make the base model 32GB is a commercial one, probably driven by market segmentation. The idea, I think, is that 16GB is good enough for casual users but advanced users would need at least 32GB. They also know that the latter have a bigger budget, so, by not offering the best compromize, they can more easily target each group. The 128GB model is the high anchor. That's basic marketing.
          Now for the technical side. Finding ways to reduce the app size is a good thing. And it would still be a

      • by hughbar ( 579555 )
        ODR sounds very like overlays: https://en.wikipedia.org/wiki/... [wikipedia.org] used in the 1970s on mainframes. Back to the future.
        • Re: (Score:2, Funny)

          by Anonymous Coward
          Apple doesn't do things that were done before. They only invent.
          • Apple doesn't do things that were done before. They only invent.

            Just like Anonymous COWARDS don't regurgitate the same, tired Apple-hating memes. They only have original thoughts.

            Come out and expose your Karma like a man, or GTFO.

        • ODR sounds very like overlays: https://en.wikipedia.org/wiki/... [wikipedia.org] used in the 1970s on mainframes. Back to the future.

          And not just mainframes. Back in the day, I saw a business that ran on a PDP-8 minicomputer about the size of an IMSAI 8800 (as seen the movie War Games) with 4 KB of RAM supporting (IIRC) 10 concurrent users, and the business' custom-built COBOL-based ERP/Accounting software.

          So, as you said, everything old is new again.

      • by DrXym ( 126579 )
        I wish Google would support a universal ABI using bitcode in their NDK. Apps that have native shared libs (i.e. most games) are faced with either bundling up all the libs compiled for each architecture into a single package (bloat), or producing separate packages for each architecture (hassle). And of course if a new architecture comes along, it means repackaging the app again.

        It'd be much nicer to just bundle up a single shared library that was compatible with any architecture. It could be turned into a

    • by Anonymous Coward

      It's not just architecture, it's screen size and resolution. Imagine a game with assets for high-pixel-density screens like Retina, low density screens, big tablet screens, tiny phone screens, etc. That's a lot of space. It sounds like Apple has made it possible for devs to release one game package to the App Store, and in turn the App Store shoves across to the consumer only what assets from that package are needed for the specific device on which it's downloaded.

      • It's not just architecture, it's screen size and resolution. Imagine a game with assets for high-pixel-density screens like Retina, low density screens, big tablet screens, tiny phone screens, etc. That's a lot of space. It sounds like Apple has made it possible for devs to release one game package to the App Store, and in turn the App Store shoves across to the consumer only what assets from that package are needed for the specific device on which it's downloaded.

        Exactly.

        As the owner of a 32 GB iPad 2 with a metric buttload of Apps, I can tell you that, when the "Retina" App-Updates came out, I stopped updating a BUNCH of my Apps, simply because the bigger resources would do absolutely NOTHING for me but eat up a non-insignificant amount of my rapidly dwindling free Flash memory.

        Now, with App Slicing, if I want to update my iPad 2 to iOS 9 (which is possible; suck it, Android!), I can Update those Apps and STILL keep the majority of my free Flash memory.

        And do

    • by Anonymous Coward

      Most likely: With 'app slicing', when you download an app, it downloads only binaries for your exact iDevice model (sliced), instead of a binary for all iDevices supported by that build of the binary ('universal binary').

      Looks like iCloud backup, though, simply backs up the entire memory state and apps as they are on your device ('device A'). Attempting to restore that backup now on another device (device b) will restore the same binaries that were backed up - which is fine if device b and device a would h

      • by LocalH ( 28506 )

        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, ju

        • by Rosyna ( 80334 )

          It may be that the iCloud backup has a bug that backs up the information used for app thinning and uses it on restore when it should not. Instead it should use the architecture information from the target device.

      • As a work-around, Apple have disabled downloading 'sliced' binaries, so instead you download full (universal) binaries. This means the backups will have the universal binaries which will work on any 'device b'.

        Which means that, right now, it's no worse than it was before, and Apple will eventually work out a protocol whereby the Device reports what it is (if it doesn't already), and iCloud delivers the correct "slicing" for that Device. This may actually cause a change in iCloud policy, wherein Apps do not "count" against your iCloud Storage quota (do they now? I don't use iCloud, so I don't really know), and the "slicing" is all done at the iCloud-Delivery-Level.

    • by gpoul ( 52544 )

      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 love Apple.

    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?

    So now we have the always secure cloud giving out our life history (check), the always avalable cloud not providing our applications when we need them. Because everytone is going to have all the internet bandwidth they need, when

    • Re: (Score:2, Insightful)

      by PopeRatzo ( 965947 )

      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

      • Well, GP was not talking about keeping control of stuff customers think they bought, but about the increased risk of that stuff being unavailable through technical difficulties. And I think he is right.

        Downloading only what you need for a certain device I can see working.

        But keeping even part of that stuff on the Cloud and downloading it "on demand" is a recipe for trouble. Connection failures happen, you know.

        • Also the reason $1 for 50GB of iCloud storage is no replacement for an SD card for expanded storage; even ignoring that the SD card will be cheaper over time, if you're not connected or there is a service interruption, your iCloud storage is useless; even if you are connected and the service is up, if your connection is slow or you have a single-digit-GB cap, it's neigh useless anyway.

          My Nexus 6 may lack an SD slot, but it supports USB host mode, so I can plug in an SD reader (micro, mini, full, whatever)
          • Can you plug in a hub then plug in multiple devices? Could you do a usb mouse, usb keyboard, usb drive, and usb vga adaptor?
            • 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.
          • My Nexus 6 may lack an SD slot, but it supports USB host mode, so I can plug in an SD reader (micro, mini, full, whatever), a hard disk, hell I can plug in a keyboard and mouse if I so choose (and yes, Android provides a mouse cursor). I say it's a fair enough trade, as A) it allows the phone to be slimmer and more water resistant and B) it allows a wider range of devices to be used with the phone.

            Since Apple now has a Lightning to USB cable, I wouldn't be at ALL surprised if iOS doesn't support USB Host Mode at this point, too. Actually, it DOES support USB Host Mode, but, from what I am seeing, the issue is POWER. It seems like if the device is parsimonious with power, it can work. I don't know enough about the USB protocol to comment on whether interposing a powered USB hub would help, or even if it would work with iOS.

            And as far as iPads go, there are several aftermarket "Camera Connection Kit"

            • I've had luck with a USB keyboard on my iPad Air, after dismissing several "unsupported device" dialogs. No such luck with mass storage devices and definitely not a mouse. I understand there are some instrument controllers that work, though; I haven't tried my M-Audio gear yet.
      • 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.

        Whoa! I think you need another layer of tinfoil on that hat!!!

        So, Apple comes up with a strategy whereby you can avoid the ever-increasing effects of "App Bloat", by on-the-fly delivering only the pieces-parts of the App that you are actually going to USE at that time, and ALL you can think of is how Apple MUST have some nefarious plan to SOMEHOW fuck you out of the "rest of the App" that will do NOTHING for you but WASTE MEMORY?

        Jeezus, you're sick. STFU.

        • So, Apple comes up with a strategy whereby you can avoid the ever-increasing effects of "App Bloat", by on-the-fly delivering only the pieces-parts of the App that you are actually going to USE at that time, and ALL you can think of is how Apple MUST have some nefarious plan to SOMEHOW fuck you out of the "rest of the App" that will do NOTHING for you but WASTE MEMORY?

          Why doesn't Apple do that "on-the-fly" delivery of only the pieces of the App that I'm actually going to use from the 128gig SD card I put in

          • by Uberbah ( 647458 )

            Oh wait, I think I know the answer to that, macs4all. Never mind.

            Nice sarcasm, but I don't see where it explains why you want binaries for other devices to take up space on your iPad. You're acting as if functionality is being stripped out when that's obviously not the case.

            • You're acting as if functionality is being stripped out when that's obviously not the case.

              If parts of your app are being stored in the "iCloud" and you happen to lose your connection, then functionality is most definitely being stripped out.

    • by MrKaos ( 858439 )

      because the cloud never fails - only we can fail the cloud.

      I failed the cloud once, luckily I wasn't sky diving.

      • because the cloud never fails - only we can fail the cloud.

        I failed the cloud once, luckily I wasn't sky diving.

        Say 20 Hail Cupertino's and a good act of contrition, my son.

        • by MrKaos ( 858439 )

          Say 20 Hail Cupertino's and a good act of contrition, my son.

          I pray in the house of the mountain veiw, I know not of your heathen ways.

    • Amazing my post was modded "Offtopic"

      Looks like even the cloud isn't the cloud.

  • Which is where iphone stability comes from ;)
  • by sethstorm ( 512897 ) on Thursday September 24, 2015 @11:28PM (#50594323) Homepage

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

  • by Anonymous Coward

    just stop charging outrageous prices for flash.

    Or *gasp*, provide a slot for external storage.

    App "slicing" is a ridiculous software solution to a problem that is rooted in greed and stupidity, not real hardware problems.

    • So you believe downloading application resources you will never need is a good idea. Got it.

      • by Anonymous Coward

        Lets see here, download resources you don't need, or come up with an error prone and overly complex solution. Being that I believe all good engineering adhears to the KISS principal, yeah, I believe downloading resources you will never need is a better idea. Even better, if they can separate them so easily, why not just make a phone version and a tablet version and then send you all of the one you need? Even simpler, no need for cloud, wonderful.

      • You assume that a) you'll always be in a situation where you can download things instantly and on demand, and b) that you can decide ahead of time, with perfect accuracy, what you'll need and when.

        For example: I bought, and use, the TomTom app for my iPhone, rather than the built-in maps app. One big reason? It's all there, predownloaded. Sure, I'll probably never need, say, the California map. on the other hand, I am safe and secure in the knowledge that, anywhere in North America, I have a reasonably

  • This would be what the rest of the world knows as dynamic loadable libraries would it?

  • Didnt we learn 30-50 years ago that thin clients suck?
  • Apple is becoming another ibm, microsoft, now apple. Used to be cool, cool no more.

    • Apple is becoming another ibm, microsoft, now apple. Used to be cool, cool no more.

      Could have been copied and pasted from a 20 year old John Dvorak article.

      • by ebvwfbw ( 864834 )

        Yes, and what happened 20 years ago? Jobs came back. Then they became cool again after he cleaned it up.

        Flaming asshole, however he had vision.

        So comment still applies and is timely. A year from now it'll be a captain obvious commercial unless they get some better leadership. I hope they do. I have a bunch of their equipment.

        • by Uberbah ( 647458 )

          Except: the same pinhole vision was applied to everything Steve did since he returned to Apple.

          • Buying Next, his own company? Not only can Apple not come up with their own ideas anymore, they're just lining Steve's pockets!

            The iMac doesn't have a serial or ADB port! They're screwing over their customers and forcing them to buy new devices !

            No wireless. Less space than a Nomad. Lame.

            Don't Hold it Wrong! [tumblr.com]

          And so on, and so on. SHDD (Same Hatorade, Different Day).

MAC user's dynamic debugging list evaluator? Never heard of that.

Working...