MacTap: turning MacBook knocks into shortcuts, with a hardware catch

What MacTap actually does, and the laptops it refuses to work on

MacTap lives in the menu bar and turns taps on the chassis, or on the desk underneath a still laptop, into shortcuts. One, two, or three knocks. The README lists copy, paste, Accept, screenshots, media, and says anything else can be mapped. The audience is narrow and clearly stated: people who want a physical gesture layer on top of macOS shortcuts and are willing to accept a hardware precondition.

That precondition is the whole story. MacTap requires a MacBook whose motion sensor is exposed as an SPU HID device. The README names M2 and later, or M1 Pro, Max and Ultra. The original M1 Air, model identifier MacBookAir10,1, and some other M1 models do not publish the accelerometer HID report MacTap reads, so knocks cannot be detected. macOS 14.6 or later is the other requirement.

The README is blunt about the failure case: MacTap does not fall back to rebinding arrow keys when the sensor is missing. That is a deliberate refusal rather than an oversight. A tool that silently degrades into a keyboard remapper would be harder to reason about, and the project chose not to ship that behaviour. Read it as a scope statement, not a bug.

How knock detection and action dispatch are separated

The architecture implied by the repository is two-stage. Detection reads the SPU HID report from the motion sensor and classifies taps on-device. Dispatch takes a classified gesture and fires the mapped shortcut.

The separation matters because the two stages have different permission requirements. The README states that detection itself does not need Accessibility, but actions do. So a user can confirm the sensor path works before granting the permission that lets MacTap send keystrokes to other applications. If you grant Accessibility and knocks still do nothing, the problem is upstream in detection, not in your shortcut mapping.

The gesture vocabulary is spatial as well as numeric. Anywhere mode uses one, two, or three knocks on the chassis or desk. Left and Right mode treats each edge as a different set of actions, which doubles the addressable gestures without adding a fourth knock. On top of that sit presets named Daily, Coding, Capture, Media, and Focus, and per-app overrides, so Cursor can get Accept, Reject and Save while everything else stays on Daily. Layout, actions and sensitivity are changed from Settings, opened from the menu extra.

Classification happens locally. The README states that taps are classified on-device, nothing is uploaded, and gesture maps live in local defaults. There is no account, no sync, and no server component in the description.

Installing MacTap 2.1.2 and confirming the signature

Get version 2.1.2 from the website at mactap.vercel.app or from the latest GitHub release. The README prefers the zip: unzip it and drag MacTap.app into /Applications. The dmg is the alternative, and the README warns not to run the app from the disk image. Open MacTap from Applications or Spotlight, and turn on Accessibility when asked so knocks can send shortcuts.

The signature story is the part people get wrong. The app is Developer ID signed and notarized, but Gatekeeper evaluates MacTap.app, not the dmg wrapper. A codesign --verify on the disk image itself will report unsigned even when the build is good. After copying the app into Applications, check the app:

spctl --assess --type execute --verbose /Applications/MacTap.app

You want accepted and source=Notarized Developer ID. If a tool blocks the dmg, install from the zip instead.

Building from source needs XcodeGen and a generated project file. The README gives this sequence, which builds a Debug configuration directly into /Applications:

brew install xcodegen
xcodegen generate
xcodebuild -project MacTap.xcodeproj -scheme MacTap -configuration Debug \
  CONFIGURATION_BUILD_DIR=/Applications
open /Applications/MacTap.app

For a signed, notarized build, the repository ships a script that writes dist/MacTap-<version>.dmg:

./Scripts/ship.sh

The README notes that notarization uses Xcode's Developer ID export, and that signing the disk image, not just the app, also needs App Store Connect API credentials: APP_STORE_CONNECT_KEY_ID, APP_STORE_CONNECT_ISSUER_ID, and APP_STORE_CONNECT_API_KEY_P8, or an AuthKey_*.p8 file. That is a contributor concern, not a user one.

Where MacTap is the wrong tool

The hardware list is the first limitation and the most expensive one, because it cannot be worked around in software. If you are on the original M1 Air or an M1 model that does not publish the accelerometer HID report, MacTap will not detect knocks, and the README says there is no arrow-key fallback. Buying the app for such a machine is a dead end.

The second limitation is the gesture channel itself. Knocks are a low-bandwidth, high-latency input compared with a keyboard shortcut you already know. Three knocks give you a small number of distinct actions, which is why the project leans on presets and per-app overrides to multiply them. If your workflow needs dozens of bindings, a knock layer will not replace a launcher.

Third, a knock is a physical event on a laptop you are touching. The README mentions the desk underneath a still laptop as a detection surface, which suggests sensitivity tuning is part of normal use rather than a one-time setup. The README does not document false-positive rates, nor does it document what happens in clamshell mode with an external display, and it does not describe rollback if a preset change makes knocks fire in the wrong app. Those gaps are worth knowing before you build habits around it.

How MacTap differs from generic keyboard remappers

The obvious alternative is a keyboard remapper such as Karabiner-Elements, which intercepts and rewrites key events at the HID level. The difference in approach is the input source. Karabiner works on keys you already press and can remap any keyboard, including external ones, on any Mac that meets its own requirements. MacTap works on a sensor that only some MacBooks expose, and it adds a gesture that no keyboard has.

That makes the two tools complementary rather than competing. A remapper changes what an existing key does. MacTap creates an input that does not otherwise exist, then hands the result to the same shortcut layer. If your goal is to stop reaching for a modifier combination, a remapper solves it on more hardware. If your goal is to trigger something without moving your hands off the chassis, only the sensor route gets you there.

There is also a category difference from launcher-style tools that bind global hotkeys. Those require a keystroke, so they inherit the same reach-and-press cost. MacTap's claim is that a knock is cheaper. Whether that is true for you depends on how often you perform the action; a shortcut you use twice a day does not justify a new input habit.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-10, the same day as the 2.1.2 release. Releases v2.1.0, v2.1.1 and v2.1.2 all landed between 2026-09-08 and 2026-09-10, so the project is being iterated quickly on the main branch. Rapid point releases also mean you should expect to reinstall rather than assume an in-app updater; the README documents downloading a zip or dmg and dragging the app into /Applications, and does not describe an update mechanism.

Upgrade cost is low but not zero. Because gesture maps live in local defaults rather than a synced profile, replacing the app bundle keeps your mappings, but the README does not document an export or import path, so a machine migration means rebuilding them by hand. If you use per-app overrides, that is the part you will redo.

The licence is MIT. That permits use, modification and redistribution with the licence and copyright notice retained. It also means there is no warranty and no support obligation from the author. Nothing in the repository suggests a commercial tier, so treat the project as source-available software you happen to install as a signed binary. This is a description of the licence terms, not legal advice; if you plan to redistribute a modified build, read the LICENSE file in the repository root.

Editorial conclusion

MacTap is worth installing if you own an M2 or later MacBook, or an M1 Pro, Max or Ultra, and you already lose time reaching for the same three or four shortcuts. It is the wrong tool for the original M1 Air (MacBookAir10,1) and other M1 models that do not publish the accelerometer HID report, because the README states plainly that MacTap does not fall back to rebinding arrow keys when the sensor is missing. Before relying on it, verify two things: run spctl --assess --type execute --verbose /Applications/MacTap.app and confirm you get accepted with source=Notarized Developer ID, then open Settings from the menu extra and confirm knocks register at all on your chassis. If detection never fires, no amount of action mapping will help.

Frequently asked questions

Official sources

1. Issues
2. jaskirat1616/mactap-app on GitHub
3. License: MIT
4. README
5. Releases