Privacy declarations are now a submission requirement on both stores, and they must describe what your app actually collects - including collection performed by SDKs you embedded and never examined. Most inaccurate declarations are honest mistakes by teams who did not know what their analytics library was doing.
01You are accountable for your SDKs
An analytics, advertising or crash reporting SDK that collects identifiers, location or contact data is collecting it on your behalf. From a regulator's and a store's perspective there is no distinction between your code and code you chose to embed.
This is where declarations most often go wrong. A team declares what their own code collects, having never audited the five third-party libraries that also collect device identifiers and send them to servers in other jurisdictions.
The required exercise is an inventory: every SDK, what it collects, where it sends it, and whether you have a lawful basis for that. It is tedious and it is the only way to make an accurate declaration.
02Consent has to be real
Where consent is your lawful basis, it must be freely given, specific and revocable - which rules out several patterns that remain common.
- Do not initialise tracking SDKs before consent. Many collect on import, so the decision must gate initialisation, not just event sending.
- Pre-ticked boxes and bundled consent are not valid. Analytics and advertising need separate decisions.
- Refusing must be as easy as accepting, and must not degrade unrelated functionality.
- Consent must be withdrawable in-app, and withdrawal must actually stop collection rather than only hiding the toggle.
- Record what was consented to and when; without an audit trail you cannot demonstrate compliance.
03Deletion that reaches everywhere
Account deletion is a store requirement and a statutory right in several jurisdictions, and it must reach every place the data went - your database, your backups within a defined window, your analytics provider, and any third party you shared it with.
Deletion requests that only remove the row in your primary database are incomplete. Analytics platforms retain event histories keyed to a user identifier; those need their own deletion path, and most vendors provide an API for it.
Document the process and the timelines. When a customer or regulator asks, the answer needs to be a described procedure with evidence, not an assurance.
04Keeping declarations accurate over time
Declarations drift. A new SDK added for a feature changes what the app collects, and nobody updates the store listing because it is not part of the release checklist.
Add it to the checklist. Any dependency change that touches network access or device identifiers should trigger a review of the privacy declaration before submission - it is a five-minute check that prevents a category of problem that is expensive to unwind.
Topics
Marcus Hale
Security Lead · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer