Bartender alternatives on Mac: what settings transfer

Choosing a different menu bar manager for macOS is rarely a question of features. Every tool in this category collapses the right side of the bar and gives you a way back to what it hid. The question that actually decides whether a switch is worth doing is narrower: how much of the setup you already built has to be built again.

That setup is easy to underestimate, because most of it is invisible by design. Which apps are always visible is obvious from looking at the bar. Which apps you deliberately hid completely is not, because they are hidden. This article covers what an import can move for you, what it cannot, how the import behaves step by step, and the order to rebuild the rest in.

The cost of switching is the rebuild, not the download

Three parts of a menu bar setup carry different amounts of accumulated decision-making.

The classification is the biggest one by time invested. Going through every item in the bar and deciding whether it stays visible, hides behind the collapse, or disappears entirely is an hour of small judgements. It is also the part you cannot reconstruct from memory, because the items in the third group are, by definition, not on screen to remind you.

Shortcuts are quick to rebuild but easy to forget you had. The muscle memory outlives the setting, so the first week after a switch involves pressing a key combination that no longer does anything.

Conditional rules are the smallest in number and the largest in intent. A rule that surfaces the power item when the battery drops, or shows a microphone item only while a meeting app is in front, encodes a decision you made once and have not thought about since. Recreating it means first remembering that it existed.

Ask what an import covers before you install anything, not after. The answer changes how long the switch takes, and it is usually documented.

What an import carries across

Where a menu bar manager offers to read Bartender's settings, the piece that moves is the classification itself. Bartender's three groups, Show, Hide, and Always Hide, map onto the equivalent three zones in the new tool.

Two details define the shape of that mapping.

First, it works per application, identified by bundle ID. Every item currently in the menu bar that belongs to a given app receives the same zone. The granularity is the app, not the individual icon.

Second, it reads one profile: the one currently active in Bartender. If several profiles exist and get switched between during the day, the active one at the moment of import is what gets read.

That is the extent of the automatic part. Described in a sentence it sounds thin, but the classification is precisely the part that took the longest to decide, so having it arrive intact removes most of the friction. Everything else should be planned as manual work.

What it does not carry

Setting	Carried by import
Show, Hide, Always Hide classification	Yes, per application
Profiles other than the active one	No
Keyboard shortcuts	No
Conditional rules and triggers, such as battery level, time of day, or active app	No
Icon spacing and appearance settings	No
Per-icon split when one app shows several menu bar items	No, all of that app's items land in the same zone

The last row is the one that surprises people. If a single application puts two items in the bar, and one of them was always visible while the other was hidden, both arrive in the same zone after the import. Separating them again is a manual step, and it takes about ten seconds once you know to look for it.

Conditional rules and shortcuts generally exist in the destination tool as capabilities. What does not exist is your particular configuration of them. Treat that as a scheduled task rather than a surprise.

It is worth being precise about why the import stops where it does. Classification is a concept every tool in this category shares, so it has a well defined meaning on both sides of the move. Shortcuts, triggers, and spacing are implemented differently in each product, with different available conditions and different units. Translating them automatically would mean guessing at intent, and a guess that lands wrong in a menu bar is worse than an empty field, because it produces behavior you did not ask for and did not write down. An import that declares a narrow scope and holds to it is easier to verify than one that claims to move everything.

What the import looks like on screen

Knowing the sequence in advance prevents the middle of it from feeling like a failure.

A row offering to bring across Bartender's settings appears in the settings window. It appears only on a Mac where Bartender's settings are actually found. If the row is not there, that means nothing was found to read, not that the capability is missing.

Pressing the import reads the settings and reports how many items were sorted into zones. That number is the confirmation that something happened, and it is worth comparing against what you expected.

Then comes the part that matters most. Importing does not change the menu bar by itself. The arrangement is applied only when you then press to apply it to the menu bar. The two steps are deliberately separate so the result can be reviewed before it takes effect. If the bar looks unchanged after importing, the apply step is almost always what is missing.

