Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now).
But orientation changes? Is that not a general "mobile issue" for you? Or is (are) the WebKit build(s) in iOS doing something specifically bad compared to (say) Android?
If you rotate an iPad from portrait to landscape, for example, then the default behaviour in Safari is to show the same page layout as you had before, but scale it up to the new width. That's far from ideal if your site uses a responsive design that could adapt quite happily to use the extra width in a landscape orientation.
Can I just mention that at least on my phone, websites that "adapt" to landscape mode often bug the hell out of me. With my getting-old-eyesight, I often rotate to landscape mode to get bigger text so I can read it more easily. When a website goes "Oh look, more horizontal pixels, I'll shrink the middle column and add some nav on the left and ads on the right!"; I'll usually just hit [back] and move on to some other site.
(Possibly interesting idea: add some analytics so that you can detect portrait/landscape orientation changes, and report on bounce rates immediately afterwards…)
In our defence, we do our best to keep the standard zoom gesture working and we use a reasonable default font size. We're not 21 any more either. ;-)
However, for most of our users, a zoomed single-column layout is going to be less useful than switching to two columns when in landscape mode on an iPad.
On an iPhone, you should see a single-column layout in either orientation using the design we're currently testing.
Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now).
Not "right now". As long as you intend to support "retina displays", it will always be an Apple-specific thing.
If you want to support something as general as high-DPI devices, you know, something concrete and not an Apple marketing-term, there are certainly lots of those being made and sold as we speak. They run Android and are not made by Apple.
You might want to consider supporting those as well.
I downvoted you because your post seemed unnecessarily pedantic and condescending to me. I think it was pretty clear that GP was casually (or accidentally) using "retina display" as a generic term for "high DPI display".
Still: targetting "retine display devices" is wrong for a multitude of reasons. You don't want your website to be tailored for a device which has 4x the number of pixels of another very specific device made by one vendor only. That is not the problem you are trying to solve.
The problem you are trying to solve is creating a DPI-independent site layout which exploits the resolution and estate available, while degrading gracefully on lower class devices.
If your solution to that problem is making your website hardcoded to fit two devices made by one vendor, as long as they remain true to leaving everything pixel perfect as they are now, for all eternity, needless to say, it's not a good nor elegant solution.
It's the "This website was made for MSIE" of olden days all over again, only this time for Apple-devices. And thats just not going to cut it.
The server should not have to decide which image to send, based on whatever it can gather of a combination of various factors, including device display resolution capability (double-density vs regular pixel mapping) and connection quality (wireless vs broadband) or whatever else comes into play. The server should be advertising the capability of high res images and the user agent should be requesting them if it wants.
That's a great idea, but that's not currently how it works. All of the high-res website image stuff that I've seen all uses client-side JavaScript to fetch the 2x images.
In my experience, the problem is that the Android/WP7/[other smartphone OS here] web browsers are so far behind iOS WebKit in terms of functionality that you basically have to handle each device on a case-by-case basis. Given that, a lot of developers choose to focus solely on iOS since it's the lowest-hanging fruit with a massively large userbase and a relatively-standards-compliant codebase.
For example, all mobile web browsers should theoretically throw either a resize or orientationchange event on orientation change, but some Android devices don't, with no other viable fallback, and no clear rhyme or reason as to which devices support it and which don't (other than that newer flagship devices are slightly more likely to be standards-compliant). CSS media queries are more consistently supported, but they aren't the solution to every problem.
But orientation changes? Is that not a general "mobile issue" for you? Or is (are) the WebKit build(s) in iOS doing something specifically bad compared to (say) Android?