Privacy, Consent and GDPR in Mobile Apps
By CodexierPublished 6 min read
An app's privacy story is told in four places: what the code actually collects, what the consent screen asks, what the privacy policy promises, and what the App Store and Google Play privacy labels declare. When those four disagree, the consequences arrive from different directions: a store rejection, a user complaint to IMY, or a review that says the app tracks more than it admits. This guide walks through aligning them, starting from the only place that cannot lie, the code.
Data your app actually collects
Most privacy problems in apps come from data the team did not know it was collecting. The analytics SDK that reads the advertising identifier by default, the crash reporter that captures the previous screen with its form fields, the map library that pings its own servers. Start with a network log from a test device over one full session and list every endpoint and what it receives. Then add what your own backend stores. That list is the truth the other three documents must match.
In-app consent and tracking prompts
GDPR does not require consent for everything; it requires a legal basis for each purpose, and consent is only one of them. Data needed to deliver the service the user asked for rests on the contract. Analytics and marketing tracking usually need consent. Apple's tracking prompt is a separate, additional requirement for anything that links the user to data from other companies for advertising. Design the consent so that it asks the right question at the right moment and works when the answer is no.
| Purpose | Legal basis | When to ask | If the user declines |
|---|---|---|---|
| Account, bookings, orders | Contract | No consent needed; explain in the policy | Not applicable |
| Crash reports without personal data | Legitimate interest | Inform, no prompt required | Not applicable |
| Product analytics | Consent in most setups | First launch, after the value is visible | App works fully, analytics off |
| Push notifications | System permission plus purpose | When the user enables a feature that needs them | Feature explains what they will miss |
| Ad tracking across apps | Consent plus Apple tracking prompt | Only if you actually do this | No tracking; app must not degrade |
Store privacy labels
Apple's App Privacy section and Google's Data Safety form both ask the developer to declare what the app collects, whether it is linked to the user, and whether it is used for tracking. Both are declarations you are accountable for, and both stores run automated checks that compare the declaration with what the binary does. Fill them in from the inventory, and update them in the same release that changes the data flow.
- Declare data collected by SDKs, not only by your own code; the SDK vendors publish what they collect for exactly this purpose.
- Linked to the user means tied to an account or identifier. Crash logs with a user id are linked; aggregated counts are not.
- If you say data is not collected but the analytics SDK sends a device identifier, expect a rejection or a forced update.
- Keep a dated copy of each submission so you can show what was declared when.
- Google also requires a public privacy policy link that opens without login and matches the form.
Third-party SDKs and data sharing
Every SDK in the app is a company receiving data about your users, and under GDPR that makes it a processor you need an agreement with, or a separate controller you must name. The practical work is a short register and a rule for adding new ones.
SDK register
Name, vendor, purpose, data sent, processing location, data processing agreement signed yes or no. One row per SDK, reviewed when a dependency is updated.
Data location
Many analytics and messaging vendors process in the United States by default. Choose an EU region where offered and document the transfer mechanism where not.
Adding an SDK
Before it goes into the app: what does it collect, does it need consent, does the policy need a new recipient, do the store labels change. Four questions, answered in the pull request.
Deletion requests and accounts
Both stores now require that an app which lets users create an account also lets them delete it from inside the app, and GDPR gives users the right to erasure regardless. Deletion is a feature, not a support process: it must remove the account, the personal data in your backend and, as far as you can trigger it, the data held by your processors. Decide what you retain for legal reasons, such as invoices under the bookkeeping act, and say so.
- A Delete account action in settings, with a clear explanation of what is removed and what is kept and why.
- Backend deletion that cascades to related records, with a log entry that the deletion happened without keeping the data.
- Deletion requests forwarded to processors that hold user-level data, such as analytics or messaging platforms.
- A way to handle requests by email as well, for users who have already uninstalled the app.
- A retention schedule: what is deleted automatically after inactivity, and when.
When you do not need this from us: an app with no accounts, no analytics and no third-party SDKs has a short policy and simple labels, and the platform templates are enough. The work grows with each SDK and each integration, and it has to be redone at every release that changes data flows, which is why we treat it as part of app maintenance rather than a one-off task; the monthly package on the pricing page includes the SDK register and label updates. If you want to know whether your current app's story adds up, book a call and we will look at it with you.
Frequently asked questions
Do we need a consent screen at first launch?
Only if you do something at first launch that needs consent, typically analytics or marketing tracking. If you can delay those until the user has seen value, ask then; consent rates are higher and the first impression is cleaner. Data needed for the service itself does not need a consent prompt at all.
Our analytics SDK says it is GDPR compliant. Is that enough?
No. The vendor's compliance covers their side; you still decide the purpose, need a legal basis, must name them in the policy and labels, and must sign their data processing agreement. Compliant SDKs make this possible, not automatic.
What happens if the store labels are wrong?
Apple and Google can reject an update, require a correction, or in repeated cases remove the app. Users and researchers also compare labels with network traffic and report discrepancies publicly. Correct labels in the next release, and keep the inventory so it does not happen again.
Can we keep some data after account deletion?
Yes, where a law requires it, such as invoice data under Swedish bookkeeping rules, or where you have a legitimate reason such as fraud prevention with a defined retention. Say what you keep and for how long in the deletion flow and the policy.
Not sure your app's privacy story adds up?
Fifteen minutes: tell us which SDKs are in the app and what the labels say, and we will point out where the four stories are likely to disagree.
Book a free 15-minute call