Two edge cases behave sensibly. If nothing is currently hidden on the Bartender side, the import says so and changes nothing, so running it out of curiosity on an untidied menu bar does not scramble anything. And the tool's own menu bar icon is excluded from the import, so it does not end up hiding itself.

Before you switch, write three things down

Take a screenshot of the menu bar collapsed and a second one expanded. The expanded one is the important one, because it is the only record of what you normally keep out of sight.

Open the current settings and note which apps sit in which group, marking any application that shows more than one item in the bar. That list becomes your checklist after the import, and those marked apps are the ones needing a manual split.

Write out the shortcuts and the conditional rules. These do not transfer, so the note you make is the rebuild instructions. If multiple profiles are in use, capture the contents of the inactive ones too, since only the active profile is read.

While you are in there, one more pass pays for itself: find every item you have neither looked at nor clicked in the past week. Those belong turned off at the source, in each app's own preferences or in macOS Control Center settings, rather than hidden. Fewer items going in means a shorter import to verify.

The order to rebuild in

Check the reported count first, then apply the arrangement and look at the actual bar. Fix the apps that show multiple items, since those are the known manual corrections.

Then use it for a day or two without configuring anything else. Anything you find yourself hunting for gets promoted back to always visible. Resist building conditional rules during this window, because the boundary between visible and hidden is still moving, and rules built against a moving boundary get rebuilt.

Once the boundary settles, add shortcuts, and only the ones you actually reach for. Collapse, expand, and search are the common three. Add conditional rules last, and only where there is a concrete reason. A small number of rules you understand beats a large number you inherited from an older setup and no longer remember the purpose of.

A reasonable timeline for all of this is one evening plus two working days. The import and the manual corrections take minutes. The two days are for noticing what you actually reach for, which cannot be shortened by working harder at it. Anyone trying to finish the whole configuration in one sitting ends up with rules protecting a layout that changes the next morning.

Keep the previous tool installed but quit during this period, so returning to it is a matter of launching it. Running both at once is the one thing to avoid, since two tools arranging the same bar produce behavior neither of them documents.

Permissions, and why nothing appears to work

Most reports of a newly installed menu bar tool doing nothing come down to permissions. Rearranging or hiding items requires Accessibility permission in System Settings under Privacy & Security, and some implementations also use Screen Recording permission, because identifying what is in the bar means reading part of the screen.

Apple's own description of these grants is worth keeping in mind, summarized:

Some apps need permission before they can work with other apps' windows or control the system, and that permission is granted per app by the person using the Mac in Privacy & Security. It can also be withdrawn later. Source: support.apple.com

After installing, confirm the app is present and checked in both lists. When an app's contents are replaced by an update, the entry can persist while the grant no longer functions, in which case removing it and adding it back resolves it. Also remove the old tool's permissions once you have stopped using it, so it is clear which app is doing what.

What to compare between candidates

Feature counts are a poor comparison in this category, because the features overlap heavily. Three things differentiate daily use.

How a hidden item is reached is first. Expanding the bar and then clicking is one model. Pressing a hidden icon while the bar stays collapsed, so its menu opens in place, is another, and for an item touched several times an hour the difference adds up. A features page should state which model applies.

Import scope is second, and it is exactly what this article has described. Whether the scope is stated plainly is itself informative, and vendor FAQ pages are usually where it lives.

Cost structure is third, since one-time purchase, subscription, and paid major upgrades lead to very different totals over three years. That belongs on a pricing page. Note that pricing and platform support in this category change; the descriptions here reflect publicly available material as of September 2026, so confirm against the current page.

What to do first

Before installing an alternative, screenshot the expanded menu bar and write down your shortcuts and conditional rules, because those are the parts no import will bring with it. Then import, apply, and give the result two days before adding any rules on top. If you want to see how one tool documents its import scope and its collapsed-state behavior side by side, Koffret lays both out against the alternatives.