Always running, or opened when you need it
An app you launch, use and quit gets judged on how well it does the job. It can take a second to start and hold a few hundred megabytes while open. You will forgive both, because the alternative is not having the feature.
An app that sits in your menu bar from login to shutdown is judged differently, and it should be. It holds memory while you are doing something else, and it shapes how the whole machine feels. A menu bar utility has no business sitting at 300 MB. That opinion is what the rest of this rests on.
The always-running set is small and specific. Clipboard manager, window manager, launcher, screenshot tool, menu bar organiser, system monitor. Six processes with your login items, and every megabyte in them is permanent.
Electron is a reasonable trade, and here is when
Three platforms, one team. If your users are on macOS, Windows and Linux, and you have four engineers, Electron is the sensible answer. The alternative is three codebases and three sets of platform bugs, and the third one never gets finished.
Complex UI you already built for the web. VS Code, Slack, Discord and Notion are Electron apps that do a great deal of work. They render documents, editors and rich chat, and they are the same on every desktop your team uses. Rewriting that in AppKit for one platform would take years and ship a worse product.
A shared web app underneath. When the desktop app is a view onto the same service the browser shows, sharing the rendering layer is honest engineering rather than laziness.
Everything in this window is AppKit and SwiftUI drawing native controls. The reason to care is not visual purity. It is that the window inherits the system's text handling, keyboard behaviour and accessibility support without me reimplementing any of it.
The part nobody advertises: native gets you the platform's own conventions for free, and it also gets you the platform's own bugs. Both are part of the deal.
One more point in Electron's favour. A well-built Electron app beats a badly built native one every time. Native is not a quality guarantee. There is plenty of slow, ugly, badly behaved AppKit software, and I have shipped some of it during development.
Where the trade breaks
Bundling a browser engine to draw a list of ten rows is where I stop defending it. A clipboard manager reads the pasteboard, stores strings and images, and shows a small window. None of that needs a rendering engine built for arbitrary web pages. The engine also has a memory floor before your code does anything.
The floor is the problem, not the peak. A browser engine loaded into a process that never quits holds its memory all day, regardless of whether you copied anything. Multiply by the five or six utilities people actually run, and the machine feels different.
Startup matters more than it sounds for this class of app too. You press a shortcut and expect the window immediately. That is a hard target when the first thing that has to happen is a JavaScript runtime waking up.
The bar I hold myself to
Shottr is around 1 MB and faster than the system screenshot tool. That obsession with speed is exactly my kind of unreasonable, and it is the standard I measure against rather than against the bloated end of the market. Comparing yourself to the worst option available is how you end up mediocre.
Maccy is the other one, free, open source and about 1.6 MB. It is fast because it refuses to do very much, which is a real strategy and not a limitation.
What going native actually costs
It is slower to build, and the platform fights you. My worst bug took three hours. The popup would not close when I released the keys, and the cause was the way macOS delivers keyboard events. On the web that behaviour is one event listener. In AppKit it is a global event monitor, modifier flag state, and reading the documentation twice.
Some of the frameworks are old and undocumented. Converting HTML into styled text on macOS still goes through a legacy WebKit-based importer. The first call in a process is slow because it loads the framework. You find that by measuring, not by reading a guide.
You give up every other platform. No Windows version, no Linux version, no browser version. For a solo developer that is a real market decision, not a purity stance.
Cross-platform is a business model, not a compromise. If your revenue needs Windows users, this whole post is somebody else's problem, and Electron is a rational choice.
What I picked
Klipto is native Swift, AppKit and SwiftUI, one binary with no bundled runtime. It is about 5 MB to download and around 11 MB installed. It is always running, which is the only reason those numbers are worth stating at all.
I only build for Mac. One platform done properly beats three done badly, and I would rather have a smaller market and an app that feels correct. The visible payoff is small: the popup appears when you press ⌥⌘V and it is gone when you let go. The hold-to-paste popup works that way because native event handling makes it possible, after I lost an afternoon to it.
The limit is plain enough. If you need your clipboard history on Windows or in a browser, I have nothing for you, and no plan to.