AirPods Head Tracking Not Working on Mac

1. Confirm the supported path

Apple’s current documentation is the authority for supported AirPods, Beats, Macs, operating systems, applications, and content. Built-in Spatial Audio is not available in every app. A third-party renderer may support a different set of sources, but it still needs compatible motion data.

Treat this as a chain in which every link must hold: the headphone model must provide motion data, the Mac and macOS version must support receiving it, the renderer must be able to consume it, and for Apple's own implementation the app and content must be supported as well. A single unsupported link produces exactly the same symptom as any other, which is why guessing at the cause is unproductive.

2. Verify output and mode

Make sure the intended AirPods are connected and selected as the physical output. In Apple’s controls, distinguish Fixed from Head Tracked. In a system-wide application, confirm the tracker reports an active state rather than assuming audio playback proves sensor availability.

Fixed and Head Tracked are the most commonly confused settings, because both apply spatial rendering and both sound clearly different from Off. The distinction only becomes audible when you move, so a listener sitting still can easily conclude that tracking is working when it is not. Check the setting rather than inferring it from how the audio sounds.

It is also worth confirming that the AirPods are connected to the Mac rather than to another device. Automatic switching between Apple devices is convenient and occasionally surprising, and audio continuing to play is not proof that the connection is where you assume.

3. Refresh the connection

Put the AirPods in their case, close it briefly, reconnect, and restart the spatial application. If the Mac recently woke from sleep or switched outputs, select another device and return to the AirPods. Avoid deleting a Personalized Spatial Audio profile unless the issue specifically concerns that profile; Apple warns that stopping use deletes it.

Sleep and wake are the most frequent trigger. A renderer holding a reference to a motion source across a sleep cycle may find the connection has been torn down and re-established underneath it, and not every implementation recovers from that cleanly. Restarting the application after the connection is confirmed is a faster fix than any deeper reset.

4. Test the correct behavior

Use a centered voice and turn slowly. A tracked scene should remain near the screen. If the scene stays centered on the head, tracking is inactive. If it moves in the wrong direction, the renderer has an orientation problem. If tone becomes hollow only when tracking starts, check for a second renderer.

Do not test with large, fast movements. They exaggerate every implementation artefact, correspond to nothing you do while listening, and make a working system look broken. Ten to fifteen degrees, slowly, is the movement that reveals whether tracking is present and stable.

5. Separate faults from intended behaviour

Several behaviours that look like faults are deliberate. A scene that slowly settles toward whatever direction you have been facing is recentering, which exists because strict anchoring would leave the soundstage behind you after you turned to talk to someone. A short delay between movement and the audio following is wireless transport latency, which no tracking setting can remove.

Genuine faults have a different character. Tracking that never responds at all, a scene that moves in the same direction as your head rather than the opposite, stepping rather than smooth motion, or tracking that works and then stops within the same session all indicate a real problem rather than a design decision.