Once Apple can get iOS working well on x86, they'll do the same.
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...
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.
Presumably an emulator copies the actual instruction set, while a simulator... only pretends to copy the instruction set?
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.
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).
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.
On iOS cross-compilation only occurs when you target an iOS device such as an iPhone which generates armv6 and armv7 code.
Really!?
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.
On the flip side, ARM doesn't scale as well as x86 to higher power outputs.
Perhaps not for the Hacker News audience. I'd assert that an iPad -- perhaps with a bluetooth keyboard -- is already enough computer for 70% of western world.
I'd say especially for the HN audience.
A lot of people around here live most of their lives in the terminal, using Vi and Git. They have no reason to work on a beefy machine, as long as they can access more hardware somewhere else. It could be a server in the closet, or "the cloud".
When I bought my first laptop and started doing webdev in 2001, I noticed that all I needed was enough power to play music, edit text and run a web/database server. It worked great with win2k WAMP on a P2 266 MHz, 96 MB, 4 GB. My much more powerful desktop was suddenly left powered off most of the time.