An iOS app archive leaks different people depending on how it was built and delivered. A development build exposes the developer's team and their testers' device UDIDs; an App Store copy exposes the Apple account that downloaded it. This scan reads the provisioning profile, the plists, and the signed binary in your browser to show exactly what - and whose data - is inside.
Scan a iOS app fileAn iOS app leaks different people depending on how it was distributed, and the scan tells you which. A development or ad-hoc build leaks the developer: their Apple Developer team name and 10-character Team ID, the signing certificate, and - most sensitively - the UDIDs of every device it was provisioned for, which are the real hardware fingerprints of the developer's and testers' phones. An App Store copy instead leaks the person who downloaded it.
That is because an App Store IPA bundles iTunesMetadata.plist, which records the Apple ID email, the legal first and last name, and the permanent numeric account id (DSID) of the account that bought or downloaded the app, plus the storefront country and purchase date. A StoreKit receipt or FairPlay DRM material ties the copy to that specific buyer.
From Info.plist the scan reads the app's privacy-capability inventory - every sensitive resource it declares (camera, microphone, location, contacts, health), whether it requests cross-app tracking (IDFA), and the backend hostnames it carves out transport-security exceptions for. The provisioning profile's entitlements add the developer's own associated domains and app-group identifiers, and an embedded GoogleService-Info.plist ships the Firebase API key and project ids in cleartext.
The Info.plist also names the exact Xcode version and the macOS build number of the developer's build machine - their environment, not the user's - and the compiled Mach-O executable adds its build UUID, linked frameworks, and, on unencrypted (non-App-Store) binaries, a string sweep for hardcoded URLs, emails and build paths.
This is a selection. The full field manual documents the fields read from each format.
An iOS app carries its developer team and Team ID, the signing certificate, the provisioning profile, the app's declared sensitive permissions and tracking behaviour, its backend and associated domains, the Xcode version and build-machine OS, the compiled Mach-O's build UUID and frameworks, and - on App Store copies - the account that downloaded it.
An App Store copy can. It bundles iTunesMetadata.plist, which records the Apple ID email, the legal first and last name, and the permanent numeric account id (DSID) of the downloading account, plus the storefront country and purchase date. A development or ad-hoc build instead exposes the developer and their registered test-device UDIDs.
They leak different people. A development or ad-hoc build has get-task-allow set and a list of provisioned device UDIDs, exposing the developer's team and their testers' devices. An App Store copy is FairPlay-encrypted and carries a store receipt and the purchaser's account details. The scan reports which channel the file came from.
Partly. From Info.plist the scan reads every sensitive-resource usage description the app declares (camera, microphone, location, contacts, health), whether it requests cross-app tracking (IDFA), and the backend hostnames it exempts from transport security. That is the app's declared privacy-capability inventory - what it says it can reach - rather than a runtime record of what it actually sends.
File X-Ray reads iOS app files entirely in your browser - the file never leaves your device. This format is inspected, not modified. Scan a file now.