Mac

Mach was developed at Carnegie Mellon University from 1984 to 1994 by Richard Rashid and his team. The goal: build a microkernel that could replace the monolithic UNIX kernel while maintaining POSIX compatibility — all kernel services (file systems, networking, device drivers) would run as user-space servers communicating via message passing.

The CMU Mach 2.5 kernel, with its elegant IPC model, became the foundation NeXT chose for NeXTSTEP in 1989. When Jobs returned to Apple, Mach came with him.

macOS's kernel is named XNU — "X is Not Unix." It's a pragmatic hybrid: the Mach microkernel provides the lowest-level abstractions (threads, virtual memory, IPC, task isolation), while the BSD subsystem (FreeBSD-derived) runs in the same kernel address space for POSIX syscalls.

The I/O Kit (device driver framework) and KEXT (kernel extensions, now replaced by DriverKit) layer on top. By running BSD in-kernel rather than as a user-space server, Apple gets Mach's clean abstractions without microkernel performance penalties.

The fundamental Mach primitive is the message. All inter-process and inter-component communication flows through typed messages sent to ports. A port is essentially a protected message queue — a capability that must be explicitly given to a task to use.

Unlike UNIX pipes (byte streams), Mach messages are structured: they carry typed data, port rights (capabilities), and out-of-line memory descriptors. The kernel validates every message, enforcing that a task can only communicate with ports it legitimately holds rights to.

This capability model is why macOS sandboxing is so robust — an app running in a sandbox holds only the port rights the OS granted it at launch. It literally cannot communicate with services it wasn't given access to.

Mach defines two execution abstractions. A task is a resource container — it holds virtual memory space, port rights, and threads. UNIX processes map 1:1 to Mach tasks; iOS apps are tasks. A thread is a unit of CPU execution within a task.

Mach's thread scheduler is priority-based and preemptive. The scheduler distinguishes timesharing threads (normal apps), fixed priority threads (real-time audio), and importance donation (priority inheritance when a high-priority thread blocks on a lower-priority mutex). This is why audio in macOS almost never glitches even under load.

Mach's virtual memory system is one of its most influential designs. The Mach VM introduced the concept of VM objects — abstract memory backing stores that can be files, anonymous memory, or shared regions. Multiple address spaces can map the same VM object with copy-on-write semantics.

This is how macOS achieves near-instant fork() — the child process shares the parent's entire address space as copy-on-write pages. Pages are only physically duplicated when either process writes to them. Every dyld shared cache (the pre-linked system library image) works via Mach VM shared mappings across all processes.

The Mach VM also implements memory pressure notifications — apps receive a signal before the system runs out of memory, allowing graceful cleanup rather than abrupt termination.

Mach ports are the OS's capability system. Each port right is a specific permission: SEND (can send messages), RECEIVE (can dequeue messages), or SEND_ONCE (can send exactly one message, then the right is destroyed).

The Bootstrap Server (now launchd) holds the port rights for every system service. When an app calls NSDistributedNotificationCenter, opens a file via XPC, or connects to the network extension, it's performing Mach IPC under the hood — requesting port rights from launchd, then messaging the service directly.

XPC (introduced in macOS 10.7) is Apple's high-level wrapper around Mach IPC + GCD, providing structured services with automatic capability handoff and crash isolation.