Ice: how to uninstall it cleanly

Dragging Ice to the Trash removes the app. It does not undo everything the app did, and one of its settings is written outside the app entirely, into a preference that affects the whole Mac. Removing the app while that setting is active leaves the effect in place with nothing left to switch it off from.

This is the order that avoids that situation: reset one setting, take note of one thing, remove the app, then clean up four files and two lists. The file paths below come from the published Homebrew package definition, checked on 10 September 2026.

Reset the icon spacing before removing anything

The app offers a setting that tightens the gap between menu bar icons so more of them fit in the same width. Unlike everything else in its settings window, this one does not configure the app. It writes a system wide preference that macOS applies to every status item.

Delete the app with that value changed, and the changed spacing stays. The menu bar keeps looking unusually tight or unusually loose, with no obvious cause and no settings window left to look in.

The clean fix is to open the settings while the app is still installed, return the spacing to its default, and confirm the menu bar looks normal before going any further. Applying the change may cause status bar apps to quit and relaunch, so save open documents first. There is a way to fix it afterwards, described further down, but doing it in this order takes one click instead of a terminal command and a logout.

Note what the always-hidden section contains

If the always-hidden section was in use, look at it once before removing anything. When the app goes, every icon it was hiding returns to the menu bar at the same moment, and the result can be a row of icons that have not been seen in months.

They will not necessarily come back in a familiar order either. A screenshot of the layout pane is enough. It takes ten seconds, it explains the sudden crowd of icons afterwards, and if the plan is to move to a different tool, that screenshot becomes the setup instructions for the new one.

Removing it with Homebrew

If it was installed through Homebrew, remove it the same way. The package manager knows about the login item and the running process, and handles both.

brew uninstall --cask jordanbaird-ice

That removes the app, quits the running process and unregisters the login item. To remove the support files at the same time, add the zap flag.

brew uninstall --zap --cask jordanbaird-ice

The distinction matters if a reinstall is likely. Without the zap flag, the configuration stays on disk and a reinstalled copy picks up exactly where the old one left off. With it, the next install starts from defaults.

Removing it by hand

For a copy installed from the downloaded archive, the order is:

1. Quit the app, from its own menu bar icon or by right clicking an empty area of the menu bar
2. Move Ice.app from the Applications folder to the Trash
3. Empty the Trash

Quitting first is not optional in practice. macOS refuses to move an app that is currently running, and a copy that is still resident in memory keeps hiding icons after its file has gone, which looks like a failed uninstall.

The four files left behind

The Homebrew package definition names exactly what a full cleanup removes:

zap trash: ~/Library/Caches/com.jordanbaird.Ice, ~/Library/HTTPStorages/com.jordanbaird.Ice, ~/Library/Preferences/com.jordanbaird.Ice.plist, ~/Library/WebKit/com.jordanbaird.Ice

Path	Contents	Worth deleting
~/Library/Preferences/com.jordanbaird.Ice.plist	Section assignments, reveal and rehide settings, shortcut bindings, everything configurable	Yes, unless a reinstall should keep the layout
~/Library/Caches/com.jordanbaird.Ice	Temporary working data	Yes, no reason to keep it
~/Library/HTTPStorages/com.jordanbaird.Ice	Storage associated with network activity such as update checks	Yes
~/Library/WebKit/com.jordanbaird.Ice	Data from rendering parts of the interface	Yes

All four sit inside the user's own library folder, none of them affects the operating system, and their combined size is negligible. Leaving them in place harms nothing. The only one with a practical consequence is the first: keep it, and a future reinstall silently restores the previous configuration, which is unhelpful when reinstalling to escape a misconfiguration.

To reach them in Finder, use Go to Folder and paste the path rather than navigating there, since the library folder is hidden by default.

Anyone who wants to keep the configuration for later should copy that plist somewhere else before deleting. Do it with the app closed. macOS holds preference contents in memory and writes them out on its own schedule, so a copy taken while the app is running can miss recent changes.

Login items and permission lists

Two things remain that are not files in any obvious sense, and both are visible in System Settings.

The first is the login item. If launch at login was enabled, an entry can survive in System Settings under General, in the Login Items list. Removing through Homebrew unregisters it. Removing by hand often does not, leaving an entry that points at nothing. Select it and remove it with the minus button.

