Ice on Mac: how to set it up

Installing Ice takes about thirty seconds. Configuring it takes longer, not because anything is difficult but because the app asks a series of small questions in no particular order, and the answers interact. Skip them and the result is a menu bar that hides the wrong things, reveals them at the wrong moment, or does nothing at all because a permission was never granted.

What follows is a setup order. Each step depends on the one before it, and the settings named here match the panes as published, checked on 10 September 2026.

Check two things before installing

The first is the macOS version. The stated requirement is macOS 14 or later, and the developer has said there are no plans to support anything earlier, because the app relies on system interfaces that only exist from that version onward. This is a floor rather than a preference, so a Mac on an older release will not run it at all.

The second check is easier to forget. If another menu bar manager is already installed, quit it before starting. Every app in this category does the same underlying job: grabbing status items and moving them along the bar. Two of them running at once will fight, with one repositioning an icon that the other immediately moves back. The symptom looks like a flickering or drifting menu bar and is usually blamed on the newer app. Evaluating two tools in the same week is fine. Running both at the same minute is not.

Install, then expect nothing to happen

There are two documented install routes. Download the zip from the releases page, unpack it and move the app into the Applications folder. Or, on a Mac with Homebrew, run brew install --cask jordanbaird-ice.

On first launch a new icon appears in the menu bar and nothing else changes. No icons hide. This is the expected state, not a failure. The hiding mechanism cannot function until the permissions in the next section are granted, and a large share of the confusion reported by new users stops here, at an app that appears to have installed and then done nothing.

Two permissions, and only one is required

The settings window has a permissions pane listing two entries, with different requirements attached.

Accessibility is required. It is used for reading the state of the menu bar in real time and for arranging items. Without it, the app cannot move a status item at all, which means it cannot hide anything. Granting it happens in System Settings, under Privacy and Security, in the Accessibility list. Quitting and relaunching the app afterwards avoids a stale state where the permission is granted but not yet noticed.

Screen recording is optional. It is used for changing the appearance of the menu bar and for displaying images of individual menu bar items. The current build runs in a reduced mode without it, which was not always the case. Declining it costs the appearance controls and the visual previews of hidden items. The core behaviour of hiding and revealing continues to work.

That split is worth a deliberate decision rather than a reflexive approval. Screen recording is a broad permission on macOS, and anyone uncomfortable granting it can still get the main function of the app. The trade is losing the ability to see what a hidden icon looks like before reaching for it.

Three sections, and how to sort icons into them

The organising idea is that the menu bar gets divided into three regions, separated by dividers the app inserts.

The visible section holds items that stay on screen permanently. The hidden section is collapsed by default and opens on demand. The always-hidden section is disabled out of the box; enabling it in the advanced pane adds a second divider, and items placed beyond it stay put unless summoned deliberately, by holding Option and clicking a divider.

Dividers can be shown or hidden as visible bracket characters in the bar. Leaving them visible while arranging things makes the boundaries obvious. Turning them off later reclaims the space once the layout has settled.

Assignment happens in the layout pane, where each section appears as a drop target and items are dragged between them. The same rearrangement can be done directly in the menu bar by holding Command and dragging an icon, which is a macOS behaviour rather than an app feature. Worth knowing: the app performs its moves by synthesising the same Command drag a person would do, which means macOS itself records where each item ended up. That detail resurfaces later, at uninstall time.

A quick sorting rule that holds up in practice: sort by how often an icon gets clicked, not by how important the app feels. Items clicked several times a day stay visible. Items rarely clicked but worth glancing at, such as anything that signals sync or connection state through colour, go in the hidden section. Items never clicked and never read, but which cause problems if quit, belong in the always-hidden section.

Getting items back, and getting them to leave again

Three independent reveal gestures are available, and any combination of them can be enabled.

Setting	Gesture
Show on click	Click an empty area of the menu bar
Show on hover	Move the pointer onto the menu bar
Show on scroll	Scroll or swipe while over the menu bar

Hover is the one most likely to be turned on enthusiastically and off again in irritation, because it fires whenever the pointer crosses the top of the screen on its way somewhere else. Before disabling it, look for the hover delay setting in the advanced pane. Raising the delay usually solves the problem while keeping the convenience.

