Mobile apps often collect more personal information than businesses realise.
A simple app may process a user’s name, email address, IP address, device identifier, location, payment information, usage behaviour or advertising ID. Under the General Data Protection Regulation (GDPR), much of this information can qualify as personal data.
For European businesses, GDPR compliance therefore needs to be considered while the mobile app is being designed and developed, not only after it has been published.
GDPR applies to organisations established in the EU that process personal data and can also apply to businesses outside the EU when they offer goods or services to people in the EU or monitor their behaviour.
This guide explains the most important GDPR requirements for mobile apps and what businesses should consider before launching an Android or iOS application.
What Is GDPR?
The General Data Protection Regulation (GDPR) is the European Union’s main data-protection framework.
It regulates how organisations collect, use, store, share and protect personal data.
For businesses developing mobile applications, GDPR matters whenever information can identify a person directly or indirectly.
The European Commission gives examples of personal data that include:
- Name and surname
- Home address
- Personal email address
- Identification numbers
- Location data
- IP addresses
- Cookie IDs
- Mobile advertising identifiers
- Certain healthcare information
Importantly, encrypted or pseudonymised information can still be personal data if a person can ultimately be re-identified. Truly irreversible anonymised information is treated differently.
Therefore, an app does not need to collect someone’s name to process personal data.
A device identifier or location history can already create GDPR obligations.
Does GDPR Apply to Your Mobile App?
GDPR may apply if your business operates in the EU and processes personal information.
It can also apply when a company is located outside the EU but offers products or services to people in the EU or monitors their behaviour there.
For example, imagine a software company outside Europe launches a fitness application specifically for users in Germany, France and Spain.
The fact that its developers or servers are located outside the EU does not automatically put the service outside GDPR.
Businesses should therefore consider who the application serves and what processing takes place, rather than only where the development company is located.
The 7 GDPR Principles Mobile Apps Should Follow
GDPR compliance becomes easier to understand when you start with its core principles.
The European Commission identifies seven key principles.
1. Lawfulness, Fairness and Transparency
Businesses need a valid reason for processing personal data and should clearly explain what they are doing with it.
Users should not have to discover hidden data collection after installing the application.
2. Purpose Limitation
Collect information for specific purposes.
For example, if a delivery application requests a user’s location to deliver an order, the business should clearly define that purpose.
The information should not automatically be reused for unrelated purposes without an appropriate legal basis.
3. Data Minimisation
Collect only the information you genuinely need.
If your application only needs a user’s city, consider whether collecting continuous precise GPS location is necessary.
4. Accuracy
Personal information should be accurate and kept up to date where necessary.
Apps that maintain user profiles should provide appropriate ways to correct inaccurate information.
5. Storage Limitation
Personal information should not be stored indefinitely simply because storage is available.
Businesses should define appropriate retention periods.
6. Integrity and Confidentiality
Personal information must be appropriately protected against unauthorised access, accidental loss, destruction and other security risks.
7. Accountability
The business needs to comply with GDPR and be able to demonstrate that compliance.
These principles should influence both the technical architecture and the user experience of the application.
1. Know Exactly What Data Your App Collects
One of the first steps should be creating a clear inventory of personal information processed by the application.
Do not look only at information users manually enter.
Your app might also collect information automatically.
For example:
Account information
Name, email address, phone number and profile information.
Device information
IP address, device identifiers and technical information.
Location information
Approximate or precise geographical location.
Usage information
Pages or screens viewed, buttons clicked and interactions with features.
Payment information
Billing information and transaction-related data.
Media
Photos, videos or files uploaded by users.
Contacts
Address-book information if the app requests contact access.
Health information
Activity, medical, fitness or other health-related information.
Advertising information
Advertising identifiers and tracking information.
The European Commission specifically recognises information such as location data, IP addresses and mobile advertising identifiers as examples of personal data.
This means businesses should review not only their own database but also what third-party SDKs inside the application collect.
2. Identify a Legal Basis for Processing
A common misunderstanding is that GDPR requires consent for every processing activity.
It does not.
Under GDPR, organisations need an appropriate legal basis for processing personal data. The EDPB lists six potential bases:
- Consent
- Performance of a contract
- Legal obligation
- Vital interests
- Public interest
- Legitimate interests
The correct basis depends on why and how the information is being processed.
Consider a food-delivery app.
The company may need a customer’s delivery address to complete the order. Processing required to provide the service may have a different legal basis from optional advertising or marketing activities.
Businesses should therefore determine the appropriate legal basis for each processing purpose, rather than putting everything under a single “I agree” button.
3. Do Not Use Consent for Everything
Consent is important, but businesses should not automatically treat it as the legal basis for every feature.
When consent is the appropriate basis, GDPR sets specific requirements.
According to the EDPB, valid consent must be:
Freely given
The person needs genuine choice and control.
Specific
Consent should relate to clearly defined purposes.
Informed
Users need sufficient information to understand what they are agreeing to.
Unambiguous
There should be a clear indication that the person agrees.
Users must also be able to withdraw consent without suffering inappropriate negative consequences.
For example, avoid one broad checkbox saying:
“I agree to all data processing.”
Instead, where consent is the appropriate basis, separate genuinely different optional purposes when necessary.
4. Make Rejecting Optional Tracking Easy
Consent interfaces should not be deliberately designed to push users towards accepting optional processing.
The European Commission warns about deceptive design techniques such as hiding a reject option, making acceptance much easier than rejection or using misleading language.
For example, an app should avoid presenting:
ACCEPT ALL
as a large obvious button while making the alternative difficult to find through several additional screens.
When consent is required, users should receive a genuine choice.
This is especially important for apps using advertising, analytics or other technologies that may require consent under applicable GDPR and ePrivacy rules.
5. Create a Clear Mobile App Privacy Policy
A mobile application that processes personal information needs to provide appropriate privacy information.
The privacy notice should be easy for users to find and understand.
According to European Commission guidance, users should receive information including the identity of the organisation, purposes of processing, relevant categories of personal information, legal basis and retention information.
Depending on the processing, additional disclosures can be necessary.
A useful mobile-app privacy notice will generally address questions such as:
Who is collecting the information?
Clearly identify the company responsible for the processing.
What information is collected?
Explain the relevant categories.
Why is it collected?
Describe the actual purposes.
What is the legal basis?
Identify the relevant GDPR basis for each processing activity where required.
Who receives the information?
Explain relevant sharing with service providers and other recipients.
How long is it retained?
Provide appropriate retention periods or criteria.
Is information transferred outside the EEA?
Explain applicable international-transfer arrangements where relevant.
What rights do users have?
Explain how users can exercise their data-protection rights.
Avoid making the privacy notice unnecessarily complicated.
GDPR transparency works better when information is written in clear language that ordinary app users can understand.
6. Use Privacy by Design and by Default
Privacy should not be something developers add one week before an application launches.
The GDPR requires data protection by design and by default in applicable processing.
European Commission guidance explains that organisations should introduce appropriate technical and organisational safeguards during the earliest stages of designing processing operations. Default settings should also provide strong privacy protection.
Consider a social application.
Instead of automatically making every new user’s profile public, a more privacy-friendly default might limit profile visibility until the user actively changes the setting.
The same thinking can be applied throughout mobile development.
Ask:
Does the app really need this information?
Does it need it immediately?
How long should it be stored?
Which employees should have access?
Can it be pseudonymised?
Can the feature work without collecting it?
These questions are often much easier to solve during development than after thousands of people are already using the app.
7. Request Only Necessary App Permissions
Mobile applications can request access to powerful device features, including:
- Camera
- Microphone
- Photos
- Contacts
- Precise location
- Bluetooth
- Notifications
The GDPR’s data-minimisation principle means businesses should consider whether the data they collect is actually necessary for their stated purpose.
Suppose you are developing a calculator app.
It probably does not need access to the user’s contacts or precise location.
A food-delivery application, however, may legitimately require location information for some features.
Permissions should therefore have a clear connection to functionality.
Avoid requesting every possible permission when the application first opens simply because the feature might be useful later.
Requesting access when the user actually needs the relevant feature can also make the reason for the permission easier to understand.
8. Be Careful With Location Data
Location information deserves particular attention in mobile applications.
The European Commission explicitly lists mobile-phone location data as an example of personal data.
Before collecting location information, determine what level of accuracy is actually necessary.
For example, a weather application might be able to provide useful information with approximate location rather than continuous precise GPS tracking.
A taxi or navigation application may genuinely require more precise location information while the service is being used.
Businesses should therefore consider:
- Why location is required
- Whether precise location is necessary
- Whether background tracking is necessary
- How long location history is retained
- Who receives the location information
- What legal basis applies
Collecting less information can reduce both privacy risk and security exposure.
9. Review Every Third-Party SDK
Your company might not intentionally collect much information while third-party software embedded inside the application does.
Mobile applications commonly integrate services for:
- Analytics
- Advertising
- Crash reporting
- Payments
- Maps
- Customer support
- Authentication
- Push notifications
- Cloud storage
- Artificial intelligence
Before adding an SDK, understand what information it processes.
For example, check whether it receives IP addresses, advertising identifiers, device information, usage behaviour or location.
Businesses also need to understand whether relevant third parties act as processors, independent controllers or in another role.
Under GDPR, a controller determines why and how personal information is processed, while a processor processes information on behalf of a controller.
This distinction can affect contracts and responsibilities.
10. Protect Personal Data Properly
A privacy policy alone does not make an application GDPR compliant.
Businesses must also implement appropriate security.
The GDPR principles require suitable technical and organisational safeguards against unauthorised or unlawful processing and accidental loss, destruction or damage.
Depending on the application and risk level, practical measures can include:
- Encryption in transit
- Appropriate encryption at rest
- Secure authentication
- Strong password handling
- Multi-factor authentication where appropriate
- Role-based access controls
- Secure API design
- Regular dependency updates
- Logging and monitoring
- Secure backups
- Access reviews
- Vulnerability testing
Security requirements should reflect the sensitivity and risks of the information involved.
An application processing restaurant bookings will have a different risk profile from an application processing medical information.
11. Give Users Control Over Their Data
GDPR provides individuals with several rights concerning their personal information.
Depending on the circumstances, these include rights relating to:
- Access
- Rectification
- Erasure
- Restriction
- Objection
- Data portability
- Withdrawal of consent
The European Commission notes that people can ask organisations what personal data they hold, request corrections and, in appropriate circumstances, request deletion or object to certain uses.
Businesses should therefore decide how these requests will actually work.
For example, an app could provide:
Settings → Privacy → Delete Account
rather than forcing users to search through several pages to discover how to submit a deletion request.
However, deleting an account does not always mean every piece of information must immediately disappear. Some data may need to be retained where another lawful requirement or exception applies.
The important point is to create a documented process rather than handling every privacy request manually after it arrives.
12. Handle Account Deletion Properly
Many apps now provide an account-deletion option.
From a GDPR perspective, businesses should think beyond simply removing the user from the visible interface.
Consider where their information exists:
- Main production database
- User profile
- Uploaded files
- Analytics systems
- Marketing platforms
- Customer-support systems
- Backups
- Third-party processors
Businesses should define what is deleted, what may legitimately need to be retained and how long remaining information stays in relevant systems.
This makes implementing user deletion requests much more reliable.
13. Set a Data Retention Policy
“Keep everything forever” is not a good default.
GDPR includes a storage-limitation principle: personal information should generally be kept no longer than necessary for the purpose for which it was collected.
Different categories of information may require different retention periods.
For example:
An inactive user’s temporary application logs may not need to remain indefinitely.
Financial transaction information may have separate legal retention requirements.
A business should therefore define retention based on the purpose and applicable obligations rather than using one arbitrary period for every database table.
Where practical, deletion or anonymisation can also be automated.
14. Understand International Data Transfers
A European mobile app may use infrastructure located outside Europe.
For example, an app might use an international cloud provider, analytics platform, customer-support service or AI API.
This does not automatically make the service non-compliant.
However, GDPR includes requirements governing transfers of personal information to countries outside the relevant European framework.
The European Commission identifies mechanisms including adequacy decisions, Standard Contractual Clauses (SCCs) and Binding Corporate Rules (BCRs) as safeguards used in international data transfers.
Businesses should therefore know:
- Where personal information is processed.
- Which providers receive it.
- Whether information leaves the EEA.
- What transfer mechanism applies when required.
This is particularly important when selecting cloud, analytics and AI providers.
15. Know When a DPIA May Be Required
A Data Protection Impact Assessment (DPIA) is a structured assessment used when processing is likely to create high risks for people’s rights and freedoms.
Not every mobile application automatically needs one.
However, businesses should assess whether their processing creates higher risks, particularly when using sensitive information, extensive monitoring, profiling or other high-risk processing.
The European Commission explains that GDPR follows a risk-based approach, meaning safeguards should correspond to the nature, scope, context and purposes of processing and the resulting risks.
A DPIA is therefore something to consider during product planning rather than after launch.
16. Does Every App Need a Data Protection Officer?
No.
Being subject to GDPR does not automatically mean every company needs a Data Protection Officer, or DPO.
The requirement depends on the organisation and its processing activities.
European Commission guidance notes, for example, that SMEs may need a DPO when relevant core activities involve certain large-scale monitoring or processing of sensitive information.
Therefore, a small business running a straightforward appointment application should not automatically assume it needs a full-time DPO.
However, businesses handling large-scale sensitive data or systematic monitoring should examine the requirement carefully.
17. Prepare for Personal Data Breaches
No application can assume that a security incident will never happen.
Businesses should have a process for identifying, investigating and responding to personal-data breaches.
That means your team should know:
- Who investigates the incident
- Which systems were affected
- What personal information was involved
- How many people may be affected
- What risks the breach creates
- What evidence should be documented
- Whether notification obligations are triggered
Incident-response planning is much easier before a breach occurs.
GDPR obligations regarding breaches depend on the circumstances and risk, so businesses should have appropriate technical, organisational and legal processes ready.
GDPR Checklist for Mobile App Development
Before launching an app for European users, a practical review should include:
Data
☐ Identify all personal data collected
☐ Document why each category is needed
☐ Remove unnecessary collection
☐ Define retention periods
Legal basis and transparency
☐ Determine the legal basis for each processing purpose
☐ Create an understandable privacy notice
☐ Implement valid consent where consent is the appropriate basis
☐ Make consent withdrawal appropriately easy
App design
☐ Apply privacy by design
☐ Use privacy-friendly defaults
☐ Request only necessary permissions
☐ Avoid unnecessary background collection
Third parties
☐ Review analytics SDKs
☐ Review advertising SDKs
☐ Review cloud providers
☐ Review payment services
☐ Review other APIs and processors
☐ Assess international transfers
Security
☐ Secure APIs
☐ Encrypt sensitive information where appropriate
☐ Restrict employee access
☐ Secure authentication
☐ Maintain dependencies and infrastructure
☐ Prepare an incident-response process
User rights
☐ Provide a process for access requests
☐ Allow correction where appropriate
☐ Handle deletion requests
☐ Support consent withdrawal
☐ Handle objections and other applicable rights
This checklist is a starting point. Exact requirements depend on the app, data, users and processing activities.
Example: GDPR Compliance for a Fitness App
Consider a European company developing a fitness application.
The app collects:
- Name
- Email address
- Age
- Activity information
- GPS running routes
- Heart-rate information
- Device information
This application requires more privacy planning than a basic calculator because some of its processing may involve particularly sensitive information.
The company should first determine which information is genuinely required.
For example, if precise GPS information is only needed while recording a run, continuous background location collection may not be necessary.
The company should also define appropriate legal bases, explain processing clearly, secure the information, review third-party SDKs, determine retention periods and provide mechanisms for applicable user rights.
Privacy decisions therefore become part of the product architecture, rather than simply text placed inside a privacy policy.
Common GDPR Mistakes in Mobile Apps
Several mistakes can create unnecessary privacy risk.
Collecting Data “Just in Case”
If information does not have a defined purpose, reconsider collecting it.
Copying Another App’s Privacy Policy
Your privacy notice needs to describe your actual processing.
Copying another company’s policy can produce inaccurate disclosures.
Assuming Everything Requires Consent
Consent is one legal basis, not the only one.
Adding Privacy After Development
This can require expensive changes to databases, APIs and application flows.
Ignoring Third-Party SDKs
An SDK can process personal information even when your own application code does not directly store it.
Making Consent Difficult to Withdraw
Where processing relies on consent, users need an appropriate way to withdraw it. The EDPB states that withdrawing consent should be as easy as giving it.
Storing Data Forever
Define retention periods based on actual purposes and applicable legal requirements.
GDPR Should Start Before Mobile App Development
The best time to think about privacy is before development begins.
During planning, create a simple map:
User → Mobile App → API → Database → Third-Party Services
Then identify what personal information moves through each stage.
For example:
Registration → name and email
Payment → payment provider
Analytics → device and usage information
Maps → location information
Notifications → device token
Support → contact and conversation information
This immediately makes potential privacy issues easier to identify.
Developers can then design permissions, databases, APIs, retention rules and deletion processes around actual requirements.
That is much easier than rebuilding the architecture after launch.
Final Thoughts
GDPR compliance for a mobile app is not simply about adding a privacy-policy page.
European businesses need to understand what personal data their app processes, why it is needed, which legal basis applies, where it goes, how long it remains there and how it is protected.
The most important principles are straightforward:
Collect only what you need.
Clearly explain why you need it.
Use an appropriate legal basis.
Give users meaningful control where required.
Protect the information properly.
Delete or anonymise information when it is no longer needed, subject to applicable requirements.
Consider privacy while designing the product, not after launching it.
The European Commission specifically describes data protection by design and by default as implementing privacy safeguards from the earliest stages of designing processing operations.
For businesses developing an app for European customers, following this approach can make GDPR compliance easier to manage while also reducing unnecessary data collection and security risk.
This article provides general information about GDPR and mobile-app development and is not legal advice. Businesses handling sensitive information or complex processing should obtain advice appropriate to their particular activities and jurisdictions.
