From 2892fe8da100bfe40a6516cf8730088dbfd1ee6c Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Tue, 28 Apr 2026 07:24:34 -0600 Subject: [PATCH] feat: update work item PDIAP-15838 with new team members and latest status; add daily log for Apollo removal progress --- .../02-work-items/pdiap-15838.md | 10 ++++- .../workstreams/consumer-integration.md | 14 ++++++- project-knowledge/06-daily/2026-04-27.md | 41 +++++++++++++++++++ 3 files changed, 62 insertions(+), 3 deletions(-) create mode 100644 project-knowledge/06-daily/2026-04-27.md diff --git a/project-knowledge/02-work-items/pdiap-15838.md b/project-knowledge/02-work-items/pdiap-15838.md index 2ee5745..6e1370e 100644 --- a/project-knowledge/02-work-items/pdiap-15838.md +++ b/project-knowledge/02-work-items/pdiap-15838.md @@ -6,9 +6,9 @@ ticket: PDIAP-15838 title: "Remove Apollo for iOS" systems: [xflowsdk] workstreams: [rest-migration] -people: [jeff-dewitte, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas] +people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas] related: [launchdarkly, github-copilot] -updated: 2026-04-21 +updated: 2026-04-27 tags: - work-item - fidelity @@ -69,6 +69,12 @@ tags: - Latest follow-up says the Apollo package/build cleanup has also now been applied: direct Apollo dependency references were removed from package/build ownership surfaces, leaving the main remaining follow-up as Fid4 validation plus any later decision on whether to deprecate/remove the temporary AppSync compatibility getters in `XFlowInitManagerConfig.swift`. - Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task. - Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared. +- Latest local follow-up suggests `SampleApp` depends on `PicoSDK`, and that transitive dependency may still be the practical reason Apollo remains in the pod graph. Newer `PicoSDK` versions no longer depend on Apollo, but the upgrade path does involve real breaking changes. The current investigation is to determine how `SampleApp` can absorb those changes by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it. +- Merge sequencing is now explicitly gated by backend production readiness: Bruce reinforced that the GraphQL/Apollo removal PR should not merge until the backend is in production because GraphQL fallback is still needed before then. +- Bruce clarified that the current SDK-side updates are not REST behavior changes; the functional REST/backend fix is on the Flagship/Fid4 side, while SDK updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface. +- Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue. +- Jeff clarified the validation ask: inspect whether Fid4 has simulator-versus-physical-device or generated-build differences in build settings/schemes/configurations, including any optimized-build-size or release-style settings that could explain behavior seen in generated builds but not when running locally. +- Current likely Fid4 build differences to report: Trunk/generated builds use the `Release` configuration while local runs are usually `Debug`; optimization settings such as `SWIFT_OPTIMIZATION_LEVEL` and `GCC_OPTIMIZATION_LEVEL` can differ; Jenkins uses a generated `build-overrides` xcconfig that local builds do not use and may affect values such as secrets; and CocoaPods dependency resolution can vary depending on the local specs repo state. --- diff --git a/project-knowledge/03-context/workstreams/consumer-integration.md b/project-knowledge/03-context/workstreams/consumer-integration.md index 15e09b0..fa625ef 100644 --- a/project-knowledge/03-context/workstreams/consumer-integration.md +++ b/project-knowledge/03-context/workstreams/consumer-integration.md @@ -37,7 +37,8 @@ Capture the durable release and validation path between XFlow changes and real c - `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release - `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version - downstream consumer release then determines when the change reaches the App Store build -- A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated. +- A code fix in XFlowSDK is not ready for **published** Fid4 validation until that full dependency chain has propagated. +- However, for **local validation**, developers can bypass the publication chain by modifying the `fid4` Podfile to use local path references for `XFlowSDK` and `XFlowViewMaker`. - In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps. - In the current integration model, Fid4 consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly. - For current-state reasoning and communication, treat XFlowViewMaker as a required part of the Fid4 propagation path, not as an optional or "usually" present layer. @@ -73,6 +74,17 @@ Capture the durable release and validation path between XFlow changes and real c --- +## Local Validation Path + +- Testing a change locally in `fid4` does **not** require publishing a new version of `XFlowSDK` or `XFlowViewMaker`. +- The local validation path involves: + - Modifying the `fid4` (`ap010981-ios-flagship-app`) Podfile. + - Adding local path references pointing to the local directories of `XFlowSDK` y `XFlowViewMaker` instead of versioned pods. + - Running `pod install` to link the local workspaces. +- This allows for rapid iteration and testing of XFlow changes directly within the flagship app context before committing to the full release propagation chain. + +--- + ## Investigation Rules - Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream. diff --git a/project-knowledge/06-daily/2026-04-27.md b/project-knowledge/06-daily/2026-04-27.md new file mode 100644 index 0000000..04144da --- /dev/null +++ b/project-knowledge/06-daily/2026-04-27.md @@ -0,0 +1,41 @@ +--- +type: daily +project: fidelity +date: 2026-04-27 +status: active +focus: [rest-migration] +work-items: [pdiap-15838] +blockers: [] +tags: + - daily + - fidelity +updated: 2026-04-27 +--- + +# 2026-04-27 + +## Focus + +- Continue Apollo-removal cleanup and validation follow-up for `PDIAP-15838`. + +--- + +## Findings + +- Jeff asked that if a PR is opened today, it should not be merged yet because the REST backend is still waiting to be deployed to production. +- Bruce reinforced the same sequencing: do not merge the GraphQL/Apollo removal work until the backend is in production because GraphQL fallback is still needed before then. +- Bruce said there are no REST changes to the SDK side for the current backend-readiness work; the functional fix is on the Flagship/Fid4 side, while the SDK-side updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface. +- Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android, likely to understand whether build configuration could affect validation or runtime behavior in production-style builds. +- Jeff clarified that the immediate ask is not to find a literal `minification` setting, but to inspect whether Fid4 is built differently for simulator versus physical-device/generated builds, including any build-size, optimization, or release-style settings that could match what Bruce described. +- David identified the most likely Fid4 build differences to report back: Trunk/generated builds compile with the `Release` configuration while local runs are usually `Debug`; optimization settings such as `SWIFT_OPTIMIZATION_LEVEL` and `GCC_OPTIMIZATION_LEVEL` differ; Jenkins uses a generated `build-overrides` xcconfig that local builds do not use and may alter values such as secrets; and dependency resolution can vary depending on the local CocoaPods specs repo state. +- David reviewed what may still be pending and noticed that `SampleApp` depends on `PicoSDK`, which still brings Apollo transitively in the current setup. +- The likely recommendation is to move `PicoSDK` to a newer version because newer releases no longer depend on Apollo. +- That upgrade path does include breaking changes. The current follow-up is to figure out how to handle them in `SampleApp` by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it. + +--- + +## Next Steps + +- Hold any PR merge until the REST backend is deployed to production. +- Check Fid4 build settings/schemes/configurations for simulator-versus-device differences, especially release/generated-build optimization or size-related settings that could explain behavior seen in generated builds but not local runs. +- Investigate the `PicoSDK` upgrade path in `SampleApp`, using the current `Fid4` integration for the two affected flows as the comparison point for handling the breaking changes safely.