Recommended minimums differ by platform and cannot be mixed

What it is

Apple's Human Interface Guidelines recommend touch targets no smaller than about 44×44 points (pt); Google's Material Design recommends no smaller than about 48×48 density-independent pixels (dp). These two numbers cannot be compared or converted directly, because pt and dp are two distinct logical unit systems, each tied to its own platform's density-conversion rules. Treating "44" and "48" as two marks on the same ruler is exactly the common mistake this card corrects.

Why it happens

Why can't the two numbers be compared directly? A point is a logical unit in Apple's coordinate system, and its physical size on any given device is set by that device's point-to-pixel scale factor; a density-independent pixel is a logical unit in Android's coordinate system, and its physical size is set by which density bucket the device falls into. The two systems define their reference density and rounding rules differently, and the real-world distribution of physical densities across each ecosystem's devices differs too, so an equal number on the two platforms need not correspond to an equal physical size — the two only land in roughly the same ballpark, on the order of 7 to 10 millimetres. That rough similarity is the result of each platform independently converging on a figure from its own human-factors research, not two expressions of the same underlying dataset, so it cannot be treated as interchangeable. A cross-platform product that hardcodes Android's 48 dp straight into an iOS project as 48 pt, or the reverse, ends up rendering a physical size that disagrees with the target platform's native controls — users experience a different feel for reachability on the two versions of the same product, usually without being able to say exactly why.

Studying it

Verifying whether cross-platform minimums are equivalent requires first converting both platforms' recommendations to a common physical unit (millimetres), then measuring hit rate and false-tap rate on each platform's real devices under its real system scale settings, rather than comparing the numbers directly on a design canvas's pixel grid. A methodological point: system-level display scaling — users can enlarge text or overall interface scale in system settings — further changes the physical size a logical unit maps to; testing only at default scale understates how much target physical size shifts for the portion of the real user population running accessibility scaling, and therefore understates the real failure rate.

Where it stops holding

Both figures are a starting point drawn from each platform's own human-factors research, not a sufficient condition for every task — high-risk actions, older users, or extreme one-handed postures may need targets larger than either platform's recommendation (a separate concern covered by the edge/corner card). Nor are they licence to blow past platform expectations regardless of a control's semantics: making every control far larger than the platform recommends breaks native visual density and the look users expect from that platform. An interface rendered through a cross-platform framework can render inconsistent physical sizes on the two platforms from the very same source value if the framework itself does not correctly handle the two density systems — a mismatch that pure code review rarely catches and that needs measurement on real devices.

Applying it

• Maintain a separate size token per target platform in the design system, with the physical-size conversion stated explicitly, rather than sharing one cross-platform number.
• Prefer native platform components so the platform itself handles touch sizing and density conversion; only cross-check the target platform's recommendation manually when a control must be custom-built.
• Test hit rate separately on real devices for each platform, and extend the test matrix to cover system-level display scaling turned up.

Related

• Same group: C2.02.1 The minimum touch-target size is set by fingertip contact area, not vision · C2.02.2 Visual size and hit size can be separated · C2.02.4 Edge and corner targets need extra margin
• Nearby: C2.03 Minimum Touch-Target Spacing · C2.06 Touch Offset and Aiming Bias
• Search terms: touch target minimum · density-independent pixel · Human Interface Guidelines