The experiment was conducted on five iPhone 17e devices running iOS 26.5.2. The behavior was consistent across all devices. Network traffic was analyzed on a controlled Wi-Fi network. The main finding of the study:

Disabling system analytics does not stop the automatic transmission of metadata to Apple’s infrastructure. It disables a specific class of diagnostic reports, but does not stop Find My, Apple Account, location services, advertising components, the App Store, MobileAsset, or system check-in mechanisms.

What exactly does the iPhone transmit?

The following were found in the decrypted requests:

  • Apple Account address;
  • the account’s DSID and alternative DSID;
  • the advertising ADSID;
  • serial number;
  • device UDID;
  • APNs and push tokens;
  • IDS (Device ID);
  • phone model;
  • iOS version and build;
  • hardware platform;
  • RAM capacity;
  • device name;
  • account region;
  • language and time zone;
  • battery status;
  • charging status;
  • screen lock status;
  • Find My status;
  • location services status;
  • BSSIDs of nearby Wi-Fi access points;
  • coordinates for WeatherKit;
  • versions of installed system components;
  • information about paired Apple devices.

This is not a single “analytical report.” The data is distributed across several of Apple’s functional services. But from a technical standpoint, this is automatic telemetry: the phone transmits information about itself, its status, and its surroundings to remote servers.

Apple receives notifications when geolocation is turned on and off

The most telling mechanism is related to Find My.

Every time the status of geolocation services changes, the iPhone sends a request:

POST p117-fmf.icloud.com/fmipservice/fmf/<DSID>/<UDID>/register

When geolocation was turned off, the HTTP request body contained:

{
  "cause": "LocationServicesStateChanged",
  "registeredCauses": [
    "LocationServicesStateChanged"
  ],
  "locationServicesEnabled": false,
  ...
}

Upon subsequent activation:

{
  "cause": "LocationServicesStateChanged",
  "registeredCauses": [
    "LocationServicesStateChanged"
  ],
  "locationServicesEnabled": true
}

Both requests were accepted by Apple’s server with the following response: HTTP 204 No Content

Thus, Apple receives more than just the current geolocation status. The server receives a separate event notifying it that the user has changed the relevant setting.

The flag itself true or false is only a small part of the request. The following are also transmitted along with it:

  • Apple Account DSID;
  • the phone’s UDID;
  • serial number;
  • device model;
  • iOS version and build;
  • Phone name;
  • APN token;
  • list of push tokens;
  • IDS Device ID;
  • battery charge;
  • charging status;
  • lock status;
  • location;
  • time zone;
  • Apple certification headers.

This is a fully identified event. It is associated simultaneously with an account, a specific device, and its current status.

What happens after geolocation is enabled?

With geolocation turned off, requests involving BSSID uploads ceased. For two and a half hours, there were no requests to the primary Wi-Fi positioning service.

Immediately after enabling geolocation, the iPhone began communicating with: http://gs-loc.apple.com/clls/wloc

A system process locationd sent Apple lists of nearby access points.

One of the requests contained 19 BSSIDs. In response, Apple returned 119 Wi-Fi entries related to the surrounding area.

The mechanism works as follows:

  1. The iPhone scans for available Wi-Fi access points.
  2. The phone sends their BSSIDs—the MAC addresses of the access points—to Apple.
  3. The server returns geographic information about the detected and neighboring access points.
  4. The phone calculates its location locally.

Technically, the device does not send a message saying, “I am at this address.” However, a list of several nearby BSSIDs, combined with the time of the request, allows the server to determine the phone’s general location with high accuracy.

Separately, the process geod calls: http://gspXX-ssl.ls.apple.com/wifi_request

This request transmits a single BSSID—likely the identifier of the current access point or the primary access point used for positioning.

Geolocation services continue to work even when geolocation is turned off

Disabling geolocation services stopped the loading of nearby BSSID lists, but did not stop the iOS geolocation stack itself.

Processes geod and locationd continued to access:

gspXX-ssl-background.ls.apple.com/dispatcher.arpc
gsp-ssl.ls.apple.com/ab.arpc
configuration.ls.apple.com/config/defaults
gspeX-ssl.ls.apple.com/pep/gcc
gspeXX-ssl.ls.apple.com/ligl/v1/ligl.bin
gspeXX-ssl.ls.apple.com/geo_manifest/dynamic/config

The requests included the following:

  • iPhone model;
  • iOS version;
  • Build number;
  • system process ID;
  • language;
  • region;
  • Apple Maps request type;
  • geographic configuration service parameters.

The responses dispatcher.arpc contained regional data and reverse geocoding blocks.

