How iOS 15 App Privacy Report Logs Network Domains

Apple’s App Privacy Report in iOS 15 provides users with visibility into how installed applications access sensitive permissions and communicate across the internet. This article explains the underlying mechanisms iOS 15 uses to detect, attribute, and record individual domain access calls initiated by third-party applications, detailing how the operating system captures network activity at the system level without compromising user payload privacy.

Network Stack Monitoring at the OS Level

Rather than relying on applications to self-report network behavior, iOS 15 logs domain access at the operating system level. When an application initiates an outgoing network connection—whether through Apple's high-level APIs like URLSession, the lower-level Network.framework, or raw POSIX sockets—the request must pass through the Darwin kernel and system networking daemons.

Because the operating system manages all socket creation and network interfaces, it observes outgoing traffic independently of the application's code.

Attribution via Process Identification

iOS assigns every running application a unique Process Identifier (PID) and tracks its associated application bundle ID. When a network connection request is made, the kernel correlates the socket with the specific process that initiated it. This allows iOS to attribute outgoing network calls to the exact app responsible, preventing third-party software from masking requests under system-wide processes.

Domain Name Extraction and DNS Resolution

To display human-readable domain names rather than raw IP addresses, the App Privacy Report captures hostnames through two primary methods:

  1. API Hostname Requests: Most modern iOS applications resolve endpoints using domain names passed directly to system networking frameworks. When an app requests a connection to an endpoint (e.g., api.example.com), the system records the requested host string prior to establishing the connection.
  2. Server Name Indication (SNI): For encrypted traffic, such as standard HTTPS/TLS handshakes, the client sends the destination hostname in plaintext within the TLS Client Hello message via Server Name Indication (SNI). The OS networking stack inspects this field to log the specific domain being contacted.
  3. DNS Query Interception: If an application issues a DNS lookup via system resolvers (such as mDNSResponder), the requested domain is logged and mapped to the resolving process.

In-App Browsing and Embedded Content

The App Privacy Report distinguishes between direct application API calls and domains contacted through user-initiated web browsing.

When an app embeds a WKWebView, network calls are handled by an out-of-process WebKit rendering engine (com.apple.WebKit.Networking). iOS attributes these network hits to the parent application hosting the web view, but groups them under web activity to reflect that resources were loaded within an embedded browser session. Conversely, components using SFSafariViewController run in a separate system process isolated from the host application's report to protect user browsing privacy.

Local Aggregation and Privacy Protections

All network logging occurs locally on the device:

  • No Payload Inspection: The system logs only metadata: the destination domain, the timestamp, and the responsible app. It does not perform deep packet inspection, decrypt HTTPS payloads, or record full URL paths, query parameters, or transmitted data.
  • Rolling Storage: Data is stored in an encrypted local database managed by system privacy daemons (sysdiagnose / coreduetd). The system maintains a rolling 7-day log of activity, which is discarded if the user turns off the feature in Settings.