---
title: "Touch targets when the hand is shaking"
canonical: "https://aifitnessapi.com/accessibility/touch-targets-during-a-workout"
cluster: "Accessibility"
primary_query: "touch target size fitness app"
last_reviewed: "2026-08-22"
description: "Apple's per-platform control sizes, Google's 48dp recommendation, and why pause and end workout should never sit next to each other."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"Touch targets when the hand is shaking\", AIFitnessAPI, https://aifitnessapi.com/accessibility/touch-targets-during-a-workout"
---

# Touch targets when the hand is shaking

> Apple's Human Interface Guidelines say to strive to meet the recommended minimum control size for each platform, and publish a default of 44x44 pt for iOS, iPadOS and watchOS with a 28x28 pt minimum. Google's Android guidance recommends a touch target of at least 48dpx48dp for touch interfaces and says larger is even better, noting that many built-in Material components in Jetpack Compose already enforce that minimum. Size alone is not enough: Apple asks you to consider spacing between controls as important as size, and to include enough padding to reduce the chance that someone taps the wrong control. During a workout that padding is the whole game, because the hand is wet, gloved or shaking and the phone is often on a mount at arm's length. Keep destructive controls such as end workout physically separated from pause, and keep control positions stable as the workout state changes.

- Canonical: https://aifitnessapi.com/accessibility/touch-targets-during-a-workout
- Last reviewed: 2026-08-22
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "Touch targets when the hand is shaking", AIFitnessAPI, https://aifitnessapi.com/accessibility/touch-targets-during-a-workout

---

The tap your user makes worst is the one that matters most. Their hand is wet, or gloved, or shaking after the last set. The phone is clamped to a bike mount at arm's length, strapped to an upper arm, or face-up on the floor while they are in a plank. They are looking at the bar, not the screen. And the control they are reaching for sits next to the one that ends the recording of the session they have been doing for forty minutes.

This is a sizing and spacing problem before it is anything else, and both platforms publish numbers for it.

## Apple's numbers, per platform

Apple's Human Interface Guidelines say: "Strive to meet the recommended minimum control size for each platform to ensure controls and menus are comfortable for all when tapping and clicking." Keep Apple's verb. This is guidance to strive toward, not a rule Apple states as a requirement.

The table Apple gives:

| Platform | Default control size | Minimum control size |
| --- | --- | --- |
| iOS, iPadOS | 44x44 pt | 28x28 pt |
| macOS | 28x28 pt | 20x20 pt |
| tvOS | 66x66 pt | 56x56 pt |
| visionOS | 60x60 pt | 28x28 pt |
| watchOS | 44x44 pt | 28x28 pt |

Two rows are worth staring at. watchOS carries the same 44x44 pt default as iPhone, on a screen a fraction of the size — more on that below. And the minimum column is a floor, not a target; a 28x28 pt control is Apple's minimum, and reaching for the minimum on a screen operated mid-exercise is a choice you should have a reason for.

## Spacing counts as much as size

Apple is explicit that size alone does not do it: "Consider spacing between controls as important as size." And: "Include enough padding between elements to reduce the chance that someone taps the wrong control."

That second sentence is the one that describes your workout screen. The failure is not that the button was too small to hit. The failure is that the user hit a button, just not that one.

Our judgement, not Apple's statement: on a screen used during exertion, two controls at the default size with meaningful padding between them beat three controls at the default size packed edge to edge. If the layout will not allow the padding, the answer is fewer controls on that screen, not smaller ones.

## Google's number

Google's Android accessibility guidance states: "Your app's UI is easier to use if its controls are easier to see and tap. For touch interfaces, we recommend that each interactive UI element have a focusable area, or touch target size, of at least 48dpx48dp. Larger is even better." Again, keep the verb: Google recommends.

Two notes on the same page matter for real apps. Google adds that "For precise input (mouses and trackpads), the touch target can be smaller" — which is about pointing devices, and a phone in a chest strap is the opposite of precise input. And: "In Jetpack Compose, many built-in Material components like Button, IconButton, and ListItem already enforce this minimum size." That is a real advantage of using the components rather than hand-rolling a tappable box, and it is also the reason a custom control is where the regression appears.

We are not converting between Apple's points and Google's dp anywhere on this page. Each figure is published for its own platform; use the platform's own number on that platform.

A common shape in fitness UI is a small glyph with a large invisible hit area, or a large pill whose tappable region is only the text inside it. Both are size mismatches and only one of them is safe.

Extending the touch target beyond the visual is fine, and often necessary to reach the recommended figures without redrawing the icon. Shrinking it below the visual is the bug: the user aims at what they can see, misses, and concludes the app is broken. When you audit, measure the focusable area, not the artwork.

## The destructive action problem

