Why a menu bar app should not need the internet

A menu bar app is a helper that lives in the strip at the top of the screen, near the clock. It is meant to be there all day, quietly, doing one job well: a clipboard tool, a window manager, a shelf for files. Because it is always running, it is worth asking what such an app is doing with your network. For most of them, the honest answer is that they could do their entire job without ever touching it. When a background helper insists on the internet, that is usually a sign of something other than the task in front of you.

What a menu bar app is actually for

The whole appeal of a menu bar app is that it is close at hand and out of the way. It does not take up the Dock, it does not need a window, and it responds to a click or a shortcut. The jobs that suit this shape are local by nature. Managing windows, holding clipboard history, tweaking a system setting, moving files, none of these are network tasks. They are things that happen entirely on the machine, to the machine.

That is why it is reasonable to expect a menu bar app to run offline. Its job is defined by what is already on your Mac. If the app is doing what it says on the label, the network is not part of the loop. The exceptions are apps whose purpose is inherently online, a weather readout, a mail checker, a server monitor, and those are honest about needing a connection because it is the point. The suspicious case is the helper with a local-sounding job that still wants the internet.

What a helper might reach out for

When a background app does talk to the network without an obvious reason, it is usually for one of a few things, and it is worth being able to name them.

There are update checks, which are legitimate but do not need to be constant, and can be done on demand. There is licence validation, which some paid apps run against a server, sometimes more often than necessary. There is analytics: a stream of data describing what you clicked, how long you used the app, and which features you touched, gathered under a label like “anonymous usage”. And there is sync, which copies settings or data to a server so it can appear on another device.

Some of these are reasonable if you opt into them. The problem is when they are on by default, bundled into an app whose actual job is local, and running in the background of something you expected to be self-contained. A window manager does not need to phone home to move a window. If it is doing so, that traffic is about the company’s interests, not yours.

The cost of an always-on connection

A menu bar app runs for as long as your Mac is awake, which makes its network behaviour different from an app you open and close. Whatever it does, it does all day.

If it phones home, it does so continuously, in the background, whether or not you are using it. That is a steady trickle of data about your machine leaving without a moment where you chose to send it. It is also a dependency: an app that expects a connection can stall, show errors, or behave oddly when the network is poor, for a task that never needed the network to begin with. And it widens the surface of things that can go wrong, from a server outage that breaks a local feature to a privacy boundary that quietly moves. For a helper meant to be invisible and reliable, every one of those is a reason to keep the network out of it.

When offline is a design choice, not a limitation

An app can be offline because it happens not to use the network much, or because it was built so the network is not available to it at all. The second is stronger, and it is the version worth looking for.

If a menu bar app has no account, there is nothing to log in to and no profile syncing in the background. If it has no cloud step, your data stays on the Mac by construction, not by policy. And if the release build is blocked from shipping when the binary links a networking library, then “runs offline” is a property you can check rather than a claim you have to trust. That last point matters more than it sounds, because it means a future update cannot quietly add a connection without failing its own build. The guarantee is baked into how the app is made.

A shelf that never leaves the Mac

Ledge is a menu bar app built this way. It turns the MacBook notch into a shelf: you drag a file, folder, image, or link up to the notch, it lands there, and you drag it off to wherever it belongs. When it hands the item over, each destination gets the version it can use, the path as text to a terminal, the file itself to Finder, an upload to a chat app. All of it happens on the machine.

It opens with a keyboard shortcut or a click on the notch, and it lives in the menu bar with no Dock icon. The global shortcut needs no special permission, because it uses a Carbon hotkey rather than an event tap. The one system permission it ever asks for, Accessibility, is requested only the first time you auto-paste a path into a terminal, never at launch. There is no account and no cloud, the release build is blocked from shipping if the binary so much as links a networking symbol, and it is signed with a Developer ID and notarized by Apple. It runs on macOS 14 or later, and on a Mac without a notch the shelf sits at the top centre of the screen.

None of this makes the shelf better at holding a file. What it does is match the app’s behaviour to its shape. A helper that lives at the top of your screen all day, doing a local job, has no reason to need the internet, and the good ones are built so that it cannot.