Required-reason APIs: the SDK inventory belongs in the release review
Analysis
By UA Ledger staff — 2 min read

Review the APIs used by the assembled app, including dependencies, before promising an update date.
A privacy-manifest task cannot be delegated away simply because the code arrived through an SDK. Apple’s upload requirement explicitly includes listed API use in third-party code, making dependency ownership part of release readiness.
Inspect the assembled application
Our recommended workflow begins with the exact dependency versions in the release candidate. Ask what the SDK does, which listed APIs it uses and how the approved reasons are represented in the delivered application. The relevant evidence concerns the assembled build, not a vendor’s generic assurance that its newest release is compliant.
For growth teams, this is a scheduling dependency. Adding or replacing an attribution, monetisation or analytics package can change the review needed before submission. Give the technical owner enough time to inspect that change before the media plan assumes a new event or onboarding flow is live.
Avoid turning the record into a privacy certification
A declared reason is not proof of every privacy claim a game makes. This change log checks one documented upload control. Data collection, permission choices and business disclosures still require their own evidence and accountable owners.
The accompanying table is intended for release planning: scope, effective date, owner and next verification. Use it to ask a precise question about the candidate build. If the dependency list changes after sign-off, preserve the earlier result and record the new check rather than letting the old approval float across versions.
The governing record is Approved reasons for APIs. This edition checks the provider documentation; it does not inspect a studio account or certify a shipped build.
Inspect the evidence
Download the applicability and deadline record. The extraction separates documented facts from our analysis and unknowns.
| Field | Evidence or limit |
|---|---|
| Provider | Apple |
| Effective or release date | 2024-05-01 |
| Applies to | New and updated apps using Apple’s listed APIs, including third-party SDK code |
| Documented change | From 1 May 2024, Apple requires approved reasons for listed API use in app code and third-party SDKs for uploads. |
| Suggested owner | Privacy engineering and release engineering |
| Next verification | Check the shipped dependency inventory against the declared reasons. |
Further reading in the existing archive: Privacy by design in UA data flows; The MMP Migration Checklist to Run Before You Switch. These links provide background; this check does not independently verify their full contents.
Featured
Related posts
measurement
platforms
·1 min read
When to turn rewarded ads off for payers (and how to measure the loss)
measurement
platforms
·1 min read
When custom product pages need their own MMP campaign mapping
measurement
platforms
·1 min read
Season pass refund rate versus standard IAP refund rate
measurement
platforms
·1 min read
Pre-reg cohort quality vs post-launch paid cohort quality
More from the Measurement desk
measurement
platforms
·2 min read
AppLovin Ad Review drops user-level journeys for aggregate-only reporting
measurement
platforms
·2 min read
Apple adds an EU alternative ATT prompt from iOS 27.2 — mandatory in five markets
measurement
platforms
·1 min read
Pity-adjusted expected value versus player-facing banner claims
measurement
platforms
·1 min read