Ice Stopped Shipping. Thaw Kept Going.

I went looking for an Ice update in the middle of a workday, after the hidden icons failed to come back again. Not every time, which is worse than every time. You flick the cursor up, the section stays shut, and you sit there for a second wondering whether you imagined the shortcut. The releases page answered faster than I wanted. Ice 0.11.12, tagged 29 October 2024. Two Tahoe beta builds after that, the last of them in September 2025, then silence. The most recent push to main is dated 20 September 2025. The issue tracker sits at 414 open.

That’s the awkward thing about menu bar managers. You install one to fix a small annoyance, and within a fortnight it’s sitting between you and every status icon you own, all day, on every space. Then macOS ships a major version and the tool you’d stopped thinking about becomes the reason your VPN indicator won’t come back. An unmaintained utility isn’t neutral. It rots.

The fork that picked it up

Thaw is a fork of Ice by stonerl, GPL-3.0 like the original, and it has been doing the work Ice put down. Same Swift and SwiftUI codebase underneath, same hidden and always-hidden sections, same drag-and-drop layout editor, same optional second bar for notched Macs. The README’s pitch is unadorned: hide what you don’t need, find any item from the keyboard, restyle the bar. Free, no account, no telemetry, signed and notarised.

I assumed this was a courtesy fork. Rename the binary, bump a version, collect the stars from people fleeing an abandoned repo. It isn’t. The development branch is at roughly 2,600 commits against Ice’s 1,140, and they keep landing — four release candidates in the past three weeks.

Why bother at all

The honest objection is that this is cosmetic, and the real fix is uninstalling the four menu bar apps you never open. Except macOS itself has moved halfway into this territory and stopped. Tahoe lets you toggle individual app icons on and off and rearrange them with Command+drag, but it offers no multiple hidden sections, no automation triggers, no hover or scroll toggling, and no custom spacing. If you have a notch and more than a dozen status items, Apple’s version runs out well before your menu bar does.

The part I actually find interesting

Not the fork story. The automation surface. Every core action in Thaw is a thaw:// URL, which is unremarkable, but the project also exposes its settings over the same scheme, and that’s where the design gets a spine.

# Plain actions
open "thaw://toggle-hidden"
open "thaw://search"

# Settings mutation, allowlisted senders only
open "thaw://set?key=showOnHover&value=false"
open "thaw://toggle?key=autoRehide"

# Ask for authorisation without reading or writing anything
open "thaw://authorize"

The settings API is off by default and lives behind Settings → Automation. The first time an unknown app fires one of those set URLs, Thaw raises a dialog showing the caller’s name, bundle ID and signing information. Approve it and the app joins a whitelist you can inspect and revoke later. Deny it and further requests fail silently, so a rejected app can’t nag you by spamming the scheme.

I assumed, from the word “whitelist”, that each request was getting its signature verified. It isn’t. Authorisation is granted once per app and stored against a bundle identifier, and the sender is whatever macOS reports as having opened the URL. The docs are blunt about where that breaks: run one of these from Terminal and sender detection fails, which is why DEBUG builds accept a bundleId override that release builds strip. A URL scheme was never a real trust boundary, and the maintainer clearly knows it, which is why reads are crippled unless you supply a callback URL.

There’s a second process too. MenuBarItemService is an XPC helper that keeps WindowServer and source-PID lookups out of the UI process, over a Codable request surface of three calls.

Numbers the README skips

Install is one line, and the beta channel is a separate cask:

brew install thaw        # stable: 1.2.0, macOS >= 14
brew install thaw@beta   # beta: 2.0.0-rc.3, macOS >= 26

I took the first one, which means I’ve been running 1.2.0 this whole time rather than the app the front page describes. More on that below.

The tunable ranges are documented properly, which is rarer than it should be. rehideInterval accepts 1 to 300 seconds and defaults to 15. showOnHoverDelay runs 0 to 5 seconds, default 0.2. iconRefreshInterval defaults to 0.25 seconds, roughly 4fps, and snaps positive values onto a 1/n grid. Out-of-range values are clamped rather than rejected.

The release notes are the other tell. The 2.0.0-rc.4 notes, published 17 August, describe a cold-start failure where the item cache froze for a full minute, every tooltip read “Menu Bar Item”, and clicks did nothing until a settling deadline expired — with one field report showing the cache rejecting refreshes for over 20 hours. rc.3, two days earlier, closed a memory leak that someone had watched grow to 47 GiB. Nobody writes changelogs like that unless they intend you to trust the next one.

Caveats, honestly

The stable release and the README describe different applications. brew install thaw gives you 1.2.0, which targets macOS 14 and later. The README on the default branch advertises macOS 26+ and documents 2.0 features like layout profiles, so if you installed from Homebrew and went looking for profiles, they aren’t there. The beta cask lags too: it sits at 2.0.0-rc.3 while the releases page is on rc.4, and rc.4 is the one that stopped the item cache stalling for good.

“Screen Recording is optional” is optimistic. The README lists it as optional and says hiding, revealing and rearranging all work without it — grant it only for previews and appearance tinting. FREQUENT_ISSUES.md then explains that without it, Settings → Menu Bar Layout may fail to load items at all, and revealing only the always-hidden section can be limited (#628). Optional in the sense that a car is optional if you live near a bus stop. There’s a companion irritation in #683, where macOS re-prompts for the permission after every reboot despite prior approval; the workaround is removing and re-adding Thaw in System Settings.

The 2.0 candidates have been eventful. The rc.4 notes openly cite an 11,500-line item manager file, identity matching that had drifted, and a test suite that wrote into the real settings of whoever ran it. All three are addressed, but that’s the condition of the code currently being stabilised.

macOS 27 isn’t supported. Preview builds exist and are labelled experimental. Everything is funnelled into #687, and the project asks you not to open separate issues for it.

Don’t install this if you want a utility you never think about. Release candidates have been landing every few days this month. Stay on 1.2.0, or use something smaller like Hidden Bar, if a menu bar tool that occasionally needs your attention sounds worse than a cluttered menu bar.

Ice next to Thaw

What I’d take from it

The detail that stuck with me is in the settings keys. Thaw still reads and writes useIceBar, iceBarLocation and customIceIconIsTemplate. A fork that renames its identifiers to erase the parent breaks everyone’s migration and buys nothing but a tidier grep. Leaving Ice’s names in the preferences file is a small, slightly ugly, entirely correct decision, and it tells you what kind of maintenance you’re getting.