1. 10
  1.  

  2. 6

    “Steve Jobs famously announced that the iPhone “ran OS X”. After a week’s work, we determined: that was a lie. While iOS and macOS share a foundation, their driver are different enough to be incompatible.”

    Two devices with very different sizes and purposes, and yet which don’t use exactly the same device drivers? Inconceivable! 🤯 Unless I’m missing something, this is like saying “Android isn’t Linux!” because a Samsung phone has different device drivers than a ThinkPad.

    I’ve been writing code targeted at both Mac and iOS since 2008, using APIs from the C and POSIX level up to Foundation and (sometimes) Core Animation. Almost all of the time, the platforms are indistinguishable and my Mac code just works on an iOS device. A few percent of the time I need to deal with API or behavioral differences — the iOS filesystem is case-sensitive and directory layout is different; ARM is sometimes more sensitive to race conditions; Apple’s goddam Security framework is infuriatingly incompatible; CA coordinate system is flipped on iOS. But it’s the same OS in most ways.

    1. 2

      Two devices with very different sizes and purposes, and yet which don’t use exactly the same device drivers? Inconceivable! 🤯 Unless I’m missing something, this is like saying “Android isn’t Linux!” because a Samsung phone has different device drivers than a ThinkPad.

      It’s not that they have different drivers, it’s that the drivers expose sufficiently different interfaces to userspace. On desktop Linux, both X.org and Weston (or other Wayland compositors) use the same KMS / DRM framework for communicating with graphics drivers (unless you’re using an nVidia card). It doesn’t matter if you’re using an Intel or AMD GPU, you get the same set of userspace abstractions and you can run the same userspace window manager.

      In contrast, if you look at an Android device, it uses a completely different device driver interface for the GPU. You can’t run X.org on top of the drivers that come with an Android handset. This appears to be similar to the situation between iOS and macOS.

      That said, even if the kernel interfaces are the same, the kernel doesn’t actually do much for a modern GPU. It sets up a context, maps some command queues into userspace, and allocates memory and shared-memory mappings. It then gets out of the way. It’s entirely possible that iOS and macOS do expose the same XNU / DriverKit interfaces for GPUs, but the macOS version of WindowServer doesn’t include any of the userspace device driver bits for talking to them.

      This is even true to a degree between watchOS and iOS. Apple’s GPUs use a high-level tool to synthesize the instruction decoder and they spin a different version for their different platforms, optimised for dense encoding of the instruction mix that they expect to run for shader programs on the target platform. Even though the GPU pipelines are identical, you can’t run a shader program compiled for an Apple Watch on an iPhone.