david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
David Delagneau
2026-04-28 07:24:34 -06:00
parent fc634280a4
commit 2892fe8da1
3 changed files with 62 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
project-knowledge/02-work-items/pdiap-15838.md
View File

@@ -6,9 +6,9 @@ ticket: PDIAP-15838
title: "Remove Apollo for iOS" title: "Remove Apollo for iOS"
systems: [xflowsdk] systems: [xflowsdk]
workstreams: [rest-migration] 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] related: [launchdarkly, github-copilot]
updated: 2026-04-21 updated: 2026-04-27
tags: tags:
- work-item - work-item
- fidelity - 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`. - 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 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. - 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.
--- ---

14
project-knowledge/03-context/workstreams/consumer-integration.md
View File

@@ -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 - `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 - `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version
- downstream consumer release then determines when the change reaches the App Store build - 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 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. - 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. - 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 ## Investigation Rules
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream. - Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.

41
project-knowledge/06-daily/2026-04-27.md Normal file
View File

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