@Vabu: To be clear, avoiding hardcoding device names is so that unmaintained software keeps working without needing to be recompiled. If you're willing to recompile to fix operation when new hardware comes out that surprises you, then you're of course welcome to make the choice to hardcode specific device names or any other test you like.
As a practical example, bkervaski's second post is a great example of what not to do. It'll break with the iPhone 5 (and by break I mean "you don't get HD graphics"), it'll break on the iPad HD in the same way, and it's broken _now_ on the Simulator in iPhone 4 mode and the iPod Touch 4G. If this code choice was being used for something like using or not using PopoverView, then breakage would be "application crashes" instead, which is obviously much worse.
The Simulator is actually a really good example of why this is a bad thing to do. ^_^ Once you're in the Simulator, you need to test something _else_ to know if your simulating an iPhone, iPhone 4 or iPad.
@MikeSz: I suspected the original OpenGL ES 2.0 poster was simply interested in speed, yes. I'd suggest that OpenGL ES 2.0 support might not remain the best indicator of that (what if Apple puts out a super-low-power device of some kind that supports the OpenGL ES 2.0 API but runs really slowly?). I grant you it's pretty unlikely over here in iOS land, but for me it's a lesson learnt in desktop PC land which actually seems to carry quite well into Android development.
On the other hand, doing the "can we intialise the API" test is at least as good, if not better, than checking GL_VERSION. ^_^
Don't the "faster" devices you've listed all use a different, faster CPU core at a higher clock rate? I'm not sure off hand how to detect that, but I expect it's possible. I'd also suggest maybe blacklisting the "PowerVR MBX Lite 3D" GL_RENDERER string, although that could potentially change if anything with that chip gets a new iOS version which drags in an updated OpenGL ES driver for that chip.
The safest way (albeit not really fun) is to actually measure some code-execution time on first startup, and remember the result for later. It's not ideal from a user-experience perspective, but it doesn't have to take _long_. You'll need hardware to validate this testing on, too, which is a pain for the individual developer.
Anyway, the issue with not doing "bad" things is really just trying to avoid relying on things that your platform provider has not promised not to change out from under you. It's not secret or magic, but we (and by we I mean those of us with a long-enough background to have been burnt by this already) are simply trying to help people avoid a rather common mistaken practice.
There's some principle about "making the right thing easy and the wrong thing hard", the exact wording of which escapes me.
So if you're going to pick something to base your code-path choices on which is not fixed in your platform API, the choice has to be good.
I don't personally think "API support" is good in the general case, although when you're identifying abandoned hardware or it's an API that's hardware-dependant, it is probably OK.
Certainly "device name" is very rarely good, unless you're blacklisting things, and you really don't expect the hardware name layout to change or new devices to appear under the old hardware.
The best choices for these things involve numbers reflecting some physical reality. Clock speeds, number of cores, physical RAM present (although that's not particularly good) and the like are good, because your test will be rather more future proof.
Anyway, I dunno where the anger that just appeared above came from... That's just bizarre. But really, if you think something is a bad practice, and can provide a coherent reasoning for it, please please please go ahead and discourage it. Don't be an ass about it, but sharing knowledge and experience is what this kind of coding forum is all about.
Keep in mind, Cocos2d isn't a democracy. It really isn't a meritocracy. It's a (benevolent) dictatorship under the control of riq. And so taking anything _into_ the framework is to a certain extent riq blessing that thing as "the right thing to do". Which is very different from a developer's personal choice to use a chunk of code in their own project. If code like this goes in (which kinda replicates or extends UIDevice's model property) I'd hope it'd be called something with "Display" in the name to make it clear that it's intended for display purposes only, rather than device capability identification.
