iOS iOs should remove redundant images

[tmoerel]

When Installing a retina compatible app why does iOs not clean up all redundant graphics files when installing?

On a non retina device it delete all @2x files where there are non @2x files existing.

On a retina device it delete all non @2x files where there are @2x files existing.

This would save a lot of flash memory!!!!!

 

[jnoxx]

I double tripple vote this up, I think it would be really nice to have this..

 

[tmoerel]

I double tripple vote this up, I think it would be really nice to have this..

And it would be so simple to implement. All they have to do is to put it in the installer!

 

[astrorider]

One reason would be restoring from an iTunes backup to a device with a different display type (non-retina backup to retina restore) would leave you without the correct images.

 

[dejo]

Also, I don't think Apple wants to allow anything to change the application-bundle. Seems like a Pandora's box to me.

 

[KnightWRX]

One reason would be restoring from an iTunes backup to a device with a different display type (non-retina backup to retina restore) would leave you without the correct images.

No it wouldn't. iTunes does not restore application bundles, only data saved by the user. The bundles are re-uploaded to the device as they are on the app store.

iTunes does not backup the applications themselves.

 

[astrorider]

No it wouldn't. iTunes does not restore application bundles, only data saved by the user. The bundles are re-uploaded to the device as they are on the app store.

iTunes does not backup the applications themselves.

Really, if you restore from a backup iTunes has to re-download all your apps as well? No way to restore if you don't have a network connection and you have to wait for your apps to download as well? I knew that would be the case for iCloud, but didn't think it worked that way for iTunes.

 

[KnightWRX]

Really, if you restore from a backup iTunes has to re-download all your apps as well? No way to restore if you don't have a network connection and you have to wait for your apps to download as well? I knew that would be the case for iCloud, but didn't think it worked that way for iTunes.

iTunes holds a local copy and updates it once when there's an update on the App Store either straight from the App Store or from your device. It does not make a seperate backup of the entire bundle everytime you back up.

So no, iTunes just uploads it back from its local copy, which is the same thing that is on the App Store. It then restores your user data to the application.

If you go to Settings -> General -> Usage on the device, click an app, you will see 2 things :

