The Honest Version of the Question

People search for a way to see what data their Mac apps send, and a useful answer has to start with a distinction that sounds like a dodge and is not one. Almost all app traffic is encrypted in transit. What you can see, without turning your Mac into a laboratory, is the outside of it: which domains an app looks up, which connections it makes, how often it makes them, and which piece of software is responsible. SplitTunnel shows you that. It does not read the contents of your traffic.

That sounds like less than you asked for. In practice it is usually the part that matters, because the questions behind the search are almost always questions about destinations rather than about payloads.

What Destinations Tell You

• •

  Who: the service on the other end, by name, rather than an anonymous spike in a bandwidth graph

• •

  How often: once at launch is a different story from every thirty seconds while the app sits idle

• •

  Which app: attribution is what turns "my Mac is busy" into "this app is busy"

• •

  Whether you expected it: an editor that contacts its own vendor is unremarkable, and an editor that contacts three analytics companies is a fact you did not have yesterday

None of that requires reading a payload. A note-taking app that talks to a mobile ad network has told you something about itself with the envelope still sealed. So has a small utility that reaches an analytics endpoint every couple of minutes while you are not using it. The address on the outside carries more information than people assume.

Watching One App

The panel is far more useful pointed at one thing than read as a whole. Give yourself ten minutes and one suspect.

Traffic during active use is mostly the app doing the job you opened it for. Traffic while nobody is touching it is the app's own agenda, and that is the stretch worth waiting through.

Two patterns are worth marking as you read. Names carrying analytics, telemetry, metrics, or events are the usual candidates when you are hunting background chatter, though the wording is a hint rather than proof. And a vendor's own domain doing something once at launch rarely deserves attention, while an unrelated company appearing on a loop usually does. You are looking for rhythm as much as for names.

Acting on What You Find

Looking is only half of it. Select a row and the detail pane offers a button reading Block followed by that domain. One click and the name stops resolving for the whole Mac: every app and every browser, no matter how each app's traffic is routed. If you already know the hostname, Domain Rules has Add Domain for typing it in directly. Either way the rule lands in Domain Rules, where Unblock removes it again.

Two things follow from machine-wide. A rule on a hostname also covers anything underneath it, so you are not maintaining a list of subdomains by hand. And a name that many apps share is shared when you block it too, which is the argument for blocking the specific endpoint you watched rather than a parent domain you assumed.

When the conclusion is about the program rather than one destination, the app-level block in the Apps panel is the other instrument: it cuts one app off from the network entirely instead of removing one name for everything. Domain rules and app blocks are separate tools, and the choice between them is really a question about what you concluded.

When Destinations Are Not Enough

Occasionally the list genuinely does not settle it. Rather than pretend this view covers everything, here are the two honest paths from there.

• •

  The vendor's own account of itself: the privacy policy, the App Store privacy label, and the data access or deletion request you are entitled to make. Slow, and the only source that speaks to contents with any authority

• •

  Software built for inspecting traffic contents: a different class of tool, aimed at developers debugging their own applications. It is a deliberate setup rather than a passive view, and it asks you to put a piece of software in a position of considerable trust

For the ordinary version of the question neither is necessary. Knowing which app contacts which service, and how often, is enough to decide what you want running on your machine.

The Limits, Plainly

• •

  Contents are not visible here, and no amount of watching will change that. Destinations, attribution, and frequency are the view

• •

  With the curated blocklists switched on, not every domain they catch appears as its own row in this version, and those lists do not take per-domain exceptions

• •

  Software that connects straight to an IP address never looks a name up, so there is no name to read and none for a domain rule to act on

• •

  A browser using its own encrypted DNS goes around the system resolver, so rules do not reach it until you turn on Block Encrypted DNS in the Strict Mode section of Settings and restart the browser. That works from a curated list of resolvers, so software pinning its own by IP address stays out of reach

Reframed, the question has a good answer. You cannot open the envelopes. You can read the addresses on them, attributed to the app that wrote them, which is enough to notice a pattern, ask a vendor a sharper question, and quietly remove the destinations you decided your Mac does not need.