The company I work for develops iOS apps for children. We currently support all devices going as far back as the 3GS. That being said, our apps would run on the the following resolutions:

480x320 - original iPhone

960x640 - retinal iPhone

1136x640 - iPhone 5 Retina

1024x768 - iPad

2048x1536 - iPad Retina

We're currently using Unity and a on-size-fits-all approach where we use a generic resolution of 1366x768. This produces a few problems:

-This resolution doesn't fit anything exactly so it skews our graphics making our artwork kind sort of fuzzy on everything

-All assets have to be noticeably larger resolution textures on smaller devices (128x128 only takes up 80x80 pixels, for example)

-Massive performance issues due to filtrate bottlenecks

-Memory issues due to larger textures (the 3GS doesn't load)

Just to address that fill rate issue further: our games are small click-and-react types right now and just about every scene uses a padded 1024x1024 background texture and a 1024x1024 texture atlas for our game object. We're drawing maybe 18 - 20 things onscreen at a single time in yet, we still have very choppy frame rates.

What we'd like to do is develop a game with the following criteria in mind:

-Use one universal app

-Keep the game under 50MB

-Try to stay away from DLC to download assets that don't fit into the 50MB, if possible

My approach would be to develop all of our assets based on a generic viewport of 1024x768, which is based off of the original iPad's resolution. Then, just crop for the iPhone's 960x640 display (I'm ignoring the iPhone 5's 1136x640 display for the time being). I'd use a 480x320 display for the 3GS, iPod 4 and iPhone 4 to avoid fill rate catastrophes. I'd generate the low-res textures by rendering the high-res ones in the bundle to a texture at 50% scale, then release the high-res ones from memory. Loading will take much longer on these slower devices, but at least we don't need to keep track of duplicate assets that'll bloat our bundle.

Another approach would be to use a generic viewport of 1136x768 to account for the iPhone 5 and low-res iPad resolutions. Then, continue with the crop-n-scale routine mentioned above.

Can also avoid using bitmap images, instead stores assets as vectors and convert to bitmap as required for the required resolution.

Vector assets are typically much smaller than bitmaps, so file size / load times usually have a good tradeoff. it also avoids getting ugly artifacts from downsampling/upsampling your bitmap art.

I think we came up with a workaround. What we'd do is crop the 1366x768 width-wise to 1024x768 for everything, and use that for all iPads. Going retina it too heavy for mobile devices. Next up, we'd have two sets of assets for backgrounds: 1136x640 for iPhone and 1024x768 for iPad. All other assets that would fit in the room could be drawn at iPad-resolution, and scaled-down programmatically for iPhone. Scaling down with linear filtering seems to look nice, and although we're still adding many more pixels to the screen for these smaller screens, we don't have to double everything which allows us to meet managements goal: keep it under 50MB.

EDIT: I'd like to mention that the iPhone 5's 1136-width for native resolution is obviously too large to fit into a texture, so we crop the width down to 1024 on each side. That way, the main part of the texture takes up 1024x640 of the 1024x1024 texture. The sides that were cropped get added in the unused region of the 1024x1024. They have to be rotated to fit properly.