Flutter and React Native: PDPL-compliant consent integration

What is Flutter/React Native PDPL consent and why should mobile apps care?

Flutter/React Native PDPL consent is how a business designs the flow to request consent, record it, and update the personal data consent state in a mobile app. For apps with advertising, measurement, or personalization SDKs, you typically incur obligations to notify and obtain consent under the regulations, and you must be able to prove you recorded the user’s choices.

The key point is that the PDPL looks beyond the permission UI to the entire consent lifecycle: when it is shown, what the user agreed to, whether it can be withdrawn, and whether the system truly honors that choice. If the app uses ads, A/B testing, attribution, or analytics, you should design consent from the start rather than bolting it on later.

Which parts of a Flutter or React Native app should request consent?

The short answer: any SDK that collects or shares personal data may trigger consent obligations under the regulations.

Common cases for Vietnamese SMEs:

• Ad SDKs: AdMob, Meta Audience Network, AppLovin.
• Measurement SDKs: Firebase Analytics, AppsFlyer, Adjust.
• Chat/support SDKs: may collect logs, device IDs, emails.
• Crash/reporting SDKs: may send device information and behavior.

You should not label everything as “always requires consent” or “never needs consent” categorically. Classify by processing purpose, data recipients, and configure according to the regulations. When in doubt, ask a lawyer to review.

How should consent be designed in Flutter and React Native?

Consent in mobile apps should be split into two layers: OS permissions and personal data consent. Many teams assume “allow notifications,” “allow tracking,” or “allow location” is enough, but the PDPL also requires you to disclose processing purposes and record appropriate choices.

Flutter: where should you store the consent state?

With Flutter, you can store consent locally using SharedPreferences or secure storage for UI state, but you should push the canonical record to the backend if you need to prove compliance. The state should include fields such as: adsConsent=true/false, analyticsConsent=true/false, consentVersion=2026-01, consentedAt=timestamp.

Example practical logic:

• App opens for the first time → call an API to fetch consent configuration.
• If there is no record → show the consent modal.
• If the user agrees to ads but declines analytics → only initialize the relevant ad SDKs.
• If the user re-enters the Privacy page → allow changing choices and update immediately.

React Native: how to handle consent without “drift” between native and JS?

With React Native, the risk often lies in native SDKs initializing too early, before JS can read the consent state. A safer approach is to wrap all SDK initialization in a “consent gate,” invoked only after the state has been loaded from storage or from the server.

Practical notes:

• Don’t let auto-init SDKs run at app launch if consent hasn’t been obtained.
• Sync state across JS, the native module, and remote config.
• When the user changes choices, call an API or native function to update the corresponding SDKs.

How should you store consent so it can be audited?

You should store consent by policy version and by processing purpose, not just a single global boolean. If you only store accepted=true, you will struggle to prove what the user agreed to, under which version, and whether they were adequately informed.

A minimal data structure could include:

• user_id or anonymous_id
• consent_type (ads / analytics / personalization)
• consent_value (granted / denied)
• consent_version
• policy_version
• captured_at
• capture_channel (app_flutter / app_rn)
• locale

If the app has logged-in users, link consent to the account but still keep logs by device or session for reconciliation. This is useful in disputes, internal audits, or when users submit access/deletion requests under the regulations.

What should the app do when a user withdraws consent?

The app must stop processing data for the withdrawn purposes and update the status across related systems. For ad/analytics SDKs, this typically includes: disabling collection, resetting identifiers if the provider supports it, and avoiding sending new events for that purpose.

If you integrate many third parties, review SDK documentation to learn how to disable tracking correctly. Don’t just flip the UI to “off” while payloads continue to be sent in the background.

What if a data breach occurs in the mobile app?

If an incident exposes personal data, the business must assess the impact and provide a breach notice within 72 hours of discovery under the regulations. In mobile apps, this can be an analytics misconfiguration, logs containing emails/phone numbers, or an API exposing sensitive data to the client.

Best practices include preparing in advance:

• An SDK and data flow register.
• A kill switch via feature flags.
• An incident response process.
• Records of consent and policy changes.

FAQ about Flutter/React Native PDPL consent

If you’re designing a consent banner, consent logs, or DSAR for a Flutter/React Native app, consent.vn can help standardize this flow for both dev and legal teams.

Source: the Personal Data Protection Law (Law 91/2025/QH15) thuvienphapluat.vn; Decree 13/2023/ND-CP thuvienphapluat.vn; Ministry of Public Security (A05) bocongan.gov.vn