Skip to main content

Changelog

3.6.16​

September 10, 2026

Summary​

Adds server-driven forced re-consent and remote per-country consent expiration, and folds every consent-invalidation reason into a single validity gate.

New Features​

  • Forced re-consent (forceReconsent) — The server can stamp a config with forceReconsent, a Unix-seconds instant (set when Do Not Sell is newly enabled). Consent recorded before that instant is treated as invalid so the user is re-prompted. The value is validated before use: an absent, zero/negative, future, or mistakenly-milliseconds value is ignored, so a malformed stamp can never lock a user out. Consent recorded exactly at or after the stamp stays valid, and re-consenting clears the condition automatically.
  • Per-country consent expiration — The SDK now fetches Osano's remote country mappings ({origin}/mappings.json, cached ~24h and best-effort) and applies each country's consentExpiration window, so consent older than the window is treated as invalid and re-prompts. Previously there was no production consent expiry (only a debug testing mode). GDPR applicability and variant continue to come from the config response, unchanged.
  • Native gated re-prompt — Adds ConsentManager.showConsentIfNeeded(presenter:consentUiBuilder:type:success:deny:), which presents the consent dialog only when there is no valid consent (never consented, predates forceReconsent, or expired), clearing the stale record first. It is opt-in and never fires on its own, so apps whose consent UI is driven by the web layer are unaffected. Also adds ConsentManager.clearConsentIfInvalid().

Changes​

  • Single consent-validity gate — ConsentManager.userConsent() now returns false for any invalidation reason — never consented, consent predating forceReconsent, or expired — and every consumer (reported categories, dialog gating, analytics) inherits it. Why it matters: previously only a raw "ever consented" flag was checked, so invalidated consent could still be reported as valid.
  • Analytics init grant gated on validity — The initial Google Consent Mode grant now fires only for a currently-valid consent record; an invalidated or expired record publishes the essential-only (denied) baseline instead of a stale GRANT. Why it matters: a third party no longer receives a GRANT for consent the user must re-give. This also suppresses the init grant for expired consent, not just forced re-consent.
  • Remote consent resync respects the signal — When repopulating consent from a previously stored server record, a record that predates forceReconsent is no longer applied, so the resync cannot silently restore invalidated consent.
  • Extra launch request — Initialization now makes one additional cached, best-effort request for mappings.json; a failure leaves consent expiration unset (fails toward not invalidating).

The consent dialog UI and existing public method signatures are unchanged; the new behavior is additive except where noted above.

3.6.15​

August 26, 2026

Summary​

Adds property-driven display of the consent UUID in the preference drawer and the "powered by Osano" banner logo, and enables the CCPA Do Not Sell opt-out by default.

New Features​

  • Consent UUID in the preference drawer — Adds the showConsentUuid config flag. When enabled, the preference drawer shows a read-only row with the user's consent UUID and a button to copy it to the pasteboard; when disabled (the default), the section is hidden. The UUID is read from the existing ConsentManager.uuid accessor.
  • Banner logo — Adds the showBannerLogo config flag. The consent dialog shows the "powered by Osano" logo below the buttons only when the flag is explicitly set to true; it is hidden by default (when the flag is unset or false). The preference drawer always shows the logo and now renders it as the bundled image (replacing the previous text link). Tapping the logo opens the Osano page, unchanged. Only the consent dialog is gated by this flag.

Changes​

  • Do Not Sell defaults to on — enableDoNotSell now defaults to true (previously false). Why it matters: the CCPA/CPRA "Do Not Sell or Share My Personal Information" opt-out is now presented by default wherever CCPA applies, so a tenant whose config omits the flag is compliant by default instead of silently hiding a legally required opt-out. Tenants that do not want it can set enableDoNotSell to false. The opt-out still appears only when CCPA actually applies (an explicit ccpaApplies, otherwise US browsing), and enableDoNotSellDefault (whether the user starts opted out) is unchanged and still defaults to false.

Other public APIs are unchanged.

3.6.14​

August 18, 2026

Summary​

Do Not Sell (DNS) opt-out is now driven by property configuration, matching the web CMP.

New Features​

  • DNS opt-out from config — Adds enableDoNotSell, enableDoNotSellDefault, and doNotSellCategories. The opt-out shows when enableDoNotSell is on and CCPA applies, toggles the configured categories (default: Marketing), and defaults from enableDoNotSellDefault. Existing consent behavior and public APIs are unchanged.

3.6.13​

August 07, 2026

Summary​

Fixes variant-specific timeout configuration for timer-based consent dialog variants.

Bug fixes​

  • Fix consent dialog auto-dismiss scheduling to respect allowTimeout and timeoutSeconds.

