Required-reason APIs: the SDK inventory belongs in the release review

Analysis

By UA Ledger staff2 min read

Required-reason APIs: the SDK inventory belongs in the release review

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.

Reference table
FieldEvidence or limit
ProviderApple
Effective or release date2024-05-01
Applies toNew and updated apps using Apple’s listed APIs, including third-party SDK code
Documented changeFrom 1 May 2024, Apple requires approved reasons for listed API use in app code and third-party SDKs for uploads.
Suggested ownerPrivacy engineering and release engineering
Next verificationCheck 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

MMP install count vs store first-open: F2P reconciliation lab