I have a feeling that the reason that Apple hasn't made their Simulator into an Emulator, is because they don't want folks digging into the substrate of iOS.
Another reason it was a Simulator and not an Emulator to begin with could be because a lot of iOS (or iPhone OS) components at the time were forks of existing Mac OS X libraries.
The reason to begin with was the Mac OS was x86-32 and the iOS environment was arm. Building for intel let the ui devs have high performance by leveraging the existing network stack and graphics compositor. But most of the libraries live parallel in the sim, not using the OS ones. That wouldn’t allow you to simulate different iOS versions.
Slightly OT but the first iPhone ran OS X at launch.
I think as time went by and the "OS X" running on phones diverged more and more, they renamed to iPhone OS and then iOS some time later? Something like that anyway.
It's not the same as Mac OS X or macOS, they share a common kernel, system libraries etc but the userland is very different on an iPhone or Apple Watch.
It's not the same version of OS X that ran on Apple's computers. The "it's OS X" was more for marketing, they just share the same "core".
You could argue that the iPhone currently still runs macOS if you used the same definition today. They share kernels (iirc Apple always kept the ARM patches to Darwin closed-source), BSD-based userlands and the iPhone used versions of the macs application libraries.
A big difference is the iOS and macOS use different compositors.
I really do wonder now that both iPhones, Macs, and iPads are all "arm64" (Apple Silicon no less) how different the bootloaders are for iOS vs MacOS. Once you are past the bootloader, why would they be maintaining two different operating systems/lots of differences if they don't have to, especially since they seem to control the hardware?
The hardware was drastically different between Macs and iPhones when iOS was released. That was in 2007. Apple only unified the hardware in 2020. Over the *13* years, the operating systems have diverged so much that unifying them is a massive effort. The linked blog post by Zhuowei Zhang shows some of the differences. The user-space components are just so different that it's not as simple as running a macOS app on iOS.
EDIT: You can run a iOS apps on macOS without recompilation, but it uses Mac Catalyst which is a user-space shim for iOS apps to work on macOS. Even then, not everything works.
In this case, the app is running in a sandbox with a user-space that simulates the iOS user-space [0].
> Your apps use the same frameworks and infrastructure that Mac Catalyst apps use to run, but without the need to recompile for the Mac platform.
> Although you can run your iOS apps unmodified on a Mac with Apple silicon, Mac Catalyst lets you build your app specifically for macOS and customize your app’s behavior on that platform.
Mac Catalyst was a multi-year effort by Apple. Doing the same to run macOS apps on iOS would probably be even harder due to how complicated macOS is compared to iOS.
It seems you agree, except previously you said “Likewise, you can't just run a iOS app on macOS. You need to recompile your app with Mac Catalyst for it to work. Even then, it's a bit jank.” That’s not true, you can just run an iOS app on macOS.
I edited my original comment. The "It's a bit jank" part is still true though. When you enable running your app on macOS without compiling specifically for macOS with Mac Catalyst, it still uses Mac Catalyst, but transparently. So, you still get all the issues of Mac Catalyst, but without the compiler warnings. Your application may crash or behave strangely.
They aren’t actually too similar. They both use XNU, but the memory model is completely different. On macOS memory can be paged to/from disk. On iOS it isn’t and applications must free memory when asked or be terminated [0].
iOS applications are sandboxed by the kernel, with no opt out. macOS applications are not sandboxed by default and are opt in.
> On macOS memory can be paged to/from disk. On iOS it isn’t and applications must free memory when asked or be terminated
Not sure what you meant by that, you always could `mmap` files into memory on iOS. Back in the 32 bits days there was a ~700 MB limit due to the address space, but there aren't anymore nowadays with 64 bits. If `didReceiveMemoryWarning` is called on your app, then you need to free resident memory but the kernel will take care of dumping file-backed memory pages for you.
> Back in the 32 bits days there was a ~700 MB limit due to the address space, but there aren't anymore nowadays with 64 bits.
Not true, unless something changed recently (definitely more recently than the 32->64 transition). All iPhones have a virtual memory limit (although the limit is higher on phones with more physical RAM).
I know this for sure because several years ago I was the main person in charge of reducing OOM kills on the Facebook iPhone app and virtual memory exhaustion on 64-bit phones was definitely an issue.
That's memory mapping. This is memory paging [1]. I.e. Windows pagefile.sys, Linux swap, macOS swap files. iOS does not have swap files, only memory compression. If you're on a Mac, open up Activity Monitor, go to Memory, and at the bottom there is `Swap Used`. That doesn't exist on iOS. So, if more memory is used than available, applications will need to free memory or be terminated. Unlike macOS, where some used memory will be swapped to disk to allow other stuff to be loaded into memory.
It's most likely just disabled rather than being completely different/non-existent. But yes, the application model is built around limited to no multitasking.
More like Objective-C++, as otherwise it is lots of fun calling macOS APIs from C++.
And no, C++ isn't as prevalent on Apple platforms as on other vendors.
Hence why you will find out most of the C++ related documentation is for IO and Driver Kit, the Metal Shading Language dialect (based on C++14), LLVM, and that is about it.
Even Metal is actually implemented in Objective-C, with Swift and C++ bindings, and the C++ bindings are really low effort versus the Swift tooling.
I have a feeling that the reason that Apple hasn't made their Simulator into an Emulator, is because they don't want folks digging into the substrate of iOS.