By EJN Labs · 10 Sep 2026 · 8 min read
Apple’s SDK privacy rules require any commonly used third-party SDK to ship a privacy manifest, an approved reason for any required-reason API it calls, and, where it is a binary, a valid signature, or the app cannot be uploaded to App Store Connect. Mobile teams typically confirm compliance by checking each SDK’s manifest against its real runtime behaviour, not just confirming the paperwork is present.
Why are Apple’s SDK privacy rules suddenly a testing problem?
Apple’s SDK privacy rules turned from paperwork into a build-blocking gate: App Store Connect now refuses uploads over a missing manifest, an undeclared required-reason API, or an unsigned SDK. Mobile teams now have to prove, technically, that every SDK does only what its manifest claims.
The scale of the requirement is easy to underestimate. Apple’s published list of SDKs needing a manifest and signature spans crash reporting, push notifications, authentication, analytics and a long tail of common Flutter plugins, and it has grown substantially since Apple first introduced it. A build that cleared submission a year ago can be rejected today without a single line of your own code changing, simply because a dependency further down the tree was added to the list.
For UK mobile teams building for enterprise, healthcare or public-sector buyers, this lands on top of an existing pressure. Security questionnaires already ask suppliers to evidence that an app’s data practices match what it declares, and an SDK that fails Apple’s own manifest and signature checks is now a visible warning sign before that conversation even starts.
What do Apple’s privacy manifest and SDK signature rules actually require?
Apple’s privacy manifest rules require any app that embeds a commonly used third-party SDK to ship that SDK’s privacy manifest and a valid signature, and require an approved reason for every required-reason API call in the app’s own code and any SDK it uses. Miss either one and App Store Connect blocks the upload.
Apple names specific SDKs on that list, among them major Firebase modules, Meta’s FBSDKCoreKit family, OneSignal, Alamofire and RealmSwift, and any repackaged version of a listed SDK is caught by the same requirement. Crucially, the list is not fixed: Apple has added SDKs to it more than once since first publishing the requirement, which is why a build that passed review previously can fail later even though nothing in your own repository has moved.
What Apple’s rules do not require is any independent verification that a manifest is accurate. The check at submission is structural: is the file present, is it formatted correctly, is the SDK signed. Whether the declared reasons match what the code actually does once the app is running is left entirely to the developer, and that gap is exactly what testing is built to close.
What should a security test check after an SDK privacy rule change?
A test after an SDK privacy rule change should check three things: does every SDK on Apple’s list carry a current manifest and signature, does the declared required-reason usage match what the code calls at runtime, and does data leaving the device match the manifest and your Privacy Nutrition Label.
- SDK inventory audit. Every embedded SDK is mapped against Apple’s current list, flagging anything unsigned, out of date, or shipped without a manifest at all.
- Required-reason API review. Each declared reason is checked against the actual API calls in the build, rather than trusting the string written into the manifest.
- Dynamic traffic capture. The app runs on instrumented real devices while every feature is exercised, recording exactly what leaves the device, to which host, and whether an identifier is linked to the user.
- Label cross-check. Observed behaviour is mapped against both the privacy manifest and the App Store listing, so any mismatch becomes a written finding rather than a guess.
Most of what this uncovers is not malicious. A third-party SDK doing slightly more than its integration guide describes, an analytics library forwarding a device identifier nobody audited, or a required-reason declaration copied from an older SDK release that no longer reflects what the current version does. Each of those is a fix, not a scandal, provided it is caught before submission rather than after.
What does an SDK privacy verification engagement involve?
An SDK privacy verification engagement starts with your build and its dependency list, not a generic checklist. Every SDK is mapped against Apple’s rules, the app runs on instrumented devices to capture what it actually does, and both are checked against your manifest before one buyer-ready report is written.
SDK privacy engagements we run typically take one to two weeks from kick-off to report, depending on how many SDKs are in scope and whether backend APIs need testing alongside the app. Many teams pair this work with a full mobile application penetration test in the same engagement, since a buyer’s questionnaire almost always asks about both in one place. Findings that need a code change, rather than a declaration correction, are flagged early so remediation can start before the final report lands.
What does SDK privacy verification testing cost in the UK?
SDK privacy verification testing typically costs £3,300 to £7,000 in the UK for a focused single-platform check, at 3 to 5 days and a market day rate of £1,100 to £1,400. Adding a full mobile application penetration test alongside it typically takes the scope to £5,500 to £11,200.
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| SDK and manifest verification only | 3 to 5 days | £3,300 to £7,000 |
| SDK verification plus mobile app penetration test | 5 to 8 days | £5,500 to £11,200 |
| SDK verification, mobile app and backend API testing | 7 to 10 days | £7,700 to £14,000 |
| Retest after remediation | 1 to 2 days | £1,100 to £2,800 |
These figures are typical UK market ranges rather than a quote; your actual price depends on how many SDKs are in scope and how many platforms the app ships on. For a broader view of how testing prices are built up across engagement types, see our guide to penetration testing costs in the UK.
How EJN Labs approaches Apple SDK privacy verification
CREST accreditation, ISO 27001 and Cyber Essentials Plus sit behind every EJN Labs engagement, and the people testing are UK-based throughout. We scope SDK privacy work against your own dependency list and manifest, not a generic template, and confirm behaviour on real devices rather than trusting the paperwork.
We treat privacy manifest verification as one strand of a wider mobile assessment rather than a bolt-on extra. Where an SDK’s behaviour does not match its declaration, the report separates a configuration fix from a code-level fix from a simple declaration correction, so a development lead and a compliance lead can both act on it without re-reading the entire document. If you are comparing firms for this kind of work, our guide to choosing a UK penetration testing provider sets out the questions worth putting to any vendor, us included.
Frequently Asked Questions
Do Apple’s SDK privacy rules require a penetration test?
No. Apple’s SDK privacy rules require a manifest, an approved reason for required-reason API calls, and a valid signature for listed SDKs, not a penetration test. Testing is how mobile teams get independent evidence that an SDK’s actual behaviour matches its manifest, which App Store Connect does not check.
What SDKs count as commonly used under Apple’s privacy rules?
Apple publishes the exact list: major Firebase modules, Meta’s FBSDKCoreKit family, OneSignal, Alamofire, RealmSwift and many Flutter plugins. Any repackaged version of a listed SDK is covered too, and the list has grown since Apple first published it, so a dependency audit needs the current version, not last year’s.
What does SDK privacy verification testing cost?
A focused SDK and manifest check typically costs £3,300 to £7,000 in the UK, at 3 to 5 days and £1,100 to £1,400 per day. Adding a full mobile application penetration test takes it to 5 to 8 days, or £5,500 to £11,200. The exact figure depends on scope and comes from the quote form.
How long does an SDK privacy and mobile security test take?
Testing itself typically runs one to two weeks depending on how many SDKs and platforms are in scope, with the report following shortly after. Teams working to a resubmission deadline should allow extra time for remediation and a retest, since a code fix needs verifying first.
What happens if an SDK’s behaviour does not match its privacy manifest?
There are two ways to close the gap, and the report recommends one: change the SDK so its behaviour matches the declaration, or correct the declaration so it matches reality. Most mismatches we identify are configuration issues, not deliberate over-collection, and either fix needs completing before resubmission.
Get an SDK privacy check scoped before your next submission
If a rejected build or a buyer’s questionnaire has put your app’s SDK privacy manifests under the spotlight, we can scope a test around your actual dependency list rather than a generic mobile checklist. Get a CREST pentesting quote and we will come back with a fixed scope and price for your app.
Related research
For adjacent Apple platform requirements and mobile testing scope, see our guides to App Privacy Details in procurement questionnaires, Apple’s medical app rules and what they mean for testing, and how OWASP MASTG shapes the scope of a mobile app penetration test.
Leave a Reply