Clipy: a macOS clipboard extension built in Swift, and how to build it yourself
Clipboard extension app for macOS.
At a glance
- What is it?
- Clipy is an MIT-licensed clipboard extension for macOS 13 and later, distributed from clipy-app.com. The interesting part is not the feature list but the build: the default signing settings point at a certificate only the maintainer holds, so local builds have to switch to ad-hoc signing first.
- Who is it for?
- Adopt Clipy if you are on macOS 13 Ventura or later and want a clipboard history tool whose source you can read, fork and build under the MIT licence. Do not adopt it if you are on Windows or Linux (the repository is an Xcode project with no cross-platform target) or if you need a signed, notarised binary produced by your own CI without touching the signing configuration.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The clipboard history problem Clipy targets, and who it is for
macOS keeps one clipboard. Copy a second thing and the first is gone. Clipy exists to sit between the user and that single slot, keeping a history that can be called back. The README describes it plainly as "a Clipboard extension app for macOS", and the repository topics list clipboard, clipboard-extension, clipmenu, macos, swift and xcode.
The intended user is a Mac owner who copies repeatedly during a task: moving values between forms, assembling a document from several sources, or pasting the same snippet on a schedule. The project is not aimed at teams running a shared service. It is a desktop utility, installed per machine, with no server component described anywhere in the README.
The lineage matters for anyone judging the design. The README thanks @naotaka for publishing ClipMenu as open source, and the repository carries a separate LICENSE_CLIPMENU file alongside the MIT LICENSE. Clipy is a continuation of that idea in Swift, distributed as an Xcode project rather than a script bundle.
How Clipy is put together: an Xcode app, a signing constraint and a private plist
The repository layout is a normal macOS application project: Clipy.xcodeproj, a Clipy/ source directory, ClipyTests/, Configurations/, Resources/, plus .swiftlint.yml for lint rules. There is no package manifest for another ecosystem and no Dockerfile, which is consistent with a native app.
The mechanism that shapes everything else is code signing. The README states that macOS checks Accessibility permission by the app's code signature, and that if Clipy is built without a stable signing certificate, macOS may ask for Accessibility permission again for every build. The default signing settings therefore use the Clipy signing certificate, which the README says is available only to the maintainer. That is a deliberate choice, and it has a cost: a fresh clone will not build under the default configuration for anyone outside the project.
Firebase is optional. The README says to place your own GoogleService-Info.plist in Clipy/GoogleService if you want those features, and that the file is not required for local builds without Firebase. PRIVACY.md is where the project documents local data storage, network communication, analytics and crash reporting; the README does not summarise those points, so that file is the place to look.
Building Clipy locally with ad-hoc signing
The README gives an explicit two-step procedure for a local build. First open the project in Xcode, then switch to ad-hoc build mode by editing the signing configuration, then build the Clipy scheme.
Start by opening the project:
open Clipy.xcodeprojInside Xcode, open Configurations/CodeSigning.xcconfig and uncomment the ad-hoc include so the file reads as follows:
#include "Configurations/CodeSigning-AdHoc.xcconfig"After that, build the Clipy scheme from Xcode. The README notes that the development environment for the project is macOS 26 Tahoe with Xcode 26.5, so an older Xcode may not open the project cleanly. The requirement for running the app itself is stated separately: macOS 13 Ventura or later.
If you want Firebase features in your build, add your own GoogleService-Info.plist under Clipy/GoogleService. Without that file the README says a local build is still fine.
The expected outcome is an app you signed yourself. Because the signature is not the maintainer's, macOS may ask for Accessibility permission again on each rebuild. That is the trade the README describes, not a bug to work around.
Where Clipy stops being the right tool
The clearest boundary is the platform. Clipy is a macOS application, and nothing in the repository suggests a Windows or Linux build. Search traffic asking for a Windows version does not correspond to anything the project provides.
The second boundary is distribution. The README directs users to clipy-app.com, and the build instructions are written for someone with Xcode. If you need a signed binary produced by your own release pipeline, you are working against the default configuration: the Clipy certificate belongs to the maintainer, so you must either run the ad-hoc path or supply your own signing identity. The README does not describe a CI recipe for either.
A third limitation is documentation depth. The README covers the build and a distribution request, but it does not document rollback, migration between versions, or what happens to stored history when the app is replaced. Anyone who needs those guarantees has to read the source or the privacy policy. Release history also shows uneven cadence: 1.2.1 is dated 2018-10-10, while 1.3.0 is dated 2026-06-20, so the gap between releases has not been uniform.
Clipy compared with a cloud-synced clipboard manager
The obvious alternative category is a clipboard manager that syncs history across devices through an account. The difference is architectural, not cosmetic. A synced tool keeps state on a server, which is what makes cross-device paste possible and also what makes an account and a network path part of the product. Clipy, as documented, is a local desktop extension; PRIVACY.md is the file that describes its data storage and network behaviour, and the README points there rather than describing a sync service.
That distinction decides the choice. If you move text between a laptop and a phone, a local-only tool will not do it. If you would rather your clipboard history never leaves the machine, a cloud tool is the wrong shape and Clipy is closer to what you want, subject to what PRIVACY.md actually says about analytics and crash reporting.
There is also a licensing difference worth naming. Clipy is MIT, and the README asks that derived work not use Clipy or ClipMenu as the product name, especially in the Mac App Store, and that the MIT terms be followed. A commercial synced product will not give you that freedom.
Maintenance, licensing and what a fork costs you
The repository is not archived, and the last push was on 2026-09-20, so the codebase is being touched. The 1.3.0 release is dated 2026-06-20. The 1.2.2 entry is labelled a draft and work in progress, so it should not be read as a shipped version.
Upgrade cost for a user is low: the README points to clipy-app.com for distribution, and there is no documented migration step between versions. Upgrade cost for a contributor is higher. Every local rebuild can trigger a fresh Accessibility prompt because the signature is not stable, which is friction that shows up each time you change the code. The project also asks for localization contributors through CONTRIBUTING.md, so translated strings are an area where the codebase expects outside input.
On licensing: Clipy is MIT, and the README adds two distribution requests, that derived work not use Clipy or ClipMenu as its product name and that the MIT terms be followed. Icons are noted as copyrighted by their respective authors, so they are not covered by the same blanket assumption as the source. The separate LICENSE_CLIPMENU file exists because part of the heritage comes from ClipMenu. This is a description of what the repository states, not legal advice; a distributor should read LICENSE, LICENSE_CLIPMENU and the icon attribution before shipping anything.
Editorial conclusion
Adopt Clipy if you are on macOS 13 Ventura or later and want a clipboard history tool whose source you can read, fork and build under the MIT licence. Do not adopt it if you are on Windows or Linux (the repository is an Xcode project with no cross-platform target) or if you need a signed, notarised binary produced by your own CI without touching the signing configuration. Before you commit, verify three things: that your machine meets the macOS 13 floor, that you can uncomment the ad-hoc include in Configurations/CodeSigning.xcconfig and build the Clipy scheme, and that you have read PRIVACY.md for what the app stores locally and what it sends over the network.
Frequently asked questions
What is the Clipy app?
Clipy is a clipboard extension app for macOS, written in Swift and licensed under MIT. It requires macOS 13 Ventura or later and is distributed from clipy-app.com.
How do I install Clipy on a Mac?
The README names clipy-app.com as the distribution site, so installation for normal use comes from there rather than from a package manager. Building from source is a separate path that requires Xcode and a change to the signing configuration.
Is there a Clipy mobile app?
The repository describes Clipy as a macOS clipboard extension and lists macOS 13 Ventura or later as the requirement. Nothing in the README describes an iOS or Android app.
Is Clipy safe to use?
The repository includes a PRIVACY.md that covers local data storage, network communication, analytics and crash reporting, and the README points to it rather than summarising it. Read that file to judge how the app handles your data.
What is the Clipy alternative for Mac?
The README does not compare Clipy with other clipboard managers. What it does document is the ClipMenu heritage, thanked in the README and covered by a separate LICENSE_CLIPMENU file, which is the closest thing to an alternative the project itself names.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/clipy-clipy)