--- type: daily project: fidelity date: 2026-04-15 focus: [xflow-swiftui-migration, ao-discourse] work-items: [pdiap-14859, pdiap-15765] blockers: [] updated: 2026-04-16 tags: - daily - fidelity --- # 2026-04-15 ## Toggle Name Follow-up - Additional historical context from Teams suggests the existing LaunchDarkly flag name `xflow-master-swiftui-enabled` was already shared in the Fid4 LaunchDarkly project as the SwiftUI toggle. - User-provided historical references: Neetu Gupta asked for the SwiftUI toggle name and Jason Mandozzi replied with `xflow-master-swiftui-enabled` plus the LaunchDarkly link; in January 2025, Thomas Payne also asked whether the team was ready to activate that same toggle. - Current interpretation: the team may be able to keep using the same flag name even though the rollout intent is now narrower. In the current rollout, toggling would switch only the final `UIHostingController` wrapping on or off, while SwiftUI remains in use either way. - This historical evidence supports keeping the existing flag name if renaming would add friction, but the semantic mismatch should still be acknowledged when describing the rollout. - Fresh clarification from Jeff on April 15: do not reuse the old SwiftUI LaunchDarkly flag for this rollout. - New required flag name for the rollout document: `xflow-swiftui-container-enabled`. - The rollout document should explicitly note that this new flag is `to be added in the future as part of implementation`. - Jeff plans to ask later how to get the new flag added when implementation time comes. ## PDIAP-15765 Follow-up Drafting Context - David plans to confirm that `PDIAP-15765` was moved from investigation back to In Progress. - Current working interpretation: the `HybridBrokerageAccountOpening` / `JointIdentityCheck` behavior appears to be a different issue from the iOS-only Youth `TeenIdentityCheck` gap. - This separate `HybridBrokerage` path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect. - Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly. - One reason for suspicion is that the validation appears to use `min: 10` and `max: 10`, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story. - Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the `birthDate` key. - Once the payload was changed from `birthDate` to `validations`, the originally reported iOS issue no longer reproduced and the validation loaded correctly. - Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally. - Jeff asked that the message start with: `One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):` - Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well. - Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from `birthDate` to `validations`. - Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only. ## Jeff Context On AO Fallback Handling - Jeff confirmed the minimal iOS fallback change is the right fix for this issue. - He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows. - Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor. - That history explains why `validations` aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling. - Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS. ## PR Drafting Context - The `xflow-for-ios` PR template currently uses sections `## What`, `## Why`, `## How`, `### Changes details`, and `## Missed anything?` with a final checklist. - The April 15 iOS fix PR is a one-line change in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`, adding `birthDate` as a fallback after `validations`. - This PR should be described as a small compatibility bug fix for older AO-style payloads rather than as a broader Android-parity refactor. - David opened the PR for this minimal iOS compatibility fix. ## Standup And Flow Naming Notes - David prefers standups to use one top-level Jira bullet with indented sub-bullets when a single ticket has multiple updates. - In recent standup wording, `Youth flow` should be treated as shorthand for the real flow ID `HybridYouthAccountOpening`. - The relevant page in that flow is `TeenIdentityCheck`. - The separate authenticated flow under discussion remains `HybridBrokerageAccountOpening`, with the relevant page `JointIdentityCheck`.