How to rearrange Mac menu bar icons
Updated 2026 · a 6-minute read
The quick answer, if that's all you need: hold ⌘ Command and drag any menu bar icon left or right. Release it where you want. That's the whole feature, it's built into macOS, and a surprising number of long-time Mac users have never been told about it.
The longer and more interesting answer is why you have to do it by hand — why no app, including ours, can rearrange those icons for you. We tried hard enough to be confident about the answer, and the finding is worth writing down because it isn't documented anywhere obvious.
Advertisement
The basics of ⌘-drag
Hold ⌘ Command, click and hold an icon, then drag horizontally. A few practical
notes:
- It works on essentially every third-party icon, and on most Control Center items.
- Some Apple items are pinned to the right end — Control Center itself, the clock, Siri and Spotlight won't move past third-party icons no matter how you drag.
- On some system icons, dragging an item off the menu bar removes it entirely. If you do this by accident, you can restore it from System Settings → Control Center.
- Order is remembered across restarts, because macOS saves each item's position.
One tip that saves grief on notched MacBooks: drag your most important icons to the right. The status area fills right-to-left and gets clipped at the left end, so rightmost icons are the ones least likely to vanish when space runs short.
Why can't an app just do this for me?
This is the obvious feature request for any menu bar utility: show me my icons in a window, let me drag them into the order I want, and apply it. It's what most people expect the moment they see a list of their icons in a settings panel.
It cannot be built, and here's the shape of the problem.
There is no API to move another app's status item
macOS provides no public interface for one app to reposition another app's menu bar icon. Not through Accessibility, not through the window server, not through anything supported. Each item belongs to the app that created it.
The saved position exists, but writing it doesn't help
macOS does persist the order. Each status item's position is stored in the owning app's
preferences under a key named NSStatusItem Preferred Position. So in principle
another app could write into that app's preferences to change where its icon sits.
That does work — with a catch that makes it useless for this purpose. The value is only read when the item is created. Writing it changes nothing until that app next relaunches and rebuilds its status item. "Rearrange your menu bar, now quit and reopen all nineteen apps" is not a feature anybody wants.
So what about simulating the drag?
If ⌘-drag is the only mechanism, the natural next thought is to perform it programmatically —
synthesise the modifier key, the mouse-down, the movement, and the mouse-up. macOS has a public
API for posting input events (CGEvent), and Accessibility permission unlocks it.
We built exactly that, and tested it against a real menu bar. The result: the icon does not move. Not once, in any variant.
Advertisement
What we tested before concluding it's impossible
It would be easy to get this wrong and blame the platform for a bug in our own code, so each link in the chain was verified independently:
- Permission was granted. Accessibility was confirmed active for the running process, not just toggled on in Settings for some other copy of the app.
- Event posting genuinely worked. We posted a mouse-move to a specific coordinate and read the cursor position back. It moved exactly where asked — so the process could definitely post real, effective input events.
- The target coordinates were right. We logged the icon's actual position and size, and confirmed the click point landed inside the menu bar band, on the icon itself.
- The gesture was realistic. A genuine ⌘ keydown held for the duration; an explicit click state on the mouse-down; small initial "slop" movements to pass the drag threshold; roughly 25 interpolated movement events rather than one teleporting jump; a clean mouse-up. A single instant jump never starts a drag session, so that was ruled out early.
Every prerequisite checked out, and the icon still didn't move. The conclusion we drew: the window server requires genuine hardware input for this particular gesture and ignores synthetic events, regardless of permissions.
This is almost certainly deliberate. An API that let any app silently rearrange or remove other apps' menu bar icons would be an obvious abuse vector — an app could hide the icon of something you'd want to notice.
What this means when you're choosing a menu bar app
Once you know the constraint, the whole category makes more sense:
- Hiding is easy; reordering is not. Hiding is a layout trick — an app can make its own item very wide and push everything to its left off the edge of the screen. That needs no permissions and works reliably. Reordering is a different problem entirely.
- Apps that appear to reorder icons are usually redrawing them. The more advanced managers capture the screen, crop out each icon, and display their own copies in a panel they fully control. That's a legitimate approach and gives real per-icon control — but it needs Screen Recording permission, and what you're clicking is a picture of the icon rather than the icon itself.
- Be sceptical of a settings panel that promises drag-to-reorder without asking for Screen Recording. If it isn't redrawing your icons, it can't be moving them.
The practical workflow
In practice this isn't a burden, because arranging your menu bar is a one-time job:
- Decide which handful of icons you genuinely want visible at all times.
- ⌘-drag those to the right of your organizer's divider. Everything to the left gets hidden.
- Leave it. New apps will add icons over time, but you only touch it when something changes.
Barkeep is built around this reality rather than pretending otherwise. Its settings show a live mirror of your real menu bar, split into Hidden and Always visible, so you can see exactly what's where — and it tells you plainly that the ⌘-drag is yours to make. It needs no permission to hide icons at all.
Related: Why menu bar icons disappear behind the notch · Why menu bar apps ask for Accessibility · How to hide menu bar icons