XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework integration. It is under evaluation for reduction or removal.
Durable Context
Historical release work often required bumping XFlowViewMaker alongside XFlowSDK before consumer validation was possible.
XFlowViewMaker was a recurring source of coupling between XFlow changes and Fid4 or flagship rollout.
Historical Slack evidence shows that version bumps through XFlowViewMaker were often blocked by external pipeline or dependency issues rather than pure feature regressions.
XFlowViewMaker currently lives in the monorepo PR100660-ios-frameworks under Adapters/XFlowViewMaker.
Release Mechanics
When XFlowSDK releases a new version, XFlowViewMaker usually needs a follow-up dependency bump before Fid4 can consume the change.
The common release flow is:
update the XFlowViewMaker podspec to the new XFlowSDK version
run tuist generate -n
run pod install
open a PR
wait for required approvals, including protected-branch/code-owner approval when applicable
merge, often through automerge once approvals are complete
let the Jenkins pipeline publish-XFlowViewMaker publish the adapter release
publish-XFlowViewMaker usually auto-detects the next version and commonly increments the minor version automatically.
The publish flow distributes the new adapter version through Artifactory/podspec channels and updates the XFlowViewMaker version on main.
Integration Implications
When a fix exists in XFlowSDK but is not visible in consumer validation, check whether XFlowViewMaker or downstream pinned versions are blocking adoption.
If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it.
Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as FTAccountOpen and FTTransfer.
Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
Historical Signals From Slack
XFlowViewMaker version bumps into flagship frequently surfaced PreviewMacros.SwiftUI, Apex, or pipeline compatibility issues.
Historical context shows growing pressure to reduce XFlowViewMaker-specific indirection and move toward simpler consumer paths.
Slack history also shows that tutorials and release steps around XFlowViewMaker were easy to misunderstand, which made version propagation a repeated risk.
