I have 2 iOS apps that have been in the market, 3 years on iPhone, 2 years on iPad HD version. The apps are a popular reference tool in the medical field. They are both comprised of 1100+ images. The current app size is roughly 52mb.
Approximately 400 images will be redone. They are currently jpg and low resolution. The replacements will be png, with higher resolution.
I'm uncertain on pixel size for these images. If they are in the 280x280 range, each file is about 100k, if in the 560x560 range, each file is almost 400k.
So I'd be looking at additional 40mb for the smaller images and 160mb for the larger.
There are plans for another 400+ images in the near future. So, I'm somewhat concerned with final app size.
If I went with the larger size for Retina devices, can I downsize for non-Retina devices?
If I supplied both sizes, image.png and image#2x.png, that would be 200mb just for these images.
I'm a little uncertain on how to manage these with regards to their individual size and, more importantly, their total size.
Any comments or suggestions are welcomed and would be helpful.
TIA,
jb
Here are a few options you have:
1. Downsizing Retina Images
I would not recommended downsizing retina images for the non-retina devices. This produces non-optimal performance and makes the images look bad. Your still loading in all the pixels of a retina image, but only displaying 1/4 of them.
2. Bundling All of the Images
Honestly for a medical reference app, I think it would be understandable if your app size would be quite large. I wouldn't imagine people would need to download this app over 3G or LTE. Your users understand this is a large database app which provides high resolution images, thus they should be okay with the large app size via this method.
3. Hosting the Images on a Web Service
Another alternative would be to host the images on a server, allowing them to be downloaded individually as needed, or in bundles. I think your users would prefer being able to fully use the app without internet connection rather than having a smaller app size.
4. Alternative Image Loading
This approach takes a bit of work and could be a little risky. You could bundle only 2x versions of your images into the app. Then on App launch you could force the user to wait until you resize all the images to their 1x counterparts and save them off to the disk. Then you could create an image loading convenience method which loads a UIImage from either disk or the app bundle based on whether or not it needs a retina image.
I definitely recommend option 2 for your purposes. I only mentioned the others to be thorough.
Related
I've made an "magic" app with a lot of coins/playing-cards.
Therefore I have a lot of images of coins, dollar bills, playing cards etc. (regular + retina resolution)
This results in a relative big file size of the final app, which I would like to avoid; since it can't be downloaded without a wifi-connection.
Currently it's 48.6 mb when downloading it from the App Store.
The images (100+) is all .png's saved in two versions, for the regular and retina displays.
Is there anyway to optimize this and reducing the final file size of my app?
I've considdered only storing the big (#2x) .png's and the scaling them accordingly.
I have had a lot of success using ImageOptim to compress the size of images in my application.
Also, if your images are png-24, you can reduce them png-8 and save a lot of space as well. png-8 doesn't support transparency though.
Why save 2 sizes? Do you have to display so many at a time that loading the retina version takes up too much memory on a 3G? Personally I don't think you should still think of supporting such an old device. Apple also dropped support for it a while ago and it really is lacking the memory for some decent applications.
Also, have you tried using some tools to compress your images without the users noticing it? like photoshop "save for web & devices", or yahoo's services etc.
why do you need to store TWO versions of images? Just use hires imges in regular displays. Or, if you whant so, you can distribute 2 apps...
Are you shure, that your images has necessary sizes? i mean retina display has 680x920 pixels. if you are don't zooming images, you don'n need to make them bigger. And in this case, mb *.app file, in archive... there must be 1000 images...
Is there a way to not add 1x images to an iPhone/iPad app?
I'm developing an iPhone app and also testing on my iPad.
When I just use #2x images, the iPad successfully resizes down to the 1x size.
Is there any downside to not to add 1x images? Or are they still important?
By forcing the device to downsample, you're sacrificing performance and memory for a negligible amount of disk space. It's a really bad trade-off. Plus, downsampling a larger image on the fly on the device is likely to use a lower-quality downsampling algorithm than what's available in, say, Photoshop (for performance reasons).
I had an app with 100+ near-fullscreen photos, and dropping the #1x versions made possible to keep the app below the 50 MB limit for downloading over a cellular connection.
In my case, I had no choice, but as #Kevin Ballard mentions, perhaps the trade-off is not worth it. Remember that non-retina images are 25% the size of the retina ones, so in terms of pixels you are only going from 1.25 to 1.00.
Granted, with compressed images the relation might not be linear (i.e., #1x PNG/JPEG may weight more than 1/4 of the equivalent #2x image on disk).
I have a few questions about screen resolution, that I'm not clear on. These questions assume they my app will be running on iOS 4.0 and up, and on either iPhone 3GS or iPhone 4.
Should the size of the splash image (default.png) be (960x640) or (480x320)?
Should the size of the app icon (Icon.png) be (57x57) or (114x114)?
What about other graphics that I may use in my app, such a graphic that represents a button? Should I always create these images for the higher resolution, and have the app scale them down? In other words, if I want a button image to be displayed on the 3GS that is 200x40 - should I create the image at 400x80, so that iPhone 4 can take advantage of it?
Thanks!
A good guide to this can be found here: http://mobile.tutsplus.com/tutorials/iphone/preparing-your-iphone-app-for-higher-resolutions/
In general you just create 2 sets of images. Your original and then a new one twice as big with #2x in the name. So for image.png at size 32x32 you would have one that is twice the resolution called image#2x.png at size 64x64. In your app just always use the image.png in Interface Builder and when loading in code.
There is no need to detect the device. These images will automatically be picked up by the OS and subbed in as necessary.
Provide both sizes (960x640 & 480x320) for the splash image using the #2x method described above
Provide both icons (57x57 & 114x114) using the #2x method
For our apps we use a combination of the #2x images and just Scaling the large images. (More information on this can be found in the above article) We use the #2x images for bar buttons, icons, etc. But for UIImageViews we often just use the Scaling. There can be a performance hit for doing this, but for most apps I'd say this is negligible. The savings in file size sometimes make scaling the only option.
Related Questions:
Retina/non-retina images in UIImageView
Making an app Retina Display friendly
You need to provide both if you want them to look nice. For example,
Default.png -> (480x320)
Amd
Default#2x.png -> (960x640)
Our graphics guy just gave me the sliced images for an Application we're building, but he only gave me the resolution for the 960x640 iPhone 4 res.
And advised that I can just scale the images down for 3g at runtime, so the resolution/image size remains the same but it's just displayed at half size.
The question: Is this allowed when submitting to the app store, or is it a requirement to have for example:
IMAGE1#2x.PNG (460x640) - iPhone 4
IMAGE1.PNG (230x320) - iPhone 3g
For all images.
I might just do the batch conversion and have two resolutions for all images, to save maximum space.
That's allowed, but obviously the images will occupy four times as much RAM on the older devices than they otherwise would, having four times the pixels. While the iPhone 4 has 512mb of RAM, the 3G and the original have just 128mb. Though assuming you are dealing with memory warnings correctly and everything will still fit, the main side effect will be performance issues whenever things are purged and later reloaded from disk (which, as I'm sure you're aware, is handled automatically for view controllers in NIBs). Based on empirical observations, the flash memory on pre-3GS devices is a lot slower than the later stuff so even if you're sticking with the large images it would make sense to attempt to minimise on-disk size.
Best practice that has worked for me is to make my retina image, then scale it down by 50%.
In order for the retina display to use the larger image, the #2x MUST be apart of the larger image. Your example is the way it should be used.
I would do the batch scaling ahead of time for sure. If for no other reason than the iPhone chooses whether or not to display the IMAGE1.PNG or the IMAGE1#2X.PNG depending on the resolution of the screen. In your code you always just reference IMAGE1.PNG. You don't have to make any coding changes. If you scale them at runtime you will have to override all of your calls to any UIImage type of thing.
IMHO, You are likely to miss one or else Apple is likely to release a different configuration of phone that will cause you to have to rework all of your code that is checking for screen resolution.
So I'm building an app for 4.x devices and I'm wondering if I can just use one set of assets at double resolution instead of one set with a #2x id and another set without.
Basically im asking can the older 3g and 3gs just use the #2x assets? and do the right thing with them?
anyone have experience with this?
Thanks
You're better off using two sets of resources, one for the high resolution retina displays and one for the older displays. Downsizing #2x graphics won't look pretty and will impact performance, especially on 2G iPod Touches.
The older devices can use the #2x but as far as I understand you'll need to:
Set your UIImageViews to scale the images to fit.
Hardcode image references to the new images.
Expect poor image quality and slower performance on non-retina devices.
Overall, it's better to provide two copies of the images, "bob.png" and "bob#2x.png" then reference them in code as "bob.png".
NB. As of iOS4 you can reference the images without their file endings, so just "bob" would work; however this has compatibility implications with devices running pre-iOS4 : the images won't be found. So for maximum compatibility include the file endings if you intend on deploying to both iOS4 and iOS3.x.
They technically can, given you make sure they're scaling the right way (e.g. if it's an image view that it's set to scale up/down).
However it's not recommended in most situations, mainly because it'll be slower, uses more resources, and leads to shorter battery life. Also, depends on your resources but an artwork scaled down by a factor of 2 doesn't have the same quality as one that is resampled specifically for the new size.