How AppUnlink matches files to an application
Strong app identity and exact bundle paths can support a suggestion; shared or ambiguous evidence cannot.
Direct answer
AppUnlink starts with the selected app’s bundle identifier, signature, Team ID, entitlements, and embedded components. Exact bundle-identifier paths are stronger evidence than a matching name. Shared App Groups, duplicate identifiers, symlinks, and name-only matches are kept or blocked.
When this guide applies
- You want to understand why a preferences, cache, container, or support file is associated with a selected app.
- An app has extensions, helpers, App Groups, or duplicate identifiers that make a name-only uninstall unsafe.
- You need a reviewable removal plan that keeps shared, protected, uncertain, and unreadable items visible.
Step-by-step review
Start from the selected app bundle
Read the app’s bundle identifier, signing information, Team ID, entitlements, embedded components, and exact bundle path.
Enumerate known support locations
Inspect supported Library locations and app containers without following untrusted symlinks outside the intended scope.
Grade each relationship
Prefer exact bundle-identifier paths and matching signed identity. Keep name-only, duplicate, shared, or contradictory evidence separate.
Review shared consumers and coverage
Treat App Groups and other shared containers as shared by design, and expose any expected location that could not be read.
Save the plan before execution
Record the selected app identity, item decisions, evidence, coverage, and revision so the executed plan can be audited.
Technical context
Identity before naming
Bundle and signing identity reduce the risk of associating an unrelated file merely because its name looks similar.
Shared consumers stay visible
A file with known shared consumers is not exclusive to the selected app, so it remains on the Mac.
Coverage is part of the answer
AppUnlink shows which expected locations were readable so a clean-looking result is not confused with complete evidence.
Risks and actions to avoid
A matching name is weak evidence
Unrelated apps and files can share human-readable names. Name similarity alone must not support removal.
Shared containers are intentionally shared
Apple App Groups allow multiple apps from the same team to use one container, so another known consumer blocks exclusive ownership.
Unreadable does not mean absent
Permission gaps, protected locations, symlinks, and duplicate identifiers must remain visible instead of being silently omitted.
What the Omuuz product can—and cannot—do
What it can do
AppUnlink can combine bundle identity, code-signing evidence, exact paths, entitlements, embedded components, and coverage into a reviewable relationship grade.
What it cannot do
AppUnlink cannot prove ownership from a name alone, remove known shared containers, follow unsafe symlink escapes, or describe unreadable locations as clean.
Product evidence