Pause and end tend to end up next to each other on a workout screen, and the two outcomes are not comparable. Pausing a workout by mistake costs a few seconds. Ending one by mistake costs the session, and to the user it is unrecoverable whether or not your code can salvage it.

Three things to do about it, all judgement rather than platform guidance:

Separate them physically. Adjacency is what makes the mis-tap possible, and padding between two controls is the mechanism Apple names for reducing it. Put the destructive control somewhere the thumb does not rest.

Do not let the layout move. If the primary control changes identity between states — start becomes pause becomes end in the same rectangle — then muscle memory is aiming at a target that has changed meaning. Keep positions stable across workout states and let the labels do the work.

Confirm the destructive one, but confirm it in a way a shaking hand can complete. A confirmation dialogue with two small buttons has just replaced one hard tap with two. A hold-to-end control or a full-width confirmation is easier during exertion than a pair of adjacent alert buttons.

## The wrist makes it arithmetic

The watchOS row above is the one that changes how you design. The same 44x44 pt default control size applies on a display a fraction of the size of a phone, so the number of controls that fit on a watch screen is arithmetic, not taste. Two is usually the honest answer for anything used mid-set.

That constraint is why watch workout UI tends toward one primary action plus a gesture or a swipe-away screen for everything else. [The watch cluster](/watch-apps) covers the construction side, and [Wear OS app anatomy](/watch-apps/wear-os-app-anatomy) covers the other platform. We did not verify a Wear OS specific touch-target figure this session; the 48dp recommendation quoted above is from Google's Android accessibility guidance, and if you need a wrist-specific number, check Google's current documentation for it rather than assuming this one carries.

## Mounted, wet and moving

The last piece is context, and none of it is a platform claim. A phone on a handlebar mount vibrates continuously and is read from further away; a control sized for a thumb held close is a different control at arm's length. An armband puts the screen at an angle that is never square to the eye. Sweat and rain both make touch input less reliable, and a gloved finger puts down a bigger, blurrier contact patch than a bare one. Cycling and treadmill setups make all of this worse at once — see [indoor bike trainer integration](/devices/indoor-bike-trainer-integration) and [treadmill app integration](/devices/treadmill-app-integration) for what those sessions look like, and [building a running app](/build/running-app) for the outdoor case.

## Monday morning

Open the live workout screen and measure the focusable area of every control on it, not the artwork. Compare each against the platform's own figure — 44x44 pt as Apple's iOS default, 48dp as Google's recommendation. Then list the destructive controls and check what sits within a thumb's width of each.

Run Google's Accessibility Scanner over the screen: Google describes it as an app that "scans your screen and suggests ways to improve the accessibility of your app" and says it "provides specific suggestions after looking at content labels, clickable items, contrast, and more." Clickable items is this page's subject. Google's [testing guidance](https://developer.android.com/guide/topics/ui/accessibility/testing) also asks for manual passes alongside tooling, which here means the unglamorous version: wet your fingers, put a glove on, mount the phone where your users mount it, and try to pause.

## FAQ

### How much padding belongs between a pause button and an end workout button?

Apple does not publish a spacing figure, only the instruction to consider spacing between controls as important as size and to include enough padding to reduce the chance that someone taps the wrong control. So this is judgement. Ours: on a screen operated during exertion, put the destructive control out of the thumb's natural arc entirely rather than trying to find a safe gap next to it. Where they must share a screen, prefer fewer controls at full size with generous separation over a dense row, and keep positions stable across start, paused and running states so muscle memory is not aiming at a moved target.

[Permalink](https://aifitnessapi.com/accessibility/touch-targets-during-a-workout#faq-1)

### Is Apple's 44 pt control size the same thing as Google's 48dp recommendation?

Treat them as two separate figures for two separate platforms, and do not convert between them. Apple's Human Interface Guidelines publish a default control size of 44x44 pt for iOS, iPadOS and watchOS, with a minimum of 28x28 pt. Google's Android accessibility guidance recommends at least 48dpx48dp for touch interfaces and adds that larger is even better. We did not verify any equivalence between the units, so a cross-platform design system should carry both numbers and apply each on its own platform rather than picking one and rounding the other to it.

[Permalink](https://aifitnessapi.com/accessibility/touch-targets-during-a-workout#faq-2)

### Do Jetpack Compose Material components already meet the minimum touch target?

Google states that in Jetpack Compose, many built-in Material components like Button, IconButton and ListItem already enforce this minimum size, in the same passage that recommends at least 48dpx48dp. That covers the standard controls. It does not cover the custom tappable surfaces a workout screen tends to accumulate: a bare box with a click modifier, a small glyph in a metrics header, a chip in a set row. Those are where the regression appears, so measure the focusable area rather than the drawn artwork, and extend the target beyond the visual rather than shrinking it inside it.

[Permalink](https://aifitnessapi.com/accessibility/touch-targets-during-a-workout#faq-3)