Why my Mac apps ship with almost no dependencies
Six small macOS utilities, most of them under four megabytes, nearly all of them pure Swift and SwiftUI. The reasoning is less about performance than about who has to maintain them.
I have six small Mac utilities in regular use. Shrinkly compresses images; ColorSnipper picks colours from anywhere on screen; PathPilot opens the directories I keep digging for; MathPad does arithmetic in a notepad. The largest is under four megabytes. Between them they pull in almost no third-party code.
That is not a performance decision. Nobody has ever complained that a colour picker was insufficiently optimised.
The real reason is maintenance
Every dependency is a promise that someone else will keep maintaining something, on a schedule you do not control, through OS releases you cannot predict. For a solo side project that promise gets broken quietly. The repo goes stale, then a macOS update lands, and now a tool you use daily is broken by code you never wrote and do not understand.
With the platform frameworks that risk mostly disappears. Apple has strong incentives to keep SwiftUI and AppKit working. When they do break something, it breaks for everyone at once, which means the fix is documented within days.
A dependency is a bet that someone else will still care about this in three years. Sometimes that is a good bet. It is rarely a free one.
Where I do take the dependency
I am not dogmatic about it. ColorSnipper and PathPilot both need global keyboard shortcuts, and the Carbon-era API for that is unpleasant enough that a well-maintained wrapper is genuinely worth it. Shrinkly talks to a compression API over the network because writing a better image compressor than a dedicated service is not a weekend project.
The test I apply is simple: if this package were abandoned tomorrow, could I replace it in a day? A keyboard-shortcut wrapper, yes. A whole UI framework or a reactive architecture, no. The first is a convenience. The second is a landlord.
What you get back
- Builds that still work. I can open a project I have not touched in a year and it compiles.
- Small binaries. Two to four megabytes, which is a pleasant thing to hand someone.
- Fewer moving parts at 11pm, when something is broken and I would like to be asleep.
- The whole thing fits in my head. Underrated, and the reason these apps still get updates.
The trade-off is real
Building without dependencies costs time upfront. I have written file-watching, drag-and-drop and preferences code more than once. If I were shipping a venture-funded product against a deadline I would make different choices, and I would be right to.
But these are tools I built because I wanted them, and I want them to still work in five years without becoming a research project. On that goal, the boring approach wins comfortably.