Affected SDKs:
iOS: Iterable-iOS-SDK 6.6.7 (confirmed in DeepLinkManager.swift / Constants.swift)
Android: com.iterable:iterableapi 3.6.2 (confirmed via decompiled IterableDeeplinkManager)
Surfaced through: @iterable/react-native-sdk 2.2.1
Summary
When a member taps an Iterable-shortened link (https://links./a/) whose token begins with a non-alphanumeric character (e.g. an underscore), the SDK fails to recognize it as an Iterable deep link and never attempts to resolve it to the real destination URL. The original short link is passed through unresolved, so the host app has no way to know where it was actually supposed to route.
Root cause
Both the iOS and Android SDKs gate deep-link resolution behind a regex check for the short-link path:
iOS — DeepLinkManager.swift, isIterableDeepLink(_:), using the pattern defined in Constants.swift:
static let deepLinkRegex = "/a/[a-zA-Z0-9]+"
Android — IterableDeeplinkManager, equivalent pattern:
/a/[A-Za-z0-9]+
Neither character class includes _, -, or any other character outside plain alphanumerics. When the regex fails to match:
isIterableDeepLink() returns false
The SDK skips its normal resolution flow (the network round-trip that follows the redirect and returns the real destination URL)
It falls through to treating the original, still-shortened URL as if it were the final destination, and hands that back to the host app's URL handler unchanged
What I dont understand is how is the shortened link generated with an _ when its own resolver check regex doesnt have _ ? Does anybody else face this issue ? Can the contributor bring a fix in the regex in the next update for this issue ?
Affected SDKs:
iOS: Iterable-iOS-SDK 6.6.7 (confirmed in DeepLinkManager.swift / Constants.swift)
Android: com.iterable:iterableapi 3.6.2 (confirmed via decompiled IterableDeeplinkManager)
Surfaced through: @iterable/react-native-sdk 2.2.1
Summary
When a member taps an Iterable-shortened link (https://links./a/) whose token begins with a non-alphanumeric character (e.g. an underscore), the SDK fails to recognize it as an Iterable deep link and never attempts to resolve it to the real destination URL. The original short link is passed through unresolved, so the host app has no way to know where it was actually supposed to route.
Root cause
Both the iOS and Android SDKs gate deep-link resolution behind a regex check for the short-link path:
iOS — DeepLinkManager.swift, isIterableDeepLink(_:), using the pattern defined in Constants.swift:
static let deepLinkRegex = "/a/[a-zA-Z0-9]+"
Android — IterableDeeplinkManager, equivalent pattern:
/a/[A-Za-z0-9]+
Neither character class includes _, -, or any other character outside plain alphanumerics. When the regex fails to match:
isIterableDeepLink() returns false
The SDK skips its normal resolution flow (the network round-trip that follows the redirect and returns the real destination URL)
It falls through to treating the original, still-shortened URL as if it were the final destination, and hands that back to the host app's URL handler unchanged
What I dont understand is how is the shortened link generated with an _ when its own resolver check regex doesnt have _ ? Does anybody else face this issue ? Can the contributor bring a fix in the regex in the next update for this issue ?