App Store Connect detects dormant ATT signatures when tracking permission is unused

[thisislvca]

New issue checklist

• I have reviewed the README and documentation
• I have searched existing issues and this is not a duplicate
• I have reproduced this in the Superwall demo project. The issue was reproduced by inspecting an App Store submission binary from an app integrating SuperwallKit through CocoaPods.

General information

• SuperwallKit version: Reproduced with 4.15.3; the relevant signatures remain in 4.16.1
• Integration: CocoaPods through expo-superwall
• iOS version(s): Not device-dependent; detected during App Store Connect submission
• Devices/Simulators affected: Not applicable
• Reproducible in the demo project: Not tested
• Related issue: Feature Request: Configuration option to disable IDFA collection #468 concerns runtime IDFA collection, but not the dormant ATT signatures detected in the compiled binary

Describe the bug

App Store Connect detects NSUserTrackingUsageDescription in an app that includes SuperwallKit even though the host app:

• Does not declare NSUserTrackingUsageDescription in its main Info.plist
• Does not import or directly call App Tracking Transparency
• Does not request tracking permission
• Does not use Superwall's paywall action for requesting ATT

This prevents publishing an App Privacy response stating that device IDs are not used for tracking.

App Store Connect reports:

Your app contains NSUserTrackingUsageDescription, indicating that it may request permission to track users. To submit for review, update your App Privacy response to indicate that data collected from this app will be used for tracking purposes, or update your app binary and upload a new build.

We downloaded and inspected the submitted IPA. The main application Info.plist does not contain NSUserTrackingUsageDescription, but the compiled application binary contains:

NSUserTrackingUsageDescription
requestTrackingAuthorizationWithCompletionHandler:
requestTrackingAuthorization()

The signatures appear to originate from SuperwallKit's tracking-permission implementation:

• PermissionHandler.PlistKey.tracking contains the literal NSUserTrackingUsageDescription.
• FakeTrackingManager compiles an Objective-C requestTrackingAuthorization selector.
• TrackingManagerProxy contains a Swift method named requestTrackingAuthorization().

TrackingManagerProxy already ROT13-encodes the actual ATT class and selector specifically to avoid static-analysis detection, but the remaining plist-key literal and fake/internal method names appear to defeat that protection.

Steps to reproduce

1. Integrate SuperwallKit into an iOS app.
2. Do not add NSUserTrackingUsageDescription to the application's Info.plist.
3. Do not request ATT permission or configure a Superwall paywall action that requests it.
4. Build and submit the app to App Store Connect.
5. In App Privacy, declare that device IDs are not used for tracking and attempt to publish the response.

Expected: Apps that do not configure or use Superwall's tracking-permission action do not ship detectable ATT signatures solely because SuperwallKit is linked.

Actual: App Store Connect detects NSUserTrackingUsageDescription and requires either declaring tracking or uploading a new binary.

Suggested resolution

Ideally, ATT support would either:

1. Avoid compiling Apple's exact privacy key and selectors into binaries that do not use tracking; or
2. Be opt-in through a build flag, CocoaPods subspec, or separate SwiftPM product.

This appears similar to the App Store permission warning addressed for microphone permissions in #421.

Would the maintainers be open to a PR that removes or encodes the remaining ATT signatures while preserving tracking-permission functionality for applications that explicitly enable it?

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[linear-code]

SW-5679