03 — OS Constraints: Ground Truth Before Designing Modules

Scope: [P0-03]. Every module proposed in P2/P3 must trace to a row in the table below marked CAN. Rows marked CANNOT are hard blocks — no module may promise them. Rows marked CAN-BUT-SHOULDN’T may ship only with the guardrail listed, and must be priced into the honesty contract (P0-06).

Verified against: macOS 27.0 (build 26A5388g), Xcode 26.4, Swift 6.3, arm64, on the actual dev machine (csrutil status, diskutil apfs list, tmutil listlocalsnapshots /, mount all run read-only during this research — see command output cited inline). Note: this dev Mac reports SIP as “Custom Configuration” with Filesystem Protections: disabled — that is a non-default developer setting (Xcode/dev tooling commonly relaxes this flag) and must not be treated as representative of a customer’s Mac. All product decisions below assume SIP is fully enabled, which is the default and the only state we can rely on for a shipped product.

CAN / CANNOT / CAN-BUT-SHOULDN’T table

Evidence notes per item

SIP-protected paths. SIP (“rootless”) is enforced kernel-side and applies even to root. The authoritative live list on any machine is /System/Library/Sandbox/rootless.conf; the stable top-level set is /System, /bin, /sbin, /usr (excluding /usr/local), plus most pre-installed apps in /Applications. /Applications, /Library, and /usr/local remain writable for third-party software. Confirmed on this machine: csrutil status reports SIP active with a custom (dev-relaxed) filesystem-protection flag — explicitly not the state we can assume for a customer.

TCC / Full Disk Access. TCC is a pair of SQLite databases (~/Library/Application Support/com.apple.TCC/TCC.db and the system-level one) recording per-app consent for sensitive categories. FDA (kTCCServiceSystemPolicyAllFiles) is the broadest grant: once on, the app can read/write essentially anywhere a normal user process can, including other apps’ data and Time Machine backups. There is no programmatic way to trigger the FDA grant flow — the app can only detect it’s missing and deep-link the user to System Settings → Privacy & Security → Full Disk Access, where they must manually add the app and flip the toggle (admin auth may be requested by the OS, not by us).

Containers and Group Containers. ~/Library/Containers/<bundle-id> (sandboxed apps) and ~/Library/Group Containers/<group-id> (shared between apps of one team) are ordinary directories gated by the same FDA rule as everything else once we’re not the owning app. With FDA granted, we can enumerate and delete inside them, but the internal layout is undocumented — Apple ships no manifest of what’s cache vs. live state inside a given container, so per-app knowledge (e.g. “Xcode DerivedData is safe, ~/Library/Containers/com.apple.mail/Data/Library/Mail Downloads is safe”) must be hand-curated per target, never inferred generically.

App Sandbox vs. FDA (App Store implication). com.apple.security.app-sandbox denies all file access outside an allowlist and the app’s own container unless extended by specific entitlements. FDA is designed for non-sandboxed apps. Apple’s own developer relations engineers have told rejected submitters that a temporary-exception entitlement broad enough to approximate FDA “is tantamount to shipping a non-sandboxed app” and won’t be approved. Confirmed: this forces direct, notarized distribution outside the Mac App Store — there is no sandboxed path to this product.

APFS purgeable space. Purgeable space is macOS’s own reclaimable-cache accounting (local snapshots, some caches), managed by the CacheDelete subsystem, not by APFS directly. Disk Utility and Finder can and do disagree because Finder maintains its own periodically-updated figure rather than querying CacheDelete live. No public API lets a third-party process force purgeable space down; the OS purges it under its own disk-pressure logic. PureMac’s own README states this outright and treats it as display-only. Recommendation: display it, clearly labeled as an OS-managed, non-actionable figure (“macOS manages this automatically — no app, including this one, can force it to free up”); never let it be part of a “GB you can reclaim” number, and never ship a “free purgeable space” button.

APFS snapshots / Time Machine local snapshots. Distinct from purgeable space, and legitimately actionable: tmutil thinlocalsnapshots <mount> <purge_bytes> <urgency 1-4> asks the system to thin up to N bytes from local snapshots; tmutil deletelocalsnapshots <date> removes a specific one outright. Verified 24 hourly local snapshots currently present on this dev machine (com.apple.TimeMachine.2026-08-07-120251.local … …-2026-08-08-111403.local), confirming this is live, real, present-day behavior, not legacy. Hazard: reclamation is asynchronous (macOS recalculates purgeable/free space in the background after the call returns, sometimes with a multi-minute lag), so any UI must not promise an instant before/after number. Also: local snapshots are not the Time Machine backup itself — deleting them is safe for disk space and does not touch the external backup history; tmutil delete (no “local”) against a backup destination is a different, much higher-stakes operation we must never expose in the same flow.

