A custom menu bar on a Mac: deciding what earns a spot up there

The search for a custom menu bar on a Mac usually starts with a symptom rather than a goal. Icons have crept in from every app that was ever installed, the clock is pushed to the far right, and on a laptop the notch has started eating whichever icon happens to land behind it. The obvious move is to install a manager and hide the overflow. That works, and it also skips the question worth answering first: which of those icons is doing anything for the person looking at them.

Everything up there falls into one of two jobs. Some items report a state that is worth a glance several times an hour. The rest are shortcuts to places where real work happens, and a shortcut in the menu bar is a worse door than the one the operating system already provides. Sorting the icons by that distinction removes more clutter than any hiding tool, and it takes one pass.

The menu bar is two separate systems sharing one strip

Apple's own description splits the strip in half, and the halves behave nothing alike. On the left sit the Apple menu and the app menus, which change every time the frontmost app changes. On the right sit items Apple calls status menus, plus Spotlight, Control Center, and the date and time that opens Notification Center.

Only the right half is customizable in any meaningful sense. The left half belongs to whichever app has focus, and the number of menus there is a decision the app's developer made. When an app's menu titles push so far right that they collide with the status icons, that is not a setting. It is two independent systems running out of room on the same line.

The right half has its own internal split, which is the part most guides skip. Some icons are placed by macOS through a settings pane. Others are placed by Control Center. And a third group is placed by third-party apps that add a status item when they launch. Each group is removed a different way, which is why a single set of instructions never covers every icon someone wants gone.

The group an icon belongs to determines which removal method works on it. Trying the wrong method and concluding that the icon is stuck is the most common dead end in this whole topic.

What macOS already lets you move

Two of the three groups are handled without installing anything. Apple's guidance on the settings route is short:

Add an icon from System Settings: Choose Apple menu > System Settings, click Menu Bar in the sidebar (you may need to scroll down), then select the icon you want to appear in the menu bar. Source: support.apple.com

That pane covers the system's own items, including Siri, Weather, and Time Machine. Deselecting an item there removes it. The second route runs through Control Center: click the Control Center icon, click Edit Controls, then drag items between the gallery, Control Center itself, and the menu bar. Controls that live only in Control Center by default, such as Quick Note, Put Display to Sleep, and Color Filters, can be promoted to the menu bar this way. The reverse also works. Dragging an item out of the menu bar in that mode removes it.

There is a faster version of the same move. Control-click an item inside Control Center and choose Copy to Menu Bar or Add to Menu Bar, and it appears without any dragging.

Rearranging and removing without any settings pane

Order is handled by the keyboard rather than a preference. Hold Command and drag an icon to move it. Hold Command and drag it off the strip entirely to remove it. This works on most status items, including many placed by third-party apps, which makes it the one technique worth memorizing. It is also the only way to control order, since neither the Menu Bar pane nor Control Center exposes a sort.

One more built-in setting is worth knowing before reaching for an app. The Menu Bar settings include an option to hide the strip automatically so it appears only when the pointer reaches the top of the screen. That reclaims the space without deciding anything about the icons, which is either exactly right or exactly wrong depending on how often the icons are actually read.

The three things that turn this into an app purchase

Built-in tools run out in three specific places, and each one maps to a different kind of third-party tool.

The first is capacity. There is no overflow behavior in macOS. When the strip fills, items on the left of the group are simply not drawn, and on a MacBook Pro the notch removes usable width from the middle. Nothing in System Settings pages the extras somewhere else.

The second is conditional display. A VPN indicator matters on an unfamiliar network and is noise at a desk. A battery percentage matters unplugged. macOS treats visibility as a permanent yes or no.

The third is custom content. Nothing built in puts a number on the strip that came from a script, a repository, a server, or a calendar.

Approach What it changes Cost model Source
System Settings and Control Center Which system icons appear, and order via Command-drag Included with macOS Closed
Bartender 7 Hides overflow, notch handling, spacing, profiles, triggers Paid, with a four-week trial Closed
Ice Hides and reveals menu bar items Free GPL-3.0
SwiftBar Adds new items whose text comes from scripts Free MIT

Two details in that table are worth expanding. Bartender 7 is built for macOS 27, with Bartender 6 covering macOS 26, and its licensing is split three ways: a one-time purchase for the current version, a yearly Pro tier, and a lifetime tier. Its site also states that it can run without Screen Recording permission, showing app icons in place of captured images of the strip, which matters to anyone unwilling to grant that permission to a utility.

Ice is published under GPL-3.0 with roughly thirty thousand stars on GitHub, and its most recent commit dates to September 2025. For a tool whose job is drawing over a system-owned strip, the date of the last release is a real input to the decision, because each macOS version changes that strip.

Scripted items are a different tool for a different problem

SwiftBar belongs in a separate category from the managers. It does not hide anything. It adds items whose content is the output of a script, which is the only way to put a project's own numbers on the strip.

