Version pins, publishing delays, and consumer build issues can block validation even when the original code change is ready.
Current Release Propagation Model
The current release path is usually:
pr100660-xflow-for-ios releases XFlowSDK
PR100660-ios-frameworks/Adapters/XFlowViewMaker updates to that XFlowSDK version and publishes a new XFlowViewMaker release
ap010981-ios-flagship-app updates Fid4 to the new XFlowViewMaker version
downstream consumer release then determines when the change reaches the App Store build
A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated.
In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
In the current integration model, Fid4 consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
For current-state reasoning and communication, treat XFlowViewMaker as a required part of the Fid4 propagation path, not as an optional or "usually" present layer.
Other frameworks also consume XFlow through XFlowViewMaker, especially FTAccountOpen and FTTransfer.
For Account Opening paths, the practical consumer route is currently understood to run through FTAccountOpen.
Step-By-Step Propagation
Release XFlowSDK from pr100660-xflow-for-ios.
Jenkins pipeline: xflow-for-ios-publish
Produces the XCFramework artifact
Publishes to internal Fidelity Artifactory at artifactory.fmr.com
Publishes the podspec to the dedicated podspec repo ap010981-ios_podspecs_3x
After publication, consumers can adopt the new SDK version through CocoaPods
Update and release XFlowViewMaker from PR100660-ios-frameworks.
XFlowViewMaker lives in Adapters/XFlowViewMaker
Update the XFlowViewMaker podspec to the new XFlowSDK version
Run tuist generate -n
Run pod install
Open a PR and get required approvals
Ping code owners when protected-branch approval is the remaining blocker
After merge, the publish-XFlowViewMaker Jenkins pipeline publishes the adapter
That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example 0.5.0 -> 0.6.0
Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on main
Update Fid4 in ap010981-ios-flagship-app.
Modify the Podfile to consume the new XFlowViewMaker version
Run tuist generate -n
Run pod install --repo-update
Open a PR and get approvals
After merge, the consumer team owns the final application release to the App Store
Investigation Rules
Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
When the question is specifically about Account Opening, verify the path through FTAccountOpen before assuming a direct Fid4-only dependency view is sufficient.
Separate these failure modes:
SDK bug
adapter/version propagation issue
protected-branch or code-owner approval delay
publish pipeline failure or auto-versioning surprise
FT module publish/test issue
consumer app setup or pipeline issue
Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
Version verification in Fid4 is not always straightforward because Podfile.lock is currently ignored in the app repo.
The fastest reliable signals are:
fixed version references in the Podfile when present
archived pipeline artifacts such as xcarchive outputs and captured Podfile.lock files
Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
When a consumer build must be reproduced exactly from an older dependency snapshot, Podfile.lock alone may still be insufficient if the private podspec repo changed afterward; the stronger reproduction path is to align the podspec repo revision too.
A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in FTAccountOpen or FTTransfer do not yet accept the new adapter version.
Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
Current evidence suggests the effective constraint may live in the podspec repo layer rather than in the FTFrameworks source repo itself.
For the current XFlowViewMaker propagation issue, the practical fix was made in the podspec repo by removing the XFlowViewMaker version reference from both the latest FTAccountOpen and FTTransfer podspecs.
After that podspec-repo PR was merged, pod install --repo-update in Fid4 resolved successfully because those podspecs no longer constrained the XFlowViewMaker version.
FTAccountOpen and FTTransfer do not appear to hold a direct XFlowViewMaker version reference in their checked FTFrameworks source podspec files; the effective resolution is managed through the published podspec layer and ftAdapter behavior.
This appears to be a risky workaround rather than a healthy long-term dependency-management pattern.
CocoaPods documentation recommends explicit dependency requirements in podspecs and specifically recommends the optimistic operator ~> because it gives version control without being overly restrictive.
Removing version constraints entirely from published intermediate podspecs weakens compatibility guarantees, makes transitive resolution less predictable, and increases the chance that consumers pick up unvalidated downstream versions.
That risk is even higher in this workspace because Fid4 does not keep Podfile.lock in Git, so published podspec changes can alter future resolutions without a strong repository-level lockfile trail.
Historical Signals From Slack
Version bump work repeatedly involved XFlowViewMaker, FTAccountOpen, and FTTransfer.
Some rollout problems involved Jenkins, Apex/ApexKit, preview macro compatibility, or secret/token access rather than the product behavior under investigation.
