XFlowSDK is the backend-driven UI engine that renders Fidelity flows from service-provided configuration.
Durable Context
XFlow behavior depends on backend rules, entry point, and authentication state.
SwiftUI migration work introduced recurring behavior questions that were not just visual; many were contract or lifecycle issues.
XFlowSDK is developed in the dedicated repository pr100660-xflow-for-ios.
Historical Slack patterns show recurring topics around:
component type expansion in SwiftUI
Next-button visibility rules
markdown link handling and analytics
modal presentation and dismissal sequencing
consumer-vs-framework ownership boundaries
Release Mechanics
XFlowSDK publishing currently uses the Jenkins pipeline xflow-for-ios-publish.
The publish flow builds the XCFramework, publishes it to internal Fidelity Artifactory at artifactory.fmr.com, and publishes the podspec to ap010981-ios_podspecs_3x.
Once published, the new SDK version can be adopted downstream through pod install or pod update, but consumer validation still depends on XFlowViewMaker and Fid4 propagation.
Debugging Implications
Do not treat XFlow output as static UI; backend configuration can change the result.
When behavior differs across environments, check whether the issue is:
service/configuration driven
auth-state driven
entry-point driven
consumer-integration driven
Some apparent XFlow regressions historically turned out to be consumer, pipeline, or environment issues.
Historical Signals From Slack
SwiftUI behavior repeatedly needed parity work beyond UIKit assumptions.
Next-button visibility logic required using the full set of service parameters, not only label text.
Modal, delegate, and lifecycle sequencing became recurring themes in pure SwiftUI environments.
XFlow work often had to be validated through consumer repositories, not only inside the SDK.
