61 lines
3.5 KiB
Markdown
61 lines
3.5 KiB
Markdown
---
|
|
type: system
|
|
project: fidelity
|
|
status: active
|
|
workstreams: [consumer-integration, xflow-swiftui-migration]
|
|
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-12284]
|
|
updated: 2026-05-08
|
|
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.
|
|
- For the current `PDIAP-12284` / `PDIAP-15836` migration planning, XFlowViewMaker is the preferred candidate owner for global host-mode resolution if product-code inspection confirms it can access the existing feature-flag abstraction cleanly. This avoids Fid4-owned per-flow mapping and keeps XFlowSDK decoupled from app-specific LaunchDarkly/Flagship clients.
|
|
- The desired host-mode behavior for that migration is SwiftUI host by default, SwiftUI host when feature configuration is missing or unknown, and `UIHostingController` only when an explicit temporary fallback flag requests it.
|
|
|
|
---
|
|
|
|
## 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.
|