Hacker News Reader

Comment by ChrisMarshallNY | Hacker News Reader

Very cool!

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.

View on HN

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.

> iOS (or iPhone OS)

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.

The first iPhone ran iPhone OS 1.0

Well, I never owned one of them, so maybe I'm not supposed to comment on this. But their website was very clear: The OS on the first iPhone was OS X.

https://web.archive.org/web/20070112064939/http://www.apple....

It's about as Mac OS X as Apple Watch runs macOS.

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.

Apple advertised the first iPhone to run OS X: https://youtu.be/VQKMoT-6XSg?t=506

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.

Developers still use Intel Macs, and you can't virtualize ARM iOS on that.

The overwhelming majority use ARM Macs these days

Doesn’t sound like a strong enough reason for the visionOS team.

Yeah, I was thinking about the ARM Macs. They are common enough, now, to make it worthwhile.

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.

You can run iOS apps directly on M1 Macs. Some developers flip a bit to disable this, but there any many that don’t.

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.

[0] https://developer.apple.com/documentation/apple-silicon/runn...

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 are very similar. The differences are largely in that macOS generally will permit some things that iOS will not.

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.

Then there are the API and UI differences.

EDIT: That linked blog post in the parent blog post also shows how different the userspace is: https://worthdoingbadly.com/macappsios/

EDIT: iPadOS 16 enables virtual memory swap [1]

[0] https://developer.apple.com/library/archive/documentation/Pe...

[1] https://www.apple.com/newsroom/2022/06/ipados-16-takes-the-v...

> 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.

See here for where this is enforced in XNU: https://github.com/apple-oss-distributions/xnu/blob/xnu-1121...

I assume Apple does this specifically because they want to prevent apps from simulating swap space by mapping a big file and allocating from it.

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.

[1] https://en.wikipedia.org/wiki/Memory_paging

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.

> It's most likely just disabled rather than being completely different/non-existent.

As evident by the limited Virtual Memory Swap enabled on iPadOS 16, but not iOS.

All Apple devices use the XNU kernel. But, as the parent blog post shows, the kernel configuration, device tree, and drivers are different.

> how different the bootloaders are for iOS vs MacOS

They are basically the same between Apple Silicon Macs and iDevices.

https://khronokernel.com/apple/silicon/2021/02/07/BOOT.html

https://github.com/AsahiLinux/docs/wiki/SW:Boot

Very different user experiences, and also, the Mac development ecosystem is well-established. I suspect a lot of Mac AAA apps are done in C++.

Probably a lot of iOS AAA apps are still in ObjC.

It is unwise to pull the rug from established developers.

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.

Depends on what part of Metal you're talking about.

I explicitly mentioned the only part that is C++, well a flavour of it.

Reply on news.ycombinator.com