How to Check Whether a Mac App Can Connect to the Internet | Reverse Everything Before I open an unfamiliar Mac app, I like to look at what is inside the app bundle first. This does not prove the app is safe, and it does not replace dynamic monitoring, but it can answer a useful first question: does this app appear to contain code that can reach the network?
On macOS, a normal .app is a directory with metadata, resources, frameworks, helper tools, XPC services, extensions, and one or more Mach-O executables. The main executable is only one part of the picture. A serious check should inspect the whole bundle, not just Contents/MacOS/AppName.
What these commands are for
The gray blocks in this post are Terminal commands. Terminal is the macOS app that lets you type text commands and ask the system to inspect files.
You can open it from Finder at Applications > Utilities > Terminal, or press Command-Space, type Terminal, and press Return.
Copy each command block into Terminal and press Return. Some blocks are meant to be pasted as a group. If a command prints an error, stop and check that the app path is correct before continuing. Some filter commands use grep. If those commands print nothing, it usually means no matching clue was found.
Start with the app bundle
In Terminal, start by saving the app path into a variable named APP. Replace this example with the app you want to inspect:
APP="/Applications/Example App.app"<br>Keep the quotes around the path. Many app bundles contain spaces, parentheses, or other shell-sensitive characters in their names. If you drag an app from Finder into Terminal, macOS may insert backslash-escaped spaces instead. That also works, but quoted variables are easier to reuse safely in later commands.
Confirm the bundle metadata and read the executable name from Info.plist:
plutil -p "$APP/Contents/Info.plist"<br>BUNDLE_EXECUTABLE="$(plutil -extract CFBundleExecutable raw -o - "$APP/Contents/Info.plist")"<br>printf '%s\n' "$BUNDLE_EXECUTABLE"<br>Then build the path to the main binary. This still works when the executable name itself has spaces:
MAIN="$APP/Contents/MacOS/$BUNDLE_EXECUTABLE"<br>printf '%s\n' "$MAIN"<br>file "$MAIN"<br>Now create a temporary plain-name link to that binary:
INSPECT_DIR="$(mktemp -d /tmp/macho-inspect.XXXXXX)"<br>INSPECT_MAIN="$INSPECT_DIR/main-binary"<br>ln -s "$MAIN" "$INSPECT_MAIN"<br>printf '%s\n' "$INSPECT_MAIN"<br>This does not copy or modify the app. It creates a temporary link with a simple path. This matters because some Apple command-line tools, especially otool, can misread parentheses in a filename as archive syntax even when the shell quoting is correct.
All later commands assume APP, BUNDLE_EXECUTABLE, MAIN, and INSPECT_MAIN were set this way. Do not remove the quotes around variable expansions such as "$APP", "$MAIN", or "$INSPECT_MAIN".
Also check whether the executable contains more than one CPU architecture:
lipo -info "$INSPECT_MAIN"<br>Many apps are universal binaries with both arm64 and x86_64 code. The commands in this post inspect the binary as a whole, but this is still useful context. If you are doing a deeper investigation, remember that behavior can differ between architectures when an app ships different code paths or bundled helpers.
If file reports a Mach-O executable, you can inspect linked frameworks, imported symbols, strings, signing data, and entitlements.
Check signing and entitlements
Start with the code signature:
codesign -dv --verbose=4 "$APP" 2>&1<br>Then print the entitlements:
codesign -d --entitlements :- "$APP" 2>/dev/null<br>For sandboxed apps, these network entitlements are important:
com.apple.security.network.client<br>com.apple.security.network.server<br>com.apple.security.network.client means a sandboxed app is allowed to make outgoing network connections. com.apple.security.network.server means it is allowed to listen for incoming connections.
There is one important catch: if the app is not sandboxed, the absence of these entitlements does not mean the app cannot use the network. Unsandboxed apps do not need those sandbox entitlements to call networking APIs.
Look for networking frameworks
Next, check what the main binary links against:
otool -L "$INSPECT_MAIN"<br>Network-related clues may include frameworks or libraries such as:
CFNetwork.framework<br>Network.framework<br>WebKit.framework<br>SystemConfiguration.framework<br>libcurl<br>libresolv<br>This is not a complete list, and linking a framework is not a guilty verdict. Many normal apps link broad Apple frameworks for common system behavior. WebKit is a good example: an app may link it because it has a web view, help screen, login screen, documentation view, or WebApp mode. WebKit is a browser engine, so it can bring network-capable code with it even when your own app code does not directly call socket() or connect().
You can filter the output:
otool -L "$INSPECT_MAIN" | grep -Ei 'CFNetwork|Network\.framework|WebKit|SystemConfiguration|libcurl|libresolv'<br>List network-related calls
When...