Originally Posted by Alfiejr
but of course apps designed graphically for the iPhone's aspect ratio - as so many are, including all the games - will look crummy stretched to fit a different one. the iTab could letter box or pillar box them, sure, but that just wastes screen area, so why? and Apple loves to standardize its stuff, which is smart of course.
CGRect cgRect =[[UIScreen mainScreen] bounds];
CGSize cgSize = cgRect.size;
// device screen dimensions available as cgSize.height, cgSize.width
Not necessarily! The above code gives both the screen size and aspect ratio. This tells the developer the largest rectangle of his content that can be displayed at one time (his content is likely larger or smaller and a different aspect ratio than the screen size). In the case of larger content, that which is not currently displayed is drawn offscreen and made visible as necessary by panning and scrolling. A canny developer will design his app, from the start, to be aware of this screen size and compensate as needed.
Even when the developer has no control over content, as in the size and aspect ratio of a movie, you have built-in adjustments. Apple's Movie Player, for example gives the user options:
1) display movie in actual size with letter box, pillar box or both
2) zoom, until one dimension fills the rectangle and letter box or pillar box the other
3) zoom until smallest dimension fits rectangle, cropping the other
Where the developer has control of the content, he has similar options (that good developers plan for in advance).
1) position the current [smaller] rectangle, as is, (usually centered) within the larger screen (rectangle)
2) zoom the current rectangle as above
3) adjust the dimensions of the current rectangle to conform to the larger screen (rectangle)
This is actually easier than you might assume. There are many powerful constructs within the Apple-supplied tools, languages and frameworks that allow these things to be done easily and efficiently.
At least as big a concern is the speed difference of new device. Will the app perform well on a faster CPU/GPU (possibly with interference from background tasks)? Again, the smart developer will anticipate this! Where necessary, the app will be written in such a way as to adjust its speed to ambient conditions.
Actually, the biggest need for change in the app may be for textual information. Consider:
1) many iPhone apps contain drill-down lists, tab bars, and navigation bars.
2) Often, their use can be seen as a poor man's table for a small screen and slow[er] CPU
With a larger screen and faster CPU, it becomes practical (necessary in some cases) to replace the above with a multi-column table, where columns are resizable, sortable, can be repositioned or displayed at the option of the user (think iTunes).
Fortunately, table constructs for this already exist in [Mac] Cocoa (large screen Cocoa). The [iPhone] Cocoa (Cocoa Touch) is a subset of the [Mac] Cocoa. Presumably, when larger touch screens become available, Apple will migrate these frameworks and APIs to Cocoa Touch.
This won't eliminate the need to recode the textual app for a larger screen, but it should make it easier.
Interestingly, one thing that migrates quite well (in both directions) is CoverFlow. This framework/API is private in both [Mac] Cocoa and [iPhone] Cocoa Touch, So developers can't [currently, legally] use it.
I hope that this will be allowed when larger touch screens (and presumably, more open architecture) become available. There are some exciting possibilities for the CoverFlow UI.
Finally, a small screen [iPhone] app, by necessity is limited to one set of content at a time. The user works on it, puts it away, then opens another.
With a larger screen, the app may need to be rewritten to handle multiple windows open at the same time, possibly overlapping and sharing the screen with the windows of other apps.
Here, [Mac] Cocoa, has already plowed this ground, and the APIs/Frameworks could be migrated to [iTablet] Cocoa Touch, to mitigate the rewrite effort.