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. Conta capire a quale app appartengono i file: un elenco più lungo non aiuta se include dati ancora necessari ad altre app.

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.

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 (guida Apple alla disinstallazione).

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.

Capire a quale app appartiene un file

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 restringe la ricerca, ma i dati condivisi vanno comunque verificati. Può non trovare le cartelle che riportano soltanto il nome dell'app.

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 attribuiti con certezza all'app possono essere associati automaticamente. Le cartelle di gruppo condivise devono restare da verificare o intatte se un'altra app le usa ancora. È 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

La scansione residui di Mole sottrae prima i percorsi ancora rivendicati da app installate, bundle ID o ricevute e lascia deselezionati i candidati ambigui. Mostra identità e dimensione e manda le rimozioni recuperabili nel Cestino; essere grande in Library non basta mai.

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.

Conta anche la data di modifica: una configurazione riscritta la settimana scorsa può appartenere a uno strumento da riga di comando che lo scanner non riconosce. I file modificati di recente vanno conservati se non è chiaro a cosa servano.

Esempio pratico: due strumenti, una suite del fornitore

Disinstalli il Prodotto A di un'azienda che distribuisce anche il Prodotto B, ancora installato.

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

Lo strumento 2 sembra più accurato, ma propone una cancellazione che può compromettere il Prodotto 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 indica che il cask non è registrato nell’installazione Homebrew interrogata, 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.

Il primo giorno dopo una disinstallazione

Molti svuotano il Cestino nell’istante in cui l’app sparisce. Un ritmo più lento non costa nulla e lascia una via di ritorno:

1. Il primo giorno metti nel Cestino il bundle dell’app e solo le cache che hai verificato essere rigenerabili.
2. Lascia stare Application Support e Containers, e usa il Mac normalmente per un giorno.
3. Se le altre app dello stesso fornitore si avviano normalmente, verifica i dati personali e i backup prima di eliminare il secondo gruppo di file.
4. Per i percorsi su cui hai ancora dubbi, annota la dimensione con du -sh e decidi una settimana dopo.

Il Cestino sta sullo stesso volume, quindi non si libera niente finché non lo svuoti. Quello che guadagni aspettando è una finestra di recupero. Se il disco è davvero pieno, svuota prima le cache rigenerabili per avere respiro e tieni da parte i percorsi contesi.

Permessi e visibilità

Senza Full Disk Access, Terminal e la maggior parte degli scanner non vedono dentro Containers né in parte della Library. du stampa errori di permesso e arriva comunque a un totale, e a quel totale manca tutto ciò che non ha potuto aprire. Non si legge «non è rimasto niente», si legge «non hai il diritto di guardare».

• Dai Full Disk Access a Terminal, o allo strumento che esegue la scansione, poi rimisura.
• Confronta i numeri prima e dopo. Decidere dal passaggio mezzo cieco è il modo in cui un container da diversi gigabyte finisce dichiarato vuoto.
• Togli Full Disk Access agli strumenti che non usi più. È il permesso di lettura più ampio del Mac, e una volta concesso sopravvive al motivo per cui l’hai concesso.

Come si dividono i compiti con la disinstallazione completa

Disinstallazione completa è l’ordine da seguire mentre l’app è ancora installata: prima il disinstallatore del fornitore, export o deautorizzazione, chiusura, rimozione del bundle, poi revisione di ciò che resta. Questa guida dà per scontato che il bundle sia già sparito, il che toglie le prove facili, e spende la sua lunghezza sulla metà che rimane: decidere quali file appartenevano all’app e quali erano soltanto condivisi.

Letture ulteriori

• Apple: Eliminare o disinstallare app sul 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?

L'installazione o l'app può ricreare cache e impostazioni predefinite. Questo non ripristina documenti personali, conversazioni o il precedente stato di attivazione. Reinstallare non sostituisce un backup.