One Switch not working on Mac: what to check

"One Switch is not working" covers at least three unrelated faults, and they are fixed in different places. Reinstalling is the usual first reflex and it is usually the wrong one, because permissions and login registrations survive a reinstall. The same symptom comes back, and now the preferences have to be rebuilt as well.

Sorting the symptom into the right bucket takes under a minute and saves most of the work.

Sort the symptom first

Three buckets cover almost everything.

The icon is missing from the menu bar entirely. This is a display problem, and it can happen while the app is running normally.

The icon is there, but clicking a toggle does nothing, or only some toggles fail. This is almost always a permission problem.

The app does not appear after a restart, or has to be launched by hand every time. This is a login item problem.

Each bucket has its own checks. Running them in order matters, because the second check is meaningless if the first one has not confirmed the app is actually running.

Confirm it is running before anything else

Open Activity Monitor and filter by the app name. Present in the process list means it is running and any missing icon is a display issue. Absent means it never started, and the next place to look is System Settings, General, Login Items.

That pane lists both apps that launch at login and background items that apps register. Entries here get disabled or dropped after system updates and after an app is replaced with a different build. A registration that is present but switched off can be turned back on in place.

If the process is running and the icon is still nowhere, skip the permissions section for now. The next section is the one that applies.

A missing icon is often just missing width

Menu bar items are laid out from the right edge leftward, and the row has a hard limit. On a MacBook with a notch, items that would fall under the cutout are not drawn at all. On screen this is indistinguishable from a crashed app.

Testing it is simple. Quit one or two other menu bar apps, or open Control Center settings and hide a few entries such as Bluetooth, Sound, or Focus, and watch whether the missing icon reappears in the freed space. Available width also changes when an external display is connected or when resolution changes, which is why an icon can be visible at a desk and gone on the road with the same software installed.

If width was the cause, the fix is arrangement rather than repair. Reduce what macOS itself puts in the row, then reduce what the app puts there: its preferences allow choosing which toggles appear and disabling the ones that are not used.

When only some toggles fail, look at three permission panes

Toggles that click but produce no result are nearly always a Privacy and Security problem. Three panes account for most cases.

Automation, which governs one app instructing another. Toggles that ask Finder or System Events to do something depend on this, and when it is missing there is often no error at all.

Accessibility, which governs an app driving the interface of others.

Bluetooth, which governs connecting to nearby devices. AirPods connection depends on this one.

The shared trait is silence. A missing grant frequently produces no dialog and no error, just a click that changes nothing. If the app is listed in the pane with the switch off, turn it on. If it is listed and already on but still does nothing, toggle it off and back on, which rewrites the stored grant.

Grants get lost in predictable circumstances: a major macOS upgrade, an uninstall and reinstall, and swapping one build of the app for another obtained from a different source. That last case gets missed. A copy installed directly from the vendor and a copy installed through Setapp are separate files as far as macOS is concerned, so grants given to one do not automatically apply to the other. If both have been installed at some point, Activity Monitor will show which one is actually running. Apple documents where these panes live and what each one controls at Apple Support.

Each toggle fails for its own reason

For the "only some toggles" case, the specific toggle narrows the cause considerably.

Hiding desktop icons does nothing. This instructs Finder, so Automation is the pane to check. Relaunching Finder sometimes restores the display on its own.

Hidden files will not toggle. Also Finder. Press Command Shift Period in a Finder window first: if that works and the app's toggle does not, the fault is between the app and Finder rather than in macOS.

AirPods will not connect. Beyond the Bluetooth grant, check the charge level and whether another device has claimed the connection.

Keep Awake is on but the display still sleeps. Another app or a power setting may be taking precedence. Check the sleep timings in System Settings power options.

Do Not Disturb switches itself back off. macOS Focus modes can carry time or location conditions, and those conditions win. Look at the schedules attached to the Focus in System Settings.

Resolution options are missing or revert. Available modes depend on the connection type and cable bandwidth for external displays.

The pattern across all of these is the same. Behind every toggle there is a macOS setting, and the app is only pressing it. Performing the same change by hand in macOS shows immediately which layer has failed. If the change cannot be made by hand either, the fault is not in the app.

The stated system requirement is inconsistent

System requirements are worth confirming before spending time on permissions. The vendor FAQ states that One Switch works on macOS Monterey, version 12, or higher. The Setapp listing agrees at macOS 12.0 or later.

One Switch works on macOS Monterey (12) or higher. Source: fireball.studio

