Mobile app GDPR compliance in 2026: what every developer needs to know

GDPR came into force in 2018, and by 2026 it is a baseline expectation for every mobile app on the Hungarian market too. Fines can reach 4% of annual turnover — for an SME, that can be enough to shut the business down. This article covers the most common compliance gaps with code-level examples, and also walks through the 2024-2026 privacy updates (Apple ATT, Google Privacy Sandbox).

This guide does not replace legal advice — a DPIA (Data Protection Impact Assessment) or a DPO (Data Protection Officer) consultation is mandatory for any complex project. But the developer-level best practices are summarized here.

GDPR basics in a mobile context

GDPR applies to personal data — anything that can identify an individual. On mobile, this can include:

• Email, phone number, name
• Location (GPS, cell-tower, or Wi-Fi triangulation)
• Device ID (IDFA, GAID, Android ID, IMEI, MAC address)
• IP address (yes, an IP address counts as personal data under GDPR)
• In-app usage analytics (can be anonymized, but often isn't)
• Push token (can directly identify a device, and through it a user)
• Browser fingerprint
• Biometric data (Face ID, Touch ID — even when processed only locally, not server-side)

The 6 core principles

GDPR Article 5 sets out six core principles. All of them must be explicitly upheld:

1. Lawful basis — every processing activity needs a legal basis (consent, contract, legal obligation, vital interest, public task, legitimate interest)
2. Purpose limitation — data may only be used for its declared purpose
3. Data minimization — collect only as much data as necessary
4. Accuracy — data must be accurate
5. Storage limitation — retain data only as long as necessary
6. Integrity and confidentiality — secure storage, encryption

The 8 user rights

Under Articles 12-22, users have the right to:

1. Be informed (Articles 13-14)
2. Access (Article 15 — Subject Access Request, SAR)
3. Rectification (Article 16)
4. Erasure (Article 17 — the "right to be forgotten")
5. Restrict processing (Article 18)
6. Data portability (Article 20)
7. Object (Article 21)
8. Be exempt from automated decision-making (Article 22)

Every one of these must be implementable in-app. The "right to erasure" doesn't mean the user can only request it by email — the app needs an actual button for it.

Consent management in detail

Consent has four requirements: freely given, specific, informed, unambiguous. A single "I agree to the terms" checkbox is not GDPR-compliant — every specific processing purpose needs its own consent.

The 2024-2026 update — granular consent

The 2024 EDPB (European Data Protection Board) guidance explicitly tightened the ban on "bundled consent." A single "I accept" button covering everything is no longer sufficient.

NOT GDPR-compliant:
☐ I accept the terms of use, the privacy policy, analytics tracking,
   marketing emails, and push notifications.

GDPR-compliant:
☐ I accept the terms of use (required)
☐ I accept the privacy policy (required)
☐ Enable analytics tracking (optional)
☐ Marketing email communications (optional)
☐ Push notifications (optional)

iOS App Tracking Transparency (ATT)

The 2024 Google and Apple updates tightened tracking consent. Since iOS 14.5+, an ATT prompt is required for any tracking data:

import AppTrackingTransparency
import AdSupport

func requestTrackingPermission(completion: @escaping (Bool) -> Void) {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                // Tracking allowed, IDFA accessible
                let idfa = ASIdentifierManager.shared().advertisingIdentifier
                completion(true)
            case .denied, .restricted, .notDetermined:
                // No tracking, IDFA = 00000000-0000-0000-0000-000000000000
                completion(false)
            @unknown default:
                completion(false)
            }
        }
    } else {
        completion(true) // iOS < 14 — no ATT
    }
}

A "purpose-blocking" UI (where the user cannot proceed until they accept) is NOT GDPR-compliant — it can be challenged. Consent must be optional for core functionality.

Android Privacy Sandbox

Since Android 14+, the Privacy Sandbox initiative has started limiting IDFA-style tracking. GAID (Google Advertising ID) is deprecated as of 2026, replaced by the Topics API and the Attribution Reporting API.

