A free, open-source way to hide the Mac menu bar for OLED protection

The free, open-source menu bar hider most people end up wanting is TuckBar. It is free, the full source is on GitHub under an MIT license, and it does something macOS cannot do on its own: it hides the system menu bar on the specific displays you tag, so a bright, static bar stops aging the pixels on an OLED screen. Because the code is public, you can verify exactly what it touches before you let it run all day in the background.

That transparency matters more than it sounds. A menu bar hider runs constantly, watches your display layout, and draws on top of your wallpaper. This is not a tool you want to be a black box. Below is what "free and open source" actually buys you, what to know about Gatekeeper and notarization on macOS, and how to install one without getting stuck.

"Free" is the easy part to match

Plenty of menu bar utilities are free. Price is not the real question. The question is what the free thing is doing in exchange, because a background app that hides your menu bar has broad reach. It can read your display configuration, draw over the screen, and launch at login.

So the checklist for a tool like this is less about cost and more about trust:

• No subscription or account. A burn-in guard should not need a login or a monthly fee to do its one job.
• Readable source. Open source means you, or someone you trust, can confirm there is no telemetry and no surprise network activity.
• Clear permissions. You should be able to see exactly what the app asks for and why.

Matching the price of free is trivial. Transparency is the part that separates a tool you can leave running for months from one you uninstall after a week of unease.

What open source actually proves here

Open source is not just a license badge. For a utility that draws over your screen and reads your display layout, public code is the only way to actually know what the app does.

With the source on GitHub, you can confirm things no marketing page can prove:

• No hidden telemetry. You can search the code for network calls and analytics SDKs and see for yourself whether any exist.
• What it requests, and why. A per-display hider needs to observe your screens and draw an overlay. Open source lets you check that it asks for that and not more.
• It can outlive its author. If the maintainer steps away, the code is still there to rebuild for a future version of macOS. A closed freeware app that stops getting updates simply dies.

You do not have to read Swift to benefit from this. The fact that the code is public means other people can and do, so problems tend to surface in the open instead of staying hidden.

Gatekeeper and notarization, accurately

This is the part people get tangled up in, so it is worth being precise, especially since it affects how a free download actually installs.

When you open an app from outside the Mac App Store, macOS Gatekeeper checks how it is signed. There are roughly three states:

• Notarized with a Developer ID. The developer paid for an Apple Developer account, signed the app, and uploaded it to Apple, which ran an automated malware scan. If it passes, Apple staples a ticket to the app and it opens with a normal double-click. Notarization does not mean Apple reviewed the features or endorsed the app. It means the binary is signed, scanned for known malware, and unchanged since the developer built it.
• Signed but not notarized, or ad-hoc signed. Many small open-source projects ship this way, especially early on. Gatekeeper does not have a notarization ticket to check, so the first launch shows a warning instead of opening directly. You get past it with a quick right-click step (more on that below).
• App Store distribution. A separate, stricter review process. Different track entirely.

To be straight with you: as of this writing, TuckBar is an early build that is ad-hoc signed, not yet notarized. That means the first launch needs the right-click-then-Open step rather than a plain double-click. Developer ID notarization is on the roadmap, but asserting it as already done would be exactly the kind of unverifiable claim this whole post is arguing against. For an app whose pitch is "you can verify everything," it would be silly to fib about its own signature.

Notarization is a malware-scan and tamper-check pass from Apple, not a feature review. Ad-hoc signing skips that pass, which is why an unnotarized app shows a warning on first launch. Neither one tells you the app is good, only how macOS treats it at open time.

Why you need a dedicated tool at all

If you are new to this, the obvious question is why macOS does not just handle it. The short answer is that it half-handles it.

macOS has a built-in auto-hide option (System Settings > Control Center > "Automatically hide and show the menu bar"). It works, but it is global. It hides the bar on every display at once, and it slides the bar back the instant your pointer touches the top edge of any screen. There is no built-in way to hide the menu bar on just one display. If you run an OLED external monitor next to a regular LCD or mini-LED laptop screen, that all-or-nothing behavior is the core problem.

