PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation

Status

Approved title: Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation.
This work is currently framed in the workspace as a dual UIKit/SwiftUI plan that removes UIHostingController dynamically while preserving both flows appropriately.
The remaining deliverable is process-oriented, not just technical implementation.

Define a consumer-facing rollout plan for the broader UIKit-removal work.
Preserve both UIKit and SwiftUI paths appropriately while introducing the new path safely.
Cover risky entry points such as FTTransfer, while keeping the latest spike finding explicit that consumer-side changes there may no longer be strictly required after the SwiftUI dismissal behavior is applied correctly.
Include validation expectations in XQ1.
Use a global feature-flag rollout model rather than entry-point-based enablement.
Include consumer communication expectations.
Include a 30-day production period with no reported bugs before final removal.
Include a follow-up release to remove the feature flag and old code after rollout confidence is achieved.

The feature-flag and rollout planning guidance applies to the broader UIKit-removal spike, not only to dismissal-sequencing work.
Jeff suggested sending the process-oriented rollout document to Quy for feedback when ready.
The draft shared with Jeff already reflects the global feature flag, broad XQ1 validation, and consumer-facing rollout flow guidance.
Additional review feedback from April 13: rename the proposed flag to xflow-swiftui-enabled, make consumer contact and XQ1 validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification.
On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section.
April 15 clarification: do not reuse the existing SwiftUI LaunchDarkly flag for this rollout.
The new flag name for this work should be xflow-swiftui-container-enabled.
The document should note that the flag is to be added in the future as part of implementation.
Late April 14 guidance: the document was approved late in the day; the next step is to publish it, then close out the spike by commenting Spike Results: with the relevant document links and the new follow-up story link.
The new follow-up story should also be marked as a blocker for the reopened UIKit-removal story.