Itsycal: how to uninstall it cleanly

Removing Itsycal takes about two minutes. The reason people search for the procedure anyway is that the interesting part is not the removal, it is everything around it: the menu bar clock that disappears afterwards, the settings file nobody can find, and the question of whether a background app that has been running for two years left something in a system folder.

It did not. Itsycal is one of the rare menu bar utilities where dragging the app to the Trash really is the whole job, and knowing why that is true is what makes the rest of the cleanup quick. What follows is the removal sequence, the two files that survive it, the Homebrew route for anyone who installed it that way, and the macOS settings that stay changed after the app is gone. Everything below was checked against the vendor's published pages and the Homebrew cask definition on 25 September 2026.

Why this one is a simple removal

Menu bar apps fall into two groups, and the group decides how hard removal is.

The difficult group does something macOS does not hand to an ordinary sandboxed app: capping battery charge, rewriting network routes, watching the whole disk, mounting remote volumes. Those installers ask for an administrator password, because they place a privileged helper in a system location and register it to start on boot. Delete the visible app and the invisible half stays, still running, with nothing left on the machine to explain what it is doing.

Itsycal is in the easy group. It draws a calendar in the menu bar and, according to the vendor's documentation, displays events from calendars already set up in the Mac Calendar app. It owns no data of its own and needs no privileged access to read what the Calendar app already has. The two third party components named on the vendor's own page, Sparkle for self updating and MASShortcut for the global keyboard shortcut, are both bundled inside the application, not installed beside it.

There is a quick way to work out which group any menu bar app belongs to, before committing to a removal method. Two signals do most of the work. Did the installer ask for an administrator password, either during setup or the first time a feature was switched on? And does the app appear in System Settings under Login Items as a background item that is allowed to run, separately from the list of apps that open at login? An app that triggers neither of those almost certainly lives entirely inside its own bundle, which means the Finder is sufficient to remove it. An app that triggers either one has placed something outside the bundle, and the vendor's own removal instructions are worth finding before anything gets dragged anywhere.

The Homebrew cask definition is the cleanest evidence of this for Itsycal. The only uninstall instruction registered for the cask is to quit the process with the identifier com.mowglii.ItsycalApp. There is no package receipt to forget, no launch daemon to unload, and no helper to remove. For completeness on compatibility: the app targets macOS 11 and later, and since version 0.13.0 it has shipped as a Universal binary that runs natively on both Intel and Apple silicon Macs.

Two things to settle first

Decide what happens to the clock. The vendor's feature list includes a configurable system clock replacement, which is why a fair number of Itsycal users have the macOS clock switched off. In that configuration, deleting Itsycal does not just remove a calendar, it removes the only time display in the menu bar. Turn the macOS clock back on in System Settings under Control Center before the app goes, and the gap never appears. Doing it afterwards works too, but it is easier to find the setting while there is still something to compare against.

Nothing needs to be exported. This one is worth stating plainly because it is the most common hesitation. Itsycal is a window onto the Calendar app, not a store. Events created through the Itsycal popover were written to whichever calendar was set as the destination, and they stay there after the app is deleted. There is no database to back up and no export step to perform.

There is also no billing to unwind. Itsycal is published free of charge, so there is no licence to deactivate before removal and no subscription that keeps renewing after it. For paid menu bar utilities those two steps matter, because a licence left active occupies an activation slot and billing sits with a payment processor rather than with the copy on the Mac. Neither applies here.

The removal sequence

Four steps, in this order.

1. Quit the app. Click the Itsycal item in the menu bar, then use the small gear button below the calendar to open its menu and quit. This matters more than it looks: the app has no window, so it is easy to assume it is closed when it is still resident.
2. Open the Applications folder. In the Finder sidebar, click Applications.
3. Drag Itsycal to the Trash. This is the procedure Apple documents for any app installed from the internet rather than from the App Store, in the case where the app has no dedicated uninstaller.
4. Empty the Trash. Apple's guidance is explicit that the app is only permanently removed from the Mac at the point the Trash is emptied, whether that happens manually or automatically.

One detail that catches people mid sequence: if Itsycal was set to open at login, quitting it in step one does not change that setting, and neither does moving the app to the Trash. The login entry is a separate record kept by macOS, which is why the fourth item in the settings pass further down exists. Removing the app first and clearing the entry afterwards is fine, in that order. Clearing the entry first and then forgetting to finish the removal is the version that leaves a half tidied machine.

