---
type: system
project: fidelity
status: active
workstreams: [consumer-integration, xflow-swiftui-migration]
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
updated: 2026-04-17
tags:
  - system
  - fidelity
---
# XFlowViewMaker

## Role

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.