feat: update work item PDIAP-15838 with new team members and latest status; add daily log for Apollo removal progress

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.
 
 ---
 

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.

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.