Release Notes - Iterable's iOS SDK

This document provides release notes for significant updates to Iterable's iOS SDK.

# In this article

# 6.7.3

June 23, 2026

Iterable's iOS SDK Version 6.7.3 includes the following changes:

• New async/await variants for disabling the device: Added async variants of the device-disabling methods, so you can call them with Swift concurrency. These are additive—the existing completion-handler methods are unchanged.

  try await IterableAPI.disableDeviceForCurrentUser()
  try await IterableAPI.disableDeviceForAllUsers()
  

• New completion handlers for logoutUser: IterableAPI.logoutUser now has an overload that accepts onSuccess and onFailure handlers. Logout is a local-only operation (it clears the stored user identity and resets the in-app and embedded managers), so these handlers are an observability signal for the one network side effect logout can trigger: the disableDevice call made when autoPushRegistration is enabled.

  • When autoPushRegistration is true, the handlers reflect the result of that disableDevice request. An onFailure here doesn't mean the local logout failed—the local logout still completed.
  • When autoPushRegistration is false, no network call is made and onSuccess(nil) is invoked once local logout completes.
  • Handlers are delivered in-process, aren't persisted across app termination, and aren't guaranteed to be invoked on the main thread.

  IterableAPI.logoutUser(withOnSuccess: { _ in
      // The logout sequence completed.
  }, onFailure: { reason, _ in
      // The triggered disableDevice request failed or couldn't be sent.
  })
  

• AuthFailureReason now conforms to CustomDebugStringConvertible: The AuthFailureReason enum is Int-backed, and now provides readable debug descriptions (for example, authTokenExpired), making JWT auth failures easier to log and diagnose.

• register(token:) calls now retry automatically when offline: IterableAPI.register(token:) is now routed through the SDK's offline queue. A push token registration made while offline is automatically retried when connectivity returns, instead of being dropped. The current user identity is captured at call time, so the queued request still targets the correct user even after a logout or user switch. Calling register(token:) without a current user identity now reports onFailure with a "register(token:) called without a current user identity" reason instead of silently sending the request.

• Fixed a CocoaPods crash when displaying out-of-the-box embedded messages: IterableEmbeddedView.xib was missing from the CocoaPods resource bundle, which caused loadViewFromNib() to crash when showing an out-of-the-box embedded message view. The podspec now bundles the UI component XIBs. Apps that integrate the SDK with Swift Package Manager were not affected.

• Fixed in-app message position when the device is in landscape: The position calculation for in-app messages now subtracts safe-area insets when computing the available width and horizontal center, so messages no longer extend under the notch or home indicator after a rotation to landscape. Centered in-app messages also use the safe-area-adjusted height when computing their vertical center.

• Changed how Unknown User Activation data is stored: The Unknown User Activation sessions blob in UserDefaults now encodes with totalUnknownSessionCount, lastUnknownSession, and firstUnknownSession fields, and stored events use eventType as the type discriminator. If you use Unknown User Activation, don't roll back to an SDK version earlier than 6.7.3 after upgrading: an older SDK can't decode the new sessions blob (the unknown user session counter resets to zero) and skips stored unknown-user events when flushing them (it looks for the old dataType discriminator). Identified user data, push registration, and other SDK functionality are unaffected; only the unknown user session counter and pending unknown-user events are lost if you roll back after upgrading.

# 6.7.2

May 27, 2026

Iterable's iOS SDK Version 6.7.2 includes the following changes:

• disableDevice calls now retry automatically when offline: IterableAPI.disableDeviceForCurrentUser and disableDeviceForAllUsers are now routed through the SDK's offline queue. A disableDevice call made while offline is automatically retried when connectivity returns, instead of being dropped. The original user identity is captured at call time, so the queued request still targets the correct user even after a logout or user switch. Queued disableDevice tasks are also preserved across logout, while other queued work continues to be purged.

