Files

david.delagneau 46c7ce2824 refactor: update work items and daily logs for PDIAP-12284 and PDIAP-15836, enhancing host-mode resolution strategy and lifecycle sequencing

2026-05-11 07:15:34 -06:00

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

type

project

status

ticket

title

systems

workstreams

people

updated

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.

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.

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.

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.