Per-app trackpad scenes: the missing layer in Mac input

Your Mac trackpad is the best input device on the machine, and macOS still treats it as a rectangle for moving a pointer.

The gestures are global. Three fingers up. Two fingers swipe. Pinch. They work everywhere, which is exactly why they cannot be specific to anything. The same swipe that means "go back" in a browser means nothing in Figma, and the edge that would make a good volume slider is ignored by the system.

A per-app scene is a different model. Instead of starting with a gesture, you start with the app in front of you and arrange the surface: edges, corners, custom areas, a center gesture. The layout changes when the app changes. A default scene covers everything else.

I have been building TrackStudio around this model. This post is about the model, not the product.

Why global layouts break

A global layout assumes every app wants the same controls. They do not.

A browser wants navigation. An editor wants windows and screenshots. A terminal wants restraint. A video editor wants transport and a way back to Mission Control. If the layout never changes, you either build a lowest-common-denominator surface or a surface that is wrong in half your apps.

The second problem is conflict. Two apps can claim the same gesture, or an app can claim a gesture the utility also wants. Scenes reduce the overlap by giving each app its own map.

What a scene actually is

A scene is a saved layout bound to an app. The mechanics are similar across implementations:

1. Detect the frontmost app.
2. Apply the layout for that app.
3. Fall back to a default when there is no match.
4. Yield when the app needs the input.

The fallback is the part people forget. If every app needs a scene before the trackpad works, the system is too heavy. Start with a good default, then add scenes only where the default is wrong.

The hard parts

Frontmost app detection is cheap. macOS gives you NSWorkspace notifications; the switch itself is not the problem.

The problems are at the edges:

• Secure input fields can suppress event taps.
• Accessibility and Input Monitoring permissions decide which actions work.
• Games and remote desktops often capture input directly.
• A layout switch has to feel instant; a visible delay makes the surface feel broken.
• Haptics have to carry information. A detent says a value changed. A tick says an action ran. Decorative haptics become noise.

None of this is exotic. It is the unglamorous work that separates a demo from something you keep using.

A worked example: Figma

Figma is a keyboard-first app, so a useful scene stays around the edges of the work.

• Left edge: brightness, for comparing colors.
• Right edge: volume, if you listen while you work.
• Bottom edge: media scrub, if music is part of your day.
• Top-left corner: Mission Control.
• Top-right corner: screenshot.
• Two small areas: undo and redo.
• Center gesture: command palette, if you prefer a press-and-drag to the keyboard shortcut.

The point is not to replace Figma's shortcuts. The point is to remove the reaches around them: the window switch, the screenshot, the brightness change.

What not to do

Do not map a destructive action to a single edge tap. Do not put a control where your palm rests. Do not duplicate a shortcut you already type faster. And do not buy a scripting tool for a layout problem, or a layout tool for a scripting problem.

The takeaway

The trackpad is not only a gesture surface. It is a layout surface. Once the layout can follow the app, the interesting design question changes from "which gesture should I memorize?" to "which controls belong in this app?"

That is the layer macOS does not provide. It is also the layer that makes the trackpad feel like hardware instead of a pointer.

I make TrackStudio, a Mac app built around this model. The longer guide, including the failure cases and a scene checklist, is here: https://trackstudio.xyz/blog/per-app-trackpad-scenes