# capcap: a macOS menu bar screenshot tool that triggers on a double-tap of Command

> capcap is an MIT-licensed Swift app for macOS 14 and later that captures a region or window when you double-tap the Command key, then hands the result to an annotation editor with mosaic, long-screenshot stitching and optional object-storage upload. It is a good fit if you want the capture step to disappear into a keystroke; it is the wrong tool if you need Windows, Linux or a cloud account with shared history.

**realskyrin/capcap** — ⌘⌘ - A lightweight, native macOS screenshot tool that lives in your menu bar. Double-tap ⌘ Command to capture any region of your screen - instantly copied to clipboard, or annotate first with pen and mosaic tools.

- Repository: https://github.com/realskyrin/capcap
- Website: https://capcap.skyrin.fun
- Stars: 932 · Forks: 77
- Language: Swift
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/realskyrin-capcap

## The problem capcap solves: removing the capture gesture from your attention

macOS ships with a screenshot shortcut that has been stable for years, and it works. The friction capcap targets is not the capture itself but the sequence around it: press the chord, drag a region, wait for the thumbnail, click it, annotate in a separate window, then export. Every step is a context switch away from whatever you were reading or debugging. capcap's answer is to make the trigger a double-tap of the Command key, which the README describes as the default and which can be replaced with any recorded global shortcut in settings. The capture overlay, the floating toolbar and the editor are one continuous surface, so annotating does not mean opening a second app.

The audience is narrow and specific. This is a macOS 14.0+ application, Universal for Apple Silicon and Intel, distributed as a Homebrew cask and as a source build. The README states there is no telemetry and no subscription, and that the app runs as an agent app without a Dock icon. If your team is standardized on macOS and you take a lot of screenshots for bug reports, design review or documentation, the design choices line up with that workflow. If your screenshots are incidental, the built-in tool is already there and costs nothing to keep.

## How the double-tap Command trigger and the capture pipeline fit together

The repository layout separates the concerns cleanly, which is a useful signal about where the complexity lives. capcap/Trigger/ holds the double-tap Command listener and the custom Carbon global shortcut. capcap/Capture/ holds the screenshot overlay, region selection, window detection, the ScreenCaptureKit capture path, long-screenshot stitching, the clipboard and the history store. capcap/Editor/ holds the annotation model, the editing canvas, the floating toolbar, the beautify renderer, mosaic and the long-screenshot preview. capcap/Upload/ holds the three object-storage implementations, HMAC signing, an HTTP wrapper with progress, and the floating upload progress indicator.

The data flow implied by that layout is: a trigger event starts a capture session, the overlay collects a region or a detected window boundary, ScreenCaptureKit produces the image at Retina pixel resolution across all connected displays, and the result is handed to the editor as an annotation model rather than a flattened bitmap. That last part matters. The README states that annotations can be moved, rotated, recolored, retextured and deleted after placement, and that arrows and numbered callouts can be bent by dragging. A flattened image cannot do that, so the editor must be keeping the shapes as objects and re-rendering on confirm. Confirm writes PNG or TIFF to the clipboard; save writes PNG to disk; pin creates a floating always-on-top window; upload pushes to a configured bucket and puts the public link on the clipboard.

Long screenshot works differently from the rest. The README describes scrolling inside the selection while capcap captures frames continuously, previews the stitch live, and then merges into a result that stays editable in the same editor. Stitching is the feature most likely to produce visible artifacts, because it depends on the content scrolling predictably and on the overlap detection being right. The README does not document what happens when a page has sticky headers or lazy-loaded images, which is exactly where naive stitchers fail.

## Installing capcap with Homebrew and taking a first annotated screenshot

The README points at a unified tap rather than a per-project one. The cask lives in realskyrin/tap, so the install is two commands. The first adds the tap, the second installs the cask from it.

```bash
brew tap realskyrin/tap
brew install --cask realskyrin/tap/capcap
```

If macOS refuses to open the app with a message about being unable to verify it for malicious software, the README gives an explicit quarantine removal step for a build you trust. It also warns that you should only run this against a build you trust, such as one downloaded from the repository or one you built yourself.

```bash
xattr -dr com.apple.quarantine /Applications/capcap.app
```

If you are running a local build instead of the copy in /Applications, substitute the real path, for example ./build/capcap.app. Building from source is a single script that produces build/capcap.app.

```bash
./scripts/bundle.sh
```

On first launch the README states that capcap opens a settings window showing two permission states. Accessibility is needed for the default double-tap Command trigger, Screen Recording is needed for ScreenCaptureKit, and Finder automation is requested the first time you use the edit-selected-image feature. Once both required permissions are granted the app can start. Then the first real use is: double-tap Command in any app, hover a window and click to snap to its boundary, or drag a region. The floating toolbar appears with the annotation tools. Press Enter or click the green check to copy the result to the clipboard, or Esc or the x to cancel without output.

## Where capcap breaks down: stitching, permissions and the Finder edge case

The honest limitations are visible in the README rather than hidden. Long screenshot requires you to scroll inside the selection while capture runs. Any page whose content does not move monotonically, or that reflows as you scroll, gives the stitcher less to align on. The README does not describe a seam-correction step or a manual alignment control, so treat long screenshots of dynamic pages as something to check before you send them.

Permission state is the second failure mode. The double-tap Command trigger depends on Accessibility, and macOS is aggressive about revoking that grant when an app is replaced by an update. The README lists a permissions entry point in settings, which suggests the app surfaces status rather than silently failing, but the underlying behaviour is the operating system's, not capcap's.

