59 lines
4.3 KiB
Markdown
59 lines
4.3 KiB
Markdown
---
|
|
type: work-item
|
|
project: fidelity
|
|
status: backlog-ready
|
|
ticket: PDIAP-12284
|
|
title: "Remove UIKit wrapping from XFlow"
|
|
systems: [xflowsdk, xflowviewmaker]
|
|
workstreams: [xflow-swiftui-migration, consumer-integration]
|
|
people: [jeff-dewitte]
|
|
related: [pdiap-15836, pdiap-15838]
|
|
updated: 2026-05-12
|
|
tags:
|
|
- work-item
|
|
- fidelity
|
|
- swiftui
|
|
- xflow
|
|
---
|
|
|
|
# PDIAP-12284 - Remove UIKit wrapping from XFlow
|
|
|
|
## Status
|
|
|
|
- Reopened after rollback.
|
|
- Quy already moved this story into the next sprint (`26Q2.6`); leave it in To Do until the sprint starts on Thursday.
|
|
- 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.
|
|
|
|
---
|
|
|
|
## 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.
|