Dozer not working on Mac: what to check

Not working covers several unrelated situations here, and the fixes have nothing in common. Blocked before the disk image opens is a different problem from installed but never launching, which is different again from launching fine but not surviving a restart.

Reinstalling is the usual first move and it resolves almost none of these, because three of the five common failures come from the state of the distribution rather than anything on the local machine. Sorting the symptom first takes a minute and saves the loop.

Five symptoms, sorted

Name the situation before touching anything:

• A warning appears when the downloaded file is opened, and it goes no further.
• The documented install command runs and nothing gets installed.
• The app is in Applications but nothing appears in the menu bar.
• Checking for updates reports that the current version is the latest one, indefinitely.
• Everything works until the Mac restarts, after which the app is gone.

The first two happen before installation, so no in-app setting affects them. The third depends on the Mac's processor family. The fourth is a distribution side condition with no local remedy. Only the fifth lives in System Settings.

The warning when opening the download

A dialog saying the developer cannot be verified, or that macOS cannot check the file for malicious software, is not a corrupted download. It is Gatekeeper evaluating the signature state of what was downloaded.

Apple states the requirement directly in its support documentation:

By default, macOS Catalina and later also requires software to be notarized, so you can be confident that the software you run on your Mac doesn't contain known malware.

Source: support.apple.com

The 4.2.0 disk image, current as of 10 September 2026, is signed with an Apple Developer ID certificate but distributed without notarization. Assessing the file locally confirms both halves of that: the signing identity is recognised, and the assessment is refused specifically on notarization grounds. The warning is the system behaving as designed.

Whether to proceed is a judgement call. Apple documents the override procedure and, in the same article, what running unnotarized software means. Two things worth knowing before searching further. First, the exact wording differs between macOS releases even though the underlying reason does not, which is why searching the message text tends to lead nowhere useful. Second, downloading again changes nothing, because the file is identical each time. Seeking out an alternative download source to dodge the warning makes matters worse rather than better, since a copy from anywhere other than the official release page may not carry the original signature at all.

On a Mac managed by an employer, this often ends the discussion. Policy commonly blocks unnotarized applications outright, and no local override applies. The next step there is a conversation with whoever administers the fleet, not another attempt at the same dialog.

It is worth separating two things that get conflated in this situation. Signing and notarization are different checks. Signing establishes which developer account produced the build and confirms it has not been altered since. Notarization is an additional pass in which Apple scans the build and issues a ticket. This app clears the first check and not the second, which is why the signing identity resolves cleanly while the assessment still fails. A build that failed the first check would be a different and more serious situation.

The practical consequence is that the warning will not go away on its own with a future macOS update. It is tied to how the file was published in 2020, and only a new release from the author would change it.

When the install command does nothing

The project README documents a package manager one liner. As of 10 September 2026, that package manager's index no longer contains an entry for this app. Querying it by name locally returns no match, and the index page linked from the README returns a not found error.

So the command failing is not a typing error and not a broken package manager. The README and the current index disagree, and the local machine cannot reconcile them. The only working route is the manual disk image download from the releases page, which then leads directly into the warning described above.

This matters most for anyone reinstalling to fix something else. A route that worked previously no longer does, so repeating it produces the same result every time.

Installed, but nothing appears in the menu bar

Release 4.2.0 is an Intel only binary, so an Apple silicon Mac runs it through the macOS translation layer. If that layer is not yet present, the first launch prompts to install it, which requires an internet connection. Once installed, the app starts normally.

If no prompt appears and nothing at all happens, the translation layer is not the issue and the app is most likely still blocked by Gatekeeper. This is easy to misread because the app is built without a Dock icon, so a successful launch produces no visible confirmation other than black dots appearing near the right edge of the menu bar.

Checking the processor family and the app's build type takes seconds: select the app in the Finder, open the info window, and read the Kind field. Apple documents the possible values on the Apple support site.

Update checks that never find anything

Preferences include an automatic update check, and the right click menu offers a manual one. Both can report that the installed version is current, permanently.

