I'd be willing to bet a lot of money that iOS already works well on x86 and has never not worked well on x86. After all, the core OS maintains ongoing heritage with an x86 OS, and every single app in the store has already been successfully compiled for x86...
> The simulator is not one. It's really a cross-compiling trick.
Uh? No, that's the exact opposite, the simulator is exactly a simulator. What it's not is an emulator: it does not emulate an ARM device, it simulates an iPhone by running iOS/x86.
An emulator does exactly as it says: it emulates. It creates an environment that appears to a running program to be identical to the real thing. This is done by emulating the hardware (e.g. BSNES), emulating the runtime environment for a native binary (e.g. VMware), or most commonly, a mixture of both.
A simulator -- at least in the world of Apple iOS development -- does not attempt to emulate iOS hardware, or even the iOS operating system. All the simulator does is provide a virtual display and launches an instance of Launchpad.app. Your app then runs within that virtual display, and talks with natively compiled copies of the iOS APIs, but otherwise it's a normal Mac OS X process that can be viewed and poked with Activity Monitor, or top, or whatever.
The simulator doesn't need to "boot up". There are no virtual drivers. There's no memory management. There's no emulated silicon whatsoever.
The only downside to this approach I can see is that the simulator can't be used to test some things like resource limits, and some things behave very differently, like OpenGL. But you have to test on real hardware anyway, and Apple have made native testing just as easy as simulated.
Thanks a lot for bringing up this subject. I feel unimaginably ashamed for never considering iOS Simulator was in fact, as the name might suggest, a simulator!
An emulator would be binary compatible with the actual device by emulating the ARM instruction set on top of x86. The iOS simulator doesn't do this but instead runs a flavor[1] of iOS natively directly on x86 that is API compatible but not binary compatible (i.e. compiled binaries for the simulator cannot be ran on the devices).
[1] The simulator OS also has distinct limitations that diverge from the real device or what you would expect from a truly emulated environment. There's no motion detection, no GPU performance, no accelerometer or compass, location data is simulated, multitouch input is limited, some frameworks are not available, etc).
Even if the environment was "truly emulated", there would still be no motion detection, accelerometer, compass, location data or multitouch input.
Nor is it likely for the emulated environment to be able to provide a sufficiently accurate performance analogue to the devices' CPU and GPU.
The simulator is the ideal development environment: stupidly fast, and completely reliable for most day-to-day development tasks. For Apple to provide more accuracy in the simulator would be a waste of their time, when you can just as easily run your app on a device.
Theoretically it would be possible develop your app in Xcode and only ever compile it for ARM and test on the actual device.
But if you use the iOS simulator to develop/test your app (which I imagine every developer does), then you're running your iOS app natively on OS X, linked against a version of all the iOS libraries compiled for x86.
No, actually. There are a couple of third-party development tools for iOS which only compile to ARM (and which therefore can't run in the iOS simulator), notably Adobe Air for mobile, and that Delphi for iOS thing. 99.999%, though; anything written in Xcode, and anything written with the majority of third-party tools, has been run in the simulator.
From what I understand, the problem with x68 is the lack of processors that can compete with ARM on battery life, which is one of the most important aspects of a portable device.
Once Apple can get iOS working well on x86, they'll do the same.