FWIW, I actually was privy to the early discussions and feedback prior to iPhone 4/iOS 4. I wouldn’t nec. have solved the problem the same way, but I don’t think Apple’s approach was madness either.
The Apple approach to the increased resolution displays has, from their point of view, some advantages. First, by keeping the workspace the same, but higher resolution rendering behind it, all existing apps picked up sharper text and less fuzzy graphics primitives automatically. As long as you used them to draw text and primitives, you picked up better rendering.
A second benefit was that existing titles could be updated to exploit the benefits of increased resolution by simply dropping in higher res alternative graphics.
Something to keep in mind is that the api already took floating point values for locations and widths. So, the graph that I had in one app, where I just calculated the positions in floating point and drew lines, automatically took advantage of the higher resolution when available. My graphs got higher res automatically. They had already set the stage for the scheme by previously offering sub pixel rendering.
JUCE uses ints for positions, but still mostly gets a free ride to better resolution. Text and the graphics primitives all render sharper and with higher density on the higher res devices without having to do a lot of behind the scenes magic to fake matching up touch input, etc.
The problem pops up when one gets to graphics, but if you are using graphics in a resolution independent app, you are likely to end up with a similar approach anyway. Look at icons, you just get better visual quality when you draw the 16x16 for 16x16, and the 128x128 for 128x128.
I’ve been working on a JUCE port of an existing little mobile utility as a proof of concept here, and synfonysid’s approach already works pretty well. I dragged the Jucer display area to match horizontal and vertical orientations for the iPhone and laid out a bunch of graphics. I basically just took 2x graphics from the existing iPhone utility, and first set them to 1/2 in absolute pixels, then switched to proportion of parent. For text I used labels, but made those proportional as well, and added font change logic to resize. The 1, 3GS, 4/S, and iPad all look pretty good compared to the original, even though the iPad is a different aspect ratio. So I built for Android, Windows, and Mac, and they all look pretty good as well. If the platform is iOS or Android, I set the titlebar to 0 and maximize, for others, normal window bar and resizable.
I had to pick a base resolution for the graphics that was reasonable across all the uses, but that would be true regardless. And if I want graphical perfection, I have to pick between multiple resolutions based on the display. Not the primitives, they are already handled. Text, graphics primitives, etc. already look sharp. But the PNGs have to be the right resolution and positioned so that the aspect ration fits the surface.
You want to do that yourself, which I can understand (though I don’t nec. understand the benefit of having JUCE giving you back renderer resolution as pixel resolution, then faking pointer resolution, as opposed to just obtaining underlying rendering resolution in the cases you really care). But, again, consider Apple’s point of view. They addressed a problem that all applications will have to face and chose to do so in a way that let app writers pretend that only two resolutions (iPad and iPhone) exist. They’re goal was the easiest path to resolution usage for developers on their platform, not people writing platform independent apps.
Again, this actually isn’t the way I would have handled the same problem, so I don’t contend it is ideal. But having deployed a bunch of iOS apps and supported them from 1G to iPad-2, I don’t think it is madness either.