Known Issues​

  • None at this time.

3.6.12​

July 29, 2026

Summary​

Adds SDK support for a new server-configured consent dialog layout, including its associated default category states. The layout is not generally available and must be enabled by Osano. Existing properties are unaffected.

New Features​

  • Added handling for an additional banner layout delivered via property configuration, including layout-specific default consent states and available banner actions.
  • No changes to existing layouts, stored consent behavior, or public APIs.

Known Issues​

  • None at this time.

3.6.11​

July 23, 2026

Summary​

Adds a debug-only consent expiration testing mode to ConsentManager, letting you shorten how long stored consent stays valid so you can exercise the re-consent flow without waiting for the real expiration window. Mirrors the Android SDK's setConsentExpirationTestingMode().

New Features​

  • Consent expiration testing mode: setConsentExpirationTestingMode(_:) makes stored consent expire a set number of seconds after it was recorded. While active and past the window, userConsent() returns false and userConsentedCategories() returns essential-only, so your app re-prompts. Pass nil to disable. It only takes effect in debug builds of the SDK — release builds ignore the value, so it cannot ship to production. Why it matters: You can validate consent-refresh flows in seconds instead of waiting out the full expiration window, and it is safe by construction because it is inert in release builds.

    Swift:

    // Consent expires 10 seconds after it is recorded (debug builds only)
    consentManager.setConsentExpirationTestingMode(10)

    // Disable testing mode and restore normal behavior
    consentManager.setConsentExpirationTestingMode(nil)

    Objective-C:

    // Consent expires 10 seconds after it is recorded (debug builds only)
    [self.consentManager setConsentExpirationTestingMode:@10];

    // Disable testing mode and restore normal behavior
    [self.consentManager setConsentExpirationTestingMode:nil];

Known Issues​

  • None at this time.

3.6.10​

June 29, 2026

Summary​

Adds a public jurisdiction getter to ConsentManager so you can read the visitor's effective jurisdiction as a single composite value, matching the web SDK's Osano.cm.jurisdiction and the Android SDK's getJurisdiction().

New Features​

  • Public jurisdiction getter: consentManager.jurisdiction returns the visitor's jurisdiction as a lowercase composite of country and region (for example, us or us-ca). Previously this value was computed internally but was not accessible from your app. Why it matters: You can now read the jurisdiction in one call and in a consistent, lowercase format across platforms, instead of having no public access on iOS.

Known Issues​

  • None at this time.

3.6.9​

June 4, 2026

Summary​

Makes swipe-to-dismiss on the bottom sheet consent dialog behave like the close/X button, so a swipe records consent through the same path instead of closing the dialog silently.

Bug Fixes​

  • Bottom sheet swipe-to-dismiss bypassed the consent flow: Swiping the bottom sheet down now runs the same logic as tapping close/X. Dismissible variants record consent via the existing deny (reject-all) or success (accept-all) callbacks, and non-dismissible variants ignore the swipe gesture entirely. A guard prevents programmatic accept/deny dismissals from firing the consent logic twice. Why it matters: Previously a swipe could close the dialog without going through denyAll()/manager.consent()/deny/success, leaving consent unrecorded. Swipe dismissal is now handled internally by the SDK with no additional integration work required.

Known Issues​

  • None at this time.

3.6.8​

May 1, 2026

Summary​

Changes how configurations are cached and requested, using server-specific headers to validate the most recent configuration is being used.

Bug Fixes​

  • New configuration changes were not being reflected until the internal configuration cache expired: Fixed an issue where a configuration file would still be used if it was within the caching duration, even if there was a more recent version available on the server. Why it matters: Users viewing the Consent UI would not see the most recent changes to the configuration until the local copy of the configuration file expired.

Known Issues​

  • None at this time.

3.6.7​

April 23, 2026

Summary​

Fixes a translation lookup bug that caused known translation keys to return their raw key (or an empty string) when no remote translation bundle was present, or the key was missing.

Bug Fixes​

  • Local bundle and fallback translations were skipped when no remote translation exists: Fixed an issue where the internal translation variable was initialized to an empty string. When the resolved remote and local paths were equal (i.e., no remote bundle for the locale), the lookup against the SDK's bundled .strings files was skipped. When a remote translation did not exist, the translation variable was not reset and consequently skipped the subsequent checks in the fallback lookup. Why it matters: Users viewing the Consent UI in locales served only by the SDK's bundled translations will now consistently see the correct localized strings, rather than the raw translation key. Additionally, if a translation key is missing from the remote bundle, both local and remote translation fallbacks will be handled appropriately.

Known Issues​

  • None at this time.

3.6.6​

March 27, 2026

Summary​

