Graphics retina display - iphone 4 & 5 ?

[appdesigner]

Originally Posted by djskinner

The reason you were asked if it was a game is because games as typically a little more difficult to get to support the different screen sizes. If you're developing a music app using mostly standard iOS components then your developer is probably not going to have to do any extra work to add iPhone5 support (for example, a full screen table view will just expand to fill the new screen space) unless you want the iPhone5 to have significantly different graphics (see below).

What I tend to do with graphics (as a developer) is to add only the highest resolution graphics to the build (i.e. the retina ones). iOS does a good job of scaling down images for non-retina screens. This helps to keep the add size low (significantly). In fact, I'm currently adding iPad support to our game and where the iPad graphics are just larger versions of the iPhone ones, I will be only adding one file for that graphic - the larger iPad version.

This is why @ovogame's point is important. If things are going to be scaled down to half the size (whether you let iOS to it or do it in Photoshop) then you better make sure that the positions and sizes of your slices are on even pixels. A graphical asset which is 131px for retina is going to scale down to 65.5px for a normal screen. This half-pixel is obviously a problem (although it reality its not that bad).

Where the graphics do need to be different (either to support iPhone 5 or iPad) then obviously you're going to need to send separate slices for these elements. In all but the most simple cases this is going to require a separate screen file (XIB) for iPad/iPhone 5.

Hi DJSkinner, thank you for your detailed explanation. I think my developer is trying to rip me off, or he's a inexperienced one. So you mean that IOS can automatically scale down large graphic files !? I only have to slice up one set of graphics?! is there any advantage to providing the three separate sizes ?
320 x 480px - iphone 3
640x960px - iphone 4
1136x640px - iphone 5

ANd if I provide just the one set of graphic files at the largest size 1136x640 , do I still name the files with the suffix @2x ?

ANd is my developer also wrong about having to create new layout files (xib files) for new retina displays/devices ? He says the UI work is at least 30% of total work, thus why he wants to charge me extra money for this. Again I think he is wrong, the graphics for all devices are the same only the resolution is different. SO the layout files for each iphone should be the same? Am I right? what new layout files does he need to create? Especially if IOS can automatically reduce the graphic size or if I provide him with the reduced graphics.

[djskinner]

Originally Posted by appdesigner

Hi DJSkinner, thank you for your detailed explanation. I think my developer is trying to rip me off, or he's a inexperienced one. So you mean that IOS can automatically scale down large graphic files !? I only have to slice up one set of graphics?! is there any advantage to providing the three separate sizes ?
320 x 480px - iphone 3
640x960px - iphone 4
1136x640px - iphone 5

ANd if I provide just the one set of graphic files at the largest size 1136x640 , do I still name the files with the suffix @2x ?

ANd is my developer also wrong about having to create new layout files (xib files) for new retina displays/devices ? He says the UI work is at least 30% of total work, thus why he wants to charge me extra money for this. Again I think he is wrong, the graphics for all devices are the same only the resolution is different. SO the layout files for each iphone should be the same? Am I right? what new layout files does he need to create? Especially if IOS can automatically reduce the graphic size or if I provide him with the reduced graphics.

There is absolutely no need to create separate layout (XIB) files to support 320x480 and 640x960 resolutions. By all means you can supply separate graphics for the retina screen by giving them the same name as the normal resolution graphic and adding the @2x suffix. The Cocoa Touch framework will automatically detect this suffix and use that graphic on retina devices if it exists. Providing you send the files correctly named and suffixed there is no additional work required on the part of the developer.

What I did for our game was simply to use only the high resolution graphics (with the @2x suffix or not - it doesn't actually matter in this case). This allowed us to keep the app size as low as possible as iOS does a fine job of downscaling these graphics for non-retina devices.

So, supporting both the 3GS and 4S, say, shouldn't really be any extra work for a developer.

iPhone 5 is different, however. In this case its not simply a doubling of the size of the images, the screen is a different shape. The level of additional developer work to support iPhone5 can vary a lot depending on your app, but in all cases is likely to take some additional effort.

To enable full screen support on the iPhone 5, you add a 1136x640 splash screen image called Default-568h@2x.png. This will stop the app running in letterbox mode and make use of the full screen.

Now, having done this, how much work is involved really depends on how the app is built and laid out on screen. There are three options here:

1) Use Auto Resize (autoresizing masks - iOS5 - possibly earlier) - whereby the screen will be extended and the graphical elements repositioned and/or stretched and the UI controls extended automatically by iOS. You can control the layout to some degree by tweaking the struts and springs rules on each element/control. This is barely any extra work - the developer will only really need to adjust the struts and springs rules to get it working. However, it's fairly restrictive and you can only get the results you want on very simple screens - i.e. there there is a full screen list that can simply be extended to show more of the list.

