We ended up patching the SDK podspec to pin the swift pod version to the last working patch (6.5.4). Suggest that you lock this version so that these don't drift without integration testing in the future.
Additional context: on Expo with the managed workflow (not committing the ios folder and relying on expo prebuild), we don't commit the Podfile.lock which means we can get version drifts like this that are unforeseen when they're within the accepted version range (~>).
I suspect in the bare metal react native approach where all of these files are committed, you'd at least be able to choose whether to commit the lockfile bump or have to manually upgrade the cocoapod versions and therefore have more visibility into this kind of issue before builds start breaking in CI
See https://github.com/Iterable/swift-sdk/issues/799 for underlying issue
We ended up patching the SDK podspec to pin the swift pod version to the last working patch (
6.5.4
). Suggest that you lock this version so that these don't drift without integration testing in the future.Additional context: on Expo with the managed workflow (not committing the ios folder and relying on
expo prebuild
), we don't commit thePodfile.lock
which means we can get version drifts like this that are unforeseen when they're within the accepted version range (~>
).I suspect in the bare metal react native approach where all of these files are committed, you'd at least be able to choose whether to commit the lockfile bump or have to manually upgrade the cocoapod versions and therefore have more visibility into this kind of issue before builds start breaking in CI