Consent Management in Mobile SDKs

The Android (Kotlin) and iOS (Swift) SDKs now support consent management. You pass the user’s consent choices, and the SDK stamps every event and blocks device mode destinations the user has not allowed.

Your app keeps the consent UI. The SDK does not show a banner, store a choice, or ask the user anything.

Consent management is off by default. Apps that do not enable it behave exactly as before: events carry no consent block and no destination is blocked.

This feature supports the Custom consent provider only. Named consent managers such as OneTrust, Ketch, and iubenda are not supported yet. If you use one of those tools, read the user’s choices from that SDK and pass them as custom consent category IDs.

See Consent Management in Mobile SDKs for how events are stamped and how device mode destinations are blocked.

Why consent management in the mobile SDKs?

The legacy Android and iOS SDKs read a consent filter once, at startup. A change applied only on the next launch, and you had to decide destination by destination in code.

In the Kotlin and Swift SDKs you declare the user’s choices, and each destination’s Consent settings in the dashboard decide what is allowed. setConsent applies the new choices immediately, including mid-session.

Key features

• Consent on every event: While consent management is active, each event carries context.consentManagement with the provider, allowedConsentIds, and deniedConsentIds from the moment the event was created. Cloud mode destinations are filtered server-side from that stamp.
• Device mode blocking: A destination the user has not allowed is never initialized and receives no events. Only allowedConsentIds gates a destination. deniedConsentIds is recorded on the event and is not used to resolve destinations.
• Runtime updates: setConsent replaces the current choices immediately. A newly allowed destination starts without an app restart. Events tracked while a destination was denied are not sent to it later.
• Your app owns persistence: Consent is held in memory for the session. Supply it again on every launch. reset() does not clear it, because consent is a device-level choice rather than a property of the signed-in user.

Consent management in the Kotlin SDK is available on Android only. It is not included in the server-side (JVM) artifact.

Get started

Consent category IDs are case-sensitive. The IDs you pass to the SDK must match the dashboard exactly.

1. Open the destination and go to Consent settings. Choose Custom, enter the consent category IDs, and set the logic to AND or OR.
2. Enable consent management when you initialize the SDK, and pass the user’s current allowedConsentIds and deniedConsentIds. You cannot turn it on later in the session.
3. When the user changes their choices, call setConsent with the full set of choices, not only what changed.

See How to Enable Consent Management in Mobile SDKs for the Kotlin, Java, Swift, and Objective-C snippets.

SDK versions

Resources

• Consent Management in Mobile SDKs: How events are stamped, and how consent interacts with identity
• How to Enable Consent Management in Mobile SDKs: Dashboard setup, initialization, and setConsent
• How to Migrate Consent Filters from the Legacy SDKs: Replace RSConsentFilter and RudderConsentFilter
• Custom Consent Management: Provider setup and consent logic in the dashboard