How to Migrate Consent Filters from the Legacy SDKs
2 minute read
This guide applies if you are moving from the legacy Android (Java) SDK or the legacy iOS (Objective-C) SDK.
There is nothing to migrate at the data level. The legacy SDKs never stored consent, and your consent category IDs stay exactly as your consent platform defines them. This is a code change only.
In the legacy SDKs you implemented a consent filter — RSConsentFilter on iOS, RudderConsentFilter on Android. It handed the SDK two maps: one marking each of your consent categories allowed or denied, and one marking each device mode destination on or off. In the new SDKs you declare the user’s choices once and the SDK decides, using the consent settings configured on each destination in the dashboard.
What replaces what
| Legacy | New |
|---|---|
| The consent filter interface you implemented | Nothing to implement |
withConsentFilter(...) on the config builder | consentManagement on Configuration |
getConsentCategoriesDict / getConsentCategoriesMap entries set to true | allowedConsentIds |
The same entries set to false | deniedConsentIds |
filterConsentedDestinations(...) | Consent settings on each destination in the dashboard |
| No equivalent | setConsent for runtime changes |
Your existing category map splits into the two ID lists by its boolean value — that is the whole mapping. The destination-by-destination map has no code equivalent: that decision now lives in the dashboard.
What you gain
- Consent changes take effect immediately. The legacy SDKs read your filter once, at startup, so a change only applied on the next app launch.
setConsentapplies right away. - Destinations start mid-session. A destination the user newly allows is initialized without an app restart. The legacy SDKs never did this.
- A complete consent record on the event. The legacy SDKs stamped only the denied category IDs. Events now carry the provider and the allowed IDs as well.