The other popular tools do not solve this either. Bartender, Ice, Hidden Bar, and Dozer are menu bar icon managers. They tidy or hide the little status icons on the right side of the bar. They do not remove the system menu bar itself, and they do not work per display. They are excellent at what they do. It is just a different job. If you want the distinction spelled out, see Bartender, Ice, and friends vs hiding the whole menu bar.

The burn-in reason this matters

The menu bar is close to a worst case for OLED. It is bright, it never moves, and it is on screen for most of your waking day. On an OLED panel, pixels wear as they emit light, so pixels held at the same brightness in the same spot age faster than their neighbors. Over enough time that uneven wear becomes burn-in: permanent, differential pixel aging that you cannot fully recover.

That is different from image retention, the temporary ghost of a static image that usually fades once the screen shows other content for a while. Retention is recoverable. Burn-in is not. A static menu bar is a textbook driver of the permanent kind, which is the whole reason a per-display hider exists. For the full picture, see why an always-on menu bar is the worst thing for an OLED screen.

One accuracy note while you shop: most Macs and Apple displays today are LCD or mini-LED, not OLED. The Pro Display XDR and current MacBook Pro screens are mini-LED, and far less prone to burn-in. On the desktop, OLED mostly means external monitors from the likes of LG, Samsung, ASUS, and Dough. iPhone and Apple Watch screens are OLED, but those are not where a Mac menu bar lives. If you are not sure what you have, check which Macs and Apple displays are actually OLED before worrying about burn-in at all.

How to install an open-source hider

Installing a free app from GitHub is straightforward once you know the steps. Using TuckBar as the example, since it is an early build you assemble it from source with the included script:

1. Clone from the official repo. Get the code from the project's real GitHub page. Sticking to the official source is half the security story.
2. Build the app. Run the included build script (./scripts/build-app.sh). It is a small Swift package with no dependencies, so this is quick.
3. Move it to Applications. Drag the built .app into your Applications folder so it lives somewhere stable.
4. Open it the first time. Because this build is ad-hoc signed rather than notarized, a plain double-click triggers a Gatekeeper warning. Right-click the app, choose Open, and confirm once. After that it opens normally.
5. Grant only what it asks for. The app needs to observe your screen layout, and the seamless wallpaper cover uses Screen Recording permission to read the wallpaper pixels behind the bar (nothing is recorded or saved). Approve only those, then tag your OLED display. The bar disappears there while your other screens stay untouched.

The point of open source is that you do not have to take any of this on faith. You can read the code that handles those permissions before you grant them, which is a luxury closed freeware never gives you.

What a good free hider should do once installed

Hiding the bar is the headline, but the day-to-day details are what make it livable. A solid per-display hider should let you:

• Paint the live wallpaper over the bar so it appears to simply vanish, or dim or black it out if you prefer a different treatment.
• Reveal on hover so the real menu bar is one mouse movement away when you actually need it.
• Hide the Dock too, since a static Dock is a smaller but real burn-in source on the same panel.
• Reveal on a timer when you need the bar for a recording or a finicky app, then re-tuck itself. You can reveal the menu bar on a timer while staying protected the rest of the day.

TuckBar does all of this, and it is the tool this checklist was built around. It is free, the source is on GitHub, and where it is still early (the not-yet-notarized signature) it tells you so up front instead of papering over it.

The bottom line

For protecting an OLED Mac setup, "free" is necessary but not sufficient. What you really want is free and open source, so you can verify there is no telemetry and see exactly which permissions the app uses. Notarization is a nice convenience on top, but it is a Gatekeeper signal, not a quality stamp, and an honest project will tell you whether it has it yet. A per-display menu bar hider that is open and transparent is the kind of thing you can leave running for years without thinking about it, which is exactly what burn-in prevention requires.