It started as the most trivial possible itch. I like reading web pages in dark — but I hate what Dark Mode does to the rest of the Mac: the Dock goes black, app toolbars and buttons go black, Safari’s chrome goes murky. I wanted dark content on a light system.
That half is easy, and worth stating because it’s the part people get backwards: run the system in Light mode and force darkness only at the content layer. Light mode keeps the Dock and buttons bright; Dark Reader blackens web pages regardless of system appearance. Done.
Which left exactly one thing I couldn’t get: a black menu bar, to hide the notch — while staying in Light mode, and without giving up my wallpaper, which shuffles through a set of underwater aerials every day.
It smelled like a tiny app waiting to be built. A toggle. A “control layer.” Maybe even something to open-source. Reader, it was not. Here’s where the floor gave out.
Reality check 1: there is no “menu bar only” switch
macOS has exactly one appearance lever, and it’s global: Light or Dark, everything at once. There is no public defaults key that darkens the menu bar alone.
There used to be. Before Mojave (Yosemite through High Sierra), General settings had a checkbox literally called “Use dark menu bar and Dock” — it darkened the menu bar and Dock while leaving your apps light. That’s the exact thing I wanted. Apple deleted it in 2018 when full Dark Mode arrived; the standalone capability got folded into “everything dark” and never came back.
Reality check 2: the app that “works” is faking it
The popular fix is TopNotch: it makes the menu bar black and the notch vanish. I installed it. It worked — and watching how it worked was the first real clue.
TopNotch doesn’t tint the menu bar. It rewrites your wallpaper — it generates a copy of your desktop picture with a black strip across the top, and sets that as your wallpaper. The black menu bar you see is just the top edge of a black-topped wallpaper showing through.
Two consequences fall out immediately:
- It can’t coexist with an animated/aerial wallpaper. To put a static black strip up there, it has to replace your living wallpaper with a frozen still. I caught it red-handed: its preview pane showed my underwater aerial swapped for a static gradient with a black bar painted on.
- It’s a 22 MB resident app to do that one substitution and keep re-applying it.
I deleted it. Not because it’s bad — because what it does is the only thing that can be done, and it does it by sacrificing exactly the wallpaper I wanted to keep.
That raised the real question. If the only way to blacken the menu bar is to darken the wallpaper behind it… is that genuinely the only way? Or can a window do it?
The experiment: can anything tint the menu bar?
On Tahoe (macOS 26) the default menu bar is transparent — it shows whatever’s behind it. So the naïve idea: float a thin black window across the top, behind the menu bar text. No wallpaper touched, no resident app freezing anything. If macOS composites windows into the menu bar, this works and it’s nearly free.
First I confirmed what I was up against. The wallpaper isn’t a file you can poke anymore — it’s a system service:
$ ls ~/Library/Application\ Support/com.apple.wallpaper/
Store/ aerials/
$ pgrep -lf wallpaper
WallpaperAgent
WallpaperAerialsExtension
WallpaperSonomaExtension
...So no image to edit. Fine — test the overlay theory directly. A ~20-line AppKit program: a borderless, black, click-through window pinned across the top of the screen.
import Cocoa
let app = NSApplication.shared
app.setActivationPolicy(.accessory)
let screen = NSScreen.main!
let f = screen.frame
let rect = NSRect(x: f.minX, y: f.maxY - 40, width: f.width, height: 40)
let win = NSWindow(contentRect: rect, styleMask: .borderless, backing: .buffered, defer: false)
win.backgroundColor = .black
win.isOpaque = true
win.hasShadow = false
win.level = NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.desktopIconWindow)))
win.collectionBehavior = [.canJoinAllSpaces, .stationary, .ignoresCycle]
win.ignoresMouseEvents = true
win.orderFront(nil)
app.run()Compile, run, and let the machine grade itself — screencapture the top strip and look:
$ swiftc -o /tmp/notchtest notchtest.swift
$ /tmp/notchtest & sleep 2
$ screencapture -x -R0,0,1440,30 /tmp/shot.pngThe menu bar came back the color of my wallpaper — a muted blue-gray — with the black window sitting uselessly below it. No tint. Maybe the window level was too low, under the wallpaper compositor? So I raised it as high as a window can go without covering the menu bar’s own text:
win.level = NSWindow.Level(rawValue: Int(CGWindowLevelForKey(.mainMenuWindow)) - 1)Recompiled, recaptured. Identical. Still wallpaper-colored. A black window slammed right up against the underside of the menu bar, at the highest level it can occupy, and the menu bar didn’t acknowledge it existed.
The verdict: the menu bar sees your wallpaper and nothing else
Two window levels, same result, and it’s conclusive:
macOS paints the menu bar by sampling the wallpaper — not the windows behind it, at any level. The same sampling drives the text color: a dark wallpaper top gives you white menu text automatically; a light one keeps it black.
That single fact explains everything upstream. It’s why TopNotch edits the wallpaper instead of drawing an overlay — an overlay was never going to work. It’s why there’s no lightweight tool hiding in this problem: a black menu bar requires dark pixels in the top edge of your actual wallpaper, full stop. Any app that delivers one is, underneath, repainting your wallpaper. There is no other door.
The deeper problem: I was asking for two opposite colors
Here’s the part that turned “hard” into “incoherent.” My wallpaper is Shuffle Underwater — Settings happily told me it rotates through 14 aerials, every day. Plenty of them are bright: pale jellyfish, sunlit shallows. A bright wallpaper top means a bright menu bar means the black notch stands out against it. That’s why the notch was bugging me in the first place.
So lay the two wishes side by side:
- “Keep my bright, daily-changing wallpaper” → light pixels at the top of the screen.
- “Black menu bar to hide the notch” → dark pixels at the top of the screen.
Same pixels. Opposite colors. This was never a missing feature or a tool I hadn’t built yet. It’s a contradiction. No amount of Swift resolves “make these pixels bright and black at the same time.”
What you can actually do (tradeoffs, not tools)
Once it’s framed as one strip of pixels you have to assign a color to, the real options are obvious and small:
- Keep the pretty shuffle, accept the notch. The notch is cosmetic; on the darker aerials it already blends, and on the bright ones it shows. Zero software.
- Pick a consistently dark wallpaper. The Earth-from-space aerials (Middle East, North Africa) are mostly black sky at the top — the menu bar stays dark, the notch hides, it still animates on wake, and you keep Light mode. You trade theme, not capability. This is the no-tool win if hiding the notch matters more than the underwater look.
- Use Dark Mode. It gives you a guaranteed dark menu bar and a daily-changing wallpaper — at the cost of the dark Dock and dark buttons I started this whole thing trying to avoid. Full circle.
All reversible; all live in Settings → Wallpaper / Appearance.
The takeaway
I went in expecting to ship a tiny utility and came out having shipped a decision: there’s nothing to build here, because the thing I wanted is two contradictory pixel colors wearing a trench coat. The menu bar samples your wallpaper and only your wallpaper — so “black menu bar” and “bright wallpaper” can’t both be true, and every app that pretends otherwise is quietly editing the wallpaper you were trying to protect.
Sometimes the deliverable is realizing the feature can’t exist, and the honest move is to not write the 22 MB app that fakes it. 🌊⬛
The epilogue: I let the ocean go
So which tradeoff did I actually take? Not the clever one. I skipped the dark Earth aerials and set the wallpaper to flat black — the whole underwater shuffle, gone.
The notch didn’t get fixed; it got nowhere left to hide. The top of the screen is now the same black it is, so there’s nothing left to notice. I gave up a wallpaper I loved to stop seeing a flaw I hated — and that the trade actually stung is how I know the flaw was real. No app, no 22 MB, no frozen still. Just one strip of pixels, finally allowed to be one color.
Footnote: I didn’t flail at this alone. I described the itch to Claude Code (thank you, Anthropic), and instead of guessing, it wrote the throwaway AppKit overlay, ran it at two window levels, screenshotted the menu bar, and read the pixels back — turning “I think the menu bar ignores windows” into a proof in about three minutes. The best part was being talked out of building the tool. 🛠️🚫