The cause is on the distribution side. The update feed the app consults still lists 4.0.0, published in August 2019, as the newest version. The newest release actually available for download is 4.2.0 from July 2020. The feed is behind the release page, so a check performed against it cannot surface anything newer.

No local setting changes this. To find out whether a newer build exists, read the releases page directly. The installed version number is shown in the menu that opens on right click, which makes the comparison quick.

Present at login, gone after a restart

Launch at login is enabled in preferences, the app runs all day, and after a restart it is absent. The checkbox is usually not the problem.

Applications of this type register a small helper bundled inside the app with macOS, and that registration is what starts the app at login. On macOS Ventura and later, those registrations are listed in System Settings under General, in Login Items, with a separate toggle controlling background execution. If that toggle is off, the app's own checkbox stays ticked and nothing starts.

• Open System Settings and go to General, then Login Items.
• Look through the list of items allowed to run in the background.
• Entries are frequently listed under the developer's name rather than the app's, so widen the search if the app name is not there.
• Re-enable the toggle, restart, and confirm.

If no entry exists at all, registration failed rather than being disabled. Turning the preference off, then on again, often re-registers it, and a restart confirms whether it held.

One detail makes this harder to diagnose than it should be. The helper carries its own bundle identifier, distinct from the main app, so the entry in that list may not read the way the app does in the Applications folder. Scanning for anything unfamiliar rather than searching for an exact name is the faster approach.

When the dots are missing or the bar folds by itself

With the app confirmed running, missing dots usually mean the preference that hides them is enabled. That setting removes the click target deliberately, leaving the registered keyboard shortcut as the way back. If the shortcut has been forgotten, opening the app from the Finder restores everything to visible.

Determining whether the app is running at all is worth doing before anything else, since there is no Dock icon to check. Filter by name in Activity Monitor: present means running, absent sends the investigation back to the three sections above.

Folding away mid task points at the auto collapse delay, which offers 3 through 30 seconds and defaults to 10. The timer restarts on any menu bar interaction, so collapsing during a genuine pause is expected behaviour rather than a fault. Lengthening the value one step at a time settles it.

After a major macOS release

A tool that worked yesterday and stopped the day an OS update landed is a recognisable pattern for anything that manipulates menu bar ordering directly. Three checks cover most of it: confirm the icon order is unchanged by reading the bar right to left, confirm the login item registration survived the update, and confirm the dots are drawn at all.

If none of those restore it, the problem is in the app and there is nothing further to do locally. Given that the newest release dates from July 2020, waiting for a fix is not a plan. At that point the decision is whether to keep it or replace it.

There is a middle option for anyone not ready to decide. Many apps that place an icon in the menu bar have a setting to stop doing so, buried in their own preferences. Turning that off for two or three of the least useful ones reduces the count directly, without any organiser involved. It is cruder than a proper arrangement, since those icons then become unreachable rather than collapsed, but it makes a broken organiser tolerable for as long as the decision stays open.

The other thing worth doing before deciding is writing down the current left to right order of the menu bar. That order represents real work, it is not stored anywhere retrievable, and it is the piece most likely to be lost during a reinstall or a switch. A screenshot of the menu bar takes a second and answers the question later.

Where each symptom actually lives

Symptom	What to examine	Fixable locally
Warning on opening the download	Signature and notarization state	Only by choosing to override
Install command does nothing	Package manager index	No, switch to manual download
Nothing appears after install	Translation layer, then Gatekeeper	Yes
Updates never found	The update feed	No, read the releases page
Gone after restart	System Settings, Login Items	Yes
Folds away unprompted	Auto collapse delay	Yes

Three of those six sit on the distribution side, which explains why repeated reinstalls produce identical results.

What to change first

Work top to bottom in the table and stop at the first row that matches, rather than reinstalling and hoping. If the row that matches is one of the three that cannot be fixed locally, the question has already shifted from repair to replacement, and the useful criteria are whether a tool is still being updated, whether its documented install steps actually work, and how hidden icons get reached once collapsed. The comparison page covers how the options in this category differ on those points, and Koffret can be tried against the same menu bar to see whether the arrangement holds.