Hacker News new | ask | show | jobs
by xenadu02 2830 days ago
> 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.
1 comments
CodeWriter23 2830 days 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.

link