Pasteboard Viewer needs macOS 26 for its current build, and the non App Store copy is a Dropbox zip updated once a year

It is not a clipboard manager, and the page names who should skip it

The positioning is stated in the first line and then repeated in a way most pages skip. This is a developer utility that lets you inspect the various system pasteboards, and its stated use is ensuring your app is putting the correct data on `NSPasteboard` on macOS or `UIPasteboard` on iOS.

Then comes the line that decides whether to keep reading: this is not a clipboard manager, and if you are not a programmer you probably do not want this app.

That is useful because the app does look like a clipboard tool. The window lists pasteboard items, and arrow keys step between them, which is the interaction a history app would use. What it does not do is keep anything. The purpose is verification, so the model is a live view of what another process just put on the system pasteboards, not a store of what you copied yesterday.

The previews are what make it more than a type inspector. Text, RTF and images are previewed, and so is anything that has a Quick Look preview, which means a document type the app does not specifically know about still has a chance of rendering.

The current build needs macOS 26, and every older system gets its own archive

The stated requirement for the current version is a minimum of macOS 26, iOS 26 or visionOS 26. That is a high floor, and it is the reason the page spends as much space on old builds as it does on the new one.

The ladder of archived versions is explicit. Version 2.11.0 for macOS 15 and later, 2.8.0 for macOS 14 and later, 2.5.1 for macOS 13 and later, 2.4.1 for macOS 12 and later, 2.2.2 for macOS 11 and later, and 1.5.1 for macOS 10.15 and later, which is the oldest system the project still supports by pointing at an archive.

Two details in that list are worth noticing. The 2.4.1 download is hosted as a file in a separate repository under the author's meta project rather than in this repository's releases, so the hosting for one archived build lives somewhere else entirely. And the oldest entry links to a release tag rather than to a zip, so the path to actually downloading 1.5.1 is one click further than the others.

Each of those archives is a separate app you install alongside nothing else, so a machine on an older system is running a build that receives no further fixes for that OS version.

The non App Store copy is a Dropbox zip, refreshed about once a year

There is a separate distribution channel for users who cannot access the App Store, and the page describes it with unusual candour about its own limits.

It is a special version for those users, it will not receive automatic updates, and the author will update it once a year. The link is a direct download to a Dropbox folder rather than a release asset, and the file name carries both the version and a timestamp, `Pasteboard-Viewer-2.12.0-1774843275.zip`, which is the sort of name that makes it obvious this is a file rather than a stable endpoint.

So the offline channel is best understood as a fallback rather than a supported path. It currently matches the store version at 2.12.0 for macOS 26 and later, but the update cadence is a year, not a release, and there is no mechanism to tell you when it has been refreshed.

For anyone who needs a current build without the App Store, the practical consequence is that you check the repository for a new tag and then find the refreshed file yourself, rather than relying on the app to tell you.

Obsolete pasteboard types are filtered out, so the view is not a raw dump

One behavior deserves attention before you debug anything with this app. It hides obsolete system pasteboard types that have modern equivalents. The named examples are three legacy identifiers, `CorePasteboardFlavorType`, `NSStringPboardType` and `NSFilenamesPboardType`.

The reason is historical rather than arbitrary: those are pre macOS 10 pasteboard flavors that no current application writes, so leaving them in the list would be noise. But it does mean the sidebar is a filtered view, and a type that is genuinely absent may be absent because it was hidden rather than because nothing put it there.

That is where the tip on the page earns its place. Right-clicking an item on macOS, or long-tapping it elsewhere, copies the item's type identifier. So the workflow for someone checking a pasteboard write is to confirm the item is present, then copy its identifier and paste it into whatever the code should be writing, rather than reading the type off the screen and transcribing it.

The same tip is also the reason the gesture is described differently per platform, which is a small sign the app is one codebase serving macOS, iOS and visionOS rather than three separate apps.

One Xcode project, three platforms, and lowercase metadata files at the root

The repository root is small and mostly not code. There is the `Pasteboard Viewer.xcodeproj` directory, the `Pasteboard Viewer/` source directory, and a `Stuff/` directory whose purpose is not explained anywhere on the page.

Then there are three plain text files that are really release metadata: `app-store-description-ios.txt`, `app-store-description-macos.txt` and `app-store-keywords.txt`. Keeping the App Store descriptions and keywords in the repository rather than pasting them into the store portal means the copy for each platform is versioned, diffable and reviewable, which is a deliberate choice for an app whose storefront text is part of the product.

Two naming details also stand out. The readme is `readme.md` and the license is `license`, both lowercase, while the project directory next to them uses a capital letter and a space, `Pasteboard Viewer/`. That is not a problem in a working tree, but it does mean the file paths are not portable to a case sensitive filesystem assumption, and it is a small inconsistency in an otherwise tidy repository.

Tooling is minimal and conventional: an `.editorconfig`, `.gitattributes`, `.gitignore` and a `.swiftlint.yml` for Swift lint rules.

Localization contributions are declined, by design

The FAQ on the page has one entry and it is a refusal. Asked whether localizations can be contributed, the answer is that the author does not plan to localize the app.

That is worth knowing before anyone opens a pull request with a `Localizable.strings` file, because the project has decided the surface stays in the language it ships in. It also explains something about the interface: a developer tool with a small, fixed vocabulary of terms like pasteboard types is a plausible candidate for staying single language.

The rest of the interface is small and platform specific. On macOS the window can be pinned above others by enabling Stay in Front in the Window menu, a standard AppKit menu action that has no equivalent on touch platforms. The up and down arrow keys step between pasteboard items. And the view refreshes live, so an app you are debugging can write to the pasteboard and you watch the item appear without any manual refresh step.

That last point is the feature that makes this a debugging tool rather than an inspector: the question you are answering is what does my code put on the pasteboard right now.

Version 2.12.0 and the last push share a date

Release history is short and the newest entry is recent enough to line up exactly with the branch. v2.12.0 was published on 2026-03-30, the default branch `main` received its last push on 2026-03-30, and the two earlier tags are v2.11.0 from 2025-09-13 and v2.10.1 from 2025-05-05.

That gives two release gaps worth naming: about four and a half months between 2.10.1 and 2.11.0, and about six and a half months between 2.11.0 and 2.12.0. For an App Store utility, that pattern fits a development model where the substantial work happens when a new macOS arrives and the intervening months are quiet.

The macOS 26 requirement of the current build is the same story from the other side. A minimum of macOS 26, iOS 26 and visionOS 26 means the app tracks the newest operating system releases rather than the oldest it can still support, and the archived builds are what carry the older systems forward.

The license is MIT, in a file named `license` at the root, and the app's public home is a page on the author's own site listing this app among others he makes.

Editorial conclusion

Install Pasteboard Viewer if you are writing or debugging an app that writes to `NSPasteboard` or `UIPasteboard` and need to see what types and payloads actually landed, because that is the whole job and it does it with live refresh and Quick Look previews. Do not install it expecting a clipboard history, since the page states plainly that this is not a clipboard manager and that a non programmer probably does not want the app. Two practical points before you start. Check your OS first, because v2.12.0 requires macOS 26, iOS 26 or visionOS 26 and everything below that needs one of the archived per version zips, with the oldest supported build reaching back to macOS 10.15. And if you cannot reach the App Store, know that the alternative copy is a direct download that gets no automatic updates and is refreshed about once a year, so it will drift behind the store version. The repository is MIT licensed, the newest tag is v2.12.0 from 2026-03-30, and the default branch was last pushed on the same day.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sindresorhus/Pasteboard-Viewer on GitHub