2) Use Auto Layout. This requires a minimum deployment version of iOS6 and I have no experience using it but I understand that it's basically an improved version of the above.

3) Create a new layout (XIB) file for the screen specifically for the iPhone 5. This is clearly the most developer intensive - not only do you need to create a new layout file but you also need to add code to detect the user's device and load the correct layout file (it's not that hard actually but from my experience as a developer, doing the graphics is mind-numbingly boring, tedious and very time consuming).

For our game we weren't happy with the limitations that 1) presented. We also wanted to make proper use of the iPhone 5 screen unlike many of the currently popular word games out there who seem to have just done a 'quick hack' which doesn't make any productive use of the new screen space. So, we went with 3) which gave us the most control.

Just to give you an example of the limitations of 1) we do have a screen that is a full screen list - the screen which shows all the matches the player is currently playing with other players. Using 1) for this screen would normally make sense - let iOS extend the list and show more of it on the screen. However, even for this screen we chose to go with 3) for one simple reason - we wanted to use a special iPhone 5 background image rather than just stretching and distorting the 640x960 one.

So, if you want to use different image files for some of your iPhone 5 graphical elements (like the background) then you're going to have to go with the developer intensive option 3.

I sense there is a bit of tension between you and your developer. It's not a good way to start out the relationship. We know this from experience. We've created another post on this forum detailing how we developed What it Takes, our first game, first by trying to outsource everything and then eventually doing almost everything ourselves (including all graphics and development). There is a good discussion over there and it might give you some ideas on how to approach app development. http://forums.toucharcade.com/showthread.php?t=171794

[appdesigner]

Originally Posted by djskinner

There is absolutely no need to create separate layout (XIB) files to support 320x480 and 640x960 resolutions. By all means you can supply separate graphics for the retina screen by giving them the same name as the normal resolution graphic and adding the @2x suffix. The Cocoa Touch framework will automatically detect this suffix and use that graphic on retina devices if it exists. Providing you send the files correctly named and suffixed there is no additional work required on the part of the developer.

What I did for our game was simply to use only the high resolution graphics (with the @2x suffix or not - it doesn't actually matter in this case). This allowed us to keep the app size as low as possible as iOS does a fine job of downscaling these graphics for non-retina devices.

So, supporting both the 3GS and 4S, say, shouldn't really be any extra work for a developer.

iPhone 5 is different, however. In this case its not simply a doubling of the size of the images, the screen is a different shape. The level of additional developer work to support iPhone5 can vary a lot depending on your app, but in all cases is likely to take some additional effort.

To enable full screen support on the iPhone 5, you add a 1136x640 splash screen image called Default-568h@2x.png. This will stop the app running in letterbox mode and make use of the full screen.

Now, having done this, how much work is involved really depends on how the app is built and laid out on screen. There are three options here:

1) Use Auto Resize (autoresizing masks - iOS5 - possibly earlier) - whereby the screen will be extended and the graphical elements repositioned and/or stretched and the UI controls extended automatically by iOS. You can control the layout to some degree by tweaking the struts and springs rules on each element/control. This is barely any extra work - the developer will only really need to adjust the struts and springs rules to get it working. However, it's fairly restrictive and you can only get the results you want on very simple screens - i.e. there there is a full screen list that can simply be extended to show more of the list.

2) Use Auto Layout. This requires a minimum deployment version of iOS6 and I have no experience using it but I understand that it's basically an improved version of the above.

3) Create a new layout (XIB) file for the screen specifically for the iPhone 5. This is clearly the most developer intensive - not only do you need to create a new layout file but you also need to add code to detect the user's device and load the correct layout file (it's not that hard actually but from my experience as a developer, doing the graphics is mind-numbingly boring, tedious and very time consuming).

For our game we weren't happy with the limitations that 1) presented. We also wanted to make proper use of the iPhone 5 screen unlike many of the currently popular word games out there who seem to have just done a 'quick hack' which doesn't make any productive use of the new screen space. So, we went with 3) which gave us the most control.

Just to give you an example of the limitations of 1) we do have a screen that is a full screen list - the screen which shows all the matches the player is currently playing with other players. Using 1) for this screen would normally make sense - let iOS extend the list and show more of it on the screen. However, even for this screen we chose to go with 3) for one simple reason - we wanted to use a special iPhone 5 background image rather than just stretching and distorting the 640x960 one.

So, if you want to use different image files for some of your iPhone 5 graphical elements (like the background) then you're going to have to go with the developer intensive option 3.

