--- type: daily project: fidelity date: 2026-04-14 focus: [xflow-swiftui-migration, ao-discourse, xflow-debugging] work-items: [pdiap-14859, pdiap-15765, pdiap-15838] blockers: [] updated: 2026-04-16 tags: - daily - fidelity --- # 2026-04-14 ## Previous Workday Refresh - `PDIAP-14859` rollout draft remained in revision on April 13 rather than being finalized; the work was limited to the specific draft changes requested in review, not a broad rewrite. - The rollout document should rename the proposed flag from `xflow-master-swiftui-enabled` to `xflow-swiftui-enabled`. - The first rollout phase should explicitly mention contacting consumers ahead of time and asking them to validate their flows in `XQ1`. - The rollout document should remove overly technical wording and avoid implying there are no consumer-side changes without qualification. - Current spike clarification: `FTTransfer` changes are no longer considered strictly required after applying the SwiftUI dismissal behavior correctly, but risky entry points still need explicit rollout coverage. ## AO / Discourse Findings - The AO reply about `TeenIdentityCheck` was approved and sent after clarifying that `CheckIdentity` was already correct and that the `TeenIdentityCheck` issue was the missing `validations` root and missing `eighteenOrAbove` inside `validation-rules`. - Later validation showed two distinct authenticated scenarios rather than one uniform cross-platform issue. - A `HybridBrokerage` scenario reproduces on both iOS and Android. - A Youth flow (`Open an account` -> `Save & Invest for a child` -> `Fidelity Youth Account`) fails on iOS while working on Android. - Current evidence suggests Android is more flexible when decoding rule variations, while iOS is stricter about the expected `validation-rules` structure in the Youth-flow scenario. - The iOS-only Youth-flow discrepancy is the scenario currently aligned with the story-level client fix. - The cross-platform `HybridBrokerage` scenario should stay scoped separately until it is clear whether it is a service/config issue or a distinct bug. ## Current Direction - `PDIAP-14859` remains focused on incorporating rollout-document feedback and publishing a consumer-facing plan. - `PDIAP-15838` remains the next implementation story after the rollout-document work is in a good state. ## New Investigation Note - For the Murali group discussion, there appears to be usage of `ApexBridgingAddressComponent` through references in `XFlowPageApexItem`. - If that usage is active, the dependency comes from `ApexKitV3`, which was expected to retain support after the earlier ApexKit removal. - Current guidance from that discussion is to migrate toward `FDS` or `ApexKitSwiftUI`, but the exact replacement for `ApexBridgingAddressComponent` is still unclear and needs investigation and validation. - Narrower wording for the current status: there are visible references at a glance, but it is not yet confirmed whether they are active or dead code; the next step is to validate with a run. ## Fresh Mattermost Sync - Confirmed with breakpoints that `ApexBridgedAddressComponent` is not used when loading an address component; the observed path goes through `ApexGoogleAddressViewModel`. - A follow-up review raised that the old component may still be used to load rules and appears in `XFloaValueChanger`, so it should not be treated as dead code without deeper verification. - Current direction for that investigation is to be exhaustive and avoid assumptions before describing the old bridged path as unused. - Clarification from the same thread: the remaining `ApexKitV3` reference does not cause build issues because `ApexKitSwiftUI` still depends on `ApexKitV3`. - `PDIAP-14859` rollout-document follow-up: Jeff asked whether the FTTransfer section needed updating, and David confirmed the document had already been revised to clarify that root cause. - Latest clarification in the Murali thread: `ApexBridgedAddressComponent` belonged to the old UIKit rule-handling flow. In the current implementation, rules are described as being handled through the SwiftUI path, parsed from the payload and applied through the `XFlowViewApadater` / `ViewModelAdapter` layer using `ApexGoogleAddressViewModel`. - Clarification for the retro/ownership discussion: the earlier FTTransfer-side explanation was not fully wrong, but it was incomplete. The SwiftUI state behavior was a real symptom/effect on the consumer side; the deeper root cause was the dismissal flow handling that had not been covered correctly. The main gap was concluding consumer ownership before isolating that underlying dismissal root cause. - Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation. - Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed. - Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently. - Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims. ## ApexKitV3 / Swift 6 Follow-up - Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced. - Breakpoint and import-removal follow-up showed that removing `import ApexKitV3` across XFlow causes `23` compilation issues. - Replacing those imports with `ApexKitSwiftUI` still leaves `13` build errors. - Current high-confidence understanding is that XFlow still has meaningful dependency impact from `ApexKitV3`, and this is not just a trivial dead-code cleanup. - Swift 6 support is not yet implemented; related work is planned under a `26Q3` backlog epic. - New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by `4:30 PM`. - The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing. - Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments. - Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder. - Additional analysis context for the ApexKitV3 investigation: the Swift version change was reverted back to Swift 5, and the Pods were updated to the latest versions including `ApexKitSwiftUI 1.27.14`. The current question is whether the ApexKitV3-removal impact remains the same under that updated dependency baseline. - Document-review guidance for the ApexKitV3 impact write-up: it should not read as if code changes have already been made, should stay understandable for a non-technical reader, and should avoid overcommitting on production impact where SwiftUI-vs-legacy-path usage is still being verified. - Additional document-review guidance: if the write-up already recommends consumer testing, it should not hedge with wording like `if the change extends beyond small cleanup`. The risk section should stay internally consistent and reflect the current conclusion directly. ## Late-Day Outcome - The ApexKitV3 impact write-up was revised with the requested wording changes, including using `Impacted Flows` and making consumer validation a direct recommendation rather than a conditional one. - Jeff approved the ApexKitV3 write-up after those edits, and David published it and sent the Confluence link to Quy with a concise summary of the effort and risk. - End-of-day direction for `PDIAP-14859`: the rollout document was approved as good enough, but it was not published on April 14. The next step is to publish it on the next workday, then comment the spike with `Spike Results:` links and the follow-up story link. - The UIKit-removal follow-up story should be linked as a blocker for the reopened UIKit-removal work after the spike is closed out. - End-of-day direction for `PDIAP-15765`: move the story back to In Progress on the next workday and focus on the authenticated iOS-only Youth `TeenIdentityCheck` gap so iOS handles the service response the same way as Android. - The separate `HybridBrokerage` scenario remains distinct from the iOS-only Youth-flow issue and may need its own follow-up ticket if the service-side problem still stands after the client-side story is resumed.