// Deprecated as of 2026, fallback only
val client = AdvertisingIdClient.getAdvertisingIdInfo(context)
if (client.isLimitAdTrackingEnabled) {
    // GAID not available — user opted out
}

The Privacy Sandbox APIs (Topics, Attribution Reporting) are clearer from a GDPR standpoint — they relay aggregated data across companies in anonymized form.

Multi-step consent flow

Best practice for 2026: staged consent, where each processing purpose gets its own decision.

type ConsentChoice = {
  essential: boolean;        // Always true, no choice
  analytics: boolean;
  marketing: boolean;
  third_party: boolean;
};

async function showConsentFlow(): Promise<ConsentChoice> {
  // Step 1: Privacy policy intro screen
  await showPrivacyPolicySummary();
  
  // Step 2: Granular consent
  const choices = await showGranularConsentScreen();
  
  // Step 3: Store consent
  await db.consents.upsert({
    user_id: getUserId(),
    timestamp: new Date(),
    choices,
    ip: getClientIp(),  // for audit
    user_agent: getUserAgent(),
  });
  
  return choices;
}

Tip: Consent storage is itself personal data — store it securely, with an audit trail. NAIH (Hungary's National Authority for Data Protection and Freedom of Information) asks about this explicitly during audits.

IDFA, GAID and alternatives

IDFA (iOS)

• Only accessible after ATT consent
• Average opt-in rate since 2024 is ~25%
• If declined: IDFA = 00000000-0000-0000-0000-000000000000

GAID (Android)

• Still available in 2026, but deprecated
• Users can disable it under Settings → Privacy → Ads
• Expected to disappear entirely by 2027

Alternative attribution

If you need advertising attribution, use alternative solutions:

iOS:

• SKAdNetwork (SKAN) — Apple's aggregated attribution framework. No IDFA, but aggregated conversion data.
• Apple Search Ads attribution API — Apple-specific paid acquisition.

Android:

• Privacy Sandbox Attribution Reporting API — Google's equivalent.
• App Set ID — an install-level ID scoped to a publisher's group of apps.

Provider-level compliance

Provider	GDPR-friendly by default	Action
Firebase Analytics	No	Turn off IP collection, anonymize ID
Mixpanel	Partially	EU residency opt-in, 30-day data retention
Amplitude	Partially	EU residency, anonymize tracking
Segment	Partially	Data residency defaults to US
PostHog (self-hosted)	Yes	Full control on your own server
Plausible	Yes	Cookieless, EU-hosted

Analytics tools — a privacy-first stack

Default analytics providers (Firebase Analytics, Mixpanel) are not GDPR-compliant out of the box — they log IPs, collect device IDs, and store data on US servers.

GDPR-friendly alternatives

Web analytics:

• Plausible — cookieless web analytics, EU server (Frankfurt), $9-69/month
• Fathom — similar, EU-based servers
• Umami — open-source, self-hostable

Mobile and web event tracking:

• PostHog (self-hosted) — event tracking on your own server, free
• Matomo Cloud (EU) — Google Analytics-like, EU-hosted
• Mixpanel EU residency — opt-in, more expensive

Setting up Firebase the GDPR way

If you're using Firebase Analytics (because it's already in your stack):

// Android Firebase Analytics — only after consent
class FirebaseAnalyticsManager(private val context: Context) {
    
    fun configure(consent: Boolean) {
        FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(consent)
        
        // IP anonymization (off by default, must enable)
        // Note: Firebase doesn't expose this directly, must configure via console
        
        // Data retention: 2 months (minimum) in console
    }
    
    fun userOptOut() {
        // Reset analytics ID
        FirebaseAnalytics.getInstance(context).resetAnalyticsData()
        FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(false)
    }
}

// iOS Firebase Analytics
import FirebaseAnalytics

class FirebaseAnalyticsManager {
    
    func configure(consent: Bool) {
        Analytics.setAnalyticsCollectionEnabled(consent)
        // Consent must come BEFORE FirebaseApp.configure() in some cases
    }
    
    func userOptOut() {
        Analytics.resetAnalyticsData()
        Analytics.setAnalyticsCollectionEnabled(false)
    }
}

Data storage and retention

GDPR principle: only retain data as long as necessary.

Concrete retention rules

Data type	Maximum retention	Reason
Active user account	As long as active	Service delivery
Inactive user account	2-3 years	Reactivation potential
Analytics events	14 months (GA4 default)	Long-tail analysis
Crash logs	90 days	Bug-fix context
Push tokens	As long as account is active	Service delivery
Marketing email opt-ins	As long as opt-in is active	Consent
Audit logs (security)	1-3 years	Legal obligation
Financial transactions	8 years (HU regulation)	Tax law

Cascading delete

-- User soft-delete: GDPR Article 17
UPDATE users 
SET 
    email = 'deleted-' || id || '@anon.local',
    name = 'Deleted User',
    phone = NULL,
    address = NULL,
    deleted_at = NOW()
WHERE id = $1;

-- Cascade
DELETE FROM push_tokens WHERE user_id = $1;
DELETE FROM analytics_events WHERE user_id = $1 AND event_type != 'aggregated';
DELETE FROM session_logs WHERE user_id = $1;

-- Audit log of deletion (kept for legal)
INSERT INTO gdpr_audit_log (user_id, action, timestamp, ip, reason)
VALUES ($1, 'erasure_request', NOW(), $2, 'user_initiated');

The backup angle

Deleted user data should not persist in backups for years. Backup retention also falls within GDPR's scope.

Best practice:

• Daily backups: 30-day retention
• Weekly backups: 90-day retention
• Monthly backups: 1-year retention

Backups should reflect deletions too — a "forgotten" user should be removed from backups within 30-90 days as well.

Privacy policy and legal notice

Privacy policy — required content

A privacy policy isn't boilerplate. At minimum, it must include:

1. Controller identification — company name, registered address, tax number, DPO contact (if applicable)
2. Types of data collected — precisely, by category
3. Purpose of processing — a distinct lawful basis for every purpose
4. Retention periods — per data type
5. Third parties — Firebase, Sentry, Mixpanel, OneSignal, etc. — an exact list
6. Data transfers outside the EU (if any) — Standard Contractual Clauses (SCC)
7. User rights — all 8 rights detailed, with guidance on "how to exercise them"
8. Cookie / tracker policy (if there's a companion website)
9. Update history — when things changed
10. Contact — an email for privacy-related questions

Hungarian specifics — legal notice (impresszum)

Hungarian website regulation requires a legal notice ("impresszum"), which must include:

• Company name
• Registered address (full address)
• Company registration number
• Tax number
• Email
• (Phone — optional, but recommended)

The URL question

The privacy policy and legal notice URLs must also be entered into App Store Connect and Google Play Console. Put them live before launch — review rejections often happen because the privacy URL doesn't work.

The audit checklist

Before submitting to the stores, check:

Privacy and legal

• Privacy policy URL works, in Hungarian and English
• Legal notice accessible within the app (Settings → About)
• Consent prompt before every tracking feature (ATT on iOS, Firebase on Android)
• Granular consent (no bundling)
• Analytics starts off by default, turned on only after consent
• EU server / EU-region data storage for every third-party provider
• DPA (Data Processing Agreement) signed with every third party (Firebase, OneSignal, Sentry, AWS, etc.)

User rights

• User account deletion function works (account deletion in-app, < 5 clicks)
• Data export function (GDPR Article 15 — Right to Access)
• Consent-revoke button in settings
• Marketing email unsubscribe link in every email

Backend

• Backend logs are PII-free or deleted within 90 days
• Database encryption at rest
• Backup encryption and retention policy
• Audit log for sensitive operations

Store submission

• App Store Privacy Nutrition Label filled in
• Google Play Data Safety form filled in, accurately
• Cookie banner on the web portal (if there's a companion website)
• Children's privacy (COPPA) — if under-13 users may use the app

Note: The App Store Privacy Nutrition Label and the Google Play Data Safety form are not the same as the privacy policy. They must independently reflect the data processing — inconsistencies between them are a common cause of rejection.

Account deletion implementation

Apple has required an "account deletion in-app" feature since 2022. The 2026 state of the art:

UX flow

Settings → Account → Delete Account
  ↓
Confirmation screen:
  "Are you sure? This cannot be undone.
   Your data will be deleted within 30 days."
  ↓
Re-authenticate (password / Face ID)
  ↓
Confirmation email sent
  ↓
Account marked for deletion
  (queued for hard-delete in 30 days)

Backend implementation

async function requestAccountDeletion(userId: string) {
  // Step 1: Mark for deletion
  await db.users.update(userId, {
    deletion_requested_at: new Date(),
    deletion_scheduled_at: new Date(Date.now() + 30 * 24 * 60 * 60 * 1000),
  });
  
  // Step 2: Send confirmation email
  await emailService.send(userId, 'account_deletion_requested');
  
  // Step 3: Log in audit
  await db.gdprAuditLog.create({
    user_id: userId,
    action: 'erasure_requested',
    timestamp: new Date(),
  });
  
  // Step 4: Schedule hard-delete (cron job)
  // (separate process, runs daily, executes 30-day-old requests)
}

async function executeScheduledDeletion() {
  const due = await db.users.findMany({
    deletion_scheduled_at: { lte: new Date() },
    deletion_completed_at: null,
  });
  
  for (const user of due) {
    await performHardDelete(user.id);
  }
}

A 30-day grace period is worthwhile — it gives the user a chance to change their mind, while keeping the delete execution safe on the backend.

Data export — Article 15 implementation

async function exportUserData(userId: string): Promise<UserDataExport> {
  const user = await db.users.findById(userId);
  const sessions = await db.sessions.findByUserId(userId);
  const events = await db.analyticsEvents.findByUserId(userId);
  const consents = await db.consents.findByUserId(userId);
  
  return {
    exported_at: new Date(),
    user_profile: user,
    sessions: sessions,
    analytics_events: events,
    consents_history: consents,
  };
}

The export format is JSON or CSV. Packaged as a ZIP, delivered via an email link. Not an in-app download — that's a security risk.

NAIH and Hungarian specifics

NAIH — the National Authority for Data Protection and Freedom of Information — is Hungary's GDPR supervisory body. The fine trend has been rising since 2024 — an average NAIH fine in the SME segment has climbed from 1-5M HUF to 5-20M HUF.

Common NAIH focus areas, 2024-2026

1. Marketing emails sent without consent — a direct red flag
2. Refusing data portability requests — failing to honor Article 20
3. Excessively long retention — user-data exports kept in Excel for 5+ years
4. Data transfers outside the EU — without an SCC
5. Mixing up controller and processor roles — who is who in the contract

DPO obligation

An SME is required to appoint a DPO when:

• It is a public authority or performs a public task
• Its core activity involves large-scale, regular and systematic monitoring
• Its core activity involves large-scale processing of special-category data

Most SME apps do not fall into this category — but it's worth consulting a GDPR advisor during discovery to confirm.

Official documentation and further reading

• Full GDPR text (Eur-Lex) — the source document
• EDPB guidelines — EU-level guidance
• NAIH guidance (Hungarian) — the domestic interpretation
• Apple App Privacy — official guide
• Google Play Data Safety — official guide
• Mozilla Privacy by Design — practical primer

Related articles from us: App Store & Play Store deployment 2026 — store-submission-level GDPR checklists. Getting push notifications right — consent and push permission flow. React Native vs. native 2026 — privacy flow across both platforms.

Wrap-up

GDPR on mobile is not a one-time compliance task — it's an ongoing process. Every new feature means a new consent flow and a new privacy policy update. Good UX also improves the consent rate (35-45% for ATT on iOS, versus the 25% baseline).

The audit checklist's 20+ items are mandatory before launch. Avoiding a NAIH fine is worth simply more than the time the setup work takes.

If you're planning a mobile app project, we always go through the GDPR checklist during discovery — most release delays happen right here, before launch. Let's walk through the details in a 30-minute call. In the first week's audit, we can often flag the 2-3 most important gaps to fix before launch.