I sense there is a bit of tension between you and your developer. It's not a good way to start out the relationship. We know this from experience. We've created another post on this forum detailing how we developed What it Takes, our first game, first by trying to outsource everything and then eventually doing almost everything ourselves (including all graphics and development). There is a good discussion over there and it might give you some ideas on how to approach app development. http://forums.toucharcade.com/showthread.php?t=171794

Hi DJSkinner! Thank you for your prompt and very informative post. I wasn't expecting a reply at Christmas time. So I thank you very very much.

Ok so I think I got it. In a nutshell, my developer will have to create two layout (xib) files - one for iphone 4 (and below) and the second one for iphone 5 ( as I do have different graphical elements like in your case , the background image).

ANd if I want to build the app for the ipad , I'm guessing he will have to create another XIB file for that as well. Right?

In terms of graphics I can just provide the one set (High resolution at 1136x640) like you have for your app, and just have IOS scale down the images for lower resolution devices. I rather do this because of the reason you specified (to keep app size low as possible) and also save time on having to slice up 3 different sets of graphics. Unless I build for the ipad as well, then I'm guessing I would have to provide a separate set for this at the ipad resolution. So maximum I would provide is two sets of graphics.

You are right there is some tension between the developer and I. After him telling me to supply 6 different sized graphic sets , I simply don't trust him. I'm not a developer and I don't even design for apps ( this is my first one) but I even knew that this seemed wrong. I agree it's not a good way to start a relationship, ..development hasnt even begun ..if I can't trust him to advise me correctly with regard to a simple matter such as graphics , how can I trust him to handle the development of it???

Thanks for the link on how to approach app development, I'll take a look at it. Thank you once again for your very detailed helpful post. I appreciate it much. Happy new year and belated Christmas

[djskinner]

Originally Posted by appdesigner

ANd if I want to build the app for the ipad , I'm guessing he will have to create another XIB file for that as well. Right?

In terms of graphics I can just provide the one set (High resolution at 1136x640) like you have for your app, and just have IOS scale down the images for lower resolution devices. I rather do this because of the reason you specified (to keep app size low as possible) and also save time on having to slice up 3 different sets of graphics. Unless I build for the ipad as well, then I'm guessing I would have to provide a separate set for this at the ipad resolution. So maximum I would provide is two sets of graphics.

Yes, in your case (as with ours) it looks like you will need three XIB files for each screen: iPhone, iPhone5, iPad. As the iPad screen is a different shape too, you again may want to provide a third set of graphics - e.g. the background - which is going to be different. However, in order to save space, if a graphical element is the same shape (just scaled up for the iPad) then I would only include the iPad-sized graphic since you only really need one copy of the image, the largest. As with scaling down from retina to non-retina, the same applies to iPad.

I'm actually in the process of adding iPad support (as a universal app) to What it Takes - with the hopes of getting a new build approved by expedited review so that when we launch on the 10th we will have full iPad support too.

Upgrading the graphics to iPad with retina resolution has doubled the size of the image files and massively increase the size of the build. If I had used separate slices for every device rather than just scaling down the iPad version where possible then I'm sure the build will be over 50mb. Even so, I'm hoping to further reduce the size of the build by disabling Xcode's default PNG optimisations and applying some manually - which should knock about 30% off the size.

[appdesigner]

Originally Posted by djskinner

Yes, in your case (as with ours) it looks like you will need three XIB files for each screen: iPhone, iPhone5, iPad. As the iPad screen is a different shape too, you again may want to provide a third set of graphics - e.g. the background - which is going to be different. However, in order to save space, if a graphical element is the same shape (just scaled up for the iPad) then I would only include the iPad-sized graphic since you only really need one copy of the image, the largest. As with scaling down from retina to non-retina, the same applies to iPad.

I'm actually in the process of adding iPad support (as a universal app) to What it Takes - with the hopes of getting a new build approved by expedited review so that when we launch on the 10th we will have full iPad support too.

Upgrading the graphics to iPad with retina resolution has doubled the size of the image files and massively increase the size of the build. If I had used separate slices for every device rather than just scaling down the iPad version where possible then I'm sure the build will be over 50mb. Even so, I'm hoping to further reduce the size of the build by disabling Xcode's default PNG optimisations and applying some manually - which should knock about 30% off the size.

Hi djskinner
Thanks for your confirmation.its much çlearèr now.
All the best with your game app, hope u sell lots of it . I saw the youtube clip of it. You guys put in a lot of work. Good luck.

[djskinner]

Hi @appdesigner. How are things going with your project? We've release the game now so please download it and let us know what you think.

Similar to what we were talking about in this thread, we've released another TIPS and TRICKS post: TIPS and TRICKS: Graphics for Universal Apps