Hidden SDKs in Your App Binary Can Cause Store Rejection

SDK Inventory: What's Inside Your App Binary

You wrote the code. You chose the dependencies. You ran the build. But do you know what ended up inside your compiled binary?

For most teams, the answer is incomplete.

The app you submit to Apple or Google is not a direct reflection of your source code. It's a compiled artifact. The difference matters.

What's the difference between source code and binary analysis?

Source code analysis shows what you intended to include. Binary analysis shows what actually shipped. The difference is significant because transitive dependencies, bundled resources, and build-time changes can all add components you didn't track.

When you add an SDK, you're not only adding that package. You're also adding its dependencies, their dependencies, and bundled resources. This is the transitive dependency chain.

Your source files and lockfiles give a partial view. The compiled binary shows the full result after code merging, optimization, resource bundling, and metadata embedding. App stores review the binary, not your source.

Signal	Visible in Source	Visible in Binary	Risk if Missed
Direct dependencies	Yes	Yes	Low
Transitive dependencies	Partially (lock files)	Yes	High
Embedded fonts	No	Yes	Legal exposure
Privacy-relevant APIs	No (runtime)	Yes (symbols)	Store rejection
Bundled certificates	No	Yes	Security risk

What hidden components live inside your app binary?

Fonts you didn't track

Some SDKs bundle font files. These fonts are included in your binary and may require a license for embedding.

If a commercial font is shipped without proper licensing, this creates legal risk.

Data collection you didn't explicitly enable

Some SDKs collect data by default or enable telemetry automatically.

Examples:

• device identifiers
• usage events
• crash reporting

This becomes a problem when your privacy policy doesn't reflect it or your store disclosures are incomplete.

Deprecated or restricted API usage

SDKs may use APIs that are deprecated, restricted, or discouraged.

Not all deprecated APIs cause rejection. But certain categories, such as private or removed APIs, can trigger review issues.

Permissions you didn't expect

Some SDKs declare permissions you don't actively use.

Example: voice-related permissions in a mapping SDK.

On Android this is more visible at install time. On iOS this typically appears when permission prompts are triggered.

Why does SDK inventory matter for compliance?

Both platforms are increasing enforcement.

Apple:

• evaluates binaries during review
• requires accurate privacy declarations
• enforces privacy manifests for API usage

Google:

• scans apps before and after release
• requires Data Safety disclosures
• performs ongoing policy checks

In both cases, you're responsible for everything in your binary. SDK behavior counts as your behavior.

How do you run an SDK audit on a compiled binary?

Start with the binary

Don't rely only on your Podfile, build.gradle, or package.json. Inspect the IPA, APK, or AAB. This is what users install and what stores evaluate.

Map SDKs to behavior

For each SDK:

• identify data collection
• check required permissions
• review API usage

Compare this with your privacy policy and store declarations.

Check embedded resources

Look for fonts, images, and config files. These can introduce licensing issues or hidden functionality.

Trace dependencies

Don't stop at direct dependencies. Include transitive libraries and bundled frameworks.

Make it repeatable

SDK contents change over time. Updates, new dependencies, and build changes can all introduce issues. This requires continuous checks in your CI/CD pipeline, not one-time audits.

Visibility is the real problem

Most teams make decisions based on source code.

But source shows intent. Binary shows reality.

If you don't inspect the binary, you're working with incomplete information.

Make it part of your pipeline

A reliable approach is:

• analyze the compiled binary
• inventory all SDKs
• map resources and APIs
• validate against store requirements

AppCompliance automates this by scanning IPA, APK, and AAB files and surfacing SDK inventory, embedded fonts, API usage, and data collection signals.

No tool is perfect. Manual validation is still needed for edge cases. But without binary-level visibility, issues are easy to miss.

Teams that treat binary analysis as part of their build process have fewer surprises during review and fewer compliance risks.