For identical requests, different server nodes returned data for Japan or the Apple Account region. This indicates that the geolocation subsystem continues to receive server-side configuration even when user access to geolocation is disabled.

WeatherKit transmits coordinates in the URL

The iOS weather component accessed:

weatherkit.apple.com/api/v2/weather/<lang>/<lat>/<lon>

The coordinates were embedded directly in the URL path with an accuracy of three decimal places—approximately 100 meters.

Additionally, the following were transmitted:

  • time zone;
  • country;
  • device languages;
  • iOS version;
  • build number;
  • list of weather datasets;
  • time range;
  • request UUID;
  • Bearer JWT.

The JWT was used to authorize WeatherKit and did not contain a DSID, UDID, or serial number. However, the HTTPS request itself still contained the source’s coordinates and IP address.

In one of the captures, Apple’s server successfully processed such a request and returned HTTP 200.

Consequently, the transmission of coordinates to WeatherKit is not just a locally generated request, but also a confirmed server-side exchange.

Find My transmits the phone’s status

Find My is used not only when toggling geolocation.

After a restart, the iPhone sends the same type of registration with the following reason: cause = DeviceRestart

The device contains:

  • serial number;
  • UDID;
  • device name;
  • model;
  • iOS version;
  • push tokens;
  • IDS (Device ID);
  • battery charge;
  • charging status;
  • whether the charger is connected;
  • whether the screen is locked;
  • Is geolocation enabled?
  • whether Find My is active.

The server receives the exact reboot time and the device’s current status.

In this case, Find My acts as a full-fledged operational telemetry channel linked to an Apple Account and a specific physical device.

Apple ID Check-In

After a reboot, the system process com.apple.NewDeviceOutreach sends a request:
POST sse-ws-p189.apple.com/device/api/v1/checkIn

It contains:

  • the Apple Account email address;
  • primary DSID;
  • alternate DSID;
  • serial number;
  • device model;
  • phone name;
  • body color;
  • region;
  • storefront;
  • language;
  • time zone;
  • warranty hash;
  • list of local Apple devices;
  • information about linked Apple Watches;
  • Apple Media Services service identifiers;
  • hardware attestation.

The server returns the result SUCCESS and the time of the next check-in.

This is one of the requests containing the most personal data. It combines account information, the physical device, warranty details, and information about linked devices.

The advertising infrastructure continues to operate even when personalization is disabled

Even with personalized ads disabled, the following system processes continued to run:

com.apple.ap.promotedcontentd
com.apple.ap.adprivacyd

They accessed:

sas.pcms.apple.com
iadsdk.apple.com
ca.iadsdk.apple.com
partiality.itunes.apple.com

The following were passed in advertising segmentation requests:

  • DSID;
  • ADSID;
  • storefront;
  • locale;
  • time zone;
  • machine-attestation;
  • server cookies;
  • advertising profile service flags.

The attribution endpoint received:

  • App Store app ID;
  • bundle ID;
  • attribution key;
  • iPhone model;
  • iOS version;
  • build;
  • storefront;
  • timestamp;
  • Apple signature.

The body contained the following value: attribution = false

This means that positive ad attribution was not established. However, the attribution and ad targeting mechanisms themselves continued to function.

Turning off personalized ads does not disable the ad stack. It changes the rules for data usage but does not stop network communication.

The App Store downloads metric configurations via bag.itunes.apple.com/bag.xml

The iPhone receives the configuration for the App Store and media services.

In its requests, the phone transmits:

  • model;
  • device class;
  • iOS version and build;
  • storefront;
  • language;
  • time zone;
  • system process ID.

The responses contain the following addresses:

xp.apple.com/report
daf.xp.apple.com/report

The server also transmits:

  • usage-metric topics;
  • performance metric topics;
  • sending intervals;
  • sampling parameters;
  • rotating client IDs;
  • event and field throttling rules.

Connections to xp.apple.com were recorded, but their contents remained encrypted. Therefore, it is impossible to determine the exact composition of the events sent there based on the available data.

Only the following can be stated with certainty: the metrics pipeline was configured, and the iPhone established connections with the reporting server.

Siri and Apple Intelligence continue to receive system manifests

Even with Siri and Apple Intelligence disabled, the phone continued to access: gdmf-ados.apple.com/v2/assets

The following system packets were requested:

com.apple.MobileAsset.UAF.Siri.UnderstandingNLOverrides
com.apple.MobileAsset.UAF.Siri.UnderstandingASRHammer
com.apple.MobileAsset.UAF.IF.PlannerOverrides

