Ice not working on Mac: what to check

Menu bar tools fail in ways that look identical from the outside. Nothing happens after install. An icon that should be hidden stays put. The layout editor opens empty. Those three symptoms have different causes, and guessing between them wastes an afternoon. Working through a fixed order instead finds the cause in a few minutes, because each step rules out an entire category. The order is: OS version, permissions, whether the app is running, then symptom specific checks.

Start with the OS version

This is the cheapest check and it eliminates the most confusing class of failure. The app requires macOS 14 or later, and the reason is documented:

Ice uses a number of system APIs that are available starting in macOS 14. As such, there are no plans to support earlier versions of macOS. Source: github.com

On macOS 13 or earlier the app either refuses to launch or behaves unpredictably, and no amount of settings adjustment changes that. The Apple menu and About This Mac settle it in two clicks.

While there, check where the application bundle actually lives. Distribution is either a direct download from the GitHub releases page or a Homebrew cask. A copy left in the Downloads folder after unzipping tends to cause trouble later, because macOS treats permissions and updates as tied to a specific application at a specific location. Move it to the Applications folder before troubleshooting anything else, and if it was already granted permissions from a different location, expect to grant them again.

Two permissions, two different jobs

Confusing these two is the single most common reason troubleshooting stalls, because the app uses them for entirely separate purposes.

Accessibility is what allows the app to manipulate menu bar items at all. The permission prompt says as much: it needs permission to manage the menu bar. Without it, nothing hides.

Screen recording has a narrower role. Two features depend on it: the separate bar that displays hidden icons below the menu bar, and the drag and drop layout editor. The app states plainly that it can run in a limited mode without this permission, which is why hiding can work perfectly while those two features stay broken.

Symptom	Permission to check
Nothing hides at all	Accessibility
The separate bar for hidden icons never appears	Screen recording
The layout editor shows nothing	Screen recording
Hotkeys do nothing	Accessibility

Both live in System Settings under Privacy and Security. A switch that is already on does not prove the permission is working. macOS ties a granted permission to a specific application, so replacing the app with a newer build, or moving it, can leave a switch that looks enabled while the running copy has no access. The fix is to remove the entry from the list, relaunch, and grant it again when prompted.

Confirm it is actually running

The app deliberately has no Dock icon. Its bundle marks it as a background agent, so launching it opens no window and adds nothing to the Dock. That makes "nothing happened" an ambiguous observation.

Two places give a definite answer. The menu bar itself is one: if the divider marking the boundary between sections is visible, the app is alive. Activity Monitor is the other, and it is the one to trust when the menu bar is too crowded to read. If the process is absent, launch it from the Applications folder. If the process is present and nothing responds, the problem is in the permissions section above.

Launch at login is separated by the same check. If everything works until a restart and then the app is gone, look at both the app's own launch at login setting and the Login Items list in System Settings under General. It is possible for one to be set and the other not.

This is also the moment to look for a second tool. Anything in this category works by moving items, adjusting their spacing and toggling visibility, so two of them acting on the same strip produce icons that reappear after hiding or snap back after being dragged. Quitting one is not always enough, since settings persist. Anything definitively unused should be removed from the Applications folder rather than left parked.

Automatic rehiding waits on purpose

A frequent report is that automatic rehiding does nothing. Often it is working exactly as designed, because the behaviour has conditions attached to it that are visible in the app's own log messages.

Recent user input postpones rehiding. So does an open menu bar item interface. And when an item cannot be hidden, the app records that specific item as failed rather than aborting the whole operation.

Practically: while the pointer is still moving, or while any menu is open, waiting is the correct behaviour. Stop touching the machine for a few seconds and watch whether the icons collapse on their own. That single test separates a real fault from a misread.

If one specific item consistently stays visible while the rest hide, the cause lies with that item, not with the timing. The reveal delay on hover is adjustable too, so a setup that feels unresponsive on reveal is often a delay value rather than a fault.

When an icon refuses to move

In the layout editor, an icon that cannot be dragged usually points at the app that owns it. The message the app shows in this case is specific: an unresponsive application's item cannot be moved until that application is restarted, and the movement of other items may be affected while that lasts. Quitting and relaunching the owning app is the first thing to try, and it resolves most instances.

