Switch from Bartender to another menu bar app cleanly
Moving from one menu bar manager to another is not like moving between text editors, where the files come with you and the only cost is learning new shortcuts. A menu bar setup is a pile of small decisions made over months. Which icons are visible, which are tucked away, which are hidden so completely that you forget they exist, plus the shortcuts and the conditions layered on top. None of that lives in a document you can copy. It lives in the app's own preferences, in the app's own format.
Some menu bar managers for macOS can read a Bartender configuration and take part of it over automatically. That helps, but only if you know in advance which part. The gap between what transfers and what does not is where people get the impression that a switch went wrong.
What actually carries over
The part that transfers is the classification. Bartender sorts every menu bar item into three groups: shown, hidden, and always hidden. Those three groups are the substance of the setup, because they encode the decision you made about each icon. A manager that imports a Bartender configuration maps those three groups onto its own three zones, one for one.
This is more valuable than it sounds. If you have twenty five icons, the classification represents twenty five separate judgements about how often you press each one. Re-entering them by hand is not difficult, but it is tedious, and it is the step where people give up halfway and end up with a half sorted bar.
What transfers, precisely:
- The three groups themselves. Shown, hidden, and always hidden are matched to the equivalent three zones in the new tool.
- The matching is done per app, identified by the app's bundle identifier.
- One profile is read: the Bartender profile that is currently active.
That is the whole list. Everything else in the next section has to be set up again.
It is worth being clear about why the classification is the part that can travel while the rest cannot. The three groups are a plain statement about each app: show this, tuck this away, bury this. That statement means the same thing in any tool built around the same idea of a visible zone and a hidden zone, so it can be translated without loss. A keyboard shortcut, by contrast, is bound to a specific tool's own commands, and a condition refers to that tool's own rule system. There is no neutral form for either of them to be converted into. This is not a limitation anyone chose. It is what happens when two separate apps hold their settings in their own formats and only one concept genuinely overlaps.
What does not carry over
The following are not read, and planning around that in advance is the difference between a smooth switch and a confusing one.
Profiles other than the active one. If you keep several Bartender profiles and swap between them for different situations, only the one currently in use is read. The others do not come across. Before importing, it is worth switching Bartender to whichever profile you consider your main one, so that the profile being read is the one you actually want.
Keyboard shortcuts. Whatever key combination you used to reveal hidden icons has to be set again in the new tool.
Conditions and triggers. Rules that show or hide items based on battery level, time of day, or which app is in front are not imported. If your setup leaned on these, this is the largest piece of manual work.
Spacing and appearance settings. Adjustments to the gap between icons and similar visual tweaks are not carried over.
Per icon splitting within one app. When a single app puts more than one icon in the menu bar, the import cannot send those icons to different zones. The matching is per app, so every icon belonging to that app lands in the same zone.
That last one catches people out, because it is invisible until it happens. If you had deliberately shown one icon from an app and hidden another from the same app, that distinction is lost, and both end up together. It is quick to fix afterwards, but only if you are watching for it.
Why matching per app matters more than it looks
Bundle identifier matching means the import works on the app, not on the individual status item. When the import runs, every item currently in the menu bar that belongs to a given app receives that app's zone.
The practical consequence is that the import result depends on what is running at the moment you import. An app that is installed but not currently running has no item in the menu bar, so there is nothing to assign. Launching everything you normally keep running before importing gives a more complete result than importing on a freshly booted Mac with three apps open.
It also means the import is not destructive to apps it does not know about. An app that appeared after your last Bartender session simply is not in the configuration, so it stays wherever the new tool's default puts it, and you place it by hand.
There is a small preparation step that follows from this. Spend two minutes before importing making sure the Mac is in its ordinary working state rather than a freshly restarted one. Open the mail client, the chat app, the backup tool, the VPN client, whatever normally sits in the bar during a working day. Items that are present get sorted. Items that are absent get nothing, and you will notice them a week later when one of them turns up in the wrong place and you have forgotten why.
The same logic applies in reverse to apps you have stopped using. If an app is still listed in the Bartender configuration but no longer runs, it contributes nothing to the import and no longer needs a decision. A switch is a reasonable moment to uninstall those rather than carry them forward.
The import is two steps, not one
This is worth stating plainly, because the halfway state looks like a failure.
A tool that supports this shows a row in its settings for taking over a Bartender configuration. On a Mac where no Bartender configuration can be found, that row does not appear at all, which is itself a useful signal: if you cannot see the option, there is nothing to import from.
Pressing the import control reads the configuration and reports how many items were sorted. At that point nothing on screen has changed. The menu bar looks exactly as it did a second ago. The assignments have been recorded, but not applied.
Applying them is a second, separate action. Only after that does the menu bar rearrange itself to match.
Two edge cases are worth knowing. If Bartender is not hiding a single icon, the import says so and changes nothing, since there is no classification to take over. And the new tool's own menu bar icon is excluded from the process, so it will not accidentally hide itself.
A checklist of what to redo
| Setting | Comes across | Where to rebuild it |
|---|---|---|
| Shown, hidden, always hidden groups | Yes | Nothing to do |
| Non active profiles | No | Switch to the profile you want before importing |
| Keyboard shortcut to reveal | No | The new tool's shortcut settings |
| Conditions and triggers | No | The new tool's rules, from scratch |
| Icon spacing and appearance | No | The new tool's appearance settings |
| Two icons from one app, split apart | No | Move the second icon by hand after applying |
Reading that table in advance turns a switch from an open ended tidying session into about fifteen minutes of known work.
The rows split cleanly into two kinds. The first row is the one that carries the weight of your past decisions, and it is handled for you. Everything below it is configuration you can rewrite from memory in a few minutes, because it is short, and because you set it up once and have not thought about it since. Treating the table as a to do list, top to bottom, keeps the work in the right order: let the import do the tedious part, then handle the small pieces deliberately rather than discovering them one at a time over the following month.
Rebuilding conditions and shortcuts
Conditions are the piece most worth thinking about rather than copying. A rule written a year ago for a situation that no longer applies is not worth reconstructing faithfully.
The reliable approach is to import first, apply, then use the bar for a few days with no conditions at all. Most people find that two or three of their old rules were solving a problem that the basic three zone split already handles. The ones that survive that test are the rules actually worth writing again. A tool of this kind will have its own way of expressing conditions and its own shortcut settings, and the feature list is the place to check which of your old rules have an equivalent before you start rebuilding.
Shortcuts are simpler. Set one key combination to reveal the hidden group, use it for a week, and add more only if you find yourself wanting them. A single reveal shortcut covers most of what people used several shortcuts for previously.
Before you uninstall anything
Keep Bartender installed until the new setup has survived a normal working week, including a restart and at least one app update. There is no benefit to removing it early, and having it there means you can look up how something used to be classified rather than trying to remember.
Do not run both as active managers at the same time for longer than the transition needs. Two tools both trying to arrange the same status items will fight, and the result looks like either one of them is broken. Import, apply, then turn the old one off.
A restart is the specific event worth waiting for. Menu bar arrangements look correct immediately after they are applied, because everything that was running is still running. The first cold boot is when apps register their icons in a different order and any gap in the setup becomes visible. Judging a switch before that has happened tends to produce either false confidence or a false alarm.
An app update during the same week is the second useful test, for the same reason. When an app is replaced rather than patched, it registers a fresh status item, and how the new tool handles that tells you more about living with it than any amount of configuration on day one does.
It is also worth checking cost and macOS support before committing, since those two facts decide more switches than any feature does. The comparison page lays out how the available tools differ on price, on licence type, and on which versions of macOS they run on.
What to do first
Open Bartender, confirm the profile in use is the one you want to keep, and launch every app you normally keep running. Then import, check the reported count, and apply. Rebuild the reveal shortcut, leave the conditions alone for a week, and only then decide which of them you actually missed. Koffret is one of the tools that reads a Bartender configuration this way.
Frequently asked questions
Will all of my Bartender settings transfer?
No. The three groups, shown, hidden, and always hidden, are read from the currently active profile and mapped across. Keyboard shortcuts, conditions and triggers, spacing and appearance settings, and any other profiles are not read. Plan to set those up again by hand.
I use several Bartender profiles. What happens to them?
Only the profile that is active at the time of the import is read. The others are not carried over. Switch Bartender to the profile you consider your main setup before importing, so the one being read is the one you want.
Why did nothing change after I imported?
The import and the application are two separate steps. Importing reads the configuration and reports how many items were sorted, but leaves the menu bar untouched. A second action applies the result to the actual menu bar. If the bar still looks the same after applying, check whether Bartender was hiding any icons at all, since an empty classification produces no change.
Can I keep Bartender installed during the switch?
Yes, and it is sensible to do so until the new arrangement has survived a normal week of work. What is worth avoiding is leaving both running as active managers for long, since two tools arranging the same status items at once will conflict. Import, apply, then switch the old one off.