macOS Is Not Fine

The WindowServer process has one responsibility: composite window framebuffers onto the physical display. It is a presentation layer - the thinnest possible mapping between application content and pixels. In practice it treats every core like a Threadripper spare, consuming 500MB to 2GB of resident memory and pegging entire CPU cores for simple transparency effects, shadow passes, and offscreen buffer allocations that should be GPU-constant-time operations.

Quartz Extreme was sold as a hardware-composited window server that would offload every overlay, every transform, every color correction to the GPU at negligible cost. That architecture is still in the kernel somewhere, buried under a decade of feature accretion that allocates a fresh IOSurface for every layer, every NSVisualEffectView vibrancy pass, every backdrop material, and every SwiftUI shadow. Mission Control re-renders the entire desktop from scratch. The menu bar's blur effect triggers a full backing-store redraw across all displays. Every window resize in a non-optimized app retriggers the entire compositing pipeline - layer allocation, offscreen render, blending, display. The result is a process that shadows Chrome in memory consumption while doing a job that should cost single-digit megabytes. On a unified-memory architecture where every megabyte allocated to WindowServer is a megabyte denied to the application, this is not just inefficient. It is architectural negligence dressed up as visual polish.

Head-tracked spatial audio on iOS and iPadOS works because the system has tight, low-latency access to the device's IMU - accelerometer and gyroscope data sampled at hundreds of Hz, fused into a stable attitude reference that anchors the soundstage to the real world. Move your head, the soundstage stays. Rotate the device, the soundstage rotates with it. The integration is seamless because the sensor pipeline was designed for it from the silicon up.

On Intel Macs the same feature exists but only via the "static" spatial audio profile - head tracking is absent entirely, despite the fact that every Mac laptop shipped in the last decade contains an accelerometer on the logic board. The sensor data reaches the kernel. It reaches IOHIDFamily. It stops there. The audio subsystem never gets the reference frame it needs, because the software pathway that bridges the IMU to CoreAudio's spatial renderer simply was never written for the Intel platform. The result is a feature that works beautifully on the A-series and M-series portable devices, but is arbitrarily gated on the very same machines running the same operating system - machines that have the sensor hardware, the I/O infrastructure, and the identical audio framework. It is not a hardware limitation. It is a software omission that communicates, with absolute clarity, which platforms Apple considers worth the engineering investment.

Every external drive, every network share, every USB stick that touches a Mac is colonized with a predictable payload: .DS_Store, .Spotlight-V100, .fseventsd, and .Trashes. These are the artifacts of macOS's background metadata framework, and they are deposited with zero regard for the conventions of the filesystem they land on.

.DS_Store files litter every directory the Finder renders, encoding icon positions and view settings that are meaningless on any other operating system. The Spotlight metadata store (.Spotlight-V100) creates a full FSEvents log and a dense database on every writable volume, regardless of whether the user asked for indexing. The .fseventsd directory logs every file system event for the lifetime of the mount. On a network share or a dual-boot drive, these artifacts accumulate silently, confusing other operating systems, consuming inodes on memory-constrained filesystems, and triggering unnecessary sync traffic on cloud storage. The behavior can be suppressed with default-write incantations and .metadata_never_index tombstone files, but these are opt-out workarounds for a design that should simply not be so careless with the shared filesystem namespace. Every other operating system manages to mount a drive without leaving metadata graffiti. macOS treats the entire world as its scratch partition.

APFS is a copy-on-write filesystem built specifically for flash storage. It offers snapshots, space sharing, and clones that make certain operations nearly instantaneous. It is also, for a specific and common class of workload, catastrophically slow: recursive deletion. The rm -rf that completes in milliseconds on ext4 can stall for minutes on APFS, pinning the filesystem thread and rendering the entire machine unresponsive.

The mechanism reveals itself with a block-level trace: APFS's B-tree-based directory structure and CoW snapshot metadata create an intricate reference graph that must be walked and resolved during deletion. When a node is a clone - the common case for npm's node_modules, where CocoaPods duplicates .dylib chains, or where Time Machine snapshots reference the same extents - the filesystem must check every reference before it can release the blocks. This is not merely a performance problem; it is a correctness guarantee that CoW cannot skip. ZFS handles this with a deferred-free infrastructure and intent-log writes that batch the metadata updates into journaled transactions. Ext4 punts entirely with its simple block bitmap. APFS does the full transactional accounting on every unlink in the critical path. The result is that the "magic" of copy-on-write - the clones, the snapshots, the space sharing - directly causes the pathological deletion performance that makes npm install cleanup a ritual of waiting. The filesystem is optimized for the creation and retention of data at the expense of every deletion operation. For development workflows, where directories are created and destroyed constantly, this is the wrong trade-off.

MacOS has never shipped native write support for NTFS. Not in 2001, not in 2026 - a deliberate omission spanning a quarter century of interoperability with the dominant desktop filesystem on earth. The capability exists in the kernel: a hidden, undocumented, and unstable sysctl toggle that corrupts data under concurrent load. Apple knows the code works well enough to read NTFS reliably. They choose not to enable writes.

