How to check whether a Mac app phones home

“Phoning home” is when an app quietly contacts a server it does not need to for the task at hand. Sometimes that is harmless: a check for updates, a licence validation. Sometimes it is analytics describing what you clicked, or a sync you never asked for. Either way, it is reasonable to want to know. The good news is that you do not have to take anyone’s word for it. macOS ships with enough tools to watch what an app does on the network, and the checks are things you can run in an afternoon.

Start with the simplest test: pull the plug

Before any tooling, try the crude version. Turn off Wi-Fi, or unplug the ethernet cable, and use the app normally for a while. Open files, change settings, do the things you actually do with it.

If everything works exactly the same offline, the app was not leaning on a server for those tasks. That does not prove it never sends anything, because it might be queuing data to send later, but it tells you the core function is local. If features break, error messages appear, or the app hangs waiting for something, you have learned that it expects a connection, and the next step is finding out what for.

This is a blunt test, but it is fast, and it often settles the question for well-behaved apps. An app that keeps working with the network gone is not depending on the network for the work you gave it.

Watch the connections with Activity Monitor

macOS includes Activity Monitor, in Applications, then Utilities. Open it and select the Network tab, and you get a live view of which processes are sending and receiving data, along with running totals of bytes in and out.

Launch the app you are curious about and watch its row. An app that is genuinely idle and local will show little or no network movement once it has started. An app that phones home will show bytes leaving even when you are not doing anything that should need a server. The numbers are coarse, and they will not tell you where the data went, but a process that steadily sends data while sitting untouched is worth a closer look.

Give it time. Some apps stay quiet for minutes and then send a burst. Leave Activity Monitor open in the background for a while and glance at the totals now and then.

See the destinations with built-in commands

To learn where an app is connecting, macOS gives you command line tools in Terminal that need no extra downloads.

The lsof command lists open files and connections. Running lsof -i -nP shows current network connections for all processes, with the app name, the protocol, and the remote address. Filter it to one app and you can see, at a glance, whether it holds any connections and to what. The nettop command gives a live, updating view of network activity per process, which is useful for catching short bursts that a single snapshot would miss.

These tools show connections while they are open, so run them while you are actively using the app and also while it sits idle. A destination you cannot explain, contacted when you are doing nothing, is the clearest sign of an app reaching out on its own.

Read what the app asks permission to do

macOS makes apps request permission for sensitive things, and those requests are a useful signal even before you open Activity Monitor. When an app first launches, notice what it asks for. Something that requests nothing at startup and only asks for a specific permission the first time a feature needs it is behaving cautiously.

You can review what an app has been granted in System Settings, under Privacy and Security. It is also worth checking the app’s own settings for switches labelled sync, backup, analytics, telemetry, or usage data, and for anything about signing in. Turning those off, where they exist, narrows what the app will send. An app with none of those switches, and no sign-in, has less it could send in the first place.

Understand the difference between policy and design

All of these checks tell you what an app does today. They do not, on their own, tell you what a future update might do. This is the limit of behaviour testing: you are observing a moving target.

The stronger guarantee comes from how an app is built. An app that contains no networking code cannot phone home, this version or the next, because the machinery is not there. Some developers make this checkable. If the release build is blocked from shipping when the binary links a networking library, then “it does not phone home” is a property of the software rather than a promise about how it is used. You still cannot read the whole source, but you can lean on a much smaller assumption.

A local app, by design

Ledge is an example of the design-level version of this. It turns the MacBook notch into a shelf: drag a file, folder, image, or link up to the notch, it lands there, and you drag it off to wherever it goes, with each destination receiving the version it can use. All of that runs on the Mac.

If you point Activity Monitor or lsof at it, you will not find it holding connections to a server, because there is no account and no cloud step in the way it works. The release build is blocked from shipping if the binary so much as links a networking symbol, so the offline test and the connection test agree with the way it was made. It is signed with a Developer ID, notarized by Apple, and runs on macOS 14 or later.

The point of all this is not paranoia. It is that you can answer the question yourself, with tools you already have, and stop guessing. Pull the plug, watch the network tab, list the connections, and read the permissions. For most apps, an hour of looking will tell you far more than any label on a download page.