Ice alternatives: decide what you can drop
Every menu bar manager for macOS is described in almost the same sentence: it hides the icons you do not need and shows them when you do. That makes a list of alternatives close to useless as a way of choosing one. A better starting point is the set of features currently in use, because it is usually smaller than expected, and because it turns an open ended comparison into a checklist.
Count what is checked off, not what is available
Ice publishes its feature list as a roadmap with completed items ticked. That list is the fastest tool available for this decision, because it can be read as an inventory rather than as marketing.
Already implemented: hiding icons, a second always-hidden section, revealing on hover, on a click in empty menu bar space, or on a scroll or swipe, automatic rehiding after a delay, hiding application menus when they collide with shown icons, a drag and drop layout editor, a separate bar for showing hidden icons below the menu bar for notched MacBooks, search by icon name, icon spacing marked as beta, menu bar tint, shadow, border and custom shapes, hotkeys for toggling sections and opening search, launch at login and automatic updates.
Not yet implemented: saved layout profiles, individual spacer items, icon groups, showing items when trigger conditions are met, removing the background behind the menu bar, separate settings for light and dark appearance, and temporarily showing one specific item.
Read both lists and mark the items that get touched in a normal week. For most people the total lands at three or four: hide the clutter, reveal it on demand, have it hide itself again. The layout editor and the appearance controls tend to be visited once during setup and never again.
If everything marked sits in the first list, features are not the reason to move. Something else is, and naming it matters, because a symptom like one specific icon that refuses to stay hidden often follows you across tools. Icons belonging to apps that tear down and rebuild their menu bar item look the same to every manager.
Where the project stands
Facts, checked on 10 September 2026. Ice is free, licensed under GPL-3.0, and requires macOS 14 or later. The developer states there are no plans to support earlier releases, because the app relies on system APIs introduced in macOS 14. Distribution is a direct download from the GitHub releases page or a Homebrew cask, and updates are delivered in app from a feed hosted on GitHub Pages.
| Version | Released |
|---|---|
| 0.11.13-dev.2 | 16 September 2025 |
| 0.11.13-dev.1 | 20 June 2025 |
| 0.11.12 | 29 October 2024 |
| 0.11.11 | 19 October 2024 |
The two most recent entries are published as development builds. Excluding those, the newest release is from October 2024. The project describes its own status in the first note of its README:
Ice is currently in active development. Some features have not yet been implemented. Source: github.com
None of this needs a verdict attached. It is context for one question: whether the implemented set covers the three or four things marked earlier.
Four things to check on any candidate
Round up articles about menu bar tools date badly, because they are usually written once and left alone. Four facts change underneath them, and all four are worth confirming on the vendor's own site rather than on a comparison page.
The first is whether the product still exists. The second is whether it still accepts new customers, since some tools continue to serve existing licence holders while closing new sales. The third is whether ownership has changed. The fourth is whether the pricing model has been reworked, which happens more often than the price itself moving.
The third one is not hypothetical. The copyright line on the Bartender site reads Surtees Studios in an April 2024 snapshot, Bartender App LLC in an August 2024 snapshot, and Applause Group, Inc. when the site is opened on 10 September 2026. That is a matter of record rather than a criticism, and it is the kind of thing worth knowing about a tool that sits between you and your menu bar every day.
The fourth is visible on the same site. The purchase page currently offers three routes: a one time licence for Bartender 6 that includes updates within that major version, a yearly Bartender Pro subscription that adds a Pro suite and future major upgrades, and a lifetime Mega Supporter tier. Prices render in the visitor's local currency, so they need to be read on the page rather than quoted from elsewhere. There is a four week free trial with no card required, a 14 day refund window, inclusion in the Setapp bundle, and free upgrades to version 6 for anyone who bought Bartender 5 during 2025.
Free options age differently
If the budget is zero, the useful comparison between community built tools is not feature count. It is how recently each one was updated, because macOS ships a new major version every year and the menu bar is one of the areas that keeps changing.
| Tool | Licence | Latest release |
|---|---|---|
| Ice | GPL-3.0 | 16 September 2025 (development build) |
| Hidden Bar | MIT | 3 March 2026 |
| Dozer | MPL-2.0 | 13 July 2020 |
All three checked on GitHub on 10 September 2026. Dozer has not been archived and its repository is still online, but more than six years have passed since its last release. Hidden Bar is also distributed through the Mac App Store at no cost.
Release dates alone can mislead, so read them alongside what changed. A tool that has been quiet for a year because its feature set is finished behaves very differently from one that has been quiet because macOS moved and nobody adjusted it. The test that settles it takes one minute: install the candidate on the current macOS version and watch whether icons land where they should on both an internal display and an external one.
Licences matter less for personal use and more for deployment. GPL-3.0 requires derivative works distributed to others to be released under the same terms, MIT imposes almost nothing, and MPL-2.0 sits between the two by applying its terms file by file. For an individual installing an app on a personal Mac, none of this changes anything. For anyone putting software on company machines, it is a question that gets asked.
What macOS handles without help
Some of the crowding can be solved before installing anything. System Settings has a Control Center pane that decides which built in items appear in the menu bar at all, and switching off unused ones frees real space. Built in items can also be rearranged by holding Command and dragging them, and dragged off the menu bar entirely to remove them.
That is the boundary. Command dragging works on system items, not on icons that third party apps create for themselves, and macOS provides no way to fold an app's icon out of sight while keeping the app running. Past roughly five background apps, a dedicated tool becomes the practical answer.
Notched MacBooks reach that point sooner. The centre of the menu bar is occupied by the camera housing, so icons filling from the right eventually disappear behind it while application menus fill from the left. Trimming built in items buys very little room here, which is why a separate bar for hidden icons shows up as a named feature in several tools. Behaviour also differs between the built in display and an external monitor, so test both before deciding.
Never run two of them at once
The most common way to make this evaluation go badly is to install a second manager while the first is still running. These tools work by moving icons, adjusting their spacing and toggling their visibility, and two of them acting on the same strip with different intentions produce icons that vanish, reappear or refuse to move.
Evaluate one at a time. Quit the incumbent, launch the candidate, run the same handful of tasks, and form an opinion. Quitting alone leaves settings in place, so anything definitively rejected should be removed rather than parked.
One setting deserves care during a trial: icon spacing. It works by writing a system level value, and applying it relaunches every app that has a menu bar icon. Ice warns that some apps may need to be restarted manually afterwards, and lists any that failed to quit. Test that particular feature outside of working hours.
Judge the retrieval, not the hiding
Every tool in this category hides icons competently. The differences show up in the opposite direction, when a hidden icon has to be used, and that is the part rarely covered in comparisons because it only becomes visible after a few days of real work.
Count the steps. In some designs, reaching a hidden icon means expanding the whole hidden section, clicking the icon, using its menu, and waiting for the section to collapse again. That is three deliberate actions plus a wait, repeated every time. Since the reason for hiding icons was to save attention, a design that charges three actions per use gives some of it straight back. A design where a hidden icon can be pressed and its menu opened on the spot, with the bar still folded, removes the round trip entirely.
Two related behaviours are worth timing during a trial. The first is the reveal delay on hover, which feels different at 0.2 seconds and at 1 second, and which is adjustable in some tools and fixed in others. The second is the rehide rule: after a set interval, after the pointer leaves the menu bar, or only on an explicit command. A tool that rehides while a menu is still open is annoying in a way that no feature list communicates.
Keyboard access is the third thing to test, and the easiest to forget during a trial because setting it up takes a few minutes on day one. If a search panel can be summoned by hotkey and an icon activated by typing part of its name, then the number of visible icons stops mattering very much, and the whole question of what to hide becomes far less delicate.
Run these three checks on each candidate with the same set of icons, and the decision usually makes itself within a day rather than a week.
What to change first
Write down the three or four features actually in use, then check them against the candidate's implemented list rather than its marketing page. If they all fit, the reason to switch is release cadence, ownership or price, and those are quick to verify. Before installing anything, record the current section layout, hotkeys and icon order so that reverting takes minutes: see How it compares for a feature by feature mapping and Features for what each one does. Koffret is one of the options worth putting on that list.
Frequently asked questions
Has Ice been abandoned?
The repository is public and the developer describes the project as in active development. The published record, checked on 10 September 2026, shows the newest stable release as 0.11.12 from 29 October 2024 and the newest development build as 0.11.13-dev.2 from 16 September 2025. Check the releases page directly before deciding, since that status can change at any time.
Does switching carry the settings over?
No. There is no shared format for section layouts, hotkey assignments or icon order, so each tool has to be configured from scratch. Setup usually takes a few minutes. Noting the current configuration before switching makes going back just as fast if the new tool does not suit.
What actually separates the free tools from the paid ones?
Less the raw feature count and more the response time to macOS changes, plus how far the feature set extends. Paid products tend to add saved layout profiles, item grouping and rule based automatic display. Free tools cover hiding and revealing well, and their update cadence varies widely between projects.
Can a Mac cope without any of these tools?
Up to a point. Control Center settings decide which built in items appear, and Command dragging rearranges or removes them. Neither works on icons created by third party apps, so on a machine running five or more background apps the built in options run out and a dedicated tool becomes the practical route.