The Finder integration has a documented boundary worth reading twice. If you select an image in Finder and trigger the shortcut, capcap copies the file to a temporary directory and loads it into the editor instead of starting a capture. The original file is not modified. But if the selection is not exactly one image (nothing selected, several selected, or a non-image), the README says the shortcut falls through to the normal capture flow. That is a reasonable default and also a surprise generator: the same gesture does two different things depending on Finder's selection state.

Finally, the app is macOS 14 and later only. There is no Windows, Linux or web build in the repository layout, and no iOS target.

## capcap versus the built-in macOS screenshot tool and versus a capture-and-upload service

The closest alternative is the screenshot tool already in macOS. It is free, always installed, and its markup editor covers rectangles, arrows and text. The difference in approach is the trigger and the persistence model. The system tool is invoked by a keyboard chord and produces a file or a clipboard image with annotations flattened into it. capcap is invoked by a double-tap of Command and keeps annotations as editable objects until you confirm, which is the whole reason the editor has undo, rotation and bendable arrows. If you annotate once and never revisit, the system tool is sufficient. If you routinely place a mosaic over a token, realize the arrow points at the wrong line, and drag it, capcap is built for that loop.

The other meaningful comparison is with services that pair a capture client with hosted storage. capcap deliberately does not host anything. Upload is optional and goes to a bucket you own: the README names Tencent Cloud COS, Qiniu Kodo and Alibaba Cloud OSS, with keys stored locally in UserDefaults. You get a public link on the clipboard and a thumbnail in history, and you pay your own object-storage bill. A hosted service gives you a link without configuring credentials, and gives a team a shared library. capcap gives you neither, and in exchange your screenshots stay on your machine unless you explicitly upload them.

## Maintenance cadence, upgrade cost and the MIT licence

The repository is not archived and the last push was on 2026-08-29, which is recent. The release list shows v1.7.10 on 2026-08-29, v1.7.9 on 2026-08-22 and v1.7.8 on 2026-08-21, so patches have been landing within days of each other. That cadence cuts both ways for an operator: you get fixes quickly, and you also get a stream of updates to install. Because the app is distributed as a cask, upgrading is a brew upgrade away, but each binary replacement can invalidate the Accessibility grant, so budget for re-checking permissions after an upgrade rather than assuming the trigger still works.

The Makefile exposes three targets that tell you what the maintainer checks before shipping: check runs scripts/compile-check.sh, verify runs scripts/rebuild-and-open.sh, and release-check runs scripts/bundle.sh with CONFIG=release and UNIVERSAL=1. If you build from source, those are the commands to run in the same order. The README also documents scripts/package-dmg.sh for producing a drag-installable DMG into dist/, and notes the app bundle is written to build/capcap.app.

Licensing is straightforward: MIT for capcap. The README lists one third-party dependency, PermissionFlow, also MIT, with its licence text under ThirdParty/PermissionFlow/LICENSE. MIT permits commercial use and modification, and requires that the copyright notice and licence text be preserved in copies. That is a description of the licence, not legal advice; if you redistribute a modified build, read the LICENSE file yourself.

## Conclusion

Adopt capcap if you work only on macOS 14 or later, you already grant Accessibility and Screen Recording permissions to a few utilities, and you want the capture gesture to be a double-tap of Command rather than a keyboard chord you have to remember. Do not adopt it if you split your day between macOS and Windows or Linux, if you need screenshots to land in a shared team library rather than a local history folder, or if you cannot install from a Homebrew tap or build from source with scripts/bundle.sh. Before you rely on it, verify three things on your own machine: that the double-tap Command trigger fires reliably in the apps you use most, that the two required permissions stay granted after a macOS update, and that a long screenshot of a scrolling window stitches without a visible seam where the editor continues to let you edit.

## FAQ

### What is capcap?

capcap is a lightweight native macOS screenshot tool that lives in the menu bar and is triggered by double-tapping the Command key. It captures a region or a detected window, opens a floating annotation editor with pen, mosaic, highlight, numbering and text tools, and can save to PNG, copy to the clipboard, pin the result on screen, or upload to a configured object-storage bucket.

### What are the key differences between capcap and capcap+?

The repository describes a single application named capcap, with no separate plus variant, so there is nothing in the project's documentation to compare. The distinctions that do exist are between distribution channels: the Homebrew cask, a source build via ./scripts/bundle.sh, and a DMG produced by scripts/package-dmg.sh.

### Which macOS versions and permission grants does capcap require?

The README states macOS 14.0 or later, with a Universal build for Apple Silicon and Intel. Accessibility permission is required for the default double-tap Command trigger, Screen Recording for ScreenCaptureKit capture, and Finder automation is requested the first time you use the edit-selected-image feature.

### Where does capcap store my screenshots and my upload credentials?

History is read from ~/Library/Application Support/capcap/History, and the README states the number of retained screenshot and colour-picker records is configurable between 5 and 20. Upload keys for Tencent Cloud COS, Qiniu Kodo and Alibaba Cloud OSS are stored only in local UserDefaults.

### How do I install capcap?

The README gives a two-command Homebrew cask install from the realskyrin/tap tap, and a source build through ./scripts/bundle.sh which writes build/capcap.app. If macOS blocks the app with a verification warning, the README documents removing the quarantine attribute with xattr, but only for a build you trust.

## Sources

- [Official documentation](https://capcap.skyrin.fun)
- [Official README](https://github.com/realskyrin/capcap#readme)
- [Project repository](https://github.com/realskyrin/capcap)
- [Release notes](https://github.com/realskyrin/capcap/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/realskyrin-capcap