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