fidelity-ai-workspace/project-knowledge/02-work-items/pdiap-12284.md

type, project, status, ticket, title, systems, workstreams, people, related, updated, tags

type	project	status	ticket	title	systems	workstreams	people	related	updated	tags
work-item	fidelity	in-progress	PDIAP-12284	Remove UIKit wrapping from XFlow	xflowsdk xflowviewmaker	xflow-swiftui-migration consumer-integration	jeff-dewitte	pdiap-15836 pdiap-15838	2026-05-13	work-item fidelity swiftui xflow

PDIAP-12284 - Remove UIKit wrapping from XFlow

Status

• Reopened after rollback and moved to In Progress on May 12.
• Jeff directed David to do this UIKit-removal work and PDIAP-15836 dismissal/lifecycle work in the same branch because both are disruptive enough to require consumer testing.
• Current implementation direction is to avoid Fid4-owned per-flow host-mode mapping and evaluate XFlowViewMaker-owned global host-mode resolution.
• David continued the implementation/validation loop on May 11; current simulator log review is promising for the SwiftUI-host dismissal sequencing in the tested run.
• Jeff confirmed on May 11 that the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) should be implemented as part of this branch's work.
• May 12 implementation pass resolved several earlier concerns: host-mode API appears branch-local/new, enum cases were renamed to neutral swiftUIHost / uiKitHost, the final flag key is iOS-XflowUIKitHostEnabled, missing/false/unavailable flag values default to SwiftUI, and AnyView was removed from buildFlow internals while remaining only at the existing public FlowViewMaker boundary.
• Current validation blocker appears to be dependency alignment rather than host-mode code correctness: XFlowViewMaker is resolving XFlowSDK 2.8.48 from its podspec, which does not expose the new host-mode API needed by the branch.
• After manual dependency/build handling, Fid4 now compiles with the latest FlowViewBuilder shape. Next validation should be runtime evidence: first verify a representative flow selects the default SwiftUI host path, then simulate/force iOS-XflowUIKitHostEnabled == true to verify the temporary UIKit host path and dismissal behavior.
• PDIAP-15836 may become a subtask of this story; final Jira structure and point handling are pending Quy/Jeff direction.

---

Context

• This is the original story for removing the UIKit wrapping.
• Current relationship to track: PDIAP-12284 should be handled with PDIAP-15836 in the same implementation branch. David identified a possible minimal PDIAP-15836 fix path that does not require removing UIHostingController, but Jeff prefers combined branch work because both changes require consumer testing.
• Desired host-mode model: SwiftUI host is the default, missing or unknown feature configuration should also default to SwiftUI, and UIHostingController should remain only as an explicit temporary fallback while consumers validate the migration.
• XFlowSDK should not be coupled directly to LaunchDarkly, Flagship, or app-specific feature-flag clients; it should receive an already-resolved host-mode decision.
• If hostMode must be passed through FlowConfig or a similar object, keep it as adapter/internal plumbing rather than a new consumer-facing per-flow responsibility.
• The latest tested run reported the expected dismissal order for the SwiftUI-host path, but the branch still needs review of the shared host-mode routing and any required broader validation before story closure.
• Resolved implementation-shape decisions from the May 12 pass: keep two host-mode enum types to preserve the boundary where XFlowViewMaker owns host-selection policy and XFlowSDK owns presentation mechanics, keep the single conversion point in FlowViewBuilder, use neutral enum names, and keep SwiftUI as default unless iOS-XflowUIKitHostEnabled is explicitly true.

---

Historical Slack Context

• November 21, 2025 Slack context says David created PDIAP-12284 and PDIAP-12285 to cover remaining UIKit-removal work inside XFlow after reviewing open Sendable and XFlowViewMaker-track stories.
• That same backlog refinement closed out pending XFlowViewMaker stories that were no longer needed.
• Current Mattermost context supersedes the old standalone refinement framing: this story is now reopened after rollback and should be handled together with PDIAP-15836.

---

Sequencing

• Work can begin, but merge/release should wait until the REST-transition consumer-validation window has completed.
• Keep the implementation branch up to date with main while waiting for approval to work with consumers and merge.
• Before implementation is treated as settled, confirm through product-code inspection whether XFlowViewMaker can resolve host mode using existing FeatureEnabling / Featuring abstractions or whether a small dependency-injection path is needed.