One folder, six update channels
Every app in /Applications arrived through some distribution channel, and that channel usually decides how the app updates, what verification happens along the way, and which installer should own the update. Before you click Update — or replace a bundle by hand — it is worth knowing which of the six common sources an app belongs to. The pillar guide to updating Mac apps safely covers the how; this page is the taxonomy.
Mac App Store
How it delivers: Apple hosts the binary, reviews each release, and installs updates through App Store > Updates — or automatically, if enabled in App Store settings.
How to identify: App Store installs carry a receipt inside the bundle. If this file exists, the app came from the store:
ls "/Applications/AppName.app/Contents/_MASReceipt"Trust profile: the strongest default chain on macOS. Apple signs and delivers the update, apps run under store sandboxing rules, and versions only move forward. The limitation is coverage — it only sees apps installed from the store, and some pro apps skip the store because sandboxing does not fit them.
Sparkle appcasts
How it delivers: the app itself checks an appcast — an XML feed where each item lists the release's version, archive URL, signature, and minimum system version — and offers the update in-app. Sparkle 2 verifies the download with an EdDSA (ed25519) signature and installs through a sandboxed XPC helper; legacy Sparkle 1 relied on weaker DSA signatures.
How to identify: the feed URL sits in the app's Info.plist under the SUFeedURL key:
defaults read "/Applications/AppName.app/Contents/Info.plist" SUFeedURLIf that prints a URL, the app updates via Sparkle. Trust profile: the developer controls the channel, and the signature check pins each update to a public key shipped inside the app. The Sparkle guide goes deeper on feeds and signatures.
Homebrew
How it delivers: Homebrew's index maps a cask token to the vendor's official release URL, usually with a SHA-256 checksum recorded per version. brew upgrade --cask downloads that release and replaces the app bundle; formulae cover command-line tools the same way.
How to identify: ask Homebrew what it manages:
brew list --caskTrust profile: downloads come from vendor URLs with checksums pinned in the cask, and quarantine is applied by default so Gatekeeper still evaluates the app. The caveats are coverage and staleness — brew only manages what it installed, and self-updating apps are skipped unless you ask for them with --greedy. The cask mechanics guide walks through the workflow and its edge cases.
Vendor updaters
How it delivers: a background helper installed by the vendor checks its own channel and installs signed packages for a whole app family. Microsoft AutoUpdate handles Office. Google Software Update (Keystone) handles Chrome. Adobe apps update through the Creative Cloud desktop app, with Adobe Remote Update Manager (RUM) as the command-line equivalent on managed Macs. Docker Desktop ships its own updater.
How to identify: look for the helper itself. Microsoft AutoUpdate lives at /Library/Application Support/Microsoft/MAU2.0, and Keystone registers launch agents named com.google.keystone.* in /Library/LaunchAgents or ~/Library/LaunchAgents.
Trust profile: packages are signed by the vendor, and the updater understands the suite's shared components. For these app families the vendor tool is usually the safest owner — replacing an Office or Creative Cloud bundle by hand can break pieces the updater would have handled.
Direct downloads
How it delivers: the vendor posts a new DMG or ZIP on its site, and updating means fetching it and replacing the old bundle yourself.
How to identify: mostly by elimination — no _MASReceipt, no SUFeedURL, not in brew list --cask, no vendor helper. The app's own website is its release channel.
Trust profile: verification is on you. Check Developer ID signing and notarization before first launch, and compare a published checksum when the vendor offers one:
spctl -a -vv "/Applications/AppName.app"
shasum -a 256 ~/Downloads/AppName.dmgKeep the old bundle until the new version launches cleanly — a direct replacement has no built-in rollback.
In-app-menu-only updaters
Some apps update only through their own Check for Updates menu item, using a custom updater rather than Sparkle. There is no feed to read, no receipt, and no cask — the menu item is the channel.
How to identify: none of the other markers are present, but the app has an update command in its menus or settings. Trust profile: it varies with the developer. The useful checks are the same as for any direct download — confirm the version moves forward, and confirm the installer comes from the vendor's own domain rather than a mirror.
Quick identification table
One pass through these checks classifies almost any app on your Mac:
| Source | How updates arrive | Quick identification | Who verifies the download |
|---|---|---|---|
| Mac App Store | App Store > Updates | _MASReceipt exists inside the bundle | Apple signs and delivers |
| Sparkle appcast | In-app prompt from an XML feed | SUFeedURL in Info.plist | Sparkle checks an EdDSA signature (Sparkle 2) |
| Homebrew | brew upgrade --cask | Token appears in brew list --cask | Checksum in the cask, then Gatekeeper |
| Vendor updater | Background helper (MAU, Keystone, Adobe) | Helper app or launch agent in /Library | Vendor-signed packages |
| Direct download | New DMG or ZIP from the vendor site | No receipt, feed, cask, or helper | You: spctl, notarization, checksum |
| In-app menu only | Check for Updates menu item | Update menu exists, no other markers | The app's own updater; varies |
How macCurrent uses source labels
macCurrent runs these identification checks for you. Each installed app gets a source label — App Store, Homebrew, Sparkle, vendor-managed, or direct — shown next to its signing identity and version direction, so you can see which update path owns each app before anything changes.
The label drives behavior: apps that can be updated directly are backed up first, app families with a trusted vendor updater are handed off to it, and anything ambiguous gets flagged for review instead of silently replaced. Some apps legitimately match more than one source — a cask-installed app with Sparkle built in, for example — and macCurrent shows which one it will use. See the current source coverage and trust-boundary map, or install macCurrent to see every app's source in one list.
Frequently asked questions
Why do Mac update sources matter?
The source determines which trust checks are available and which installer should own the update. An App Store app gets Apple's signing and delivery chain, a Sparkle app gets a signature-verified feed, and a direct download gets only the checks you run yourself.
Can Homebrew update direct-download apps?
Only if the app is actually installed and tracked as a Homebrew cask. Many direct-download apps are outside Homebrew's view, though newer Homebrew releases can adopt a matching manually installed app with brew install --cask --adopt.
Should vendor-managed apps be updated manually?
Often yes — through the vendor's own tool. If an app family has a trusted updater such as Microsoft AutoUpdate or the Creative Cloud app, the safest path is opening that updater instead of replacing app bundles directly.
How do I tell if a Mac app came from the App Store?
Look for the receipt Apple embeds at install time. If /Applications/AppName.app/Contents/_MASReceipt exists, the app was installed from the Mac App Store and updates through App Store > Updates.
How do I check whether an app uses Sparkle?
Read its Info.plist. Run defaults read /Applications/AppName.app/Contents/Info.plist SUFeedURL in Terminal — if a URL comes back, the app checks that Sparkle appcast for updates.
Can one app have more than one update source?
Yes. An app installed as a Homebrew cask may also ship a Sparkle updater, and some vendors distribute through both their site and the App Store. Pick one channel to own updates for each app — mixing them can leave version records out of sync.