The download panel further down that same product page states macOS Big Sur, version 11, or higher. As checked on 10 September 2026, those two statements on one page disagree. Anyone running macOS 11 and seeing partial failures may be looking at a support boundary rather than a configuration fault. For reference, the macOS version Apple currently promotes is 27, so the supported range spans a great deal of change in how the system handles menu bar items and permissions.

Faults caused by an unsupported version do not respond to permission resets. Checking the version number first avoids a long detour.

Keep a four line record

Diagnosis goes in circles when there is no note of what has already been ruled out. Four lines are enough: the macOS version, the app version, the name of the toggle that fails, and the checks already performed with their results.

The macOS version comes from the Apple menu, About This Mac. The app version comes from the information item in its own menu. Those two go at the top because every later judgement depends on them, including whether the version conflict described above applies at all.

The value of the record shows up twice. It becomes the body of a support message with no extra writing, and it survives until the next major macOS update, when permission behaviour changes and a similar symptom is likely to return. Starting that second round from a record rather than from scratch is the difference between ten minutes and an afternoon.

It also makes the decision about reinstalling a real decision rather than a guess. With the checks written down, it is possible to see whether a reinstall could plausibly change any of them, and in most cases the answer is visibly no.

When the answer is that it will not be fixed

Some faults are boundaries rather than bugs. Running an unsupported macOS version is one. A toggle that depends on a system feature Apple has changed is another, and a system setting that an employer manages centrally is a third: on a managed Mac, a permission pane can be locked so that a grant cannot be given at all.

Recognising a boundary early is worth as much as fixing a fault, because the response is different. There is nothing to repair, so the options are to change the environment, to reach the setting a different way, or to accept that this particular toggle is not available on this particular machine.

For a bundle of toggles this is rarely fatal, since every toggle wraps a setting that macOS still exposes elsewhere. If one path is closed, the underlying setting is generally still reachable through Control Center, System Settings, or a keyboard shortcut. Losing the shortcut is an inconvenience rather than a loss of capability, and framing it that way stops a small fault from consuming an evening.

Trial expiry and activation

Timing can masquerade as a fault. The vendor states a 7 day trial with no prepayment. If toggles stopped working roughly a week after installation, expiry is the first thing to rule out, ahead of any permission work.

After purchase, the vendor FAQ describes sending an activation code by email. A code that never arrives is usually a spam filter or a typo in the address given at checkout, and a code that will not validate is usually the wrong code rather than a broken licence. The same FAQ states that updates are free and the licence is lifetime, so upgrading the app does not invalidate an existing activation.

There is one more timing case worth ruling out. An app obtained through a subscription stops working when that subscription lapses, and the failure looks like a licensing bug rather than a billing event. If the copy in use came from Setapp, confirming that the membership is current takes less time than any permission check and explains a sudden total failure cleanly. Confirming which copy is actually running comes first, since having installed both a direct build and a subscription build at different times is common and only one of them is in the process list.

Three support routes are published: in app feedback, the developer's account on X, and a dedicated space on Reddit. Sending a report that lists the macOS version, the app version, which toggle fails, and which checks were already run turns a long exchange into a short one.

What to change first

Note the macOS version and the app version, then work through the order above: running, width, permissions, version, licence. If the width test is what fixed it, the row was the real problem and the next step is arranging it deliberately rather than by accident, which is what Koffret is for. Permissions behave the same way for any menu bar tool, and the FAQ covers which grants get requested and when they need renewing.

Frequently asked questions

Will reinstalling fix it?

Sometimes, but often not. Permission grants and login item registrations persist across a reinstall, so if either is the cause the symptom returns unchanged and the preferences have to be rebuilt for nothing. Checking whether the app is running, whether the row has width, and whether the grants are intact takes less time and identifies the cause.

The icon is gone but the toggles still work. What happened?

The app is running and only the icon is not being drawn. Menu bar items fill from the right edge and stop when space runs out, and on a notched MacBook the overflow is simply not rendered. Quitting another menu bar app or hiding a Control Center item confirms it within seconds.

Why do only some toggles fail?

Different toggles need different permissions. Anything that instructs Finder or System Events depends on Automation, and anything that connects a device depends on Bluetooth. A click that registers but changes nothing is the signature of a missing grant, since these usually fail without any error message.

Which macOS versions are supported?

The vendor FAQ and the Setapp listing both say macOS Monterey, version 12, or later. The download panel on the same vendor page says Big Sur, version 11, or later, and as of 10 September 2026 those two statements conflict. On macOS 11, unexplained partial failures may be a support boundary rather than something fixable in settings.

Back to all posts