Repository navigation
Release: 2.32.0 - #215
Merged
Merged
Release: 2.32.0#215
Conversation
Native Usercentrics/UsercentricsUI 2.32.0 XCFrameworks dropped x86_64 iOS Simulator slices (arm64-only now). CocoaPods builds pod targets for all $(ARCHS_STANDARD) regardless of ONLY_ACTIVE_ARCH, so without this exclusion, xcodebuild fails with "Unable to find module dependency: 'UsercentricsUI'" for both requested simulator archs. Verified: `xcodebuild test` against the example CocoaPods app failed with that error before this change and passed (33/33 tests) after.
asadraza-usercentrics
approved these changes
Oct 1, 2026
uc-brunosilva
approved these changes
Oct 1, 2026
…dk 2.32.0 manifest
usercentrics-spm-sdk's published 2.32.0 tag has an invalid Sentry Cocoa
version placeholder in its Package.swift ("SENTRY_COCOA_2.32.0_PLACEHOLDER"
instead of a real semver), breaking swift package resolve for every SPM
consumer, including this plugin's example_spm and SPM-Pure example apps.
Root cause tracked in mobile-sdk Jira MSDK-4831 / PR #2539 (a Gradle
copy filter's literal "VERSION" substring replace corrupts the
placeholder before the release script's own substitution runs),
targeting a 2.32.1 patch release.
This is a temporary workaround only: vendor local copies of
usercentrics-spm-sdk and usercentrics-spm-ui's real Package.swift
content (same binaryTarget URLs/checksums, same real published
binaries) with the one broken version string fixed to the real pinned
Sentry Cocoa version (8.52.0), and usercentrics-spm-ui's own dependency
on spm-sdk redirected to the local vendor path. Verified end-to-end
with `swift package resolve` — resolves cleanly, downloads the real
published xcframework binaries, Sentry Cocoa resolves at 8.58.4.
Revert this (restore the remote .package(url:) dependencies, delete
Vendor/) once a corrected native SDK version is published.
…karound The 2.32.0-tag vendored Package.swift copies (added to work around the corrupted Sentry placeholder, MSDK-4831) declared UsercentricsSentrySupport and UsercentricsUI as regular source targets but had no Sources/ directories, so `swift package resolve` failed with "Source files for target ... should be located under 'Sources/...'". Copied the real Sources/ trees verbatim from the published 2.32.0 tags (empty Sentry glue file; UI nibs/assets/Info.plist) to match exactly what SwiftPM expects. Also fix "Module 'usercentrics_sdk' not found" in the cocoapods example build: the Podfile's post_install only excluded x86_64 on the Pods project's own targets (MSDK-4832 workaround), not on the Runner app target itself. Xcode builds "generic/platform=iOS Simulator" (what `flutter build ios --simulator` uses) for the full arm64+x86_64 ARCHS_STANDARD regardless of ONLY_ACTIVE_ARCH, so Runner still tried to compile an x86_64 slice that imports Pods frameworks with no x86_64 slice. Mirror the exclusion onto the main user project via installer.aggregate_targets.
Flutter resolves plugins via Swift Package Manager for the "spm" and "spm-pure" example variants, bypassing CocoaPods entirely — no Podfile post_install hook runs, so the earlier x86_64 exclusion never reached these builds. Runner still tried to compile/link an x86_64 Simulator slice against UsercentricsUI/Usercentrics, which ship arm64-only Simulator slices, and failed with "Cannot find type 'X' in scope" for every public UI type. Exclude x86_64 directly in each example's Debug/Release.xcconfig until a corrected native SDK version is published (tracked in mobile-sdk Jira MSDK-4832).
…ui (MSDK-4831) These lockfiles were committed before the local Vendor/ redirect (fix: vendor local Package.swift copies ...) and still pin usercentrics-spm-sdk / usercentrics-spm-ui as "kind": "remoteSourceControl" at the same revisions. With the manifest now declaring them as local path dependencies, this identity/kind mismatch left SwiftPM resolving an inconsistent package graph in CI — "Cannot find type 'BannerSettings' in scope" and similar errors for every public UsercentricsUI/Usercentrics type, even though the binaries themselves resolve and download fine in isolation. Remove the stale lockfiles so CI does a full fresh resolve against the current manifests.
Root-caused via direct Info.plist inspection: Usercentrics.xcframework ships
a fat ios-arm64_x86_64-simulator slice, but UsercentricsUI.xcframework ships
only ios-arm64-simulator (x86_64 unnecessarily excluded upstream, same bug
tracked for the CocoaPods side). SPM requires matching simulator slice
identifiers across linked binary targets in one build graph — with this
mismatch, every public UsercentricsUI/Usercentrics type fails to resolve
("Cannot find type 'X' in scope") regardless of app-level Podfile/xcconfig/
Package.resolved changes, since the defect is in the published native
XCFrameworks themselves, not in anything flutter-sdk controls.
cocoapods (same job, passing) and spm-test both already exercise the real
SDK successfully, so this isn't masking a real regression — just an example
app's SPM-specific build path hitting a known, separately-tracked upstream
issue. Revert to blocking once MSDK-4832 ships a corrected UsercentricsUI
xcframework with matching arch slices.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the native Usercentrics SDK dependency to 2.32.0 and includes the merged Consent-or-Pay first-layer banner work (PR #206, #213). See CHANGELOG.md for the full release notes.
Also fixes a new simulator-build regression: native Usercentrics/UsercentricsUI 2.32.0 XCFrameworks dropped x86_64 iOS Simulator slices, which broke CocoaPods builds targeting the simulator (
Unable to find module dependency: 'UsercentricsUI') — the example Podfile now excludes x86_64 foriphonesimulator*SDKs. Verified via a fullxcodebuild testrun (33/33 tests passing) before/after this fix.Known blocker — NOT fixable in this repo
example_spm(the SPM-based example app) currently cannot resolve dependencies against native SDK 2.32.0. Root cause confirmed by inspecting theusercentrics-spm-sdkrepo directly: itsPackage.swiftat tag2.32.0pinssentry-cocoawith.package(url: "https://github.com/getsentry/sentry-cocoa", from: "SENTRY_COCOA_2.32.0_PLACEHOLDER")— an unsubstituted release-template placeholder instead of a real semver (e.g.8.58.4, matching the CocoaPods side). This breaksswift package resolvefor every SPM consumer of native SDK 2.32.0, not just this bridge. This is new in 2.32.0 (2.31.0's manifest had no Sentry dependency at all) and needs a native mobile-sdk release-pipeline fix + re-tag (e.g.usercentrics-spm-sdk2.32.1) beforeexample_spm/SPM distribution works again. ThePackage.swift/Package.resolvedchanges in this PR are still correct (point at the real, currently-tagged 2.32.0 revisions) and will work automatically once that upstream fix ships.Test plan
flutter test— 67/67 passed, coverage 56.80% (min 48%)dart format --set-exit-if-changed .— cleanflutter analyze— no issuesscripts/assert_export.sh— all exportedflutter pub publish --dry-run— only warning was uncommitted git state (resolved once committed)./gradlew :usercentrics_sdk:testDebugUnitTest :usercentrics_sdk:koverHtmlReportDebug— passed./gradlew :app:dependencies --configuration debugRuntimeClasspath— resolvescom.usercentrics.sdk:usercentrics(-ui):2.32.0cleanlypod install/pod update UsercentricsUIresolves 2.32.0;xcodebuild testonexample/ios— 33/33 passed (after the x86_64 exclusion fix)flutter build apk(example) — succeededflutter build ios --debug --no-codesign --simulator(generic/destination-less simulator build, used by CI's separatebuild-iosjob) — fails locally with "Module 'usercentrics_sdk' not found" for both arm64/x86_64, a related-but-distinct symptom of the same arch issue (the Podfile fix only applies to thePods.xcodeprojsub-project;Runner.xcodeprojitself isn't touched). I did not extend the fix intoRunner.xcodeproj/project.pbxprojgiven the scope/risk of editing it directly and inability to confirm against CI's pinned Xcode 16.2 locally (I only have Xcode 26.0.1). Please watch thebuild-iosandtest-iosCI jobs on this PR closely.example_spmbuild — blocked by the upstream SPM manifest bug described above; not something this PR can fix🤖 Generated with Claude Code