--- type: work-item project: fidelity status: in-progress ticket: PDIAP-15836 title: "Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment" systems: [xflowsdk, xflowviewmaker, ftframeworks] workstreams: [xflow-swiftui-migration, consumer-integration] people: [jeff-dewitte] related: [pdiap-14859, pdiap-12284, pdiap-15838] updated: 2026-05-14 tags: - work-item - fidelity - xflow - swiftui --- # PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment ## Status - Moved to In Progress on May 7. - David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, and was validating it. - Jeff directed David to do this dismissal/lifecycle work together with `PDIAP-12284` in the same branch because both changes are disruptive enough to require consumer testing. - May 11 simulator log review suggests the tested SwiftUI-host path now fires in the intended order: host-disappearance confirmation precedes `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as promising validation evidence for the tested run, not final consumer validation. - May 12 branch validation reported that explicit UIKit host mode still preserves dismissal-completion behavior and delegate callbacks/session cleanup remain after confirmed dismissal. Broader compile validation still depends on resolving the XFlowViewMaker / XFlowSDK dependency mismatch. - May 13 AccountLink runtime validation looks good in both SwiftUI-default and forced UIKit-host modes. Both paths preserved the intended dismissal sequencing, with delegate callbacks and session cleanup after confirmed dismissal. - May 14 SampleApp work refined dismissal validation coverage: SampleApp can exercise both UIKit-host and SwiftUI-host paths, while XFlowSDK entrypoints prepare the matching dismissal mechanism for the active integration path. This supports validating that UIKit dismiss completion and SwiftUI `XFlowDismissalHost` lifecycle sequencing both converge on the canonical delegate/session teardown path. - Quy confirmed on May 13 that this story and `PDIAP-12284` can both remain In Progress together, so no immediate Jira restructuring is required. - Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation - Sized at `8` points --- ## Context - This story came out of the `AccountLink` root cause investigation. - It is tied to the dismissal sequencing problem found after UIKit removal in SwiftUI-only paths. - The root cause document was updated and the revised wording was approved. --- ## Approved Scope - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI flows. - Cover the missing lifecycle contract where delegate callbacks can happen before the view is fully removed. - Validate the change across affected SwiftUI flows rather than only in one narrow reproduction. - Preserve a single canonical delegate/session-clear path if possible, and do not treat SwiftUI `onDisappear` as proof of dismissal completion unless simulator logs validate that lifecycle contract. --- ## Sequencing And Dependencies - This story should come after `PDIAP-15838`. - `PDIAP-12284` is the original UIKit-wrapping removal story and was reopened after rollback. - Current working relationship: implement and validate `PDIAP-15836` together with `PDIAP-12284` in the same branch unless direction changes. David identified a possible isolated/minimal fix path, but Jeff prefers combined branch work because consumer testing is required either way. - It is aligned with epic `26Q2 - Updating XFlowSDK to Decouple and Fix ApexKit Dependencies (Split Part 2)`. - If possible, it should use the same consumer-impact feature flag strategy as the broader UIKit-removal rollout. - Current combined-branch planning should keep dismissal sequencing host-agnostic: the SwiftUI host path must prove dismissal completion before delegate callbacks, while the temporary `UIHostingController` fallback should preserve legacy dismiss-completion behavior. - Current validation logs did not show the key failure patterns for the tested run, such as delegate firing before host-disappearance confirmation or repeated host-disappearance confirmation for the same dismissal id. - SampleApp should be used as a guardrail for stale host-mode state by running UIKit-host and SwiftUI-host flows back-to-back without restarting the app. - Expect a long-lived branch: after implementation, maintain the branch until consumer-testing approval. Jeff expects the GraphQL-removal branch to merge first after the REST validation period, then that branch should be merged into the `PDIAP-15836` / `PDIAP-12284` branch. Current estimate is roughly 90-100 days from 2026-05-05 unless Fidelity shortens the review windows. --- ## Communication Notes - Keep the scope framed as lifecycle sequencing in a pure SwiftUI environment, not only as a symptom like multiple modal presentation. - If mentioned externally, keep it separate from `PDIAP-15838`. - The Confluence/root-cause document was updated to reflect that FTTransfer changes are not the primary need anymore. - The primary recommendation is to adjust the dismissal handling/sequencing correctly in the hosting path. - FTTransfer improvements can still be mentioned as a secondary improvement, but not as a required change to reproduce the same visual behavior. - When explaining why code still remains, clarify that the spike identified and documented the root cause, but implementation changes have not yet been published.