The mechanism is deliberately plain. A script goes in a folder, and the refresh interval lives in the filename rather than a settings screen. The README states the format directly: {name}.{time}.{ext}, where the time is a number plus a modifier of ms, s, m, h, or d. A file named date.1m.sh runs every minute. The first line of output becomes the text on the strip, and further lines become the dropdown.

It installs with brew install swiftbar, runs on macOS Monterey and later, and is MIT licensed. One behavior is worth knowing before building a set of these: position is remembered per filename, so renaming a plugin file means positioning it again with Command-drag.

The reason this matters to the original question is that scripted items are the only category that reliably earns permanent space. A build status, a queue depth, or an hours-remaining figure is state that changes on its own and is worth a glance. It is not a shortcut to somewhere else.

The right answer changes between a laptop and a desk

Most advice on this topic assumes one screen and one situation, which is why it stops working the moment a laptop gets plugged into a display. The constraints are genuinely different, and so is the correct icon set.

On a built-in laptop display the binding limit is width. The notch removes usable space from the middle of the strip, and the app menus on the left expand or contract with whatever app has focus, so the point at which icons stop being drawn moves during the day rather than staying fixed. An icon set that fits while Finder is frontmost can overflow the moment a design tool with a dozen menu titles takes over. This is the case where automatic hiding, or a manager that pages the extras somewhere else, earns its place.

On an external display the width problem mostly disappears, and the useful question inverts. With room for everything, the strip fills with icons that nobody reads, and the cost stops being space and becomes attention. Every item that changes color or shape is a small claim on the eye, positioned in the part of the screen people look at to check the time.

That difference is why per-situation switching exists as a paid feature rather than a setting. Bartender lists menu bar profiles that can be paired to display setups, swapped with a hotkey, or changed by a trigger, along with spacing presets that pull items closer together to fit more of them. Its documented triggers cover the conditional cases directly, such as showing a battery item when power is disconnected.

Anyone who moves between one screen and three most days should decide the two icon sets separately, then choose a tool based on whether switching between them by hand is acceptable. For a single fixed desk, it usually is.

A test for whether an icon has earned its spot

Run every icon currently on the strip past two questions.

Does it display information that changes without any action, and would a glance at it change what happens next? Battery on a laptop, network state on unfamiliar connections, whether a microphone is live, whether a backup is stale. These are the icons to keep. Apple's own privacy indicators are the clearest example of the category: an orange dot for a microphone in use, green for a camera, purple for system audio being recorded, and an arrow for location, with only one shown at a time.

Or is it a door to an app? Mail, chat, a notes app, a music service. These are the icons to remove. A menu bar entry is a small target that opens a small panel and does not appear in the app switcher, does not get a Mission Control space, and cannot be assigned to a display. Apps that hold twenty minutes of attention deserve a window, and the window comes with all of the operating system's own handling for free.

That second group is where the real reclaimed space is. It is also where the menu bar gets used as a workaround for a different problem, which is having too many web services open in one browser. Keeping each service in its own window, with its own login state, is the Workspaces idea rather than a menu bar idea, and the list of services that behave well that way is on the Supported apps page. For anyone comparing the tools in that category before deciding, Compared with Wavebox sets out the differences.

What to change first

Turn on automatic hiding for a day before installing anything, because a strip that is out of sight makes it obvious which icons were actually being read. Then Command-drag off every icon that was only a shortcut, and only after that decide whether the remainder still needs a manager. If the services being shortcut are web apps, give each one a window instead, which is what SpaceDeck is built to do.

Frequently asked questions

Why can some menu bar icons not be removed with Command-drag?

Command-drag works on most status items but not on all of them, and some apps place an item that can only be turned off inside that app's own settings. If the icon belongs to macOS rather than an app, the switch is in System Settings under Menu Bar, or in Control Center under Edit Controls.

Does hiding icons with a manager reduce memory or battery use?

No. A manager changes what is drawn, not what is running. The app behind a hidden icon keeps working exactly as before, so the gain is attention and horizontal space rather than resources. Quitting the app is the only way to stop its work.

Is there a free option that hides overflow icons?

Yes. Ice is published free under GPL-3.0 and hides and reveals menu bar items. Its last commit dates to September 2025, so anyone on a recent macOS release should check current compatibility before relying on it.

What happens to menu bar icons hidden behind the notch?

macOS does not move them, so an icon that lands behind the notch is unreachable until the order changes. Command-drag can shift items past that area by hand, and Bartender 7 lists automatic handling of notch-hidden items among its features.

Do scripted menu bar items need any coding beyond shell?

Any language that prints to standard output works, so shell is a starting point rather than a requirement. SwiftBar reads the first line of output as the text on the strip, takes the refresh interval from the filename, and also accepts Shortcuts as a plugin type for anyone who prefers not to write scripts at all.

Back to all posts