FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTransfer, and related libraries that mediate how XFlow changes reach Fid4.
Durable Context
FTFrameworks is often part of the real validation and release chain, not just a downstream detail.
Historical Slack context shows pinned FT module versions repeatedly blocking adoption of newer XFlow or XFlowViewMaker changes in Fid4.
Changes to XFlow often needed corresponding FTAccountOpen or FTTransfer updates before end-to-end testing was realistic.
FTAccountOpen and FTTransfer consume XFlow through XFlowViewMaker rather than directly from XFlowSDK.
For Account Opening flows, the current path is understood to go through FTAccountOpen.
Validation And Release Implications
If Fid4 does not reflect the expected XFlow fix, check FT module versions before concluding the SDK change failed.
Version movement can require a chain such as:
XFlowSDK
XFlowViewMaker
FTAccountOpen / FTTransfer
Fid4
Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready.
FTFrameworks code-owner approval can also be a practical gate when the XFlowViewMaker update PR lives inside the shared PR100660-ios-frameworks monorepo.
In the current XFlowViewMaker propagation pattern, effective downstream constraints may be enforced in the podspec repo rather than the FTFrameworks source repo itself.
A successful Fid4 upgrade required removing the XFlowViewMaker version reference from both the latest FTAccountOpen and FTTransfer podspecs in the podspec repo, then rerunning pod install --repo-update.
Historical Signals From Slack
FTAccountOpen and FTTransfer were repeatedly mentioned in version bump and release coordination work.
Historical messages also tied FTFrameworks to FTAuth and MFA-related stories, showing that dependency understanding matters when sizing or scoping work.