Fixes locale initialization for ConsentUiBuilder, ensuring the locale is correctly set during both initialization and property updates.

Bug Fixes​

  • Default device locale not applied during initialization: Fixed the handling of the languageCode property initializer to correctly fallback to the default device language (if supported). Why it matters: Previously, setting the language code during ConsentUiBuilder initialization did not trigger the property observer, so the locale could be silently ignored. The SDK now applies the correct locale consistently, and correctly falls back to the device default language (or English when the device language is not supported).

Known Issues​

  • None at this time.

3.6.5​

February 25, 2026

Summary​

Centralizes all translation keys, improves translation reliability for mobile apps. The SDK now uses mobile-specific translations when available, with automatic fallback to web keys.

Improvements​

  • Centralized translation keys — All translation keys are now defined with a prefix for mobile-specific strings.
    Why it matters: Makes it easier to update, audit, and maintain localizations across your app.

  • Smarter translation lookup — The SDK checks for mobile-specific translations first, then falls back to web keys in both customer and global translation maps.
    Why it matters: Ensures users always see the most relevant, up-to-date text with less developer effort.

  • UI and IAB translation consistency — All UI and IAB-related translation lookups now use the new centralized keys. Policy links and consent screens are easier to localize and maintain.
    Why it matters: Reduces the risk of missing or inconsistent translations, and simplifies localization updates.

Action Required​

To use mobile custom translations, add or update your strings in your web configuration (Osano dashboard).

Known Issues​

  • None at this time.

3.6.4​

February 3, 2026

Summary​

Architectural improvements to ConsentManager initialization, improved user context switching performance, and fixes for drawer toggle synchronization issues.

Bug Fixes​

  • Drawer toggle synchronization: Fixed issue where consent category toggles in the preferences drawer would not reflect the correct user's consent state immediately after user switching.
    Why it matters: Users now see accurate toggle states that match their stored consent preferences, eliminating confusion about their actual consent status.

New Features​

  • Smart ConsentManager re-initialization: Added controlled re-initialization logic that only triggers when customerId or configId or extUsrData changes on an already initialized instance.
    Why it matters: Improves user switching performance while ensuring fresh consent data is properly loaded for each user or configuration context.

Improvements​

  • Optimized initialization flow: Eliminated redundant network requests during ConsentManager property setup.
    Why it matters: Faster SDK initialization and reduced network overhead, especially beneficial for apps with frequent user switching.

  • Improved user context isolation: Enhanced user context switching to ensure proper consent data isolation between different users.
    Why it matters: Better data privacy and more reliable cross-user consent management in multi-user scenarios.

Known Issues​

  • Race condition during user switching: There's a brief moment during extUsrData updates where async consent lookup may still be in progress.
  • Recommendation: Avoid calling showDialogViewController() immediately after changing extUsrData.

3.6.3​

January 26, 2026

Summary​

Major improvements to user consent isolation, automatic migration system, and enhanced remote consent handling for cross-device scenarios.

Bug Fixes​

  • Cross-user consent data leakage: Fixed critical issue where consent data was persisting across different user login/logout sessions.
    Why it matters: Users now see only their own consent preferences, ensuring proper privacy isolation between different user accounts when using cross-device consent functionality.

New Features​

  • Automatic consent migration: Legacy consent data is automatically migrated to user-scoped storage on SDK upgrade.
    Why it matters: Existing users won't lose their consent preferences when you update to this version - migration happens seamlessly in the background.

  • Enhanced cross-device consent handling: When external user identifiers are provided, the SDK now always stores remote consent from your backend.
    Why it matters: Ensures cross-device consent synchronization works reliably and prioritizes server-side consent state over local storage.

Improvements​

  • User-scoped consent storage: Consent data is now isolated per user context using secure identifiers.
    Why it matters: Prevents consent data leakage between different users of the same app instance, critical for multi-user applications.

  • Code quality improvements: Refactored internal architecture to eliminate duplicate code and improve maintainability.
    Why it matters: More reliable SDK behavior and easier troubleshooting for your development team.

Migration Guide​

No code changes required - the SDK handles migration automatically. However, note these behavior changes:

  • Cross-device consent: If you use extUsrData for cross-device consent, the SDK now prioritizes remote consent over local consent in all cases.
  • User isolation: Consent data is now properly isolated per user session. Call clearConsent() or clearAllUsersConsent() if you need to reset consent data during testing.

Known Issues​

  • None at this time.

3.6.2​

December 22, 2025

Summary​

Improves consent correctness and transparency under the latest IAB TCF policy and adds platform attribution to consent records.

New Features​

  • Platform attribution in consent records (iOS): The SDK now distinguishes between production apps and official samples when tagging the originating platform in consent records.
    Why it matters: Enables cleaner reporting and troubleshooting across environments without requiring integrator code changes.

