- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps.
- Established a daily logs index for easy navigation of daily notes.
- Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams.
- Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
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.
david.delagneau
1ad707373a