Rimuovere i file residui dopo la disinstallazione di app Mac

Punta due scanner di residui sulla stessa app disinstallata e otterrai due elenchi. Non è un bug. Ogni strumento sceglie la propria regola di appartenenza, la propria lista di esclusioni e il proprio limite sul lavoro da amministratore. Quelle tre scelte decidono tutto ciò che compare sullo schermo. Quando capisci l’attribuzione, la pulizia dei residui smette di essere «chi trova più spazzatura» e diventa «i cui errori costano meno».

Questa guida riguarda lo stato successivo: l’app è già sparita, o è appena finita nel Cestino, e vuoi rivedere i residui con la stessa cura che un disinstallatore avrebbe dovuto usare. Per la sequenza completa mentre l’app è ancora in esecuzione, vedi disinstallazione completa. Per le scelte di prodotto, vedi oltre AppCleaner.

Risposta breve: trascinare un’app nel Cestino rimuove solo il bundle; i suoi dati restano sotto ~/Library in Application Support, Caches, Preferences e Containers. Attribuisci i residui tramite l’identificatore del bundle, mai per dimensione o nome, e rivedi ogni candidato prima di eliminarlo, oppure usa un disinstallatore che applica esattamente questa regola.

Cosa significa davvero «disinstallare» su macOS

macOS non tratta un’applicazione come un solo oggetto con un solo pulsante di eliminazione. Ci sono almeno tre livelli:

Trascinare nel Cestino garantisce solo il primo livello. Il livello intermedio è dove gli strumenti generici aiutano. Il terzo è dove spesso fingono e falliscono: driver, estensioni di rete, helper privilegiati, daemon di licenza. Apple continua a consigliare di preferire l’app Uninstall del fornitore per questo motivo (Delete or uninstall apps).

Dove vivono davvero i residui utente

La maggior parte dei residui di terze parti si concentra sotto la Library della home:

I percorsi a livello di sistema sotto /Library (LaunchDaemons, PrivilegedHelperTools, ricevute sotto /private/var/db/receipts) sono un livello di rischio più alto. Preferisci il remover del fornitore; tratta gli scanner generici come solo-revisione lì.

Un’app sandbox spesso sembra ordinata: il container principale sotto ~/Library/Containers/<bundle id>. Può comunque usare App Groups, Application Scripts, cache condivise, CloudKit o elementi del Keychain. La sandbox restringe l’accesso diretto ai file; non garantisce un’impronta di una sola cartella. Un’app non sandbox può disperdersi tra Application Support, Caches, Preferences, Logs, Saved Application State, WebKit e Cookies. Una dispersione più ampia lascia più spazio a due strumenti per non essere d’accordo.

L’attribuzione è l’intera abilità

La scoperta sicura dei residui si basa sull’identità, non sui nomi di marketing.

Identificatore del bundle contro nome visualizzato

com.example.widget resta stabile tra rinomine e localizzazioni. I nomi visualizzati no. Due prodotti possono condividere una cartella aziendale (…/Application Support/Google) mentre solo uno è disinstallato. Associare «Google» come stringa è il modo in cui gli scanner inventano falsi positivi da multi-gigabyte.

L’abbinamento per identificatore è preciso e quasi mai propone i dati di un’app sorella. Non trova le cartelle che l’app ha nominato con il proprio nome.

L’abbinamento per nome trova quelle cartelle, e anche cose che condividono solo una parola. Trova di più ed è sbagliato più spesso.

Controlli pratici prima di qualsiasi eliminazione:

mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null

Se esiste ancora qualcosa con quell’id, tratta i percorsi di supporto condivisi come attivi.

Helper e identità incorporate

Le app moderne spediscono helper con id correlati: com.example.widget.helper, nomi dichiarati in SMPrivilegedExecutables, elementi di accesso sotto Contents/Library/LoginItems. Uno scanner accurato raccoglie quegli id dal bundle prima che l’app sparisca. Dopo che il bundle è sparito, hai solo ciò che è stato registrato o ciò che resta su disco con nomi esatti.