• New optional shouldLog(level:) method on IterableLogDelegate: Added an optional shouldLog(level:) -> Bool method to IterableLogDelegate. When the delegate returns false for a given level, the SDK skips message formatting entirely for that log call. The default implementation returns true, so existing custom log delegates continue to work without changes. DefaultLogDelegate routes its minLogLevel filter through this method, and NoneLogDelegate returns false for every level.

• Fixed main-thread hang from log message formatting: Cached the DateFormatter used by the SDK's logging utility as a single static instance instead of creating one per log call. Combined with the new shouldLog short-circuit, this fixes a 2.4–3.2s main-thread hang observed on foreground transitions in apps using a restrictive minLogLevel.

• Fixed NetworkMonitor memory leak: Resolved a memory leak where NWPathMonitor and its wrapper were retained for the lifetime of the app across foreground/background cycles. NetworkMonitor.start() is now idempotent, and stop() reliably cancels and releases the monitor. Resolves GitHub issue #867.

• Fixed Swift access race in Pending/Fulfill: Serialized all internal state access in Pending/Fulfill behind a private dispatch queue, with callbacks invoked outside the critical section. Resolves a Thread Sanitizer warning reported by customers and also removes a latent O(N²) firing path when registering callbacks against an already-resolved Pending. Resolves GitHub issue #767.

• Fixed hanging API calls when JWT auth retries are exhausted: Fixed a bug where API calls that triggered a JWT token refresh could hang indefinitely if the refresh hit the retry cap, was paused, or ran after logout. Callers are now notified through a new onRetryExhausted callback instead of being silently dropped, so upstream awaiters always make progress.

# 6.7.0

March 31, 2026

Iterable's iOS SDK Version 6.7.0 includes the following changes:

• Auto-retry for JWT failures in offline processing: When offline event processing is enabled and a queued API call receives a 401 JWT error, the SDK now automatically pauses authenticated task processing, refreshes the JWT token, and retries the failed task. Unauthenticated endpoints (such as disableDevice, mergeUser, and trackConsent) continue processing while authentication is paused. This feature requires no code changes. This feature is not enabled by default — ask your Iterable customer success manager to enable it for your account.

• New lastAuthTokenState property: IterableAPI.lastAuthTokenState exposes the current validity state of the JWT auth token as an AuthTokenValidityState enum (.unknown, .valid, .invalid). Use this to observe auth token health in your application.

  switch IterableAPI.lastAuthTokenState {
  case .valid:
      // Token is verified and active
  case .invalid:
      // A 401 was received; the SDK is refreshing the token
  case .unknown:
      // Token was recently refreshed but not yet verified by a request
  }
  

• Removed trackEmbeddedDismiss and trackEmbeddedImpression: These deprecated methods and their underlying API endpoints have been removed from the SDK. If your code references them, remove those calls.

• In-app display fix: Fixed an issue where inAppDisplayDelegate was not displaying in-app messages during sync cooldown periods. Existing messages are now processed even when a sync is skipped due to cooldown.

• Improved retry logic for offline processing: The SDK now distinguishes between permanent client errors (4xx, except 401 and 429) and transient failures (5xx, network errors, and 429 rate-limit responses). Transient failures are automatically retried; only true client errors are treated as permanent.

• Network connectivity debounce: The offline task runner now debounces connectivity changes (3-second window) to prevent rapid pause/resume cycles when the network connection is unstable.

# 6.6.6

January 28, 2026

Version 6.6.6 of Iterable's iOS SDK includes the following changes:

• Carthage build fix: Resolved SwiftVerifyEmittedModuleInterface errors when building the SDK with Carthage using Xcode 16 / Swift 6.2. The fix makes SendRequestValue and SendRequestError types public to properly support builds with BUILD_LIBRARY_FOR_DISTRIBUTION=YES.

• New isIterableDeepLink method: Added a public static method to check if a URL is an Iterable deep link before handling it. This method returns true if the URL matches the Iterable deep link pattern (URLs containing /a/ in the path).

  if IterableAPI.isIterableDeepLink(urlString) {
      // URL is an Iterable deep link
  }
  

• Support for multiple applications using a shared keychain access group.

• Improves in-app full screen position to display over the entire screen including the status bar.

