Well grasshopper, apparently iPhone app developers are sooo stupid and sooo lazy that that can't handle coding for multiple screen sizes.
Honesty, isn't computer science 101 to never assume a given screen size? (I program fro Mac's and PC's, but not iPhones, so maybe there is something I am missing here. Does the iPhone only support bitmaps?)
Yes, if you have never developed for iOS, then
there is something that you're missing here. It's not that iOS developers are lazy; it's that Apple didn't include the necessary tools and support within their devkit/SDK and the API for their developers to create truly resolution-independent apps. If the platform doesn't support it, the platform doesn't support it. Now, there has been speculation that
Apple will be bringing over the Auto Layout APIs to iOS 6, but the fact is that even if this happens,
they still didn't exist for iOS developers to use before iOS 6, so you
still have the problem of what to do about pre-iOS-6 apps.
Stop saying there are few screen sizes for devs. There are many iOS screen sizes. 1024x768, 768x1024, 2048x1536, 1536x2048, 960x640, 640x960, 480x320, 320x480, and about to add 1136x640, 640x1136.
Wrong. As of right now, before the release of "the new iPhone," there are only two screen "sizes", and
they're measured in "points", not "pixels": 480x320, and 1024x768. The other resolutions you listed are either the retina resolutions -- which are
exactly twice the resolution of the old screens in
both dimensions
for a reason -- or the opposite device orientation. The retina resolutions don't count as an extra resolution because, again, developers write apps for resolutions measured in points, not pixels, and both the non-retina and retina resolutions are the exact same number of "points", so apps written pre-retina only needed to have their bitmap graphics updated to include so-called "2x" images, while all of the other controls remained in the exact same place without the developers being required to change anything,
even if they referenced the placement of those controls using absolute screen coordinates.
As far as the iPhone vs. iPad resolutions or the different screen orientations go, these are actually very good examples of exactly why Apple has avoided a multitude of different screen sizes so far: again, because of the lack of good resolution-independent APIs in iOS to-date, you will recall that when the iPad was first released,
not a single iPhone app that had been released before then scaled to fit the iPad screen natively. Were
all iOS developers lazy before the iPad? Really? You'd think that there would have been at least
one developer that had "done things right" and had written their iPhone app to adjust for different screen sizes in case Apple ever made an iOS device with a bigger screen, right? No: every single iPhone app on the original iPad had "black bars" around it and was either displayed in 320x480 pixels or pixel-doubled to 960x640. And app developers who want to write for iPhone and iPad have to in essence
make two completely separate versions of their app. You can release the app as a "single app" in the store as a universal binary so that you don't have to list it twice, but it really is basically two different apps inside one app bundle.
As far as the screen orientations go, you can try to use the "springs and struts" control placement system to automatically adjust your app for portrait or landscape views, but that system is so limited and primitive that
most developers actually end up writing two separate views for their app, in essence crafting two separate UIs: one for portrait orientation, and one for landscape. So, yeah: not a good example of "resolution independence," which for all intents and purposes does
not exist in iOS.
-- Nathan
