Paste Switch started with a small annoyance.
When I work on a Mac, I often copy several things in a short burst: a command, a URL, a sentence, an image, a note, another command. Clipboard managers can store all of that, but most of the time I do not want to open a big history window, search, pick an item, and go back.
I wanted something faster:
copy a few things
press one shortcut
paste the latest item
press the same shortcut again if I wanted the previous one
That was the whole idea. Stay in the app where I am typing, and switch recent clipboard items without opening a manager.
The first name was PasteCycle. It described the action, but it sounded more like a feature. The product became Paste Switch: a small Mac menu bar utility for switching recent clipboard items into the place where I am already working.
The important decision was what not to build
There are already powerful clipboard managers. They have search, folders, favorites, sync, rules, rich previews, and long history.
Paste Switch is not trying to be that.
Its job is narrower:
watch recent clipboard items
-> keep a small local history
-> paste the newest item
-> press again to replace it with the next one
-> get out of the way
That boundary changed the engineering. History could stay small. The panel could be secondary. The main experience had to be the shortcut.
The question was not “can I store everything the user copies?” The better question was:
Can I paste the wrong recent item, press the same shortcut again, and quickly get the right one?
If that works, the product has a reason to exist.
The MVP was the shortcut loop
The tempting thing was to design a beautiful clipboard panel first. I still needed a panel, but the product would be judged by the shortcut.
The first loop was:
copy A
copy B
press Shift+Cmd+V -> paste B
press Shift+Cmd+V again -> replace B with A
That looks simple. It is not simple in real apps.
Pasting is easy. Safe replacement is the hard part. After the first paste, the user might type more text, move the cursor, switch apps, or change the selection. At that point, blindly undoing and pasting something else would be dangerous.
So Paste Switch keeps replacement inside one active cycle. While the cycle is active, repeated shortcut presses can undo the previous Paste Switch paste and paste the next item. If unrelated keyboard input happens, the cycle ends.
That keeps the feature from becoming too aggressive.
macOS permissions are part of the UX
Paste Switch has to send native paste and undo events into the focused app. That means macOS Accessibility permission is not a small implementation detail. It is part of the product experience.
Later, the smoother cycle interaction also needed Input Monitoring. With that permission, the app can know when Command or Shift is released and end the cycle immediately. Without it, the interaction cannot be as precise.
The permission UI had to explain this without sounding scary:
- Accessibility lets Paste Switch paste and replace content in the focused app.
- Input Monitoring lets it end a cycle when the shortcut modifiers are released.
- No private data is collected or uploaded.
For a utility like this, trust is not separate from functionality.
The overlay should be feedback, not a picker
Shortcut-only switching can feel invisible. The app needs to show what just happened, but it should not pull the user into a full picker.
That is why Paste Switch has a small overlay. It appears near the active input position, shows the current item, and updates when the user presses the shortcut again.
The overlay has one job: make the shortcut feel understandable while keeping focus in the target app.
This small UI created a surprising number of details: modifier-key timing, multi-monitor positioning, full-screen apps, input-position detection, overlay height, hover behavior, and when to hide. None of those details are glamorous, but they decide whether the app feels crisp or broken.
The menu bar shape fits the product
Paste Switch is not something I want to open all day. It should be running quietly.
So the app became a menu bar utility:
- no Dock-first workflow;
- status lives in the menu bar;
- clicking the icon opens the compact panel;
- losing focus hides the panel;
- right-click can quit the app.
The panel still matters. It shows recent clips, permissions, shortcut state, reset, clear, and Pro status. But it supports the main action. It is not the main action.
Making it a product added another layer
Once the shortcut loop worked, the next question was whether it could become something another person could try.
That meant adding the less exciting parts:
- a stable app identity and icon;
- trial and Pro state;
- monthly and lifetime payment links;
- license activation;
- update checks;
- tests for UI and cycle logic;
- signed local builds and DMG packaging;
- a product page and download flow.
This is the same lesson I keep relearning: the core feature is only one part of a product. The path around it matters just as much.
What I would keep
The best decision was keeping the product narrow.
If I had started with “build a better clipboard manager,” the scope would have exploded. Search, folders, sync, rich formats, permanent history, import/export, rules, and power-user settings would all seem necessary.
By starting with one repeated action, the product stayed clear.
Copy a few things. Stay in the app where you are working. Press the shortcut until the right item lands.
That is a small enough product to build, and a useful enough workflow to keep polishing.
Top comments (0)