How to vet a free Mac utility before you trust it
Free does not mean untrustworthy, and paid does not mean safe. There is a five-minute test that separates them.
Two bad heuristics dominate this topic. The first is that free software is inherently risky. The second is that paying for something makes it safe. Neither survives contact with reality — a great deal of excellent Mac software is free and open, and a great deal of commercial software ships analytics you never agreed to.
What actually separates trustworthy from not is evidence, and the evidence is cheap to collect.
The five-minute test
Check where it came from
Developer's own site, the project's releases page, or a package manager. Never a download aggregator, a mirror, or a search result that merely looks official.
Verify the signature
codesign -dv --verbose=4 /Applications/Name.app shows the developer identity. spctl -a -vv /Applications/Name.app confirms notarisation.
Check the permission scope
After install, look at every Privacy & Security list. It should appear where its function requires and nowhere else.
Watch it for a day
With a connection monitor running, sort by process. An update check is expected. Analytics endpoints are a decision point.
Look for a history
A public issue tracker, dated release notes, a named maintainer. Software with a visible history is constrained by it.
Why provenance is the whole ballgame
The realistic threat to a Mac user is not that a popular utility is secretly malicious. It is that the copy you downloaded is not the one the developer published.
Free and widely searched utilities are heavily impersonated. Aggregator sites repackage legitimate applications inside their own installer, which may bundle adware, a search hijacker, or worse. The application then behaves exactly as advertised, which is why nobody notices.
If you remember nothing else: get the app from the developer, not from whatever ranked first. Signature verification exists precisely to catch the case where you did not.
What open source does and does not buy you
Does: makes claims falsifiable. "It does not phone home" stops being a promise and becomes a question someone can answer by reading. It also makes a quiet change of ownership — the classic route by which a beloved utility becomes adware — much harder to execute unnoticed.
Does not: guarantee anyone has actually read the code, or that the binary you downloaded was built from it. A small project with three stars and no history is not safer than a reputable commercial app merely because the source is public.
The strong version is reproducibility: build it yourself and the reviewed source and the running binary are the same thing by construction. Almost nobody does this, but the fact that it is possible constrains what a project can get away with.
A worked example
It helps to run the checklist against something concrete. Take a keyboard window manager, since that category requires a powerful permission and is therefore worth being careful about.
| Test | Result for a well-run project |
|---|---|
| Provenance | Official site, GitHub releases, and Homebrew all available — e.g. rectangleapp.com or brew install --cask rectangle |
| Signature | Signed with a consistent developer identity, notarised by Apple |
| Source | Public under a permissive licence, so the network-behaviour claim is checkable |
| Permission scope | Accessibility only. Absent from Screen Recording, Input Monitoring and Full Disk Access |
| Observed traffic | An update check, which can be disabled. Otherwise silent |
| History | Years of public releases, an issue tracker, a named maintainer who publishes other software under his own name |
Six for six. That is what a pass looks like, and it is the standard to hold other utilities to rather than a claim about one specific app. The same test applied to a random menu bar tool from a download portal usually fails at step one.
Red flags
- An installer package for something that should be a drag-to-Applications app. Packages run scripts as root.
- Permissions unrelated to function. A clipboard tool has no business in Full Disk Access.
- No identifiable developer. A company name with no history and no address.
- Aggressive upgrade prompting in something billed as free.
- Connections to analytics vendors in a utility with no plausible reason to measure anything.
- An uninstaller that leaves launch agents behind — see the menu bar audit.
The uncomfortable part
You cannot verify everything, and pretending otherwise leads to either paralysis or theatre. The realistic position is a hierarchy: verify carefully anything that holds a powerful permission, check provenance and signature on everything, and accept residual risk on the rest.
Which is another argument for keeping the number of installed utilities small. Every one is a trust decision you have to maintain, and the cheapest way to reduce that burden is to have fewer of them.
Frequently asked questions
How do I check if a Mac app is signed and notarised?
Run codesign -dv --verbose=4 on the app bundle to see the developer identity, then spctl -a -vv to confirm Apple notarisation.
Is open-source software automatically safer?
It makes claims verifiable, which is valuable, but it does not guarantee anyone has audited the code or that the binary you downloaded was built from that source.
Where should I download Mac utilities from?
The developer's own site, the project's official releases page, or a package manager like Homebrew. Download aggregators frequently repackage apps with unwanted extras.
What permissions should a small utility need?
Only those its stated function requires. A utility appearing in several powerful permission lists at once needs a specific justification.