The simulator is not actually running real iOS or the iOS build of your app. Instead, when you run an app in the simulator, your app is being compiled to the current Mac’s native instruction set and links/runs against a set of Mac frameworks and libraries that _simulate_ and in some cases only stub in the expected iOS behavior. So as an example, you can’t just take an iOS binary off of the App Store and run it in the iOS Simulator (especially not on an Intel Mac). You also can’t use the simulator to probe and learn anything about how real iOS works internally, because the simulator isn’t really running full iOS. If you drill down in the simulator’s frameworks far enough you eventually just find yourself back in macOS.
Contrast with an emulator, where you are just running the full iOS build identical to the build on a real device. You would in theory be able to run any iOS binary unmodified and probe how the real os works.
It’s sort of like the difference between running an app through Wine versus running an app in a Windows VM, except in the case of the simulator it’d be like if you had to custom recompile/link a Windows app first against the Wine environment before being able to run it. If you wanted to study how Windows works internally, there's not much you can learn about that from running Wine, but there is quite a lot you could learn from probing a VM running Windows.
Since you are someone who seems to know what they're doing I hope you'll forgive a random unrelated question: do you happen to know if it's possible to call out to M1 code inside Rosetta2? It seems like this should be possible since Rosetta2 is (supposedly) a transpiler and so it's (supposedly) really running M1 code under the hood, but I haven't been able to figure out a way to call out to native M1 code.
That's a great question. The short answer is: no, you can't, but not necessarily for the reason you might expect. The long answer is: Rosetta 2 is indeed a transpiler generating native arm64 code, but transpiled code running via Rosetta 2 vs. native arm64 code in macOS use two different ABIs. Transpiled Rosetta 2 code uses a arm64-ized version of the System V x64 ABI that contains a direct mapping between x64 and arm64 registers, whereas native arm64 code uses the standard arm64 ABI. There's a lot of magic going on in the Rosetta 2 arm64-ized System V ABI that is necessary to make Rosetta 2 work.
One interesting side effect of this ABI difference comes from modern x64 macOS using AVX2 instructions by default but Rosetta 2 not supporting AVX2. Because Rosetta 2 uses a different ABI than native arm64, code running under Rosetta 2 can't just call into the native arm64 system libraries; for calls to system libraries, Rosetta 2 transpiles from the x64 versions of those as well, which are available on Apple Silicon Macs thanks to the universal binary architecture. In macOS, all of the commonly used system dylibs are pre-linked into a single giant file called the dyld cache. Since the native x64 dyld cache contains AVX2 instructions though, it isn't usable by Rosetta 2, so for when a system library call requires going into the dyld cache, Rosetta 2 ships with a _separate second version_ of the x64 dyld cache that is compiled without AVX2.
This is an interesting quirk that has proven to be exceptionally useful for getting newer macOS versions running on older unsupported Macs that have Intel CPUs that are too old to support AVX2.
IIRC Rosetta 1 did attempt to use the native x86 versions of system frameworks, but there were issues with floating point precision between the emulated and native code. I don't remember if they gave up on it, fixed it, or just left it like that.
Note that that reply isn't authoritative in terms of Apple choosing or not to stray from reusing code/frameworks across macos for simulating/emulating and ios
Contrast with an emulator, where you are just running the full iOS build identical to the build on a real device. You would in theory be able to run any iOS binary unmodified and probe how the real os works.
It’s sort of like the difference between running an app through Wine versus running an app in a Windows VM, except in the case of the simulator it’d be like if you had to custom recompile/link a Windows app first against the Wine environment before being able to run it. If you wanted to study how Windows works internally, there's not much you can learn about that from running Wine, but there is quite a lot you could learn from probing a VM running Windows.