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.
Fid4 currently consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
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.
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.