Improvements​

  • IAB TCF policy alignment: Default behavior aligns with the most recent IAB TCF policy expectations.
    Why it matters: Keeps your consent signaling and downstream ad-tech interoperability compliant with current standards.

Note: Visit IAB Tech Lab - Consent string and vendor list formats v2 to get more information about vendor disclosure

  • Accurate vendor disclosure after consent changes: Vendor disclosure is automatically kept in sync whenever a user updates their consent choices.
    Why it matters: Ensures audit-ready transparency and consistent reporting for privacy reviews.

Known Issues​

  • None at this time.

3.6.0​

July 31, 2025

Summary​

Adds an optional debug logging toggle for troubleshooting and refreshes localizations across supported languages.

New Features​

  • Debug logging toggle: You can enable verbose SDK logging during development/testing.
    Why it matters: Speeds up diagnostics and support interactions without shipping noisy logs to production.

Improvements​

  • Localization refresh: Updated translations across supported languages.
    Why it matters: More consistent and accurate UI copy for end-users.

3.5.0​

March 21, 2025

Summary​

Introduces integration with Apple’s App Tracking Transparency (ATT).

New Features​

  • ATT framework integration: The SDK now interoperates with ATT to respect system-level tracking authorization.
    Why it matters: Aligns consent UX with platform requirements; improves user trust and app store compliance.

Learn more: Apple ATT → https://developer.apple.com/documentation/apptrackingtransparency

3.4.0​

November 12, 2024

Summary​

Enables cross-device consent and adopts Apple’s privacy manifest.

New Features​

  • Cross-device consent: Consent can be recognized across sessions/devices when an external, privacy-safe identifier is provided.
    Why it matters: Reduces repeat prompts and gives a consistent consent state for multi-device users.

  • Privacy manifest (PrivacyInfo.xcprivacy): The SDK declares data use in Apple’s privacy manifest format.
    Why it matters: Improves transparency and helps meet App Store privacy requirements.

Learn more: Apple Privacy Manifests → https://developer.apple.com/documentation/bundleresources/privacy_manifest_files

3.3.2​

September 16, 2024

Summary​

Fixes a platform-specific issue on iOS 16.0–16.3 when using domain-scoped consent behavior.

Fixes​

  • Domain-scoped consent on iOS 16.0–16.3: Corrected behavior that could impact consent resolution on those OS versions.
    Why it matters: Ensures reliable consent evaluation on older iOS 16 builds.

3.3.1​

August 29, 2024

Summary​

Clarifies IAB banner copy to include required special feature language.

Improvements​

  • IAB banner copy: Updated message to cover special-feature disclosures.
    Why it matters: Better compliance and user clarity under IAB guidance.

3.3.0​

June 26, 2024

Summary​

Adds Google Consent Mode support, improves initialization ergonomics, enhances IAB stability, introduces a second policy link, resolves an iPad crash, and streamlines translation fetching.

New Features​

  • Google Consent Mode support Why it matters: Lets you propagate consent signals to Google tags for measurement and ads use-cases.

Learn more: Google Consent Mode → https://developers.google.com/tag-platform/security/concepts/consent-mode

  • Initialization completion handlers
    Why it matters: Easier to sequence app logic after the SDK is fully ready.

  • Second policy link
    Why it matters: Surface multiple policy resources (e.g., Privacy Policy + Do Not Sell/Share) in the UX.

Fixes​

  • IAB stability fixes
    Why it matters: More reliable consent strings and vendor/feature handling.
  • iPad preferences drawer crash
    Why it matters: Prevents a UX-blocking crash on larger devices.

Improvements​

  • Translation fetching
    Why it matters: More consistent and up-to-date localized copy.

3.2.0​

March 26, 2024

Summary​

Corrects analytics toggle behavior and adjusts Accept All handling for a specific banner flavor.

Fixes​

  • Analytics toggle state
    Why it matters: Ensures the analytics category reflects user intent.

Improvements​

  • Accept All behavior (specific banner flavor)
    Why it matters: Aligns the one-tap action with expected consent outcomes.

3.1.1​

March 19, 2024

Summary​

Fixes a regression in GDPR applicability checks.

Fixes​

  • GDPR scope detection: Accurately determines when GDPR rules should apply before enforcing consent.

3.1.0​

January 9, 2024

Summary​

Finalizes support for IAB TCF 2.2.

New Features​

  • IAB TCF 2.2: Aligns consent signaling and vendor/feature handling with the IAB’s latest framework updates.

Learn more: IAB Europe TCF → https://iabeurope.eu/tcf-2-0/