Ext4, btrfs, and ZFS are not supported either, despite being the standard filesystems of Linux - the operating system that runs the servers macOS depends on, the containers it virtualizes, and many of the embedded systems it develops firmware for. The only first-class filesystem on macOS is APFS. To read a drive from any other operating system, the user must install a third-party kernel extension - macFUSE, ext4fuse, NTFS-3G - each of which must be codesigned for the current SIP policy, must survive the next OS update without breaking, and must not panic the kernel on unload. The FUSE layer introduces double-caching, lacks proper ACL support, and has never handled the hotplug-remount cycle reliably. The signal is unmistakable: making non-Apple drives deliberately fragile trains users to stop trying. It is a moat, not a feature gap. For developers who live in multi-OS environments - and that describes the entire audience macOS claims to serve - this is a declaration of hostility toward the very workflows that make a general-purpose computer worth owning.

The loginwindow process is the session manager for the Aqua desktop. It authenticates the user, initializes the WindowServer, launches the Dock and Finder, and iterates through Login Items to start user-space agents. It does all of this sequentially on a single initialization thread with no timeout. A single hanging agent can freeze the entire session startup, and the result is indistinguishable from a kernel panic to the person staring at the screen.

The failure mode is reproducible: a launch agent that registers a Mach service and blocks on a network socket during initialization. loginwindow submits the job to launchd, waits for the service registration acknowledgment, and blocks on the response. The WindowServer is running. The GPU is initialized. The cursor moves. But no Dock renders, no menu bar appears, no desktop icons materialize, and no key combination opens Terminal or Activity Monitor. The user is locked out of a functioning session with no diagnostic output and no recovery path. On any well-engineered system, a hung session agent would be killed or skipped after a configurable timeout and the failure logged to a console accessible from single-user mode. On macOS, the entire initialization chain is held hostage by its single-threaded, no-watchdog design. The engineering decision here is not about security or reliability. It is about not allocating engineering time to a failure mode that Apple's internal testing does not reproduce. The user, holding the power button down for the third time this month, reproduces it daily.

The mds and mdworker processes index the filesystem to enable instant search. The mechanism is FSEvents-driven: every directory modification, file rename, or metadata change triggers a reindex of the affected subtree. The intent is reasonable. The implementation is a thermal catastrophe.

A typical indexing spike on Apple Silicon draws 8-12W from a thermal budget of roughly 25W. That is nearly half the power envelope of the entire SoC consumed by metadata extraction - running SQLite transactions against the Spotlight index database, running mdimport plugins against every file's content, and walking directory trees that may not have changed. The efficiency cores absorb part of the load, but the sustained power draw translates directly into skin temperature on a fanless chassis. The user experiences throttling not because they are compiling code or rendering video, but because the OS decided to reindex the project folder they renamed. The worst part: the search results do not justify the energy budget. Spotlight returns Mail messages from three years ago before it surfaces the file that was modified five minutes ago. It cannot search file contents reliably. It cannot exclude noisy directories without manual plist surgery. The indexing is maximally expensive and minimally useful - the worst ratio a background service can achieve. And users cannot disable it without sacrificing the search field that the OS pushes as a primary navigation interface.

System Preferences was a mature, responsive, and discoverable configuration interface built on a preference-pane plugin architecture that third-party developers could extend. System Settings is a port of the iPad Settings application, rendered with SwiftUI, rendered on a machine that has a keyboard and a mouse and a large display - none of which the UI acknowledges.

The regression is measurable. System Settings launches with a sidebar search that returns fewer results than its predecessor. Navigation between panes is not instant - it is an animated push transition designed for a touch interface, adding 200-400ms of latency to every click. The preferences are reorganized into a hierarchy that mirrors iOS Settings, hiding networking details behind nested panels and burying sharing configurations behind three levels of navigation. Third-party preference panes, a feature that existed for two decades, were silently dropped. The result is a UI that feels slower on a MacBook Pro with 64GB of RAM than System Preferences did on a Core 2 Duo. The justification is visual consistency across platforms. The cost is a loss of functional density, navigational speed, and discoverability that makes everyday administrative tasks - changing a DNS server, configuring a printer, adjusting trackpad sensitivity - take measurably longer. This is not a redesign. It is a port, and the port introduces latency and complexity that did not exist in the original.

Every major desktop operating system ships a built-in window tiling system. Windows 11 has Snap Layouts. KDE Plasma has a configurable tiling grid. GNOME has tiling extensions that are more polished than macOS's native offering and shipped years before. macOS has a green fullscreen button that hides your other windows and a long-press shortcut that half-tiles to one side. That is the default. In 2026.

The behavior has two modes: full-screen (which creates a new Space and hides every other window) and the macOS 15 Sequoia tiling, which snaps to a grid quadrant when the Option key is held during a drag. Neither offers custom grid sizing. Neither supports keyboard-driven placement. Neither remembers layouts across display configurations. Neither allows the user to create a preset of window positions for a given workspace. The only way to get functional window management is to install a third-party utility: Rectangle, Magnet, yabai, Amethyst. These tools are excellent. They should not need to exist. The argument that macOS is a 'pro' platform becomes harder to sustain when Apple cannot be bothered to implement a feature that every competing OS - including the mobile operating systems Apple itself builds - has offered for years. The third-party tiling utility is a tax. A recurring one, because every major OS update breaks at least one of these tools until the developer pushes a compatibility release. The platform that charges the most for its hardware requires the most third-party software to reach functional parity with its competitors. That is not a premium experience. It is a subsidy extracted from the community.