fidelity-ai-workspace/project-knowledge/02-work-items/pdiap-15836.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-15836	Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment	xflowsdk xflowviewmaker ftframeworks	xflow-swiftui-migration consumer-integration	jeff-dewitte	pdiap-14859 pdiap-12284 pdiap-15838	2026-05-11	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.
• 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.
• 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.