3 ms·

> It merely translates the iOS calls into OSX ones That is not an accurate description of what the simulator does. It is a separate userspace running on the sa

> It merely translates the iOS calls into OSX ones That is not an accurate description of what the simulator does. It is a separate userspace running on the same kernel, in this case the iOS userspace running side-by-side but isolated from the macOS userspace. The simulator uses entirely iOS binaries, built for x86/x86-64. This includes UIKit, Foundation, libc, libdispatch, etc. It does not use the macOS ABI, nor the macOS libc/Objective-C/Swift runtimes. Each individual simulated device is its own isolated mach bootstrap, with its own separate launchd, daemons, and XPC services. With the exception of a few libraries like the syscall interface and libpthread, which are tightly bound to the kernel.

CodeWriter23 8y ago
And still, the simulator is not the same as running on-device. Much of the iOS security model is non-existent in the simulator. If you’ve ever written an AppEx using a shared container, you know that. (Or you’re running to verify your code works on-device right now) The simulator has to render the screen via the macOS display device, and I can tell you my trusty Radeon 5870 is only up for rendering about 5 frames per second in the simulator. I’m pretty sure any Metal apps will be wildly different in the simulator. I don’t even consider myself an expert iOS Programmer at this point, and I can come up with three examples off the top of my head. I’m sure there are plenty more. And there’s a reason every single iOS library or widget on GitHub requires all bug reports to be made only after testing on-device.