- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps.
- Established a daily logs index for easy navigation of daily notes.
- Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams.
- Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
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.
The current PicoSDK update also requires re-enabling the FGO and FidFolios flows in SampleApp for validation there; without this update, the Pico endpoint path fails in the sample app.
Jeff confirmed this PicoSDK / SampleApp work should be treated as in scope because Apollo must be removed from the project, including the transitive SampleApp path used through PicoSDK.
Important scope nuance: updating PicoSDK affects SampleApp, not XFlowSDK production runtime itself.
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.
Include the PicoSDK / SampleApp update in the current Apollo-removal PR.
david.delagneau
1ad707373a