The second is the permission grants. Under Privacy and Security, both the Accessibility list and the Screen Recording list can still show the app after deletion. These are inert once the app is gone, but they accumulate, and a long list of removed apps makes the real entries harder to audit. Select and remove them the same way.

There is one case where clearing these matters beyond tidiness. Reinstalling to fix strange behaviour is much less useful if the old permission grants and the old preference file are still in place, because the new copy inherits the same state. A genuine clean reinstall means removing the app, the plist, and both permission entries first.

The setting that survives deletion

This is the part most people miss. The icon spacing preference described at the top is stored against the global domain rather than the app, so deleting the app leaves it exactly as it was. The symptom appears later: menu bar icons sitting closer together or further apart than on any other Mac, with no app installed to explain it.

Clearing it takes two commands:

defaults -currentHost delete -globalDomain NSStatusItemSpacing
defaults -currentHost delete -globalDomain NSStatusItemSelectionPadding

Nothing changes on screen immediately. The menu bar has to be rebuilt for the default to take effect, which means logging out and back in, or restarting. Absence of these keys is the default state, so deleting them is the correct fix rather than writing a specific number back.

These keys govern status item spacing only. Removing them does not affect any other application's behaviour.

Note also that this preference is stored per user account. On a shared Mac, it was only ever affecting the account that changed it, and the other accounts on the machine were never touched.

Shared Macs need the cleanup repeated per account

On a machine used by more than one person, the removal splits in an awkward way. The application itself lives in the shared Applications folder, so deleting it removes it for everybody at once. The traces do not work like that.

The preference file, the permission grants and the login item registration are all stored per user account. Deleting the app from an administrator account leaves the other accounts with a preference file for software that no longer exists, plus entries in their Accessibility and Screen Recording lists pointing at a missing application.

None of that causes a functional problem. The consequence is a privacy pane that lists apps nobody can find, which makes it harder to audit what genuinely has access. Cleaning it properly means logging into each account and checking the two System Settings lists and the library folder there. On a family Mac that is usually not worth the trouble. On a work machine subject to any kind of access review, it usually is.

The spacing preference behaves differently again, since it is stored per user rather than per machine. Only the account that changed it ever saw the effect, so only that account needs the terminal commands above.

A short check to confirm it is really gone

Four things confirm a complete removal, and each takes seconds.

The Applications folder should have no Ice.app. Activity Monitor should show no matching process, which is the check that catches a copy quit improperly. System Settings, under Privacy and Security, should show no entry in either the Accessibility or the Screen Recording list. And the menu bar itself should look normal, with icons spaced the way they are on any other Mac.

If the fourth check fails while the first three pass, the cause is the global spacing preference rather than anything left over from the app, and the two commands above resolve it after a logout.

Running through these in order also separates two situations that otherwise look identical: an incomplete uninstall, and a menu bar that was always crowded and is now simply visible again. The second is not a leftover. It is the original problem, returning.

Icon order stays where it was, and other things that look broken

Two more behaviours are worth recognising so they do not get mistaken for damage.

Menu bar item order does not revert. The app rearranges items by synthesising the same Command drag a person would perform, which means macOS itself is what remembers the resulting positions. Deleting the app removes nothing from that memory. Rearranging by hand, holding Command and dragging, puts things back in any preferred order.

An app that appears to still be working usually is. Deleting the file does not terminate the process, so a copy quit improperly keeps hiding icons until the process ends. Activity Monitor will show it, and logging out ends it for certain.

Preferences that seem to survive deletion have the same explanation in reverse. macOS caches preference contents, so a plist deleted while the system still holds its contents can be written back. Following the sequence of quit, delete app, delete plist, log out avoids the whole class of problem.

What to change first

Once the app is gone, every icon it was hiding is back at once, and on a MacBook with a notch some of them will now sit behind it, drawn nowhere and reachable by nothing. That is the moment to decide whether the goal was to stop using this particular tool or to stop hiding icons at all.

If it was the former, compare how the alternatives handle reaching a hidden icon rather than how they hide it, since that is where the daily difference lives. The interaction models are set side by side on how it compares, and a build of Koffret can be tested on the same menu bar once the spacing preference above has been cleared.