If the Finder objects that the app is in use, the app is still running. Check that the menu bar item is gone. If the message persists, restart the Mac and repeat step three, which is also what Apple's page suggests for this case.

The full Apple instruction, including the Trash warning, is on the macOS user guide page for installing and uninstalling apps.

What stays behind, and whether to delete it

Two files remain in the user Library after the app itself is gone. They are not a secret: the Homebrew cask registers exactly these two paths as the ones a full cleanup should trash.

Path	What it holds
~/Library/Preferences/com.mowglii.ItsycalApp.plist	Settings: first day of week, which calendars are tracked, font size, number of months shown, the assigned keyboard shortcut
~/Library/HTTPStorages/com.mowglii.ItsycalApp	Working data left by the self update framework when it checked for new versions

Both are small. Leaving them in place costs nothing measurable in disk space, and there is a reason to keep them: reinstalling later with the preferences file intact brings back the calendar selection, the week start, and the shortcut without any setup. Anyone who thinks they might come back should skip this step entirely.

For a full reset, delete both paths and nothing else. The temptation to open ~/Library/Preferences and sweep out anything that looks related is where this goes wrong, because bundle identifiers share prefixes and the neighbouring file often belongs to a different app that will silently lose its settings. Match the identifier exactly.

If it was installed with Homebrew

Installing through a package manager and then removing through the Finder leaves the install record behind and makes the next audit disagree with reality. Use the same route in both directions.

brew uninstall --cask itsycal          # removes /Applications/Itsycal.app
brew uninstall --zap --cask itsycal    # also trashes the two paths above

The zap variant is what clears the preferences file and the update framework's working folder, because those are the paths the cask author registered for that purpose. The cask token is itsycal, the app installs to /Applications/Itsycal.app, and the version currently recorded in the definition is 0.15.14. A machine running an older build can be removed without updating first, since the version has no bearing on the removal steps. The definition itself is published at formulae.brew.sh.

macOS settings that do not revert on their own

Deleting an app never undoes the system settings that were changed to accommodate it. Four places are worth one pass each, immediately, while the reason for each change is still obvious.

Control Center, for the clock. Covered above. If the menu bar has no time display after the removal, this is why.

Login Items. System Settings, General, Login Items. A stale entry for a deleted app sometimes remains in that list. Select the row and remove it.

Privacy and Security, Calendars. Itsycal asked for access to Calendar data, so it appears in that list. After removal, check whether the entry is still listed and clear it if it is. This list records which apps requested access, so it is worth reading through rather than assuming it is current.

The keyboard shortcut. Whatever combination was assigned to open Itsycal is released along with the app. If that combination is wanted elsewhere, reassign it now rather than discovering the conflict later.

None of these four are dangerous to skip. They are the difference between a machine that looks deliberately configured and one that accumulates entries nobody can account for six months later, which is the state that makes the next round of troubleshooting slower than it needs to be.

If the real problem is a crowded menu bar

Sometimes the app being removed is not the app causing the annoyance. If the calendar itself was working fine and the actual complaint is that the menu bar has too many items to scan, deleting a small calendar reclaims one slot out of a dozen and changes very little.

Itsycal's own appearance settings can narrow what it displays, down to a date with no extra text. That reduces width. It does not reduce count, and a row with ten background apps in it is still a row with ten background apps in it after one of them gets thinner.

The other approach is to collapse the row rather than shorten its contents. A menu bar organizer keeps every icon installed and reachable while hiding most of them from view until they are needed. The behaviour that decides whether this works is what happens in the collapsed state: a tool that can open a hidden item's menu in place, without expanding the whole row first, lets a calendar stay hidden and still be readable on demand. One that only reveals icons turns every glance into two clicks. That distinction is set out on the Features page, and the way the options in this category differ from one another is on the How it compares page.

What to change first

Turn the macOS clock back on before deleting anything, then quit Itsycal, drag it to the Trash, and leave the preferences file alone unless a full reset is the goal. Once the row is one item shorter, spend the next ten minutes on the remaining icons instead of letting the next installer claim the free slot, and Koffret is one way to collapse what is left.