I'm sure you're correct, but that seems backwards. OpenGL is a cross platform API, why would that be emulated in software? And the iOS devices have a different CPU architecture (ARM) than the MacBook Pro (x64) you develop on, so how is that being run as native code?
I can only speculate as to why OpenGL is rendered in software, I assume it has to do with the fact that the graphics capabilities are different on iOS versus Macs, and perhaps software rendering is needed to ensure consistent behavior or implementation of OpenGL extensions (though I'm not positive that the simulator offers the same OpenGL extensions anyway; I'm not a graphics programmer so I haven't really explored this).
As for it being a simulator, it's because your app actually compiles to x86_64 code when you're targeting the simulator. When you switch between targeting the simulator and targeting a device, your app is recompiled for the new architecture. And the simulator includes a complete copy of iOS and all its frameworks (but without most of the built-in apps) that were compiled for x86_64 in order to run in the simulator.
OpenGL is not being emulated, it's being implemented. OpenGL is just the API and specifications, it's up to individual graphics hardware vendors to put a conforming OpenGL implementation in their driver. Ideally it would all be done very fast in hardware, but there are still times when a particular feature can't be done on certain hardware, and is performed in software to conform to the OpenGL spec.
Apple already has a complete software OpenGL implementation, which they may have modified to simulate the individual OpenGL ES implementations for each iOS device. This also has the advantage of removing the developer's hardware from the equation: If they want to test a bleeding-edge OpenGL ES app on a really old MacBook, it'll run - just slowly.