Group containers

~/Library/Group Containers/ contiene dati di suite condivisi di proposito:

• group.<bundle id>
• nomi con ambito team come <TeamID>.<bundle id>
• spazi group.* condivisi usati da più app

Solo i percorsi con ownership esatta del proprietario sono candidati all’associazione automatica. Gli alberi di gruppo condivisi devono restare solo-revisione o intatti se resta una sorella. È la categoria in cui gli strumenti che «trovano di più» causano danni reali.

Varianti di nome e build di canale

Foo Beta può lasciare Foo Beta, FooBeta e a volte una cartella stabile Foo che appartiene al canale release ancora installato. I nomi base senza canale sono ad alto rischio di falsi positivi: tienili solo-revisione finché non dimostri che l’app stabile non c’è più.

Tre punti di ingresso sicuri

1. Prima i disinstallatori del fornitore

Agenti di sicurezza, client VPN, driver audio e strumenti endpoint conoscono le proprie ricevute e l’ordine di smontaggio delle estensioni. Eseguili prima di qualsiasi passeggiata in Library. L’eliminazione di file non è un flusso affidabile di disattivazione per le estensioni di sistema o di rete; macOS le registra.

2. Revisione dopo che l’app è già sparita

Quando il .app non c’è più, cerca percorsi ancora etichettati con quell’id del bundle o con varianti esatte del nome. Predefinite conservative:

• Spesso OK se di proprietà: cache, log, stato salvato, report di crash
• Rivedi con cura: Application Support, Containers, Preferences (licenze, mail offline, database di progetto)
• Di solito lascia stare: Group Containers senza ownership esatta, Documents fuori dalla Library, qualsiasi cosa di cui un altro id abbia ancora bisogno

Misura i candidati:

du -sh ~/Library/Application\ Support/<Name> \
  ~/Library/Caches/<bundle.id> \
  ~/Library/Containers/<bundle.id> 2>/dev/null

Gli errori di permesso di solito significano che Terminal non ha Full Disk Access, non che la cartella sia vuota.

3. Il momento in cui l’app finisce nel Cestino

Molte persone cestinano prima e pensano dopo. Un watcher che nota un nuovo .app in ~/.Trash, legge l’identità dal suo Info.plist, scansiona i file di supporto correlati e apre un pannello di revisione intercetta i residui senza una caccia al tesoro. Vincoli di progettazione che separano l’utile dal dannoso:

• Non eliminare mai automaticamente il bundle dell’app cestinata (Metti via deve funzionare)
• Non comparire per classi protette / AV / MDM
• Consumare una soppressione one-shot quando il cleaner stesso ha cestinato l’app durante la disinstallazione, o il pannello gareggia con il flusso di disinstallazione
• Condizionare a Full Disk Access; fallire in silenzio senza di esso piuttosto che chiedere dallo sfondo

Mole porta analisi del disco, manutenzione delle app e pulizia con revisione prioritaria in un’app Mac nativa. macOS e le app proprietarie gestiscono ancora i dati di sistema.

Gli orfani non sono «qualsiasi cosa grande in Library»

Scoprire residui di app che hai dimenticato richiede la sottrazione delle rivendicazioni: enumerare le cartelle di supporto candidate, poi sottrarre tutto ciò che è ancora rivendicato dal software installato (id del bundle, app in esecuzione, registrazione Launch Services, root del fornitore). Se la scansione delle rivendicazioni è parziale (timeout, directory illeggibili), il risultato sicuro è zero orfani, non un elenco a indovinare. Gli strumenti che trovano sempre dozzine di app «spazzatura» su un Mac pulito ottimizzano per un numero di vendita.

Contano anche i gate di quiet-period: una config riscritta la settimana scorsa può appartenere a uno strumento CLI che la passeggiata delle rivendicazioni non vede. Gli mtime recenti dovrebbero sopprimere i candidati.

Esempio pratico: due strumenti, una suite del fornitore

Disinstalli Product A di un’azienda che spedisce anche Product B, ancora installato.