Revealing is only half of it. Items left showing defeat the purpose, so there is an automatic rehide setting with three strategies. One uses a smart algorithm that decides based on context. One rehides after a fixed number of seconds. One rehides when the frontmost app changes.

The fixed timer is the easiest to reason about while learning the app, since the behaviour is entirely predictable and the number is adjustable. The frontmost app strategy tends to feel most natural afterwards, because it ties the menu bar to the rhythm of switching tasks rather than to a clock.

Notch machines and the bar below the bar

On a MacBook with a notch, the menu bar has a gap in the middle. Once enough status items accumulate, the overflow disappears behind the notch and stops being reachable, which is a different problem from hiding: those items are not hidden, they are simply not drawn.

The app addresses this by offering to display hidden items in a separate bar rendered below the menu bar rather than inside it. The position of that bar is configurable in three ways: adjusting based on context, centred below the mouse pointer, or centred below the app's own icon.

On a notched machine this setting is close to mandatory. It guarantees that whatever gets revealed lands somewhere with room to draw it, no matter how many items are involved.

Shortcuts, the settings window, and long app menus

Keyboard shortcuts exist for six actions: toggling the hidden section, toggling the always-hidden section, searching menu bar items, enabling the separate bar, showing section dividers, and toggling application menus. None of them has a default assignment, so nothing works from the keyboard until a combination is chosen manually.

Assign the search shortcut first. Once a dozen icons are distributed across three sections, finding one by name is faster than remembering which region it landed in, and search makes an aggressive hiding setup workable rather than annoying.

Two related settings deserve a mention here. The app's own icon can be hidden, which frees one more slot in the bar, but doing so removes the visible route into the settings window. The replacement is a right click on an empty area of the menu bar. Anyone who hides the icon without knowing that ends up assuming the settings are gone.

The other is the toggle for hiding application menus. Menu bar congestion is not only about status icons on the right. Apps with long menu titles on the left consume horizontal space from the other direction, and on a 13 inch display there may not be enough room left to draw revealed items. The setting pulls the application menus out of the way for as long as items are showing, and it can be bound to a shortcut too.

Appearance settings, and when they are worth the permission

A separate pane controls how the menu bar itself looks rather than what it contains. The available controls cover a tint, applied as a solid colour or a gradient, a shadow, a border, and a custom shape that can be rounded, split into segments, or both. A later build added the ability to set different appearances for light and dark mode instead of forcing one look across both.

All of this depends on the optional screen recording permission, which makes it the main reason to grant that access. Anyone who declined it earlier will find this pane inert.

Whether the trade is worth making depends on what the reader is trying to fix. If the complaint is purely that there are too many icons, appearance changes solve nothing and the permission can stay off. If the complaint is that the menu bar is hard to read against a busy wallpaper, a solid tint behind it does more for legibility than hiding a further two icons ever will. On a notched MacBook, the split shape option also changes how the bar reads around the gap, which some people find clearer and others find distracting.

One caution: heavy tinting draws attention to a strip of screen most people have trained themselves to ignore. If the goal was a calmer menu bar, subtle settings tend to serve better than dramatic ones.

Spacing reaches outside the app

There is a setting that tightens the gap between menu bar icons, fitting more of them into the same width. It behaves unlike everything else in the app, because it does not configure the app. It writes a system wide preference that affects every status item on the Mac.

The settings pane carries its own warning that a logout and login may be required for the change to apply properly. Applying it can also involve status bar apps quitting and relaunching. Treat it as a setting to touch when interrupting other applications is acceptable, not during a working session.

Leave it at the default at first. Arrange the sections, live with the layout for a few days, and only reach for spacing if width turns out to be the actual constraint. Reversing it later requires the same disruptive round trip, which is a reason not to change it casually.

What to change first

Grant accessibility access, sort the icons into three sections by click frequency, enable exactly one reveal gesture, pick a rehide strategy, and bind a search shortcut. That is the entire setup, and it takes about ten minutes.

If the friction that remains is the number of steps needed to actually use a hidden icon rather than the hiding itself, that is a difference in interaction model rather than configuration, and it is worth comparing directly on how it compares or by testing a build of Koffret alongside it for an afternoon.