Both app stores now require you to declare what your app collects before it ships, and both display that declaration to users deciding whether to install.
Most developers answer those questions honestly and get them wrong anyway, for one reason: they answer about the code they wrote, and the stores are asking about everything inside the app, including third-party libraries somebody added two years ago and nobody has thought about since.
This article covers what each store actually requires, how App Tracking Transparency works and when it applies, and the audit that makes the answers accurate.
The three separate obligations
They get merged in conversation and they are distinct.
Apple's App Privacy details, sometimes called privacy nutrition labels. Apple describes explaining how your app handles user data as an important part of submitting to the App Store, with the label's purpose being to help customers understand what data is collected from your app and how it is used [1]. To create it you answer questions about what data your app collects, the use case for each type, and how it is stored [1].
Google Play's Data safety section, which Google describes as a way for developers to show users transparently whether and how they collect, share and protect user data before users install the app. Developers complete a form in Play Console and the information appears on the store listing [2].
App Tracking Transparency, which is Apple's runtime permission framework and a different kind of obligation entirely.
An app can have an extensive privacy label and never need an ATT prompt. It can have a minimal label and still require one. Answering each on its own terms rather than treating them as a single exercise is the first step to getting them right.
Google's requirement catches people out
One detail is worth pulling out because it produces avoidable delays.
Google states that all developers with an app published on Google Play must complete the Data safety form, including apps on closed, open or production testing tracks, and that even developers whose apps do not collect any user data must complete the form and provide a link to a privacy policy [2].
Two consequences.
Collecting nothing does not exempt you. Teams reason that a form about data collection cannot apply to an app that collects nothing, which is intuitive and wrong.
And the obligation covers testing tracks, not just public releases. A team planning a closed beta discovers the requirement when the track will not go live and somebody is already waiting to test.
Complete the form before you need the track.
What ATT actually governs
Apple's definition is precise and worth reading carefully, because the common understanding of it is wrong.
In iOS 14.5 and later, you need the user's permission through the App Tracking Transparency framework in order to track them or access the device's advertising identifier. Tracking refers to linking user or device data collected from your app with user or device data collected from other companies' apps, websites or offline properties, for targeted advertising or advertising measurement purposes [3].
Read that again and notice what it is about: linkage across companies, for advertising purposes. Not analytics in general. Not any data collection.
Which produces the question developers get wrong most often.
"We do not run ads, so ATT does not apply to us." Possibly false. The trigger is not whether you sell advertising. It is whether data from your app is linked with data collected by other companies for advertising or advertising measurement. An attribution SDK measuring which campaign produced an install is doing exactly that, and plenty of apps contain one because somebody added it during a growth push in 2023.
So what decides it is not your intentions. It is what your app actually does, which in practice means which third-party SDKs you have included.
The dependency audit is the whole job
This is the section that matters, and it is the one teams skip.
Your disclosure obligations cover data collected by third-party code in your app, not only code your team wrote. As far as the stores are concerned, you are responsible for what your SDKs do.
Most developers answer the store questions from their own understanding of the app, which is an accurate account of their own code and an incomplete account of the app. The analytics library, the crash reporter, the attribution tool, the advertising network, the customer support widget, the social login SDK: each may collect and transmit things nobody on the current team has ever examined.
So build the list. Every third-party library in the app. For each one, find its own privacy documentation, which the major providers publish specifically so developers can complete these declarations, and record what it collects and for what purpose.
It is a tedious afternoon for a simple app and longer for one with a large dependency tree. It is also the only way to answer accurately, and most teams have never done it. Making the list usually surprises somebody, which is itself a useful outcome.
Do it once properly and subsequent releases become a review rather than a repeat.
A worked audit, start to finish
The dependency audit is the whole job, so here is what doing it actually looks like on a real app rather than in principle.
Step one, list everything. Open your dependency manifest, whichever your platform uses, and write out every third-party package. Not the ones you remember adding, all of them, including transitive dependencies that arrived because something else needed them. A mid-sized app frequently has thirty to sixty entries and the team can name perhaps ten.
Step two, separate the ones that touch data. Most entries are utilities that never transmit anything: a date formatter, an image loader, a layout helper. Set those aside. What remains is usually a much shorter list of analytics, attribution, crash reporting, advertising, payments, support chat, social login and push notification libraries. That is your actual scope.
Step three, find each one's privacy documentation. The major providers publish this specifically so developers can complete store declarations. Record for each: what categories it collects, whether it transmits off-device, whether it links to identity, and whether it does anything that meets Apple's tracking definition.
Step four, reconcile against your current declarations. Put your list next to what you told Apple and Google last time. The gaps are the finding. Expect at least one, and expect it to be something nobody currently on the team chose.
Step five, decide what to remove. Anything on the list that no longer earns its place comes out. This is usually the most valuable part of the exercise, because removing a library removes a disclosure, a review risk, a maintenance burden and an attack surface simultaneously.
Budget an afternoon for a simple app and a couple of days for a large one. Do it once properly and every subsequent release becomes a five-minute check rather than a repeat of the whole thing.
Apple's privacy manifests, and why stable apps break
There is a second, related requirement that catches teams who have not changed anything.
Apple requires third-party SDKs commonly used in apps to ship a privacy manifest describing their data practices, and for binary dependencies a signature, with Xcode validating both at build time. Apple publishes the list of SDKs to which this applies [4].
The consequence is not obvious until it happens to you. The requirement applies when you submit, not when you last wrote code. An app that has been running unchanged for two years still has to satisfy today's requirements the next time you update it for any reason at all.
So a small bug fix turns into a dependency upgrade project, because a library you have not touched since 2023 does not ship a manifest and the build now fails validation.
That is a strong argument for keeping libraries reasonably current rather than batching upgrades, which our guide on saying no to a feature covers as a general maintenance principle. The cost of staying current is small and continuous. The cost of catching up is concentrated and lands at the worst moment, which is when you urgently need to ship a fix.
The questions the forms actually ask
Both stores work through data categories: contact information, identifiers, financial information, location, health data, contacts, user content, usage data, diagnostics. For each, whether you collect it, why, and whether it is shared or linked to identity.
Two definitions cause most of the errors.
Collected versus shared. Collected means data leaves the device to you. Shared generally means it goes to a third party. Teams get this wrong because sending data to an analytics provider they use daily feels like internal use rather than sharing. It is commonly treated as sharing. Read each store's current definitions rather than applying intuition.
Linked to identity. Whether data is associated with the user's identity rather than held genuinely anonymously. Teams over-claim anonymity here routinely. If data can be tied back to an account, a device identifier, or anything else resolving to a person, it is generally linked, regardless of whether you personally use it that way.
The category lists and definitions change, so work from the current form in the console rather than from a copy of last year's answers. Both Apple and Google revise this material without version histories, which is a reason to check current documentation before every significant submission rather than relying on what you did last time.
Designing the ATT prompt properly
If ATT applies, when and how you ask matters.
Timing. After the user has some sense of what your app is and why the request is being made, rather than immediately on first launch before anything has happened. Apple's broader permissions guidance is to request access when the app clearly needs it for a specific feature, and a prompt fired at launch before any value has been shown reliably produces declines. Our guide on apps nobody is using covers permission timing as an onboarding issue in more depth.
Context. You can explain in your own interface beforehand why the permission helps, and that is generally sensible. The system prompt has fixed wording you cannot alter beyond the purpose string. Explaining honestly is legitimate; implying the app will not work without it is not.
The declined state. If a user declines, you must not track them or access the advertising identifier, and your app should continue to work normally. Design for declined as the default case rather than as an exception. Building an experience that degrades or repeatedly nags after a decline is poor practice and a review risk.
Where the declarations contradict your own policy
Here is a mismatch that exists in a great many apps and that almost nobody checks.
The store declaration is completed by a developer, from a technical view of the app. The privacy policy is usually written by somebody else, often adapted from a template, describing intentions rather than implementation.
They frequently disagree.
A privacy label declaring collection of device identifiers and location, alongside a website privacy policy that mentions neither because it was written for the website, is a contradiction sitting in public on two different properties. It is also precisely what any inquiry would look at first.
Read them side by side. Both stores require a privacy policy link, and Google states it explicitly even for apps collecting no data [2]. The link needs to work, resolve to a genuine policy covering that app, and stay live. A dead privacy policy link is a trivially avoidable rejection and it happens regularly when a marketing site gets redesigned and nobody checks the store listings.
If your app collects things your general company policy does not mention, extend the policy. That is usually sufficient and it is considerably cheaper than the alternative of leaving the gap.
What this is not
It is not UAE data protection compliance. Store disclosures are platform requirements set by Apple and Google. They overlap with data protection law in that both concern personal data, and they are different obligations with different scopes and different enforcement. Our guide on PDPL compliance covers the local framework, and satisfying a store form does not discharge it.
It is not a route around obligations by distributing internally. Google's requirement covers testing tracks. For genuinely internal enterprise distribution outside the public stores, the store requirements do not apply in the same way, and your data protection obligations do not change at all. Only the platform layer differs.
What goes wrong, in order of frequency
Five failure patterns, roughly ranked by how often we see them.
An SDK collecting something nobody knew about. The clear leader. The declaration is honest about the team's own code and silent about a library added during a growth experiment two years ago. Nobody is being deceptive; nobody looked.
A declaration completed accurately at launch and never revisited. Features were added, libraries changed, and the store listing still describes the app as it existed at version 1.0. This drifts slowly enough that no single release feels like the moment to check.
A privacy policy that contradicts the store label. Written by different people at different times for different purposes, never read side by side. It is a contradiction sitting in public on two properties you control.
A dead or wrong privacy policy link. Usually caused by a website redesign where nobody thought about the app store listings. Trivially avoidable and reliably costs a review cycle.
Over-claiming anonymity. Declaring data as not linked to identity when it is tied to an account or a persistent device identifier. Teams do this sincerely, because they do not personally use the data that way, which is not the test.
Notice that four of the five are process failures rather than knowledge failures. The team knew what the rules were. Nothing in the release process required anybody to check.
Where this sits alongside your other privacy work
Businesses running an app usually have three privacy artefacts in flight and no single owner across them.
The store declarations describe what the app collects, completed by a developer, visible to every prospective user before install.
The privacy policy describes what the business does with personal data, usually written by legal or adapted from a template, linked from both the app and the website.
The data protection compliance work under UAE law is a separate obligation with its own scope, covering how you collect, process, store and delete personal data across the whole business, not only in the app.
These should be consistent and frequently are not, because each was produced by a different function at a different time. The store declaration is the most technically accurate and the narrowest. The privacy policy is the most public-facing and the most likely to be generic. The compliance work is the broadest and the one most likely to be incomplete for a small business.
The practical suggestion is not to merge them, because they genuinely serve different purposes. It is to have one person read all three together once a year and note where they disagree. That is a half-day exercise that surfaces problems no individual review would catch, because each artefact looks fine on its own terms.
Reduce what you have to declare
The most underrated response to all of this is to collect less.
Remove SDKs you no longer use. More common than teams expect. An attribution tool from a campaign that ended, an analytics library replaced but never deleted, a support widget from a vendor you left.
Question whether each remaining library earns its place. Every one contributes to your declaration, your review risk, your app size and your maintenance burden.
Collect fewer identifiers where you reasonably can.
A smaller dependency footprint produces a simpler declaration, a faster review, and less to keep accurate over time. Whether a lighter privacy label improves conversion is a fair question, and we are not going to quote you a figure, because the published numbers come from analytics and marketing vendors with an interest in the answer. Treat it as good practice rather than as a measurable lever.
One more thing worth checking
Both stores expose your declaration publicly, which means your competitors' declarations are visible to you too.
That is a genuinely useful and almost entirely unused research input. Open the store listing for three apps in your category and read their privacy labels. You will learn what data collection is normal in your market, whether you are an outlier in either direction, and occasionally that a competitor is collecting something you had not thought to.
Being a visible outlier on the heavy side is worth knowing about, since the label sits in front of every prospective user at the moment they are deciding. Being an outlier on the light side is worth knowing too, because it is something you could reasonably say in your marketing.
Neither observation should drive your engineering. It costs ten minutes and it occasionally changes a priority.
Making it stick
Two process changes prevent the drift that produces inaccurate labels over time.
Ownership. A developer who can see the dependency list, working with whoever owns privacy or legal. The technical view is needed for accuracy; the governance view is needed to check the answers against your policy and your obligations. Completed by a developer alone, the answers tend to be technically accurate and inconsistent with what the business has published elsewhere.
A release checklist item. At each release, check whether any dependency was added, removed or upgraded, and whether any new feature collects something new. If either happened, revisit the declarations before submitting.
That single checklist line is the difference between a declaration that stays accurate and one that quietly drifts away from reality across a year of releases.
Before your next submission
Four checks, fifteen minutes.
Confirm the current requirements on both stores rather than assuming they match last time. Verify your privacy policy link resolves and describes the app. Confirm no dependency changed since your last declaration. And read your privacy label next to your privacy policy to check they agree.
If you want the deeper version, an SDK and disclosure audit covering what your app actually collects, whether your store declarations match, whether your privacy policy agrees with both, and what could be removed starts from around AED 2,500 with us. Final pricing depends on scope, and these are our own figures rather than a market survey. Legal questions about your obligations belong with a qualified adviser rather than with us.
The free version remains the list: every third-party SDK in your app, with what each one collects, taken from its own documentation rather than from memory.
References
- Apple, App Privacy Details on the App Store
- Google Play Console Help, provide information for Google Play's Data safety section
- Apple, user privacy and data use
- Apple, upcoming third-party SDK requirements
- Apple, App Store Review Guidelines
- Apple App Store Connect Help, manage app privacy
- SKIMBOX, app store rejection and review guidelines
- SKIMBOX, your app is built and nobody is using it
- SKIMBOX, product analytics and event tracking
- SKIMBOX, PDPL compliance in the UAE
Apple and Google revise these requirements without published version histories, so check the current documentation before each significant submission. Store disclosure requirements are platform obligations and are not a substitute for compliance with UAE data protection law. This article is not legal advice.
