GDPR for App Developers: Privacy by Design, User Consent and Mobile Compliance
If you build mobile or web apps, GDPR applies to you whether you have users in Frankfurt or just a handful of beta testers in London. App developers face a distinct set of compliance challenges: you collect data through code, often invisibly to users, through SDKs you didn't write, stored on servers you don't own. This guide covers everything development teams need to know to ship GDPR-compliant apps in 2026.
Privacy by Design: Building Compliance In, Not Bolting It On
Privacy by design is not just a philosophy — it is a GDPR requirement under Article 25. It means that data protection must be considered at the earliest stage of development, not added as an afterthought when legal raises a flag two weeks before launch.
In practice, privacy by design for app developers means:
- Default to minimum data collection. If you don't need a field, don't collect it. If you don't need precise location, use approximate location. If you don't need real-time tracking, don't enable it.
- Design access controls before you design features. Who in your team can see user data? Who can export it? These decisions should be made before the database schema is written.
- Pseudonymise where possible. Store a user ID rather than an email address in analytics events. Keep the mapping table separately secured.
- Consider data flows in architecture reviews. Every API call that sends personal data should be documented and justified.
The goal is to make privacy decisions explicit rather than accidental. When you retrofit privacy into an app that wasn't built with it in mind, you invariably miss things.
App Store Privacy Requirements: Apple and Google
Both major app stores now require detailed privacy disclosures that go beyond a link to your privacy policy.
Apple App Privacy Labels
Apple requires all apps to complete a privacy nutrition label in App Store Connect covering:
- Data used to track you (linked to identity, used for advertising)
- Data linked to you (collected and associated with your identity)
- Data not linked to you (collected but not tied to identity)
Apple's categories cover contact info, health and fitness, financial info, location, identifiers, usage data, diagnostics, and more. You must disclose data collected by third-party SDKs, not just your own code. Getting this wrong — or omitting it — can result in your app being rejected or removed.
Google Play Data Safety
Google's equivalent is the Data Safety section, which asks you to declare:
- What data your app collects
- Whether data is shared with third parties
- Whether collection is optional or required
- Whether users can request data deletion
Both Apple and Google have tightened enforcement. A mismatch between your declared data practices and what your app actually does is a compliance failure on two fronts: the app store and GDPR.
User Consent Flows and Cookie/Tracking Consent
Web apps built with cookies and tracking pixels need a consent management platform (CMP) that meets GDPR's standard for valid consent. The requirements are clear:
- Consent must be freely given — no cookie walls that block access unless users agree
- Consent must be specific — bundling analytics and advertising consent is not valid
- Consent must be informed — users must understand what they're agreeing to
- Consent must be unambiguous — pre-ticked boxes do not count
- Consent must be withdrawable — users must be able to change their minds as easily as they gave consent
For mobile apps, consent flows have their own patterns. Push notification permissions, location access, camera access — each should be requested at the moment it's clearly needed, with a clear explanation of why. Asking for every permission on first launch is both a UX failure and a GDPR red flag.
Tools like Custodia can scan your web app to identify trackers and cookies that fire before consent is given — a common issue when third-party scripts load on page ready before your CMP has fired.
Data Minimisation: Collect Only What You Need
Article 5(1)(c) of GDPR requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." This is data minimisation, and it has direct implications for how you build features.
Practical examples:
- If you're building a food delivery app, you need delivery address. You don't need date of birth unless you're verifying age for alcohol.
- If you're building a productivity tool, you need email for login. You don't need phone number unless it's required for two-factor authentication.
- If you're running A/B tests, you need a session or user identifier. You usually don't need to tie that to a real identity.
Review your database schema and API contracts with data minimisation in mind. Every field that holds personal data should have a documented justification.
User Account Data and the Right to Deletion
GDPR's right to erasure (Article 17) means users can request that you delete their personal data. For app developers, this has to be a real, functional feature — not a process that involves someone manually running a SQL query.
A proper deletion flow needs to:
- Delete or anonymise the user's personal data across all systems (primary database, backups if feasible, analytics, email marketing, support tools)
- Handle cascading data relationships (what happens to content the user created? Comments? Purchases?)
- Confirm to the user that deletion has been completed
- Complete within 30 days of the request
Hard deletes are simpler from a compliance standpoint. Soft deletes (setting a deleted_at flag) still retain personal data, which means the right to erasure is not satisfied until that data is purged. If you use soft deletes for recovery purposes, implement a hard purge that runs automatically after a defined retention period.
Location Data as Sensitive Data
Location data receives heightened attention under GDPR because it can reveal where a person lives, works, worships, or seeks medical care. Precise GPS coordinates are particularly sensitive.
If your app uses location:
- Request only the precision you need. Many apps can function with approximate location (city or region level) rather than precise GPS.
- Don't persist location data longer than necessary. If you need location to complete a delivery, you don't need to store every GPS ping for six months.
- Be explicit in consent flows about what location data you collect, how long you keep it, and who you share it with.
- iOS and Android both offer background location as a separate permission. Only request it if you genuinely need it, and be prepared to justify it.
Push Notification Consent
Push notifications require explicit opt-in permission on both iOS and Android. This is technically enforced by the operating system — users must tap "Allow" for your app to send notifications.
Under GDPR, this is also a consent requirement. Users must understand what kinds of notifications they'll receive. If you use push notifications for marketing as well as transactional messages, these should ideally be separate consent decisions. A user who wants order status updates may not want promotional offers.
Document push notification consent in the same way you would email marketing consent: when consent was given, what the user was shown, and any subsequent changes.
Children's Apps: COPPA and GDPR Together
If your app is directed at children — or is likely to attract children — you face a dual compliance challenge. In the US, COPPA requires verifiable parental consent for users under 13. Under GDPR, the age of digital consent varies by EU member state (13-16), and parental consent is required for children below that threshold.
For app stores, both Apple and Google require you to declare whether your app is directed at children. Apps that target children under 13 are placed in restricted categories with limits on advertising, analytics, and data collection.
In practice:
- Avoid behavioural advertising entirely in children's apps
- Limit analytics to what is strictly necessary for app function
- Remove third-party SDKs that collect data for their own purposes (many analytics and advertising SDKs are prohibited in children's apps)
- Implement age gates at registration, and consider how to verify age rather than just asking users to self-declare
Third-Party SDKs and Analytics Libraries as Sub-Processors
Every third-party SDK you integrate into your app is a potential data processor. Under GDPR, if an SDK transmits personal data to a third party, that third party is your sub-processor and you need a Data Processing Agreement (DPA) with them.
Common culprits:
- Analytics SDKs (Firebase Analytics, Amplitude, Mixpanel) — collect device IDs, session data, and user behaviour
- Crash reporting (Crashlytics, Sentry) — may capture device information and user context at the point of crash
- Advertising networks (Google Ads, Meta Audience Network) — designed specifically to collect data for advertising profiles
- Customer support tools (Intercom, Zendesk SDK) — may store conversation history and user metadata
Audit every SDK in your project. For each one, ask: what data does this collect? Where is it stored? Do I have a DPA? Can users opt out?
Custodia's scanning tools can help identify trackers and analytics calls on your web app, giving you a starting point for a full sub-processor audit. For mobile apps, review your Podfile, package.json, or build.gradle for third-party dependencies, then cross-reference against each vendor's privacy documentation.
Privacy Policy Requirements for Apps
Your app needs a privacy policy that covers:
- What personal data you collect and why
- The legal basis for each type of processing
- How long you retain data
- Who you share data with (including sub-processors)
- Users' rights under GDPR (access, rectification, erasure, portability, objection)
- How users can exercise those rights (and a contact method)
- Your data protection contact or DPO if applicable
- Cross-border transfer mechanisms if you transfer data outside the EEA
Both Apple and Google require a privacy policy URL for any app that collects personal data. The policy must be accessible from within the app, not just linked in the App Store listing.
Handling Data Breach Notifications
GDPR requires you to notify your supervisory authority within 72 hours of discovering a personal data breach that poses a risk to individuals. If the risk is high, you must also notify affected users "without undue delay."
For app developers, breach readiness means:
- Knowing what personal data you hold and where it is
- Having monitoring in place to detect unauthorised access
- Having a response plan that includes notification drafts, contact details for your supervisory authority, and clear internal escalation paths
- Documenting breaches even when you decide notification is not required (you need to show the reasoning)
Seventy-two hours is not long. Development teams that discover a breach on a Friday evening need to know exactly who to call and what to do.
DSAR Handling at Scale
Data Subject Access Requests can come from any user at any time. At small scale, handling them manually is possible. At scale, you need a system.
A scalable DSAR process includes:
- A dedicated intake mechanism (a form, a dedicated email address, or an in-app request option)
- Identity verification before releasing data
- An automated or semi-automated way to gather data from all relevant systems
- A standard response template and review process
- A tracking system to ensure you respond within 30 days
If you use a customer data platform or CRM that aggregates user data, investigate its DSAR export capabilities before you need them.
Cross-Border Data Transfers: US Servers and EU Data
If you store EU user data on US servers, GDPR's rules on international data transfers apply. Since Schrems II invalidated the original Privacy Shield, the legal landscape has evolved. The EU-US Data Privacy Framework (DPF), adopted in 2023, provides a mechanism for data transfers to certified US organisations.
If your infrastructure provider (AWS, Google Cloud, Azure) is DPF-certified, and you're using EU-region data centres, the transfer risk is lower. But you should still:
- Confirm your cloud provider's DPF certification and applicable DPAs
- Use EU-region infrastructure for EU user data where possible
- Document your transfer mechanism in your privacy policy and records of processing
- Use Standard Contractual Clauses (SCCs) where DPF certification isn't available
Practical Compliance Checklist for Development Teams
Use this checklist as a starting point for your compliance review:
Architecture and Data
- Data minimisation applied to all models and APIs
- Personal data documented in a data map or RoPA
- Retention periods defined and automated where possible
- Pseudonymisation or anonymisation applied where feasible
Consent
- Consent management implemented for web (cookies and tracking)
- Push notification consent documented
- App permissions requested contextually, not on launch
- Consent records stored
Third Parties
- All third-party SDKs audited for data collection
- DPAs in place with all sub-processors
- App store privacy declarations completed accurately
User Rights
- Account deletion flow implemented and tested
- DSAR intake and response process documented
- Data export capability in place
Security and Breach
- Monitoring in place for unauthorised access
- Breach response plan documented
- Team knows the 72-hour notification requirement
Documentation
- Privacy policy current, accurate, and accessible from the app
- Records of processing activities maintained
- DPO or privacy contact designated if required
Where to Start
Privacy compliance for apps can feel overwhelming when you look at everything at once. The most effective starting point is understanding what your app actually does — what data it collects, where it sends it, and who can see it.
Start with an automated scan of your web app at https://app.custodia-privacy.com/scan to identify trackers, cookies, and data flows you may not be aware of. Then work through the checklist above with your team, prioritising the highest-risk areas: consent, deletion, and third-party SDKs.
GDPR compliance is not a one-time project. It's a practice — one that gets easier when it's built into your development workflow from the start rather than treated as a legal problem for someone else to solve.
Top comments (0)