9

I've seen a couple posts about the UIImage automatically loading the filename-568.png image in the new iOS6, but I can't seem to recreate it in the UIImageView class.

I'm using the Storyboard (not my app, just having to do some checks), and I've a simple layout with just the Image View scaled to fit, no code in the view controller, and I've sure the filename.png and filename-568h.png exist (as well as -568@2x.png just in case) but when I load it up in the iOS6 simulator. This has been for iOS 4 and 5, loading the @2x image for retina, doesn't seem to work in iOS6 though. Any ideas?

The image happens to be called Default.png since it is the same as the launch image, could this be the issue?

Thanks for any help in advance

redroot89
  • 257
  • 1
  • 4
  • 11
  • I found answer here: - http://stackoverflow.com/questions/12532405/images-for-iphone-5-retina-display - http://stackoverflow.com/questions/12431445/iphone-5-what-naming-convention-the-new-images-have-to-follow – Thesalan Sep 25 '12 at 14:20

2 Answers2

32

iOS6 does NOT automatically load -568h as it does with the @2x images. The only exception is the default screen, but further than that you have to manually set you 568h image yourself.

I created some code to mimic the loading behavior for -568h images when using the [UIImage imageNamed:@""] method, but from the IB I do not know the way. If you are interested in such a solution, check it out at http://angelolloqui.com/blog/20-iPhone5-568h-image-loading

Angel G. Olloqui
  • 8,045
  • 3
  • 33
  • 31
  • Actually, I've found that if I specify the image within IB as say "image.png", then no matter what type of phone simulator I use, it loads the correct file, [@2x] for 3.5" retina, and [-568h@2x] for 4" retina. If I try to code it myself using [UIImage imageNamed:] then it doesn't work. Odd. I'm going to have to do the same as @Angel Garcia Olloqui above. – PKCLsoft Oct 01 '12 at 03:03
  • 1
    I tried your code and whilst it works fine in the simulator, it does not compile for a real device. The #include of fails to compile. – PKCLsoft Oct 01 '12 at 08:33
  • I don't get one thing in the code: returning the same method at the end, doesn't create a recursive loop ? – Nicu Surdu Oct 01 '12 at 14:48
  • I noticed that too. I suspect the recursion is handled, but I removed it in any case to reduce risk. Due to my issue with the device based build, I've turned it into a simple category and just call the imageNamed568h instead from within my app. I know that swizzling seems neat, but I'm not a fan. – PKCLsoft Oct 01 '12 at 22:28
  • Thanks for the comments. I just updated the code to include #include instead of the header that was having problems for device. It should work now. – Angel G. Olloqui Oct 04 '12 at 13:37
  • 1
    Regarding the recursive loop. Check it out that I am swizzling the methods, so the recursive loop that you see is not a recursive loop! it is actually the call to the original method. Just include the class in your project and use everything as you used to. No need to change your code because the methods as I explained are swizzled, and it performs better because this only happens on iPhone5 devices. – Angel G. Olloqui Oct 04 '12 at 13:39
  • No, it doesn't create recursive loop. The method actually refers to the old one, this shit happens at run time so everything works out. – 0xSina Nov 01 '12 at 03:08
  • 1
    You may want to see the information in the selected answer for this question on how to handle loading of these images from Interface Builder. http://stackoverflow.com/questions/10398547/are-images-assigned-in-a-xib-cached – Norman H Mar 27 '13 at 11:55
4

Typically, you should only use 568h for the launch image. If you notice yourself using different image assets within your app for the new display height, you should consider that you might be making your UI too static.

The most obvious place people want to use 568h for images is for background images. An alternative is to just have one asset that has the largest possible dimensions and align it properly using the contentMode property of UIView.

But perhaps you have something floating in the image at the top and the bottom, so contentMode doesn't solve it. You could consider that the top and bottom floaters should probably be separate views anyway.

Remember, we have always been making apps with variable heights. Every time a keyboard pops up, its as if the size of the screen has shrunk.

Richard Venable
  • 8,310
  • 3
  • 49
  • 52
  • 1
    I don't agree with your last sentence, the keyboard is shown on top of a view, it does not shrink the view at all. It would make sense that iOS properly detects -568h resources, since it does handle @2x images and the OS itself needs the -568h for splash screen. I think it forces us to write horrible code to handle iPhone 5 screen ratio. – Christophe Fondacci Aug 08 '13 at 22:57
  • If you feel Apple is forcing you "to write horrible code", you should probably step back and see if you are needlessly violating any Apple conventions. In iOS, that typically results in more work, less payoff. – Richard Venable Aug 09 '13 at 00:49