Firmlinks and the read-only system volume. Since Catalina, the boot disk is really two APFS volumes (System, read-only/sealed; Data, writable) merged into one apparent volume via firmlinks — bidirectional, folder-level “wormholes” Apple has never fully documented. Confirmed on this machine: / mounts disk3s1s1 as read-only, and disk3s5 (the “Data” role volume) mounts at /System/Volumes/Data with nobrowse. Practical consequence: there is no reclaimable user data on the System volume at all — every real deletion target (caches, logs, app data, Containers) lives on the Data volume and is reached through the ordinary ~/... / /Library/... paths, which the firmlinks make transparent. We never need to and never should address /System/Volumes/* paths directly.

Localization/language file removal. Mechanically possible (just files), but deleting them from an already-signed .app breaks the code signature’s sealed-resource manifest — codesign --verify fails, and Apple’s own Gatekeeper documentation demonstrates this exact “file removed → sealed resource missing” failure mode. In practice Gatekeeper mostly re-checks at first launch/quarantine rather than every run, so breakage may not be instantly visible, but it reliably breaks delta/incremental updaters (Sparkle, App Store patches) that diff against the original file manifest, and any macOS-triggered re-validation will flag the app as damaged. Given modern SSD sizes, the bytes recovered are small relative to the support/trust risk. Not viable as a headline feature in 2026 — see consequences below.

“Repair permissions.” Removed from Disk Utility with El Capitan (2015) because SIP already prevents system-file permission drift and the installer/updater pipeline repairs permissions automatically. Nothing in current macOS exposes an equivalent capability to third parties. Shipping this as a “feature” would be pure placebo.

Free RAM / memory purge. macOS has used compressed memory (not raw free RAM) as its primary memory-pressure relief valve since Mavericks. Activity Monitor’s own health signal is “Memory Pressure” (green/yellow/red), not the “Free” number. Forcing a purge (e.g. via the purge command) only makes the OS immediately re-fill and re-compress, burning CPU for no durable gain, and can be actively counterproductive right after being run.

SMAppService privileged helper. The modern (macOS 13+) way to register a helper daemon/agent without the old SMJobBless/blessed-helper installer script dance. It runs privileged operations over XPC as root, but “root” here still means “subject to SIP and to whatever TCC has or hasn’t granted the calling app” — it is not a bypass mechanism. Its only functional benefit for us is reaching things a normal user process can’t (e.g. another local user’s files with proper authorization, or system log rotation), not reaching SIP-protected paths. It also cannot self-approve: the user must go to System Settings → Login Items & Extensions once per registration.

Notarization. A Gatekeeper-facing malware scan at submission time, not an ongoing behavioral certification, but Apple can and does revoke the ticket after the fact if an app is later found behaving maliciously or deceptively (this is the actual enforcement lever against scareware-pattern cleaners) — so honesty-contract compliance (P0-05/P0-06) is a continuous obligation, not a one-time submission checkbox.

Consequences for product design

1. Direct, notarized distribution is mandatory, not a preference. Sandboxing forbids FDA outright; there is no sandboxed path to this product’s core function. (Confirms P0-07’s premise.)
2. Hard-exclude SIP paths from every scan root. Treat /System, /bin, /sbin, /usr (minus /usr/local), and pre-installed /Applications bundles as permanently out of scope — not filtered at delete-time, filtered at discovery-time so they never even appear as a candidate.
3. Never target /System/Volumes/* directly. All real targets are reachable through ordinary ~/Library, /Library, /private/var (Data-volume) paths via firmlinks; there is nothing reclaimable on the read-only System volume.
4. FDA has no programmatic grant flow. Onboarding must include an explicit, honest screen that deep-links to System Settings → Privacy & Security → Full Disk Access and explains why before the app can do anything meaningful — this is a first-run UX requirement, not an edge case.
5. APFS purgeable space: display-only, never actionable, never counted. No “reclaim purgeable space” button, ever. Label it explicitly as OS-managed and non-reclaimable by any third-party app, ours included. Any violation is a release blocker per the honesty contract (P0-06).
6. Local Time Machine snapshot thinning is a legitimate, real module — build it on tmutil thinlocalsnapshots/deletelocalsnapshots, but the UI must not promise an instant post-delete byte count (reclamation is async), and it must be visually and functionally distinct from any backup-destination deletion flow (never expose tmutil delete on a backup destination in the same surface).
7. Localization-file removal defaults to OFF, or ships as an explicit opt-in with a “may break this app’s future auto-updates” warning, and never contributes to headline “space saved” numbers. Given the small real yield vs. code-signature/updater breakage risk, the default recommendation is to not ship this in v1.
8. Never ship “repair permissions” in any form — it is a no-op since 10.11 and would be a knowingly fake feature; classify FALSE in the P0-06 honesty audit.
9. Never ship “free RAM”/memory purge as a performance claim — classify FALSE in the P0-06 honesty audit; if a Maintenance module exposes it at all (cosmetic bucket), it must carry an honest one-liner (“temporarily forces macOS to recompress memory; no lasting effect”) and must not contribute to any headline number.
10. The privileged helper (SMAppService) is not a backdoor around SIP/TCC — design every privileged-helper operation as “root-required but otherwise already-legal,” never as a way to reach FDA- or SIP-gated data the main app wasn’t already entitled to. Approval for the helper is a second manual System Settings trip (Login Items & Extensions) — budget for it in onboarding.
11. Cross-app container access (once FDA is granted) is scoped to hand-curated, documented cache subpaths only — e.g. specific known subpaths inside ~/Library/Containers/<id> or ~/Library/Developer — never a whole-container or whole-Group-Container delete, since internal layout is undocumented and may include live, unsynced state.
12. Treat notarization as a continuous compliance obligation, not a one-time gate. Any scareware-style pattern (inflated numbers, fake urgency, silent deletion) is both a trust-stack violation (P0-05) and a live risk of retroactive notarization revocation.