Eyes Technology

This page explains how eye tracking produces the gaze signal your application receives, and what limits that signal in accuracy, calibration, and availability.

Eye tracking runs on dedicated sensors inside the device. Devices without those sensors cannot support it.

Eyes are a noisy input source. They move in rapid saccades between brief fixations, so a raw gaze signal is not usable as a pointer. The system smooths that signal before it reaches targeting.

What an application receives is one combined gaze pose: an origin and a direction in world space. There is no per-eye data on this path. The pose carries a validity flag, and an application has to check that flag before it uses the data.

Per-eye gaze pose and confidence come from a separate, social-facing API rather than from the interaction signal. That output is temporally smoothed and converges in front of the user, and it is not the data targeting reads. The split is the reason the interaction path gives you a single ray instead of two.

Gaze availability is not guaranteed at runtime. Applications that receive gaze data directly request a runtime permission, and the user can revoke it at any time.

2D panel surfaces do not receive gaze data, because eye tracking data is sensitive. This covers 2D Android applications and web content in Meta Quest Browser. The system renders hover on their behalf and delivers touch events only.

For the targeting cone, stabilization window, and disambiguation values, see Gaze specs.

Accuracy varies by hardware, by user, and by calibration quality. Some users are harder to track than others, and that variation is a property of the person and the device fit rather than of your application.

Reliability also falls off toward the perimeter of the field of view. The center of a surface is the most reliable place to put a target, and aim gets looser as content moves outward.

When designing, the practical bar is the angular target-size rule: size a target by the angle it covers at the user’s viewing distance. See Eyes best practices for that rule.

Calibration is a system-level concern. It happens outside your application, and the system owns it.

There is no developer-facing calibration API for gaze. This differs from body tracking, which does expose one. Your application cannot trigger calibration, query its state, or correct it.

Calibration quality is also not static. It degrades when the device shifts on the user’s head, and a shifted device is the most common cause of gaze suddenly feeling off target. Because your application cannot detect or repair that condition, it has to degrade gracefully instead.

The system also monitors device fit, separately from gaze calibration, and shows a notification prompting the user to reposition the device when the fit drifts far enough to affect tracking. Your application receives no signal that this happened and cannot trigger it.

Eye tracking is a device feature. Some devices ship without it, and on devices that have it, it can be unavailable when your application starts or drop out while the application runs.

Targeting does not fall straight through to head gaze. The hand or controller ray takes over first, and direct touch stays available at close range. Head gaze, which targets with the center of the field of view, is the final fallback, used only when no hand or controller tracking is available. For the full chain, see Input hierarchy.

Design for the hand ray path first, because that is what a user on a device without eye tracking will reach for. Head gaze is the narrower case, and it is noisier than either: the signal carries head motion that the eyes would otherwise absorb, so a target drifts in and out of a narrow cone more often. A wider targeting cone offsets that, and larger, better separated targets help for the same reason. Ensure other input modalities are also supported. For the design side of graceful degradation, see Eyes best practices.

Explore more design guidelines and learn how to design great experiences for your app users: