Privacy Compliance for Expo & React Native in 2026

GDPR enforcement has moved from occasional headlines to sustained financial exposure. Aggregate GDPR fines reached about EUR 7.1 billion by 10 January 2026, including EUR 1.2 billion issued against Meta Platforms Ireland in 2023, according to DLA Piper's GDPR Fines and Data Breach Survey. For a mobile team, that reality changes the question. Privacy compliance isn't a document you publish before launch. It's a set of product workflows that must survive SDK updates, backend migrations, rushed releases, and the moment a user asks what data you hold.

I've shipped mobile products through GDPR and CCPA reviews, and the failures rarely came from an obviously malicious feature. They came from an analytics package initialized before consent, a forgotten Supabase log, an account deletion button that removed the profile but not the related records, or a privacy notice that described an older build. With Expo, React Native, Supabase, and Hono, you can build a durable system without turning every sprint into a legal review, but you have to make privacy behavior explicit in code.

Table of Contents

• Understanding the Privacy Compliance Landscape for Mobile Apps
  • What actually creates mobile risk
• Mapping Your App's Data Flows and Storage Points
  • Build the inventory from runtime behavior
  • Turn the map into engineering controls
• Building Consent Flows That Actually Work
  • Store evidence, not just the current state
• Auditing Third-Party SDKs for Privacy Risks
  • Compare function against exposure
• Handling Data Subject Access Requests Efficiently
  • Test the unhappy paths
• Monitoring and Maintaining Compliance Over Time
  • Make evidence part of delivery

Understanding the Privacy Compliance Landscape for Mobile Apps

The modern privacy compliance era accelerated on 25 May 2018, when the GDPR took effect. Its maximum administrative fine is EUR 20 million or 4% of worldwide annual turnover, whichever is higher, a structure that helped establish GDPR as a global benchmark for consent, retention, breach response, and vendor governance. DLA Piper recorded aggregate fines of about EUR 5.88 billion by 10 January 2025 and about EUR 7.1 billion by 10 January 2026, showing that enforcement has become an ongoing regime rather than a symbolic warning. (DLA Piper)

A map illustration showing GDPR, CCPA, and LGPD data privacy regulations affecting mobile app compliance.

For developers, the practical obligations overlap even when the statutes differ. GDPR applies when your app processes personal data connected to people in the European Economic Area, subject to the regulation's scope and territorial rules. CCPA and related California requirements focus on transparency, access, deletion, and choices around selling or sharing personal information. LGPD creates a comparable operational need in Brazil, including a lawful basis, notices, data-subject rights, and governance around processors. Your app store country setting doesn't decide this alone. User location, targeting, service delivery, and backend processing matter.

What actually creates mobile risk

Prioritize the data your app collects automatically or sends to vendors:

• Identity data: email addresses, names, phone numbers, account identifiers, and authentication metadata.
• Sensitive context: precise location, health information, financial details, contacts, photographs, or biometric signals.
• Device and behavioral data: advertising identifiers, IP-derived location, push tokens, crash traces, session recordings, and event histories.
• Operational records: Supabase audit rows, Hono request logs, support tickets, backups, and exported files.

You can defer cosmetic policy improvements. You can't safely defer knowing which SDK receives device identifiers, whether a location permission is necessary, or how a verified user exercises deletion. The CMS Enforcement Tracker data reported by Kiteworks recorded 2,685 fines totaling about EUR 6.11 billion by 1 March 2026, with an average fine of EUR 2,277,122 across all countries. The average can mislead because a small number of large penalties dominate the total, so a risk register should rank processing activities rather than treat every data field equally. (Kiteworks enforcement analysis)

Practical rule: Fix uncontrolled collection, unclear consent, untested deletion, international transfers, and vendor access before polishing low-risk documentation.

Privacy programs also consume real engineering capacity. Thomson Reuters reported that 44% of surveyed global organizations said they were failing to adhere to new data privacy regulations, 47% were struggling to keep up or falling further behind, GDPR compliance consumed 31% of the average data privacy budget, and privacy-related issues cost organizations an average of USD 1.4 million annually. (Thomson Reuters privacy infographic) For teams working with sensitive information, resources on secure data practices for clinics can add useful sector-specific context, especially where ordinary app data intersects with healthcare expectations.

Mapping Your App's Data Flows and Storage Points

You can't answer a deletion request or write an accurate notice until you know where data travels. Start with one concrete user journey in your Expo app, then follow every value beyond the screen where it first appears.

A diagram illustrating how user data flows through an app ecosystem, including storage points for privacy compliance.

Take onboarding. A user enters an email address in React Native, Supabase Auth creates an identity, your profile trigger writes a row, Hono may enrich the request or call an AI service, and an analytics SDK may emit events before the user reaches the home screen. A push-token library can add another identifier. Crash reporting may capture route names and exception context. None of those flows disappear because the user only sees one form.

Build the inventory from runtime behavior

Create a data inventory as a versioned file in the repository, not a spreadsheet that only one person remembers to update. For each field or event, record:

Supabase teams often inventory the obvious tables and miss database logs, storage objects, edge-function logs, generated exports, and backups. Inspect migrations, SQL triggers, RLS policies, server functions, and provider dashboards. Search the codebase for track, identify, setUserId, capture, Sentry, posthog, segment, expo-location, expo-device, and permission calls. Then run a test account through onboarding while observing network requests in development.

Keep separate records for collection and disclosure. A value might be stored in Supabase but also transmitted to Hono, forwarded to a vendor, copied into an email service, and retained in a support system. The user data protection guide is useful background, but your inventory must reflect your own runtime and infrastructure.

Turn the map into engineering controls

Every new data field should have an owner, purpose, retention decision, and deletion path before it reaches production. Add a pull-request template question asking whether the change introduces personal data, a new processor, a new transfer, or a new permission. For high-risk processing, document the reason for collection and consider a DPIA before implementation.

The best map is imperfect but current. A short, repository-backed inventory that changes with migrations will protect you better than a polished diagram that describes last year's app.

Building Consent Flows That Actually Work

Consent fails in production when teams treat it as a single boolean. A user might agree to essential authentication, decline analytics, allow notifications, and later withdraw location access. Your app needs to preserve those distinctions and enforce them before data leaves the device.

Start with purpose-specific choices. A React Native preference component can keep the interface understandable while storing a structured object rather than one consentAccepted flag:

type ConsentPreferences = {
  essential: true
  analytics: boolean
  marketing: boolean
  location: boolean
}

function ConsentPanel({
  value,
  onChange,
  onSave,
}: {
  value: ConsentPreferences
  onChange: (next: ConsentPreferences) => void
  onSave: () => void
}) {
  return (
    <>
      <Switch
        value={value.analytics}
        onValueChange={(analytics) => onChange({ ...value, analytics })}
      />
      <Text>Product analytics</Text>

      <Switch
        value={value.marketing}
        onValueChange={(marketing) => onChange({ ...value, marketing })}
      />
      <Text>Marketing messages</Text>

      <Button title="Save choices" onPress={onSave} />
    </>
  )
}

The labels, explanation, and link to the full notice matter as much as the toggles. Don't preselect optional purposes, bury rejection behind a second screen, or make withdrawal harder than acceptance. A preference center should remain reachable from account settings, and the app should stop optional collection when the user changes a choice. For authentication architecture decisions, mobile app authentication methods can help you separate identity management from optional tracking.

Store evidence, not just the current state

In Supabase, record the user, purpose, decision, policy version, timestamp, and collection context. A simple table might look like this:

create table consent_events (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users(id),
  purpose text not null,
  granted boolean not null,
  policy_version text not null,
  created_at timestamptz not null default now()
);

The current preference can be derived from the latest event for each purpose, while the event history explains what the user saw and when. Enforce the decision in the backend, not only in the client. A Hono handler should reject an analytics write, or discard optional fields, when the server-side preference doesn't authorize that purpose.

app.post('/events', async (c) => {
  const user = c.get('user')
  const body = await c.req.json()

  const { data: consent } = await supabase
    .from('consent_current')
    .select('analytics')
    .eq('user_id', user.id)
    .maybeSingle()

  if (!consent?.analytics) {
    return c.json({ accepted: false, reason: 'analytics_not_allowed' })
  }

  await supabase.from('analytics_events').insert({
    user_id: user.id,
    event_name: body.eventName,
    properties: body.properties,
  })

  return c.json({ accepted: true })
})

Consent versions need an explicit update strategy. If the purpose changes materially, ask again. If the app update adds a new optional SDK, keep that SDK disabled until the relevant choice exists. Children's data requires special handling because age thresholds, parental authorization, and applicable rules vary by market. Don't infer age from a profile field and call the problem solved. Define the product behavior with counsel, then make the resulting state machine testable.

Legitimate interest may be appropriate for some limited processing, but it isn't a shortcut around transparency, objection rights, or a genuine balancing assessment. Analytics that profiles users or shares identifiers deserves a higher bar than operational logging required to keep an API secure.

Auditing Third-Party SDKs for Privacy Risks

An SDK can collect data before your own feature code runs. That makes dependency review part of privacy compliance, not a task reserved for release week.

A table outlining privacy evaluation criteria for various third-party software development kits, including analytics, ads, and payments.

I evaluate each SDK against four questions: what leaves the device, when collection starts, whether consent gates it, and how deletion works. Firebase Analytics, Amplitude, Mixpanel, PostHog, Sentry, Crashlytics, RevenueCat, Stripe, and advertising packages all have different defaults, endpoints, identifiers, and retention behavior. The package name doesn't tell you enough. Read vendor documentation, Apple privacy manifests where applicable, Android data-safety disclosures, dependency changelogs, and the actual native initialization code.

Compare function against exposure

Don't pass full objects to analytics. This pattern is dangerous:

analytics.track('profile_saved', profile)

It can send names, location, preferences, or internal identifiers. Use an allowlist instead:

analytics.track('profile_saved', {
  profile_type: profile.type,
  completion_stage: profile.completionStage,
})

Wrap every vendor behind your own module. The rest of the app should call privacyAwareAnalytics.track, not import a vendor directly. That wrapper can check consent, redact properties, add a documented app version, and no-op in restricted regions. It also gives you one replacement point when a vendor changes its collection behavior.

Don't approve an SDK because its dashboard says “anonymous.” Verify whether the payload, identifier, IP handling, device fingerprinting, and retention model support that description.

Run an audit on a clean install, a denied-consent install, and a withdrawal flow. Inspect startup requests, background jobs, deep links, crash breadcrumbs, and push-registration calls. Review transitive dependencies too. A package you didn't choose directly can still add native code or a data-sharing path.

The following video can complement code review with a visual SDK-audit workflow:

Document the decision, not just the vendor name. Record the SDK version, purposes, data categories, consent dependency, processor terms, retention, regions, and the person responsible for rechecking it after upgrades.

Handling Data Subject Access Requests Efficiently

A DSAR pipeline should begin with identity verification and end with an auditable result. Don't let a support agent search production tables manually, and don't trust an email address alone when the request could expose another person's information.

Create a Hono endpoint that authenticates the requester, creates a request record, and queues work. The initial response should be fast even if the export takes longer:

app.post('/privacy/requests', async (c) => {
  const user = c.get('user')
  const { type } = await c.req.json()

  if (!['access', 'delete', 'portability'].includes(type)) {
    return c.json({ error: 'unsupported_request' }, 400)
  }

  const { data, error } = await supabase
    .from('privacy_requests')
    .insert({
      user_id: user.id,
      request_type: type,
      status: 'queued',
    })
    .select('id, status')
    .single()

  if (error) return c.json({ error: 'request_not_created' }, 500)
  return c.json(data, 202)
})

The worker then queries every known data store. For a typical Supabase project, that includes profiles, application tables containing user_id, Storage objects, consent events, analytics rows, support records, and any Hono-created audit entries. Keep the query list explicit and versioned so a future migration can't fall outside the process.

const [{ data: profile }, { data: preferences }, { data: consents }] =
  await Promise.all([
    supabase.from('profiles').select('*').eq('id', userId).maybeSingle(),
    supabase.from('preferences').select('*').eq('user_id', userId),
    supabase.from('consent_events').select('*').eq('user_id', userId),
  ])

const exportPayload = {
  profile,
  preferences,
  consents,
}

For access and portability, generate a machine-readable JSON package with a human-readable summary. Use a signed, expiring download link rather than placing sensitive data in email. Record which sources were queried, which failed, when the export was created, and who approved release.

Deletion needs more judgment than delete from profiles. Revoke sessions, remove Storage objects, delete application rows, clear optional analytics records, and remove derived indexes. Preserve only information you're required to retain for a documented legal or security reason, and mark retained records so they aren't reused for unrelated purposes.

Test the unhappy paths

Test a request for a user with missing related rows, a user with many Storage objects, a failed provider call, a duplicate request, and a request made with a stale session. Add an idempotency key so retries don't create multiple deletion jobs. Require stronger verification for sensitive exports, and log the decision without logging the exported personal data itself.

Account deletion should invoke the same backend job as a privacy deletion request. A button that only removes the authentication record creates the appearance of compliance while leaving the actual data behind.

Monitoring and Maintaining Compliance Over Time

A release process should catch privacy regressions before users do. Treat data collection like an API contract. In an Expo app backed by Supabase and Hono, a new event, permission, table, vendor, or log field should trigger review in the same pull request that introduces it.

A circular diagram illustrating a continuous compliance workflow for monitoring and maintaining data privacy and regulation.

Add a small privacy checklist to every Expo and Hono change:

• New data: Identify every personal or sensitive field introduced by the feature.
• New destination: Record whether the value reaches Supabase, an edge function, a log, or a vendor.
• New purpose: State why the app needs it and which user choice or lawful basis supports processing.
• New lifecycle rule: Define retention, export, deletion, and redaction behavior.
• New evidence: Update the inventory, notice, consent version, and test coverage.

Automate checks that code can inspect. CI can flag direct imports from analytics packages, search migrations for columns named email, phone, location, or device_id, and reject event payloads that bypass the privacy wrapper. Static checks cannot resolve every legal question, but they catch the accidental bypasses that create production work.

Make evidence part of delivery

Keep consent events, SDK review records, DSAR status changes, access-control changes, and release approvals in systems the team already uses. Each record should show who made the decision, what version was deployed, which data categories were affected, and which test demonstrated the control. Keep the record set small enough to maintain. A concise, current log is more credible than a large binder assembled after an incident.

Training covers collection paths that code review misses. The 2025 Data Security and Compliance Risk Survey found that 71% of organizations cited inadequate employee training and awareness as a major challenge, while only 35% reported compliance automation and less than 25% had adopted privacy-enhancing technologies. (Kiteworks risk survey) Teach developers to classify fields, support staff to verify DSARs, and product managers to treat a delayed privacy notice as engineering debt.

Inspect logs separately. Redact request bodies, error messages, URLs, and AI prompts in structured logging. Teams handling sensitive workflows can also evaluate PII detection and masking when manual review cannot reliably identify personal data in logs and text.

Regulatory requirements differ by jurisdiction, so maintain one operating workflow with local variations. Paul Weiss notes that multiple U.S. state privacy laws took effect in 2025, that nine states amended existing privacy laws, and that requirements expanded into teen data, geolocation, biometric data, health data, and automated decision-making. Its review also describes China's Network Data Security Management Regulations, including privacy-policy content rules, separate consent requirements, and annual risk assessments. (Paul Weiss 2025 review) Maintain a jurisdiction matrix, then apply shared controls for inventory, consent, access, deletion, vendor review, and incident escalation.

Use a practical mobile app security checklist during feature review. AppLighter provides an Expo-based starter kit with authentication, navigation, state management, a Supabase adapter, and a Hono/TypeScript API layer. Teams can wire privacy checks into those product workflows instead of adding them after launch.

AppLighter can help teams start with Expo, Supabase, and Hono foundations for consent gates, authenticated privacy endpoints, and repeatable mobile release workflows. Visit AppLighter to review the starter kit and build privacy controls into the app from its first commit.