• Strumento 1 (pesante sugli identificatori): elenco piccolo, soprattutto percorsi com.vendor.productA.*.
• Strumento 2 (pesante sui nomi): aggiunge ~/Library/Application Support/Vendor (4 GB) e un group container usato da entrambi i prodotti.

Lo strumento 2 sembra più accurato. Sta proponendo l’eliminazione che può rompere Product B. Il totale in fondo allo schermo non è un punteggio di qualità. Lo sono le categorie sopra di esso.

La ricevuta orfana di Homebrew

Se l’app veniva da Homebrew Cask, rimuovere solo il .app può lasciare un record Caskroom che blocca la reinstallazione. Dopo i residui di file:

brew list --cask

Se il token resta, brew uninstall --cask <token> cancella l’associazione (accetta --zap solo se vuoi la pulizia più ampia di brew). «Cask is not installed» dopo che l’app è già sparita è un’associazione obsoleta, non un motivo per fare rm -rf su percorsi Caskroom a caso.

Cosa rifiutare anche quando il nome corrisponde

• Sorelle ancora installate e gemelli di canale
• Group container condivisi e cartelle padre del fornitore
• Ricevute e helper privilegiati senza un remover validato
• Documenti utente fuori dalla Library
• Store di chat AI e directory di modelli che stanno vicino a percorsi di cache (pulizia AI)

Errori comuni

Massimizzare l’elenco di trovati. Più candidati spesso significa attribuzione peggiore.

Eliminare i Group Containers per impostazione predefinita. Condivisi di proposito.

Saltare il disinstallatore del fornitore per VPN, AV, audio, virtualizzazione.

Misurare senza Full Disk Access, poi concludere «non è rimasto nulla.»

Svuotare subito il Cestino dopo un’eliminazione massiva di residui. Tieni un giorno di uso normale se qualcosa di importante potrebbe essere stato attribuito male.

Verifica

1. Rimisura i percorsi rimossi.
2. Conferma che non resti login item o launch agent per quell’id (elementi di avvio).
3. Avvia le app sorelle dello stesso fornitore.
4. Svuota il Cestino solo dopo aver accettato le rimozioni.

Ordine delle operazioni

1. Cerca un disinstallatore del fornitore se l’app aveva driver, estensioni o helper.
2. Esporta o deautorizza mentre l’app è ancora in esecuzione, se conta.
3. Chiudi l’app e gli helper visibili.
4. Rimuovi il bundle (o conferma che è già nel Cestino).
5. Rivedi i residui per identità; lascia stare i container condivisi.
6. Gestisci le ricevute Homebrew cask se applicabile.
7. Tieni gli elementi nel Cestino mentre usi il Mac normalmente, poi svuota.

Letture ulteriori

• Apple: Delete or uninstall apps on Mac
• Correlati: disinstallazione completa, alternative ad AppCleaner, cosa i cleaner non dovrebbero mai eliminare

La pulizia dei residui è manutenzione dell’identità. L’abilità non è massimizzare i gigabyte; è provare la proprietà, proteggere lo stato condiviso e mantenere le eliminazioni recuperabili.

Domande frequenti

È sicuro eliminare da soli i file residui sotto ~/Library?

Solo con attribuzione: abbina la cartella all’identificatore del bundle dell’app, non alla sua dimensione o a un nome simile, e rivedi ogni elemento prima che vada. Un’ipotesi sbagliata può cancellare i dati di un’altra app o i tuoi documenti.

Perché le app lasciano file dietro?

macOS non ha un contratto di disinstallazione: trascinare il bundle nel Cestino è l’intero meccanismo, e tutto ciò che l’app ha scritto a runtime resta dove è stato scritto.

Una reinstallazione ricrea ciò che ho eliminato?

Lo stato ricostruibile, sì: cache, ricevute e preferenze predefinite tornano al primo avvio. Documenti, cronologia delle chat e licenze no, ed è per questo che uno strumento attento preseleziona solo ciò che una reinstallazione ricreerebbe.