--- type: daily project: fidelity date: 2026-04-17 focus: [ao-discourse, consumer-integration, rest-migration] work-items: [pdiap-15765, pdiap-15838] blockers: [] updated: 2026-04-17 tags: - daily - fidelity --- # 2026-04-17 ## Standup Draft Clarification - David clarified that the XFlowViewMaker follow-up work for `PDIAP-15765` is further along than the earlier summary implied. - The XFlowViewMaker PR is already open and has some approvals. - One FTFrameworks code-owner approval is still required before the PR can merge. - After that approval, the remaining work is to run the pipeline and update Fid4 so the XFlow `2.8.48` change propagates through the consumer path. - `PDIAP-15838` remains the next story after the `PDIAP-15765` propagation steps are in a good place. - David's current plan is to ping Tauf for that remaining approval. ## Standup Wording Feedback - Jeff said not to use `fallback` in the standup wording because a broader audience will not understand that term without extra context; prefer plain outcome wording like `Got the PR approved`. - Jeff clarified that when `PDIAP-15765` is waiting on approvals or pipeline movement, the standup should explicitly say David is returning to GraphQL removal work rather than sounding like the day is blocked on waiting. - David updated the standup wording with those changes and sent the final version. ## Learning Session - Release Propagation - David clarified the current release propagation chain for XFlow changes. - XFlowSDK is released from `pr100660-xflow-for-ios` through Jenkins pipeline `xflow-for-ios-publish`, which builds the XCFramework, publishes it to `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`. - XFlowViewMaker lives in `PR100660-ios-frameworks/Adapters/XFlowViewMaker`; after an XFlowSDK release, its podspec must be updated, then `tuist generate -n`, `pod install`, PR review, protected-branch/code-owner approval, merge, and `publish-XFlowViewMaker` publication are required. - The XFlowViewMaker publish pipeline usually auto-detects the next release and commonly auto-increments the minor version. - Fid4 then consumes the new XFlowViewMaker version from `ap010981-ios-flagship-app` by updating the Podfile, running `tuist generate -n` and `pod install --repo-update`, opening a PR, and merging it before the downstream app release process carries the change to users. - This release chain is durable context for understanding why an XFlowSDK fix can be merged and released but still not be visible yet in Fid4. - David clarified that Fid4 consumes XFlow only through XFlowViewMaker, not directly through XFlowSDK. - David also clarified that other frameworks such as `FTAccountOpen` and `FTTransfer` use XFlowViewMaker, and the practical Account Opening path is currently understood to go through `FTAccountOpen`. - Version verification in Fid4 is imperfect because `Podfile.lock` is ignored in the repo; fixed Podfile references and pipeline artifacts can help verify released versions, but podspec-repo edits can still change what gets resolved later. - Tauf was identified as a CI/Jenkins support contact who has helped with pipeline issues in the past. - David clarified that Tauf's full name is `Taufiqur Ashrafy`; he is often referred to informally as `Tauf`. - David also noted that Fidelity Teams may display people in surname-first order, which can make person matching less obvious across tools. - David clarified that the surname-first display in Fidelity Teams is consistent for everyone. - David also clarified that Teams and Mattermost represent different social contexts; outside of Jeff, people seen in Teams are generally not the same people David interacts with through Mattermost. - David corrected current people status: Norman Arauz and Derian Cordoba no longer work with the current All-Win Software / Mattermost / Slack group, and Erik Reynolds previously worked for Fidelity but no longer does. - David clarified an important working-context rule: Jeff is the only person who regularly communicates with Fidelity-side Teams stakeholders, while David works from the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side. ## Mattermost Refresh - Dependency Conflict - After XFlowViewMaker was published, David hit a dependency conflict while trying to update Fid4. - The conflict appears to come from `FTAccountOpen` and `FTTransfer` depending on XFlowViewMaker with constraints that do not yet allow the new version. - David noted that Tauf has handled similar cases before by updating the constraint directly in the podspec repo. - Jeff asked David to message Tauf, ask him to remind David what he does in this case, and then document the process for future reference. - Follow-up Teams evidence from Tauf clarified the practical fix path: - first try `pod install` - if resolution still does not move to the latest XFlowViewMaker version, the change belongs in the podspec repo, not in FTFrameworks - `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their FTFrameworks source podspec files; the effective versioning is handled through the published podspec layer and the `ftAdapter` function - David later clarified the actual fix: in the podspec repo PR, he removed the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs - Tauf approved that podspec-repo PR - After that merge, `pod install --repo-update` worked in Fid4 because the published podspecs no longer constrained the XFlowViewMaker version ## Mattermost Refresh - Release Progress - The remaining XFlowViewMaker code-owner approval was obtained from Tauf, allowing the release process to continue. - The XFlowViewMaker release was published successfully. - David then opened the Fid4 PR with the latest versions and planned to request reviews from Santosh and Tauf. ## Mattermost Refresh - Urgent REST Validation - Jeff redirected work to an urgent consumer report claiming REST calls were failing on iOS when the toggle was enabled. - David clarified that David does not have access to Flagship LaunchDarkly projects; only the sample app LD project is available from David's side. - David tested locally on `main` and reported that REST loaded correctly with the `iOS-XflowRestEnabled` flag enabled. - David also verified that XFlow `2.8.47` already supports that flag and is present in the 4.30 line used for consumer validation. - David later verified on the `release/4.30` branch that the behavior still looked correct there. - Current working hypothesis: the consumer report may reflect a version mismatch or incorrect flag configuration rather than a reproducible iOS REST failure in current local validation. - Adam's `trunk build` reference appears to mean a real-device build platform that can provide downloadable App Store/internal IPAs and a dependency snapshot such as `Podfile.lock`, even though David cannot run those IPAs on simulators. ## Communication Correction - David corrected a drafting mistake: when proposing a message that David will send directly to a Fidelity-side contact, the wording must not imply Jeff is the sender or that the recipient already knows David through Jeff. - For this kind of direct outreach, avoid phrases like `Jeff mentioned...` unless David explicitly wants that framing. - David made a second correction: if Jeff asked for internal documentation or future-process capture, that should stay internal and should not be surfaced in David's external message unless explicitly requested. ## Mattermost Refresh - Dependency Reproduction Caution - Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior. - David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced. - If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone. ## Learning Correction - Build Inspection Sources - David clarified that `iosinstaller` is one of Fidelity's internal apps for inspecting distributed consumer builds. - `iosinstaller` can download App Store and internal builds and also expose the corresponding `Podfile.lock`. - David also clarified a useful app-store debugging path in the Flagship app pipeline: the artifact `appstore/DistributionSummary.plist` records the framework versions installed for that build. - That artifact can be used to confirm which XFlowViewMaker and XFlow versions were actually installed in a specific App Store build.