The spacing setting deserves separate care. Adjusting the gap between icons writes a system level value, and applying it relaunches every app that has a menu bar icon. The app warns that some apps may need to be restarted manually, and it lists the ones that failed to quit. After applying spacing, read that list and start the missing apps by hand. Since the relaunch sweeps up whatever is running, this is a setting to change when nothing important is open.

Notched MacBooks add a category that looks like a fault but is not. The camera housing occupies the centre of the menu bar, so once enough icons accumulate, the ones filling from the right disappear behind it while application menus fill from the left. Nothing is hidden. There is simply no room. Settings include an option to inset the shape on notched screens, and behaviour differs between the built in display and an external monitor, so reproduce the problem on both before drawing a conclusion.

Sorting the kinds of "will not hide"

Four different situations produce the same complaint, and telling them apart decides whether the issue is fixable at all.

The first is placement. These tools work by putting a divider in the menu bar and treating each side differently, so an item positioned outside the hidden section stays visible by definition. The layout editor shows where each item sits.

The second is system items. The clock, Control Center and similar built in items behave differently from icons created by third party apps. Holding Command and dragging identifies them, and switching them off in the Control Center pane of System Settings is more reliable than trying to hide them.

The third is apps that rebuild their menu bar item. If an app destroys and recreates its item whenever its state changes, the recreated item arrives as something new and appears again. This is a property of the other app, and swapping menu bar managers does not necessarily change the outcome. When only one or two apps behave this way, leaving them permanently visible costs less than fighting them.

The fourth is a stale position preference. macOS remembers a preferred position per item, and an outdated value can produce an order that does not match what was configured. Re-setting the position in the layout editor and restarting to see whether it holds is the test.

Hotkeys that stop responding

Keyboard shortcuts fail in their own way, and the cause is rarely the app that was configured. Three checks cover almost all of it.

The first is the accessibility permission again, because sending and intercepting key events falls under it. A shortcut that used to work and stopped after an app update is the classic sign of a permission tied to a replaced binary.

The second is a conflict. macOS assigns a large number of system shortcuts of its own, and other background apps register global hotkeys without announcing it. When a combination is claimed twice, the result is usually silence rather than an error. The fastest test is to reassign the action to a deliberately odd combination and see whether it fires. If it does, the original combination was taken, and the work is finding out by whom rather than fixing anything in the menu bar tool.

The third is focus. Some full screen applications and remote desktop sessions capture keystrokes before anything else sees them, so a shortcut that works on the desktop can appear dead inside them. Testing from the Finder rather than from inside the app where the problem was noticed keeps this from being misattributed.

Worth knowing: separate hotkeys exist for toggling individual sections, opening the search panel, enabling the separate bar, and showing or hiding the divider icons. A shortcut that appears to do nothing is sometimes bound to a feature that is itself disabled, in which case the fix is in that feature's settings rather than in the hotkey.

Updates and settings

Automatic updates come from a feed the developer hosts on GitHub Pages, and there are two separate settings involved: whether to check automatically, and whether to download automatically. Both are worth reading before concluding that updates are broken.

The published release record is the other half of that check. As of 10 September 2026, the newest published build is a development release dated 16 September 2025, and the newest release excluding development builds is from 29 October 2024. A copy matching those is current, not stale.

For settings that appear to have reset themselves, the preference file is at ~/Library/Preferences/com.jordanbaird.Ice.plist. Moving it aside and relaunching produces a clean configuration, which is a reasonable last resort. Note the section layout and hotkey assignments first, since rebuilding them from memory takes longer than writing them down.

What to check first

Run the order rather than the symptom: OS version, accessibility, screen recording, whether the process is running, login items, then the specific behaviour. Most reports resolve at step two or three, and starting from the symptom instead usually means hours spent in a settings window on a problem that was a missing permission. If the diagnosis ends at an app that rebuilds its own icon, no tool will fully solve it, and the reasonable move is to leave that one visible.

Once things work again, the question worth asking is how many actions it takes to use a hidden icon, because a tool that requires expanding and recollapsing the bar each time gives back the attention it saved: Features covers what that involves and How it compares maps the differences between tools. Koffret is one of them.