just how "smart" is iOS in regards to images?

Normally you would create two or four versions of an image (depending on devices)

and iOS would choose the “correct” one to give the best display for the device resolution.

But what if you have an overlapping situation?

you have 3 sizes 32x32, 64x64 and 128x128
an iPad2 would use 32x32 and 64x64
and iPad retina would use 64x64 and 128x128

does this mean you need TWO copies of the 64x64 icon with 2 diffent names

xxx64.png would be for iPad2 at 64x64
xxx@2x.png would be for iPad Retina for 32x32 image

same thing for a 128
yyy128.png for iPad2 to display at 128x128
yyy@2x for iPad retina to display at 64x64

and then zzz@2x would be a 256x256 image to display at 128x128 for retina

but both images would be IDENTICAL, yet take up twice the store?

IF they are the same image (at different resolution) you will have no multiple copies, only the 3 sizes (@1,@2,@3)

If they are different images… they are different only with overlapping sizes.

then one of us is missing something

an iPad2 is going to look for xxx.png and xxx~ipad.png
an iPad Retina is going to look for xxx@2x.png and xxx@2x~ipad.png and fall back to the non @2x versions if not available, and then scale the image to “fit” which might result in less than optimum display

where the xxx~ipad.png and the xxx@2x.png would be the same image, same size, same content only the filename is different in order for each device to “pick” the approripate resolution

you have to give the “hint” ~ipad only if you really need it

Sadly Xojo doen’t use assets (as xCode) so your app will take more store than needed

you are missing the point of the question

iPad-Non Retina [1 pixel = 1 point]
xxx_01.png 32x32 pixels … shown at 32x32 points
xxx_02.png 64x64 pixels … shown at 64x64 points

iPad-Retina [1 pixel =2x2 points]
xxx_01@2x.png 64x64 pixels … shown at 32x32 points
xxx_02@2x.png 128x128 pixels … shown at 64x64 points

assuming the app needs to show the same “image” in two different places , one as 32x32 and another as 64x64

That is FOUR images with 4 different file names, but xxx_02.png and xxx_01@2x.png contain the exact same image, so it takes up twice the resources…

While iOS automatically looks for @2x image files, I’ve not heard of automatic “-ipad” name lookups in the same way. What gave you that idea? Maybe I’m a bit behind on it. Maybe the “-ipad” suffix is a Xojo behavior, not iOS.

The other thing I know is that when you have both a normal and a @2x version, and you load the normal one into an NSImage, the 2x will get loaded into the same image, as a second representation, and then iOS picks the best looking one, even if you try to display at some other odd scale, e.g. 3x. I must admit I don’t know how it’s handled now with the new iPhone 6 resolutions, though. But the idea is always to get all the sizes loaded into the same NSImage, and then iOS can be smart about it, as you desire. I.e, if you would load your 3 versions into one NSImage, then you can use the same for drawing into various target sizes, and the best one will be picked for you.

the “~ipad” behaviors is an iOS one, and probably (but should be) and XOJO one

the “~ipad” says “if the device I’m running on is an iPad … start with this image”

and I do know it does “something” when the required “@” designator isn’t there… .like older apps on a iPhone6+ are missing @3x

but since the “logic” of how it chooses isn’t "published’… it forces the developer to include 3 images instead of two


says to use “~iphone” (the opposite of above)… but I have also read “both” ways work

In that case I think your question is better suited for Stackoverflow as it is not Xojo specific.

I’m trying to figure out how many and what size images to include in my project… how is that not XOJO related?
And SO has a stock answer for almost everything “Don’t be a dumbass, quit wasting our time, read the manual”

[quote=214902:@Dave S]I’m trying to figure out how many and what size images to include in my project… how is that not XOJO related?
And SO has a stock answer for almost everything “Don’t be a dumbass, quit wasting our time, read the manual”[/quote]

There are often stupid comments, but overall the answers are relevant and often right to the point. You can also ask the question in the Apple dev forums https://devforums.apple.com/community/ios . Or in the Google Swift group https://groups.google.com/forum/#!forum/swift-language . Or in http://www.mac-forums.com/ .

The iOS developers are not very many here. You might as well extend your query.

On the purely pragmatic side, have you tried generating a project with all pictures and see if the end up in the bundle ? If iOS is smart enough to see pictures by resolution, it should keep only the useful ones. Otherwise, I am not sure you should freak about a few more pictures. When the smallest memory size is already 8 Gb, what are a few more megabytes ?

I’m not sure I completely understand Dave’s question, but FWIW here’s my take on it from the perspective of my own app just in case it helps.

For each image icon (e.g. for a toolbar button) I include Icon.png, Icon@2x.png and Icon@3xpng. If I’m creating “standard” icons I use dimensions of 32x32, 64x64 and 96x96 respectively (note that the @3x icon is not the 128x128 size mentioned in the OP - it needs to be three times the size of the first, non-@x image, and not double the size of the second image). Sometimes I have a need for a “small” icon, in which case I use dimensions of 16x16, 32x32 and 48x48 respectively. Sometimes I have a need for a “large” icon, in which case I might use, for example, dimensions of 64x64, 128x128 and 192x192.

My understanding from reading both the Xojo and Apple docs is that provided you provide these three sizes, with the @2x and @3x images being twice and thrice the size of the first image, the images will scale properly across iPhone and iPad models and that has been my experience both with internal test devices and with end-user devices.

The extra specifiers (~ipad ~phone) are just in case you want a different image on the ipad or iphone
So you dont HAVE to supply them but you CAN supply them

I’m not sure why everyone is having trouble understanding my question. first off… forget @3x for now

the app needs to display a 32x32 image of a cat on one screen, and a 64x64 image of a cat on another screen.

the iPad2 would need a 32x32 version of the image and a 64x64 version of the image… simple. there would be no “@” designator

however, the RETINA iPad would need a 64x64 version of the image and a 128x128 version of the image

 +--------- iPad2-----------+--------- iPad Retina --------+
 +----32 ---+------64-------|-----32 ----+-------64--------+ image display
 |cat.png   |  cat_big.png  | cat@2x.png | cat_big@2x.png  |
 +----32 ---+-----------64x64 -----------+----128x128 -----+ image size in pixels
 |          |<----These 2 are SAME ----->|                 |

this only applies to current iPads as all existing iPhones are for the most part Retina devices, but iPad2 is NOT.

iPhone6 would require a 96x96 and 192x192 would do not duplicate any required iPad sizes.

If there was no need or desire to continue to support iPad2 this would be moot. But as of now Apple requires said support.

Dave AFAIK you will need:

cat.png (32x32)
cat@2x.png (64x64)

cat_big.png (64x64)
cat_big@2x.png (128x128)

So, while it would be nice to think that some fuzzy logic would mean that you would only need one 64x64 image, I don’t know of a way to achieve this.

So as I thought, iOS is not that “smart”, I guess while its a pain to have to cram 25% more graphics into the bundle than required, the iOS9 “app thinning” should “fix” that (supposedly)

That’s my understanding, though as yet Xojo has no plans to support this.

I haven’t read any specifics on it, but my understanding was the developer didn’t have to “do” anything… the App Store (or iTunes) simply stripped the bundle on download… but there may be more required than that.

As I understand it, Xcode automatically creates “slices” for an app in the build process but one of the Xojo guys advised that they currently have no plans to support this because it is currently optional.