App slicing and asset catalogs are part of the attempt to address one part of this. Because back in the old days, every single resolution variant would end up in the app bundle.
As far as scaling images down goes, the question to ask is really "How important is pixel perfection in your images to you?"
In this case, I'm not that worried about pixel perfect, but it is only 30 images at the same time.
Do you have a recemmendation as far as what a good rule of thumb would be?
Are there any other things I need to consider such as App size, etc..
Thanks for the reply
I think 30 images is near the low end in terms of quantity..no big deal, and if you make them to spec/72dpi you'll not have issues. But I'm not sure 30 would cut it...remember, as for support, you need to include non-retina, retina (2x) and retina HD (3x) - and does each image work the same regardless of orientation?
>I'm just wondering if there is a good rule of thumb
Nothing that fits all examples, no.
Of course the only real way to know for sure with your images in your app is to try multiples vs. scaling and then see how the app performs when testing on hardware.
And don't forget what Apple promises (works when followed to a tee, so be sure to get it right):
"When building, Xcode compiles the asset catalog into the most efficient bundle for final distribution."
About app size, see:
I'm new to ios development so I'm learning as I go. I make the 3 images that I specified earlier, 2 for iphone (2x and 3x), and 1 for ipad (2x). I'm under the impression that this covers the majority of devices, so I don't include a 1x image for either iphone or ipad. I'm not sure what the standard is, but logically this makes sense to me. Is it a requirement to include a non-retina 1x version?
and my app is landscape only.
When I ask the question about a "rule of thumb", I'm refering to the extremes on both sides of a situation. Are there a milion situations, of course... But if you give me the situations in which you would use one way over another, then I can come to my own conclusion on all the situations inbetween.
I appreciate all comments and info. Thanks for the reply
Non-retina is required when an app is iPhone only, but might be dropped when Universal, such as in your case.
I still think 3 of each isn't enough - you need at least that many to cover iPhone 5 and up, not including iPad. Remember, resolution is one thing...varying screen heights while keeping same width, is another. Simple @2/3x scaling can't overcome stretching.
If you scale, your app runs the risk of leaning on physical memory - if you go with native multiples, you run the risk of leaning on physical storage.
Again, best to create as near to release images as practical, and then device performance test, regardless of which path you follow.
To give you more details of how I laid out my app with the 3 images this is my process.
Sorry for the "story" post; I can ramble on for sure.
I utilize inkscape for my graphics. I have a file that has 3 background images that are the pixel size of the dimensions of the biggest device for each of the 3 categories: 2x iphones, 3x iphones, and 2x ipads. Most devices in each category share the same ratio aspect, so since I make my images to the size of the biggest image, they scale down fairly well for other devices (or at least from what I've seen in the preview view within xcode).
I try to make each image a multiple of the biggest devices pixel size. So example:
Biggest Iphone 2x: 750 x 1334
So when I make an image that I want for the device, say a logo image, I make it a multiple of this resolution:
so width of logo could be: 750 x .5 if I want the image to be half the size of the width of each device.
I can then add constraints to that logo in interface builder to make sure that its width is in fact .5 of the actual device.
There is a few problems I have with this technique though. For one, iphone 4 is a pain in the ass because it doesn't fit the same aspect ratio of the newer iphones at 2x. I get around this by adjusting the constraints per image to the size that looks acceptable for me on all devices.
A second problem is with ipad since it has a different aspect ratio in comparison to iphones. Lucky I can get around this with different devices with constraints. Since my app is landscape only, devices that are Regular width, regular height are ipad. devices that are regular width and compact hieght is my 3x devices, and compact compact is my iphone devices. With these different constraints I can get the app looking pretty much the same across all devices. There are minor differences with spacing for certain devices. Iphone 4 especially (wish there were a way to provide constraints for iphone 4 in interface builder).
Is this correct: My understanding is that there are very few iphone 4's out in the wild, and almost non-existent of previous models. So I figure these 3 images work well for all modern iOS devices.
For iphone 5 or iphone SE, they have the same aspect ratio as a iphone 6 or 7. So my scales down for the 5 and SE.
With all this said, this has been my process so far. I'm self taught so I'm going off of what I have learned from books, online sources. I don't know if there is a more efficient way of handling this, or if I'm going about this all wrong, but it seems to be working as of now. I haven't fully tested all devices available, so I may need to make adjustments.
Also as a note, when I'm adding constraints to my views, I typically constrain the width and height to the devices width and height (explained earlier with the 0.5 multiple or something similar). I try to use stackviews to group things the way I want, and then constrain the stack view to the center. With the horizontal and vertical center constraints I'm able to adjust this as well which is nice. I can constrain other groups to the corners if I need the placement there instead of centered.
The methods used above are not pixel perfect per device, as I'm scaling down, but it doesn't look that bad for what I'm trying to accomplish. I wish interface builder and image set supported more devices so that I can implement more variations without adding code. I've though about adding code for the iphone 4 because its size dimension throws it off. But with constraints I have been able to get to an acceptable look on all devices.
You obvious have a lot more experience than me. I'm curious on your throughts on my overall process.
Technically*, if you focus on aspect ratio, you only need two of each image:
These models are all 9:16:
- iPhone SE, 5, 5C, 5S, iPod Touch 5g
- iPhone 6, iPhone 6s, iPhone 7
- iPhone 6 Plus, iPhone 6s Plus, iPhone 7 Plus
- iPhone 8, iPhone 8 Plus
These models are all 3:4:
- iPad Mini 2, iPad Mini 3, iPad Mini 4
- iPad 3, iPad 4, iPad Air, iPad Air 2, 9.7-inch iPad Pro
- 12.9-inch iPad Pro
If you focus on diagonal size, you need 6.
If you focus on ppi, you only need 3.
If you focus on resolution you need 5.
As a side note, 3 class sizes (pairs) would cover those devices, landscape only.
The question then is what is the lowest required number that satisfies your focus. 3 in one category may not be the same 3 in another, so if overlap occurs, the minimum could be higher than 3. Scaling, as an example, can be a good scheme, but it might not cover all your needs.
Example is applied aspect ratios vs. ignored diagonal size...when displayed on your target devices, 2 out of 6 will display correctly; 4 will be stretched. How those 4 look to the user depends on your image...a simple fill might be hard to detect if stretched, whereas a shiny or deeply contrasted gradient could display artifacts, warping, flashing etc. A distorted gradient might be acceptable in one case but visually disturbing if it sits behind one font vs. another. And remember, not all pixels for your target devices are square...some are rectangular and don't play well w/certain graphics when ignored.
It's the overlap that prohibits rule of thumb. Overlap when involved, can be entirely different based on which of the above are represented by your app and your images. Applicable results that matter to the dev, for a given use case, can only be found by testing.
>I'm going off of what I have learned from books, online sources.
Be careful - books often rely on beta code/specs and are typically outdated by the time they reach the shelf...keep the receipt, better yet avoid them - online references can suffer the same fate - specs change too frequently and the newcomer can waste time chasing beta and/or outdated material, unaware they've been misled.
>I'm curious on your thoughts on my overall process.
You're getting there...
Striving to simplify any task is a good thing, but risky as a primary driver when new to that task. I like to learn and work with a topic as much as I can first, and only when I know it inside/out will I see if it can be distilled and if it can, I'm all over it....it's the systems analyst in me, I guess.
* Note 11.7.17:
- Aspect ratio for the iPhone 8/Plus is 9:16; diagonal size is 4.7"/5.5"; ppi is 326/401; resolution is 750x1334/1242x2208
- Aspect ratio for the iPhone X's 5.8-inch OLED display is 9:19.5; diagonal size is 5.8"; ppi is 458; resolution is 1125 x 2436
Updated for iPhone 8/Plus and iPhone X:
- If you focus on aspect ratio, you need 3
- If you focus on diagonal size, you need 8
- If you focus on ppi, you only need 4
- If you focus on resolution you need 7
When I scale down, I set the image the aspect fit, so that it keeps the same aspect fit. I don't think there is any stretching with my implementation that I'm aware of.
For the same ratio of the 2x and 3x devices. I know I could get away with one image instead of two. I just figure, that if I make 2, then at least the most current devices which are the biggest are going to have images specifically for them, so it should look exactly as I intend on those devices.
I would prefer to create more images so that I wouldn't have to do as many constraints to get it to look well on all devices, since the sizes will fit better. The reason I opted for the 3 that I have chosen is because in xcode, I'm only able to have an image set that has ipad and iphone slots. I want to avoid having to use code in order to make other devices use different images. At least for this project.
You mentioned that you can use the diagonal and make 6 images. I would do this if I could, but I don't know of a way of implementing this in xcode and without writing code. Is there a way of doing this? or does method require code?
Also as a side question; I can imagine that the more images I use the bigger my app gets. does Apple have some sort of scheme that when the user downloads an app, it only brings with it the images that it needs and discards the rest (images that are meant for different devices)?
Also, for research that I have done as I've learned what I have learned. I have not read an entire book or went through an entire course on iOS. I get little bits and pieces from different sources. It definitely is a struggle to find current information though. Since swift is rather new, it seems that it has changes a lot more than some of the other languages that have been around.
Also, the topic of images, and how to implement them is rough to find good sources of information on. Hence the reason I'm here.
>the topic of images, and how to implement them is rough to find good sources...
Why do you think that is? Certainly not from want, so why?
> I don't think there is any stretching with my implementation that I'm aware of.
Testing would move thinking to knowing, but if you only use three images for each example, you will have stretching - the question is, will it be your friend.
I'm not exactly sure. I would say maybe because there isn't a "rule of thumb" when it comes to images and there is multiple ways of implementing them.
But that doesn't explain the lack of content because if you are going to make an App, or teach people to make an App, it seems like this is an important part. Maybe I just haven't found a good source.
>Maybe I just haven't found a good source.
Maybe it's a fluid, moving non-trivial target, that fossilized discourse would only muddy. Some things, especially w/app dev content, can turn on a dime, where it takes constant attention to stay current. It's called 'development' for a reason, after all.
Wait 'till you get to the hard stuff
I have another question if you have time?
thanks by the way, you have been really helpful in leading me to understand how to handle images.
So, when I create an image for a device and export it using inkscape, or any other image software for that matter. Does the export DPI matter?
Take a background for an Iphone 6: I make the image size in pixels as 750x1334. This matches the screens resolution.
When I export the inkscape tells me the dpi is 96 by default. If I change this number it scales the image, but that is not what I want.
So I now have an image that is 750x1334 that is 96 dpi. When I import that into xcode it even tells me this. So I'm not sure if this is a concern or not.
It looks the way I want on screen, but I haven't tested it out on an actual device yet. I was under the assumption that a pixel is a pixel, so I have the correct amount of pixels for a 2x Iphone 6 in this example, why does the dpi matter or does it not?
As I mentioned in my original reply: 72 dpi - strictly. Anything more is wasted.
Right I read that. I don't quite understand what that means though. Why 72?, why not 96. Isn't a pixel a pixel, so if I make a 100x100px image it is only going to be 100x100 pixels regardless of dpi?
I'm told that the required DPI* for iOS development assets is 72 dpi (irrespective of the actual device DPI). In the presets it is set to the DPI of the device, not 72 dpi, and that the presets rely on 72 as the base, ignoring/regardless of whatever the actual asset dpi may have been. If you want to be in line with that process so you have a comparative 1:1 visual reference when creating your images, output at 72.
Using a higher output dpi when making an image won't matter on the device...lower may. Again, 72 dpi is for the dev's workflow, not for the device. The goal is to give you as fair a chance as practical to have the final output match the original input.
Pixels as a hardware topic, in my opinion/in this example, are too subjective to discuss w/non-engineers, so I've learned to leave that topic for other venues rather than participate here in the forums.
*Be aware that iOS asset/device dpi is not the older traditional 'dpi' reference long used for printing, as an example.
Do people even develop for iPhone 3 or 4 anymore? It seems like such a small percentage when I google version stats. I'm wondering if I should just not worry about how the app looks on iPhone 4. I'm not sure if I can specify when the app has s done the range of devices that the app is compatible with. I'm sure you know?
Those fall into the category of devices that can no longer run a current iOS, so I'd say to put your efforts into users that are up to date, etc. instead.
But again, iPhone-only apps are still expected to run and look ok when installed on iPad and used in 1x/2x emulator mode...app review will check in that case.
Since you plan on a Universal app, I don't think you need to worry.
Thanks for all the info, you have been very helpful. I think for this app I'm going to continue with what I have been doing. Not worry about iphone 4s anymore, and focus on the most current devices.
I now know that some of the different ways I can work with images, I think my next app, I'm going to look into using the diagonal as a source for different image sizes. I'm sure this can be approached in different ways.
Either make all 6 images seperately, then it appears that you would have to reference images with code on certain devices using the diagonal.
Or you could make the 2 images like you would with aspect ratio and scale down those 2 images using the diagonal.
You made a valid point that depending on what we do could mean bigger app size Vs. would it be memory usage or just cpu cycles spent on scaling down the images.