46 lines
3.4 KiB
Markdown
46 lines
3.4 KiB
Markdown
---
|
|
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.
|
|
- 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.
|