Stops macOS asking for your login keychain password when you move between the two Mac editions.
The keychain prompt
If you used the disk image and then installed the App Store edition, macOS asked for your login keychain password on first launch, naming id.uniauth.clip.devicekey. Nothing was wrong and Deny was safe, but a clipboard app asking for your password reads as a break-in. It no longer happens.
The cause: macOS ties a keychain item to the signature of the app that created it, and the two Mac editions are signed differently — Developer ID for the disk image, Apple's own for the store build. Both were storing the sync key under one name, so each was reading an item the other owned. They now use separate names and cannot see each other's.
Your passphrase is not affected. The build that wrote the existing key can read it without a prompt, so it moves it to the new name silently on first launch. Nothing to re-enter, nothing lost.
Installing the App Store edition fresh will ask for your sync passphrase once, as any new install does.
Everything else
No other changes. Capture, history, search, pinning, sync and auto-paste are untouched.
macOSDisk image
macOS 14 or later2 MB
Developer ID Application: UniAuth Inc. (A5FW5P2536), notarised by Apple
Fixes the Mac app icon properly. 1.2 aimed at the wrong cause and did not fix it.
The icon
The Mac icon now fills its space the way every other app's does, at every size.
The cause was not the artwork. Ten icon slots were being fed by seven files, because a 32px image serves both 16@2x and 32@1x, and likewise at 256 and 512. The compiler keeps one slot per file, so six of the ten representations were silently dropped — every size above 256 among them. macOS had nothing to draw at large sizes, fell back to the 256px image at its natural size, and left a border around it that looked like a margin problem.
1.2 read that border as a shape problem and inset the artwork, which made it smaller still. That was wrong and is reverted. Each slot now has its own file.
Everything else
No functional change. This release and 1.2 differ from 1.1 only in how the icon is drawn.
1.2
ビルド4
Attempted to fix the Mac app icon and did not. The diagnosis was wrong; 1.3 has the real fix. The App Store submission of this build was cancelled.
Superseded by 1.3
This release reshaped the Mac icon on the theory that macOS was not masking it. That was not the cause, and the change made the icon smaller rather than fixing it. See 1.3.
Both Mac editions were put on one version number here, which was worth doing and still stands.
macOSDisk image
macOS 14 or later2 MB
Developer ID Application: UniAuth Inc. (A5FW5P2536), notarised by Apple
SHA-256 · UniClip-1.2.dmg
1.1
ビルド3
Fixes the update mechanism. 1.0 never checked for updates and never asked whether it could; this release asks once and then honours the answer.
Updates
UniClip now asks, on its second launch, whether it may check for updates on its own. Whichever you answer is remembered, and you can change it any time in Settings, under Privacy.
1.0 asked nothing and checked nothing. It shipped with automatic checks switched off rather than unset, which Sparkle reads as a question already answered, so the update scheduler started and then did nothing for the life of the build.
Nothing about how an update is verified has changed: it is installed only if signed by the same Apple Developer ID as the copy you are running.
If you are running 1.0, it could not have brought you here. You either came back to this page or clicked Check for Updates — which is exactly the problem this release fixes.
Everything else
1.0
ビルド1
First release. Clipboard history on the Mac, the same history on iPhone and iPad, and a keyboard that carries it into any app.
macOS
Menu bar app with no Dock icon. ⌘⇧V opens the history, typing filters it, Return pastes.
Captures text, images and file URLs, with the app each item came from.
Pin the things you paste constantly so they stay at the top.
Optional auto-paste, off until you turn it on and explained before macOS is asked for the privilege.
Installs an update only if it is signed by the same Apple Developer ID as the copy you are running. See the known issue below for how this build finds one.
A disk-image user who installs the App Store edition still gets a login keychain prompt on first launch, because both editions store the sync device key under one shared name and are signed differently. Deny is safe; the app sets sync up again. The fix costs a passphrase re-entry, so it waits for its own release.
Fixed in 1.4, without costing anyone their passphrase.
macOSDisk image
macOS 14 or later2 MB
Developer ID Application: UniAuth Inc. (A5FW5P2536), notarised by Apple
No other changes. Capture, history, search, pinning, sync, the keyboard and auto-paste all behave exactly as they did in 1.0.
The release process now refuses to publish a build whose update feed, signing team, bundle identifier or advertised version disagrees with the artefact being uploaded. None of that is visible in the app; it exists so this class of fault cannot ship twice.
macOSDisk image
macOS 14 or later2 MB
Developer ID Application: UniAuth Inc. (A5FW5P2536), notarised by Apple
This build never looks for updates on its own, and never asks whether it may. It shipped with SUEnableAutomaticChecks set to false, which Sparkle reads as an answer already given rather than as a question to ask — so the update scheduler starts and then does nothing.
Nothing is broken and nothing is at risk. But a fix published here will not reach this build by itself, so it is worth knowing: use Check for Updates in the menu bar, or switch on "Check for updates automatically" in Settings, under Privacy. Both work, and the switch is remembered.
The next release removes the key, so the app asks once on the second launch and then honours whichever answer you gave.
iPhone and iPad
A full keyboard — QWERTY, emoji, autocorrect, glide typing — with your clipboard along the top.
Start typing something you copied and it appears beside the word suggestions.
Add items through the share sheet or the app, because iOS does not let any app read the clipboard on its own.
Try the keyboard inside the app before installing it, without the two trips through Settings.
Privacy
Every item is sealed with AES-GCM on the device before upload, under a key derived from your passphrase with PBKDF2 at 600,000 rounds.
Content another app marks as confidential is refused before it is read. That one is not a setting.
API keys, private keys, one-time codes and payment cards stay on the device that copied them, masked in the list.
Search runs on the device, because the server has nothing it could index.
macOSDisk image
macOS 14 or later2 MB
Developer ID Application: UniAuth Inc. (A5FW5P2536), notarised by Apple