# 6.6.5

December 19, 2025

Version 6.6.5 contains a fix for an issue with concurrent API requests and adds support for embedded messages, as described in the detailed release notes.

# 6.6.0

September 3, 2025

Version 6.6.0 of Iterable's iOS SDK includes support for Unknown User Activation, which is available in beta; for information about adding it to your project, talk with your Iterable customer success manager.

This update includes the following changes:

• Adds support for capturing user consent with Unknown User Activation.
• Updates to the Unknown User Activation feature to resolve minor issues and bugs.

# 6.5.10

January 20, 2025

Version 6.5.10 of Iterable's iOS SDK includes a fix for the silent push notification–related bug introduced in version 6.5.9.

# 6.5.9

January 15, 2025

This version of the SDK is deprecated. Do not use it.

Version 6.5.9 of Iterable's iOS SDK include changes to help keep a user's Iterable profile in sync with their physical device's push settings for your app (by keeping the device's notificationsEnabled flag up-to-date in Iterable).

However, this version of the SDK includes a bug that can prevent the SDK from receiving silent push notifications, which in turn can prevent end users from receiving expected in-app and embedded messages.

If you've started building on this version of the SDK, please roll back to a previous version while we work on a fix.

# 6.5.5

August 7, 2024

Version 6.5.5 of Iterable's iOS SDK provides more insight into JWT refresh failures, so you can take appropriate action in your application code.

• When a JWT refresh fails (for any of various reasons), the SDK calls onAuthFailure(_ authFailure: AuthFailure) on the IterableAuthDelegate instance you provided to the SDK at initialization. The AuthFailure object provides more information about the failure.

  Note that onAuthFailure(_ authFailure: AuthFailure) replaces onTokenRegistrationFailed(_ reason: String?). If you've implemented onTokenRegistrationFailed, you'll need to update your application code.

• To set a retry policy for JWT refreshes, you can set the retryPolicy property on IterableConfig to a RetryPolicy object. Use this object to specify:

  • The maximum number of consecutive JWT-related request failures the SDK should allow before giving up, Defaults to 10.
  • The interval between each JWT refresh attempt. Defaults to 6 seconds.
  • A backoff strategy: linear or exponential. Defaults to linear.

• You manually pause JWT refresh attempts by calling IterableAPI.pauseAuthRetries(true)

For more information, see the docs for our iOS SDK.

# 6.5.0

Feb 1, 2024

Version 6.5.0 of Iterable's iOS SDK includes support for Embedded Messaging — eligibility–based, personalized messages created in Iterable and displayed inline, using native interface components, in your mobile and web apps. The SDK provides customizable, out-of-the-box embedded message views (cards, banners, and notifications), or you can design and implement fully custom embedded message interfaces.

To learn more, read Embedded Messages with Iterable's iOS SDK.

# 6.4.15

August 31, 2023

Version 6.4.15 of Iterable's iOS SDK supports Iterable's European Data Center.

For more info, see Iterable's iOS SDK.

# 6.4.9

November 8, 2022

Version 6.4.9 of Iterable's iOS SDK makes it possible to store in-app messages in memory, rather than in an unencrypted local file. However, an unencrypted local file is still the default option.

To store in-app messages in memory, set useInMemoryStorageForInApps to true:

Swift

let config = IterableConfig()
config.useInMemoryStorageForInApps = true
IterableAPI.initialize(apiKey: "<YOUR_API_KEY>", launchOptions: launchOptions, config: config)

Objective-C

IterableConfig *config = [[IterableConfig alloc] init];
config.useInMemoryStorageForInApps = YES;
[IterableAPI initializeWithApiKey:@"<YOUR_API_KEY>" launchOptions:launchOptions config:config];

When users upgrade to a version of your iOS app that uses this version of the SDK (or higher), and you've enabled this option, the local file used for in-app message storage (if it already exists) is deleted. However, no data is lost.

# 6.4.8

October 31, 2022

Version 6.4.8 of Iterable's iOS SDK, as a privacy enhancement, encrypts the following data when storing it at rest:

• email — The user's email address.
• userId — The user's ID.
• authToken — The JWT used to authenticate the user with Iterable's API.
• lastPushPayload — The JSON payload that came along with the last push notification received by the app.

(Note that Iterable's iOS SDK does not store in-app messages at rest—before or after this update.)

When a user upgrades to a version of your app that uses this version of the SDK (or higher), the fields shown above are encrypted. No data that's already stored is lost.

For more information about the encryption described above, examine the SDK source code:

• IterableKeychain
• KeychainWrapper

# 6.4.5

July 12, 2022

This release makes offline events processing available to all Iterable customers who'd like to use it — just ask your customer success manager to enable it for your account. Offline events processing saves a local copy of events triggered in your app while the device is offline (up to 1000 events). When a connection is re-established and your app is in the foreground, the events will be sent to Iterable. For more information, read Offline events processing.

# 6.4.0

December 13, 2021

Version 6.4.0 of Iterable's iOS SDK includes the following changes:

• Removes support for iOS 9. For iOS 9 support, use version 6.3.4.

• Prevents in-app messages from executing any JavaScript code included in their HTML templates.

• Adds an allowedProtocols field to the IterableConfig class.

  Use this array to declare the specific URL protocols that the SDK can expect to see on incoming links (and that it should therefore handle). Doing this will prevent the SDK from opening links that use unexpected URL protocols.

  For example, to allow the SDK to handle http, tel, and custom links, set the allowedProtocols field on your IterableConfig object to an array that contains these values:

  Swift

  let config = IterableConfig()
  config.allowedProtocols = ["http", "tel", "custom"]
  IterableAPI.initialize(apiKey: "<YOUR_API_KEY>", launchOptions: launchOptions, config: config)
  

  Objective-C

  IterableConfig *config = [[IterableConfig alloc] init];
  config allowedProtocols = @["http", "tel", "custom"];
  [IterableAPI initializeWithApiKey:@"<YOUR_API_KEY>" launchOptions:launchOptions config:config]
  

  IMPORTANT

  Iterable's iOS SDK handles https, action, itbl, and iterable links, regardless of the contents of this array. However, you must explicitly declare any other types of URL protocols you'd like the SDK to handle (otherwise, the SDK won't open them in the web browser or as deep links).

# Deprecations

This release deprecates and sets an end-of-life date for various older versions of Iterable's iOS SDK, as described in the Deprecation dates and support windows section of this document. Also see Iterable's SDK Support Policy.

# 6.3.0

May 27, 2021

Version 6.3.0 of Iterable's iOS SDK introduces offline events processing. This feature saves a local copy of events triggered in your app while the device is offline (up to 1000 events). When a connection is re-established and your app is in the foreground, the events will be sent to Iterable.

Offline events processing off by default, and we're rolling it out on a customer-by-customer basis. After you start using this version of the SDK, we'll send you a message before we enable the feature on your account (unfortunately, we can't give you an exact timeline for when this will happen). If you have any questions, talk to your Iterable customer success manager.

# 6.2.21

March 30, 2021

Version 6.2.21 of Iterable's iOS SDK includes:

• Support for syncing in-app message read state across multiple devices. Note that:
  • When the SDK fetches in-app messages from Iterable, it examines each message's read field to determine if it has already been read.
  • The SDK's default implementation no longer automatically displays in-app messages that have already been seen on another device (even if those messages were not configured to go directly to the inbox).
  • When you view a message, the SDK calls POST /api/events/trackInAppOpen to create an inAppOpen event on the user's Iterable profile. Previous versions of the SDK made this same API call, but the call now also causes Iterable to set the message's read field to true.
  • Previous versions of the SDK will correctly sync a message's read / unread indicator for the default implementation of a mobile inbox. However, these older SDK versions will not automatically suppress messages that have already been seen on another device (as this version of the SDK will).
• Support for the display of a custom message (title and body) in an empty mobile inbox. For more details, see Customizing Mobile Inbox on iOS

# 6.3.0 - Beta

February 12, 2021

Version 6.3.0-beta2 of Iterable's iOS SDK includes:

• The features introduced in the 6.2.x releases (for example, Mobile Inbox, JWT-enabled API keys, and in-app animations).
• Beta support for offline events processing (capturing engagement events when a device is offline and sending them to Iterable when a network connection is reestablished) and in-app message prioritization (specifying a priority for an in-app message campaign, to determine its display order for your users). To try these beta features, have your Iterable customer success manager enable them for your project.

# 6.2.0

February 25, 2020

This release moves version 6.2.0 of Iterable's iOS SDK out of beta. It also adds customization options to the Mobile Inbox feature. For more details, see Customizing Mobile Inbox on iOS.

# 6.2.0 - Beta

October 15, 2019

Version 6.2.0 (beta) of Iterable's iOS SDK works with Iterable's Mobile Inbox feature. With Mobile Inbox, users of your mobile apps can save in-app messages and revisit them when it's convenient or when the content is more relevant.

The SDK includes a default implementation of an inbox user interface, which can be customized as necessary to match your brand's styles. Also, it automatically captures inbox-related events to Iterable, where they can be used to segment users, filter and trigger journeys, or send system webhooks.

To get started with Mobile Inbox:

• Read In-App Messages and Mobile Inbox.
• Install the version 6.2.0 beta of Iterable's iOS SDK.

# 6.1.0

June 10, 2019

Version 6.1.0 of the Iterable iOS SDK is now generally available and supported by Iterable.

This version of the SDK automatically downloads new in-app messages, allows apps more control over which in-app messages to display and when to display them, and consolidates the way deep links are handled across push notifications, in-app messages, and emails. For more information, see the beta announcement.

# How to upgrade

Upgrading to version 6.1.0 of the Iterable iOS SDK requires some code changes in your mobile apps. For more details, read Upgrading from a version prior to 6.1.0.

# Deprecations

This release deprecates and sets an end-of-life date for various older versions of Iterable's iOS SDK, as described in the Deprecation dates and support windows section of this document. Also see Iterable's SDK Support Policy.

# 6.1.0 - Beta

May 13, 2019

The version 6.1.0 beta of Iterable's iOS SDK provides various new features:

• Automatic downloading of new in-app messages

  With this version of the SDK, mobile apps automatically download all available in-app messages and store them on device. This makes it possible to inspect the messages to decide when and how to display them. Automatic in-app message downloads happen:

  • When Iterable sends silent push notifications (not visible or audible to the user) indicating that new in-app messages are available.
  • At key points in the mobile app's lifecycle, such as when it launches or comes to the foreground.

  This feature makes it easier than ever to test in-app message campaigns. Simply send a proof and wait for it to appear in the app (no need to manually force the app to download new messages, as could be the case with previous versions of the SDK).

• More control for mobile apps to decide when and how to display in-app messages

  Since this version of the SDK automatically downloads all available in-app messages and stores them on device, the mobile app can examine each message to decide when and how to display it. For example, the app might:

  • Skip displaying a particular message
  • Display multiple messages in sequence (by default, in-app messages display in sequence, with a 30-second delay between messages—but this is customizable)
  • Wait to display a particular message until a network connection is available
  • Create a native user interface for a particular message, rather than rendering the HTML supplied by Iterable
  • Display a particular in-app message when a user completes a specific action in the app

• Consolidated handling of deep link URLs

  This version of the SDK provides a common way to handle deep link URLs in a mobile app. With this feature, deep link URLs in emails, in-app messages, and push notifications are all handled in the same way, making it easier for marketers to define a set of deep link URLs that work as expected, regardless of message type.

# How to upgrade

Upgrading to version 6.1.0 of the Iterable iOS SDK requires some code changes in your mobile apps. For more details, read Upgrading from a version prior to 6.1.0.

# More information

To learn more, take a look at the Iterable iOS SDK 6.1.0 beta on GitHub.

# Deprecation dates and support windows

This table lists deprecation dates, support windows, and end-of-life dates for various versions of Iterable's iOS SDK.

# Further reading

• Iterable's SDK Support Policy