the same app, two versions, and one of them can do less

why the App Store version is missing features

apps in the Mac App Store have to be sandboxed. a sandboxed app is confined: it sees its own container, plus whatever you hand it through a file dialog, and cannot reach into the rest of the system or into other applications.

that is a good security model, and for most software it costs nothing: a text editor, a drawing app or a game needs nothing outside itself.

what the sandbox actually forbids

Apple publishes the list rather than leaving it to be inferred. an app in the sandbox may not use the accessibility APIs the way an assistive app does, may not send Apple Events to arbitrary apps, may not read or change another app's preferences, may not quit another running app, may not configure network settings, and may not load kernel extensions.

read that list again as a list of products. moving another app's windows is the first line, and so is pasting into whatever you were last typing in. an uninstaller chasing what an app left behind is the third and fourth. a switch for your vpn configurations is the fifth. these are not things Apple forgot to allow — they are what the sandbox is for, and a utility is often software whose entire purpose sits on that list.

the clipboard case is the shortest illustration — a history is only useful if it can paste back into the app underneath: clipboard history for Mac

Apple's page on the sandbox carries both halves — that it is required for the App Store, and the list of what it makes impossible: protecting user data with App Sandbox

why a window manager has to choose

the line is finer than «no accessibility in the App Store», and the wrong version of it is repeated everywhere. a sandboxed app can hold Accessibility permission. what it cannot do is use it to reach into another app and act on it — and that is what a window manager, a switcher or a clipboard tool is for. the sandbox keeps an app inside its own world; these tools exist to work between worlds.

so their developer picks one of two bad options: leave the App Store, or ship a version there that does less. that is the whole of the pattern you noticed, and it has held since sandboxing became mandatory in June 2012.

Many Tricks put the boundary more precisely than the documentation does, explaining their own case: you cannot sandbox an app that controls another app. why isn't Witch in the Mac App Store

the category the sandbox rules out first, and what one of these actually does: window manager for Mac

what the App Store version and the site version guarantee

the row worth reading twice is the second. neither route is unchecked: a direct download from a legitimate developer is signed and notarized, so Apple has verified the identity behind it and scanned the binary. it is simply not confined — and for a utility, that is the product.

«in almost every case» is doing real work in that row. the guidelines ask that an app be «appropriately sandboxed», which is not the same sentence as «sandboxed», and a handful of apps predating the 2012 rule are still sold in the store without a sandbox at all. so App Store does not mechanically mean confined — and that is checkable rather than a matter of faith.

the wording itself, in the rule that governs it — section 2.4.5(i), on apps for macOS: app review guidelines

one of those older window managers, still in the store, is the standing exception: Magnet alternative

how to check which version you are looking at

two commands settle it for any app on your Mac. neither installs nor changes anything: they read the signature already there.

what the App Store version tells you

1. ask where it came from: spctl -a -vv /Applications/Some.app — an App Store app answers source=Mac App Store, a direct download answers source=Notarized Developer ID, and anything else is the answer that needs explaining.
2. ask whether it is confined: codesign -d --entitlements - /Applications/Some.app — look for com.apple.security.app-sandbox in the output.

run it on a real machine and the theory stops being tidy. Pages, Telegram and an unarchiver from the store all report the sandbox entitlement, as expected. Magnet — a window manager, bought from the store, receipt inside the bundle — reports four entitlements and not one is the sandbox. it is doing nothing wrong; it arrived before the rule and is allowed to stay. but the badge alone did not tell you what you assumed. thirty seconds in Terminal did.

the check runs the other way too, and that direction is the more useful one. «Notarized Developer ID» means a verified identity on file with Apple and a binary that went through Apple's malware scan. that is a stronger statement than «it is from the internet», and the one most warnings about downloading outside the store quietly skip.

what a direct download tells you

a third command explains the warning you actually see. anything your browser downloads is tagged: xattr -p com.apple.quarantine ~/Downloads/whatever.dmg returns a line naming the app that fetched it. that tag is why macOS checks the notarization ticket the first time you open the file, and why an unchecked one stops you there.

the uninstall case with the sandbox out of the way — «another app's preferences» is one line in Apple's list and about thirty places on disk: uninstall an app with its leftovers

how to tell a direct download you can trust

• it opens without warnings. a notarized app just launches; one that makes you right-click to open, or tells you to strip the quarantine flag in Terminal, is telling you something about how it was prepared.
• the permissions match what it does. a window manager needs Accessibility. a note-taking app asking for the same needs to explain itself.
• you can find the developer: a name, a site with history, a repository, an issue tracker with real people in it.
• the source is readable, where there is any. for a free utility from a stranger, that is the difference between trust and hope.
• and the practical safeguard: every permission is revocable in System Settings, and you find out at once what stopped working.

what notarization is and is not, in Apple's own words: notarizing macOS software before distribution

on our own side, since it is the same question: hop.tools is distributed from its site rather than the App Store, and not as a preference. removing an application together with what it left in about thirty places, switching the system's own vpn configurations, and blocking the keyboard are all things a sandboxed app is prevented from doing — the first two by name, on the list further up this page. the download is signed and notarized, the source is on GitHub, and each permission is asked for when the feature needing it is first used. spctl says so about our build the same way it says so about anyone else's.

«configuring network settings» is the fifth line of that list, and this is what it rules out: vpn switcher for Mac

the permission that most often prompts this question, and what it actually grants: why a Mac app asks for accessibility permission

frequently asked questions

is it safe to install a Mac app from outside the App Store?

from a legitimate developer, yes. such apps are signed with a Developer ID and notarized — Apple has checked the identity and scanned the binary. they are not sandboxed, which is often why they exist at all.

why isn't this app in the Mac App Store?

usually because it cannot be. a sandboxed app cannot reach into other apps to control them, and window managers, uninstallers and clipboard tools are built to do exactly that.

why does the App Store version have fewer features?

the developer kept a reduced build that fits inside the sandbox. the missing features are the ones that require reaching other apps or the system.

how do i know if an app is sandboxed?

run codesign -d --entitlements - on the bundle and look for com.apple.security.app-sandbox in what comes back. spctl -a -vv on the same bundle says where it came from — Mac App Store or Notarized Developer ID.

what does notarized mean?

the developer submitted the app to Apple, which scanned it for malicious content and issued a ticket macOS checks at launch. not a feature review, but not nothing either.

which is safer overall?

the App Store version is more confined, and confinement is the strongest safety property there is. a direct download trades it for capability, and you make that up with ordinary judgement: a known developer, permissions that match the features, readable source where there is any.