fix(ios-e2e): Xcode 26 + Swift compat libs for PurchaseConnector 6.17.x#419
Merged
Conversation
…sion) Both deploy/build_unity_package.sh and deploy/strict_mode_build_package.sh had the --version) case hardcoded to 6.18.0 instead of using $2. This caused the manual E2E package to be named 6.18.1 instead of manual-test. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When release_tag is provided (e.g. v6.18.1), the build-package job downloads the published .unitypackage from the GitHub release instead of building from source. The tag is also used as the checkout ref so AppsFlyerDependencies.xml matches the released versions. When release_tag is omitted, behaviour is unchanged (build from source). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Old tags (e.g. v6.18.1) don't have scripts/import-unity-package.py. Always checkout github.ref_name (the workflow branch) so scripts exist, then fetch AppsFlyerDependencies.xml from inputs.release_branch when it differs, so pod versions still match the tested release. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…cripts rc-e2e-ios.yml: restored to original (checkout release_branch). e2e-manual.yml: always use github.ref_name as checkout ref so scripts exist regardless of how old the release_tag is. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
New workflow_dispatch workflow that downloads a published .unitypackage from a GitHub release by tag and runs the full E2E suite (iOS + Android) against it. No Unity build step needed — tests the exact artifact shipped to customers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
e2e-manual.yml: when release_tag is set, fetch AppsFlyerDependencies.xml from the release tag and bundle it in the artifact alongside the package. rc-e2e-ios.yml: after artifact download, restore AppsFlyerDependencies.xml if bundled, so ios-pod-install.sh uses the correct pod versions for the release being tested rather than the workflow branch versions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Cache test-app/Library between runs to avoid full reimport (~20 min saved). Also increase build timeout from 30 to 60 min to handle cache-miss runs. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds --android-billing-version flag to bump-version.sh and a corresponding android_billing_version input (default 8.0.0) to rc-release.yml so the billing library version can be overridden at dispatch time without requiring a prep branch. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rameAlloc PurchaseConnector 6.17.9+ uses Swift 5.9 coroutine runtime symbols (_swift_coroFrameAlloc) that are only OS-provided on iOS 17+. With platform :ios, '15.0' and static linkage they were never back-deployed into the simulator build, causing a consistent linker failure. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pods_UnityFramework was built at iOS 17 (from ios-pod-install.sh) but xcodebuild was linking the app at iOS 15, causing a deployment target mismatch. Adding IPHONEOS_DEPLOYMENT_TARGET=17.0 to xcodebuild aligns both sides so _swift_coroFrameAlloc resolves from the OS runtime. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… (iOS 17)" This reverts commit 943a32f.
…ft_coroFrameAlloc" This reverts commit 998e9c9.
PC < 6.18.0 was compiled with Swift 5.9/5.10 (Xcode 15) and references _swift_coroFrameAlloc, which was removed from the Swift 6.0 (Xcode 16) runtime. PC >= 6.18.0 was compiled with Swift 6.0 and links fine with Xcode 16. Read the PC version from AppsFlyerDependencies.xml at runtime to automatically select the compatible Xcode toolchain. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…linker error PC 6.17.9 references _swift_coroFrameAlloc which is not resolvable on macos-14 (max Xcode 16.2). macos-15 ships with a newer Xcode that should provide the Swift runtime symbols needed to link PurchaseConnector 6.17.x. Also reverts the PC-version-aware Xcode selection (Xcode 15 also failed). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…meAlloc UnityFramework has no Swift source files so Xcode does not add $(SDKROOT)/usr/lib/swift to the linker search path. PurchaseConnector 6.17.x compiles Swift code that references _swift_coroFrameAlloc, which lives in libswiftCore.tbd at that path. Add LIBRARY_SEARCH_PATHS and OTHER_LDFLAGS via xcodebuild so the linker can resolve the symbol. Also remove deprecated VALID_ARCHS setting. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The symbol _swift_coroFrameAlloc is in libswiftCore.tbd starting from iOS 26 SDK (Xcode 26). Xcode 16 ships iOS 18 SDK which does not export it, causing a linker failure when PurchaseConnector 6.17.x is linked into UnityFramework. macos-15 runner has Xcode 26.3 available. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…hone target Add $(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME) to LIBRARY_SEARCH_PATHS and -lswiftCompatibility56 -lswiftCompatibilityConcurrency to OTHER_LDFLAGS. Unity-iPhone target has no Swift sources so Xcode doesn't auto-add these paths; PurchaseConnector 6.17.x emits __swift_FORCE_LOAD_$ symbols that require them. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…mpat libs On macos-15/Xcode 26 runners TOOLCHAIN_DIR resolves to the Metal toolchain which has no Swift compat libs. DEVELOPER_DIR always points to the selected Xcode Developer dir; XcodeDefault.xctoolchain is the stable relative path. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
al-af
previously approved these changes
Jun 15, 2026
Keep parameterized version in deploy scripts (development version). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
al-af
approved these changes
Jun 15, 2026
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
2 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.
Summary
macos-14→macos-15_swift_coroFrameAlloconly exists in the iOS 26 SDKDEVELOPER_DIR/Toolchains/XcodeDefault.xctoolchaintoLIBRARY_SEARCH_PATHSand-lswiftCompatibility56 -lswiftCompatibilityConcurrencytoOTHER_LDFLAGS— resolves__swift_FORCE_LOAD_$_swiftCompatibility56/Concurrencylinker errors for the non-SwiftUnity-iPhonetargetWhy
PurchaseConnector 6.17.x emits
_swift_coroFrameAllocwhich only exists in the iOS 26 SDK (Xcode 26). The Unity-iPhone target has no Swift sources so Xcode doesn't auto-link the Swift compat static libraries — they must be added explicitly.🤖 Generated with Claude Code