Introduction

If App Review says your app uses the AdSupport framework and you did not intend to ship ad-tracking functionality, the next job is to find which binary or dependency links it. The problem is often not your own code, but a third-party SDK that pulls in AdSupport transitively. The fastest way to debug it is to inspect the built app and its embedded frameworks rather than guessing from package names alone.

What Apple Is Detecting

The AdSupport framework is associated with access to advertising-related APIs such as the Identifier for Advertisers. Apple may flag your app if:

• your app binary links AdSupport directly
• an embedded framework links it
• a third-party SDK contains symbols related to AdSupport or IDFA usage

That does not automatically mean you are intentionally tracking users, but it does mean something in the delivered app bundle references the framework.

Start With the Built App, Not the Source Tree

The most reliable place to inspect is the final built product. If you inspect only package manifests, you can miss a binary dependency that is linked later.

Useful commands include otool and nm.

To inspect the main app binary:

otool -L /path/to/YourApp.app/YourApp

If AdSupport is linked directly, it will appear in that list.

To search all embedded frameworks inside the app bundle:

find /path/to/YourApp.app -name "*.framework" -type d

Then inspect each framework binary with otool -L.

Search for IDFA-Related Symbols

A framework may not make the issue obvious from package naming alone. Looking for symbols can help.

nm -gU /path/to/SomeFramework.framework/SomeFramework | grep ASIdentifierManager

You can also search for the AdSupport framework name directly in binaries or link output.

If a framework exposes symbols such as ASIdentifierManager, that is a strong hint it is the component that triggered App Review's concern.

Check Xcode Linking and Embedded Frameworks

In Xcode, inspect:

• 'Link Binary With Libraries'
• embedded frameworks
• package dependencies
• CocoaPods or Carthage outputs if you use them

If AdSupport.framework is listed explicitly in your app target, remove it unless you truly need it.

If it is not listed directly, the likely cause is an embedded SDK.

Common Culprits

SDK categories that often bring AdSupport into a project include:

• advertising SDKs
• attribution or analytics SDKs
• social SDKs with ad-related measurement features
• older all-in-one mobile SDK bundles

Sometimes the vendor offers multiple variants, such as a no-IDFA build or a privacy-focused subspec. In those cases, switching package variants is the cleanest fix.

Verify After Removing or Replacing the SDK

Do not stop after removing a suspected library from the dependency file. Rebuild the app, inspect the new app bundle again, and confirm the framework reference is gone.

A practical flow is:

1. remove or replace the suspected SDK
2. clean the build output
3. rebuild the app
4. rerun otool -L on the final app and embedded frameworks

That last verification step matters because stale build products can make you think the change failed when the old binary is simply still present.

App Review and Privacy Context

Even if the responsible framework is legitimate, the app still has to match what you declared in App Store metadata and privacy settings. If a library accesses advertising-related APIs, you may also need to review App Tracking Transparency behavior and privacy disclosures.

So the technical fix and the policy fix are related but not identical.

Common Pitfalls

The biggest mistake is guessing based on the library name alone. The final built app bundle is what App Review inspects.

Another mistake is checking only the main app binary. The actual AdSupport link may be inside one embedded framework.

People also remove a dependency but forget to clean and rebuild, which leaves stale binaries in the product and makes the issue look unchanged.

Finally, do not ignore vendor documentation. Some SDKs explicitly document which package variant includes IDFA support and which one avoids it.

Summary

• The responsible library is usually identified by inspecting the built app and embedded frameworks, not by guessing from source dependencies alone.
• Use tools such as otool and nm to detect AdSupport links and IDFA-related symbols.
• Check both the main app binary and all embedded frameworks.
• After removing a suspect library, clean, rebuild, and inspect the final app bundle again.
• If an SDK offers a no-IDFA variant, that is often the cleanest fix.