The requests included:

  • phone model;
  • hardware platform;
  • RAM capacity;
  • iOS version and build;
  • Build ID;
  • System Image ID;
  • update status;
  • rollback status;
  • Versions of installed components;
  • Session ID;
  • Nonce;
  • Asset Audience.

The responses contained signed manifests:

  • System archive URL;
  • component version;
  • build;
  • archive ID;
  • archive decryption key;
  • digest;
  • size;
  • range of compatible iOS versions;
  • caching rules.

There is no transmission of voice, Siri text, or user requests here. This is a check for system model updates.

However, disabling these features does not remove the device from the support cycle for the relevant components: the iPhone continues to regularly check their versions and send Apple detailed hardware and software configuration information.

Restarts and Airplane Mode trigger a cascade of connections

A reboot is one of the most resource-intensive events.

Immediately after the iPhone starts up:

  • it registers with Find My, with the reason DeviceRestart;
  • it performs an Apple Account check-in;
  • it checks network availability;
  • it determines the external IP address;
  • downloads App Store caches;
  • reestablishes connections to iCloud;
  • checks MobileAsset;
  • updates geographic configurations.

Within one minute after the restart, dozens of requests were recorded to:

gateway.icloud.com
bag.itunes.apple.com
setup.icloud.com
gsa.apple.com
itunes.apple.com
fpinit.itunes.apple.com

Similar behavior was observed when Airplane Mode was turned on and off.

After regaining network connectivity, the iPhone established connections with: gateway.icloud.com

and triggered a re-initialization of Apple’s system services.

The contents of the exchange with gateway.icloud.com was indecipherable, but the very fact of the network event and its connection to toggling Airplane Mode were reproduced in a controlled experiment.

Secure services disappear when viewing HTTPS

Some Apple services consistently failed to function while HTTPS traffic was being viewed.

The experiment was repeated:

  • on five iPhone 17e devices;
  • over the course of two days;
  • after 5–10 reboots of each device.

While HTTPS traffic was being decrypted, the corresponding services failed to establish working connections.

Immediately after decryption was disabled, they resumed operation and became visible as opaque CONNECTconnections.

This behavior was consistent and was not a random network glitch.

Therefore, the complete picture was composed of two types of captures:

  1. with decryption—to analyze URLs, headers, and bodies;
  2. without decryption—to identify secure services that refuse to operate under surveillance.

A single CONNECT is not equal to a single HTTP request. Multiple operations can occur within a single tunnel. Therefore, the number CONNECT cannot be directly compared to the number of decrypted GET and POST requests.

The phone continues to communicate with Apple during idle time

During a prolonged background session, the iPhone remained idle without any user interaction.

Despite analytics, geolocation, Siri, and syncing being disabled, the device continued to communicate with Apple’s infrastructure every few minutes.

Among the most frequent connections:

  • gspXX-ssl-background.ls.apple.com — approximately once every 30 minutes;
  • configuration.ls.apple.com — about once every 50 minutes;
  • iphone-ld.apple.com — about every 51 minutes;
  • gateway.icloud.com — in bursts;
  • weatherkit.apple.com — about once every few hours;
  • caldav.icloud.com — about once an hour.

Over the course of 8.8 hours, there was not a single fully “sleeping” interval longer than 21 minutes.

Conclusion

The investigation did not uncover any explicit crash reports, stack traces, or complete diagnostic archives. It is likely that the “iPhone Analytics” toggle does indeed disable this specific type of reporting.

However, it does not disable iOS telemetry as a system.

Even with user settings disabled, the iPhone 17e continues to send the following to Apple:

  • account identifiers;
  • Apple Account email;
  • DSID and ADSID;
  • serial number;
  • UDID;
  • push tokens;
  • IDS (Device ID);
  • battery status;
  • lock status;
  • reboot status;
  • geolocation switch status;
  • whether the network status has changed;
  • BSSIDs of nearby Wi-Fi access points;
  • coordinates for the weather service;
  • information about connected devices;
  • detailed hardware and software fingerprint;
  • advertising segmentation and attribution data.

Key takeaway:

iOS lacks a single user toggle that stops the automatic transmission of metadata to Apple. Disabling analytics turns off a specific analytics mechanism, but functional services continue to report to the server what kind of device it is, which account it is linked to, its current status, and changes to its system settings.

All of the data described is transmitted over encrypted HTTPS connections. An ISP or the owner of a standard Wi-Fi network cannot see it. Apple receives it directly. We cannot confirm whether data might have been transmitted to gateway.icloud.com or to other services that use SSL Pinning.