Fid4 is the main Fidelity consumer iOS app and the most important environment for validating real integration behavior.
Durable Context
Fid4 is the newer flagship-style app and is heavily SwiftUI-based.
Validation in Fid4 often reveals issues that do not appear in XFlowSDK isolation or sample apps.
Historical Slack context shows that some tickets were incorrectly scoped until behavior was checked in Fid4 or flagship.
Real consumer testing in Fid4 matters for modal presentation, validation messaging, and backend-driven flow behavior.
Fid4 currently consumes XFlow through XFlowViewMaker rather than depending on XFlowSDK directly.
Validation Implications
If an issue depends on real flow behavior, do not assume XFlow-only validation is sufficient.
When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope.
Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint.
Fid4 currently adopts XFlow changes through the app repo ap010981-ios-flagship-app after XFlowViewMaker has been published.
The common update path is:
modify the Podfile to the new XFlowViewMaker version
run tuist generate -n
run pod install --repo-update
open and merge a PR
wait for the consumer team to carry the change forward in their normal App Store release flow
Podfile.lock is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles.
Historical Signals From Slack
Fid4 was repeatedly referenced as the right place to verify SwiftUI/XFlow bugs before finalizing scope.
Historical work included modal-on-modal presentation issues, goal/date validation behavior, and consumer-facing eventing questions.
Some XFlow tickets needed rework because the original spike or story had not been validated in flagship/Fid4.