App Size (the actual bundle's size, this is stored once by iTunes when you download the App or an update)
Documents and Data (this is your saved data for this app. This is backed up and restored by iTunes each time you perform a device backup).

So really, modifying the bundle upon installation on the device would only be an issue if iTunes has not yet had a chance to update its own local bundle. You could make it so the device does not remove any files until it has synced your iTunes bundle and made sure both device and computer have the same version. Then it could simply change the on-device bundle, knowing it has a copy of the proper App Store version in the local data on the computer.

 

[firewood]

iTunes on a Mac will restore app bundles. I just installed an iOS app that is no longer available in the iOS app store, but I had a copy purchased long ago on another iOS device.

 

[kayloh20]

Really, if you restore from a backup iTunes has to re-download all your apps as well? No way to restore if you don't have a network connection and you have to wait for your apps to download as well? I knew that would be the case for iCloud, but didn't think it worked that way for iTunes.

It's like music. Apps are stored on your computer and transferred, but they aren't stored in the iTunes backup file itself (that would eat up your computer's memory after several backups).


Anyway, I definitely like this idea (of course Apple themselves would have to push out an update). It wasn't fun when I updated iWork for iOS and lost a ton of memory due to retina images my iPad 2 is never going to even use.

What would be even better is if in addition to iTunes stripping upon sync, OTA downloads are already stripped (so Apple's servers would be the ones to strip out the images). This would allow for some applications to be downloaded in a shorter amount of time. Of course I'm not sure how Apple would handle syncing to iTunes from an already stripped application (maybe it will popup with a message saying "iTunes was unable to sync some items due to them being stripped" then having a button to download the full version from app store for free).

I'm sure some applications would break with this process, though (I'm sure there are some developers out there with only one set of images that are retina sized and being programmatically scaled on non-retina devices).

 

[tmoerel]

Also, I don't think Apple wants to allow anything to change the application-bundle. Seems like a Pandora's box to me.

Not really. Apple does not have to allow any changes. It is them who need to implement this in their installer code.

I am sure the apple geniuses should be able to come up with a solution. Right now all we are doing is wasting gigabytes of storage and that sucks.

 

[robbieduncan]

It would break the code signing so the app would no longer run

 

[PhoneyDeveloper]

Code signing. Conceivably apple could build retina and non-retina versions on their side and then both could be signed and downloaded and only the required one would be installed.

Some apps would break. This could be an option that apps could opt-in for or opt-out of.

HD space is cheap these days.

 

[throAU]

This would save a lot of flash memory!!!!!

In the scheme of things, it won't really save a heap. And do you/we know they don't already do this?

Just make one version of the images (retina) and on a non-retina device, scale the images by 0.5x after loading them. Would certainly be more efficient than including 2x the assets, but then again, maybe developers these days aren't as cluey as they were back in the 80s...

 

[tmoerel]

Code signing. Conceivably apple could build retina and non-retina versions on their side and then both could be signed and downloaded and only the required one would be installed.

Some apps would break. This could be an option that apps could opt-in for or opt-out of.

HD space is cheap these days.

Not talking HD space but flash storage on iOS devices. By no means is this cheap as you cannot add any and need to buy another device to get more!

----------

In the scheme of things, it won't really save a heap. And do you/we know they don't already do this?

They don't do this yet. Adding retina images on an app i am developing grew the app from 200Mb in non retina version increased the size to 304Mb even on a non retina iPad 2.

 

[KnightWRX]

They don't do this yet. Adding retina images on an app i am developing grew the app from 200Mb in non retina version increased the size to 304Mb even on a non retina iPad 2.

Maybe you should look into other solutions ? Infinity Blade II, the "iPad retina" version actually took up less space than the previous version when I updated last week.

 

[tmoerel]

Maybe you should look into other solutions ? Infinity Blade II, the "iPad retina" version actually took up less space than the previous version when I updated last week.

Pretty difficult when you are building a photobook application with 150+ photos at retina resolution

 

[KnightWRX]

Pretty difficult when you are building a photobook application with 150+ photos at retina resolution

Maybe you should build a "photobook" application instead of a static photo gallery then. Have your users transfer the actual photos after the fact, based on their device. Your app could be a small 100 kb photo gallery and you'd just have the users download the picture packs after they got the app ?

There's always a different solution.

Also, with picture packs offered outside the actual application instead of built-in, you can then have your app able to be bought over 3G/4G, have your users gain new pictures without having to redownload everything, etc.. etc..

Heck, you should do this, Retina display or not.

 

[ArtOfWarfare]

Heck, you should do this, Retina display or not.

Pretty sure it'd annoy people to have to download required resources after they've already downloaded the app.

Edit: For my next game, I've decided I won't be using any image files at all... instead I'll just be using drawing commands... that should help keep the download small + ensure the game looks as good as possible on whatever screen it's being displayed on. (Granted, I'm going for a retro look...)

 

[admanimal]

Just make one version of the images (retina) and on a non-retina device, scale the images by 0.5x after loading them. Would certainly be more efficient than including 2x the assets, but then again, maybe developers these days aren't as cluey as they were back in the 80s...

Or maybe developers don't want things to look like crap on non-retina devices.

In reality, I think retina vs. non-retina images is a minor problem as non-retina iOS devices will be less and less common moving forward. The more pressing issue is removing iPad resources from a universal app running on the iPhone. Retina iPad images can add hundreds of MB to an app, which are useless on the iPhone. Unfortunately this is a difficult thing to deal with, as currently there is no way for anyone but the developer to know which resources are for the iPad or iPhone, plus it has all of the issues with removing stuff from the bundle that have been discussed here.

 

[KnightWRX]

Pretty sure it'd annoy people to have to download required resources after they've already downloaded the app.

Dunno, people don't seem to be against the Music app even though by default it contains no music. Or the Photos app even though it doesn't contain any pictures, or the mail app, even though there's no mail in there on initial install or a e-Reader app even though there's no books in there to begin with.

A lot of stuff on the app store are just content packs packaged as apps. Really, that's not what proper application design is. You should make your application generic, and then provide content for it (or let others provide content).

We weren't talking games, so it's not like we're talking "ressources" for a game.

----------

Or maybe developers don't want things to look like crap on non-retina devices.

Why would downscaled images look like crap ? There's more to image scaling then nearest neighbour algorithms.

 

[xStep]

It would break the code signing so the app would no longer run

Actually no. An Apple tech doc explicitly states that code signing does not apply to resources such as images. I was surprised to read that nib files are included in that statement.

Cocoa Core Competences - Application Code Signing

"An application’s executable code is protected by its signature because the signature becomes invalid if any of the executable code in the application bundle changes. Resources such as images and nib files are not signed; a change to these files does not invalidate the signature."

As for the topic. Could there be confusion on what files to delete? Do you base the deletion based simply on the existence of a 2x file name? What about cases where an app communicates an image to the outside world where the opposing image size would be wanted? I would expect that Apple would want to protect the potential of messing up an app,so they would likely require a developer to opt-in option.

 

[tmoerel]

Maybe you should build a "photobook" application instead of a static photo gallery then. Have your users transfer the actual photos after the fact, based on their device. Your app could be a small 100 kb photo gallery and you'd just have the users download the picture packs after they got the app ?

There's always a different solution.

Also, with picture packs offered outside the actual application instead of built-in, you can then have your app able to be bought over 3G/4G, have your users gain new pictures without having to redownload everything, etc.. etc..

Heck, you should do this, Retina display or not.

Well. Did you ever spend time in the African bush for example? No wifi, no 4G, 3G, 2G or even 1G.

Well. Perhaps i would want to use my book there too while on safari. This means all images need to be preloaded. Postloading is no option!

 

[KnightWRX]

Well. Did you ever spend time in the African bush for example? No wifi, no 4G, 3G, 2G or even 1G.

Well. Perhaps i would want to use my book there too while on safari. This means all images need to be preloaded. Postloading is no option!

Hum... you didn't quite understand what I said. Postloading is an option still. In the African bush, your users can't download your app at all now can they ?

Again :

You make a "Photobook" app. This app is a reader for "Photobooks". You make "Photobooks" available for download in the app when it has connectivity, which you then store on the device in your data portion instead of in the app bundle.

2 benefices :

- Your app is now a smaller, less then 30 MB executable and can be downloaded over 3G/4G and not just over Wi-Fi
- You can update photobooks without updating the app and vice versa. A simple bug fix in the reader portion ? Users don't need to redownload 200 MB of data. A new bunch of photos ? Users can just grab that new photopack instead of redownloading the whole 200 MB of data.

Just a suggestion. Make apps that are apps (data and executables being seperate with clearly defined boundaries) and it'll save you a lot of headaches.

Your users can download the books before leaving for their safari, same as they would your app (they're obviously not getting while on the safari).

 

[tmoerel]

Hum... you didn't quite understand what I said. Postloading is an option still. In the African bush, your users can't download your app at all now can they ?

Again :

You make a "Photobook" app. This app is a reader for "Photobooks". You make "Photobooks" available for download in the app when it has connectivity, which you then store on the device in your data portion instead of in the app bundle.

2 benefices :

- Your app is now a smaller, less then 30 MB executable and can be downloaded over 3G/4G and not just over Wi-Fi
- You can update photobooks without updating the app and vice versa. A simple bug fix in the reader portion ? Users don't need to redownload 200 MB of data. A new bunch of photos ? Users can just grab that new photopack instead of redownloading the whole 200 MB of data.

Just a suggestion. Make apps that are apps (data and executables being seperate with clearly defined boundaries) and it'll save you a lot of headaches.

Your users can download the books before leaving for their safari, same as they would your app (they're obviously not getting while on the safari).

From s development point this makes sense. From a marketing point this is a disaster. Customers want to buy, install and use. Having to download something again annoys them. Grabbing a new photopack would involve in-app-purchases. Again something putting people off. I prefer a single app.