Worth Doing Badly

The achievement is massive - but if I understand what’s going on the title is misleading; I think it is more like running a patched macOS userland via chroot. From an outside point of view, the author is cryptic about context, but the technical details are even more fascinating. Some technical details in this thread:

https://www.reddit.com/r/jailbreak/comments/1mn7mk1/comment/n8319s9/

- Based on a POC done by Zhuowei Zhang few years ago, I think that is happening is that the author is using a filesystem from an existing macOS to run WindowServer and and enough of the supporting daemons.

https://worthdoingbadly.com/macappsios/

- Moreover, TFA’s solution requires a host iPhone Simulator to all Metal acceleration via XPC, using the same shim that provides Metal debugging.

To be clear, though, “iOS kernel provides enough facilities to run entire macOS userland” is an incredible discovery and achievement. It demonstrates that it is an order of magnitude easier to give iOS a genuine desktop environment than we would assume.

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/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html

[1] https://www.apple.com/newsroom/2022/06/ipados-16-takes-the-versatility-of-ipad-even-further/

I work on some Mac applications that, at times, try to exceed what MacOS applications are capable of doing.

They almost always break between MacOS releases. Usually the cause is that Apple improved various security restrictions in Gatekeeper. What tends to happen is that older builds work fine, but any new builds don't work well.

But, what's interesting is that the page at https://worthdoingbadly.com/assets/blog/appkitcompat/appkit_processed.html doesn't list any bundle hashes. I always assumed that Apple's hacks for backwards compatibility were tied to the bundle hash, and not the specific application.

A14/M1 and higher all have the hardware for virtualization, nothing is fused off for "devices". iOS and iPadOS don't ship Hypervisor.framework but the kernel still recognizes the entitlements for using it. Apple will never sign provisioning profiles with those entitlements, of course; but on at least one particular OS version with a jailbreak you could set up hardware virtualization. See https://worthdoingbadly.com/hv/

The main problem is purely just Apple not seeing a use case for virtualization on a touchscreen. They need to let go of at least one Strongly Held Belief.

This looks to be a follow up of:

https://worthdoingbadly.com/vowifi/

Which was a really good read!

I noted this however:

> However, VoLTE’s implementation is not compatible with our everyday VPNs and VoIP software. This report from Sysmocom shows that it would take months to modify Ubuntu Touch for VoLTE support.

I wonder why that is? I am using a Pinephone with Mobian right now, and a Librem 5 with PureOS, and both support VoLTE just fine.