feat: transition PDIAP-15838 to active status and update Apollo removal strategy to include production-gated merge requirements and PicoSDK dependency cleanup.

project-knowledge/02-work-items/pdiap-15838.md

@@ -1,14 +1,14 @@
 ---
 type: work-item
 project: fidelity
-status: planned
+status: active
 ticket: PDIAP-15838
 title: "Remove Apollo for iOS"
 systems: [xflowsdk]
 workstreams: [rest-migration]
 people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
 related: [launchdarkly, github-copilot]
-updated: 2026-04-27
+updated: 2026-04-28
 tags:
   - work-item
   - fidelity
@@ -19,8 +19,8 @@ tags:
 
 ## Status
 
-- Planned for next sprint
-- Not the current sprint's active implementation story
+- Active Apollo-removal cleanup and validation
+- PR merge should wait until the REST backend is deployed to production because GraphQL fallback is still needed before then
 - Sized at `8` points
 
 ---
@@ -46,7 +46,8 @@ tags:
 - Do not frame this ticket as directly tied to the UIKit-removal spike.
 - Do not imply it is dependent on or part of dismissal-sequencing work.
 - Keep the migration framing explicit: REST remains behind a feature flag until otherwise confirmed, and GraphQL fallback context still matters when describing the overall migration.
-- Keep the REST-activation investigation context as useful background, but do not present this story as current-sprint active implementation work if it is assigned to the next sprint.
+- Keep the REST-activation investigation context as useful background, but focus current updates on Apollo-removal cleanup, validation, and merge sequencing.
+- For standups and concise status updates, center the story on Apollo-removal progress and the `PicoSDK` transitive dependency path; omit extra exploratory asks unless they directly affect the story outcome or create a blocker.
 - Jeff confirmed this investigation should stay ahead of Adam's separate service-side flow report for now and asked for faster progress.
 - Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side; remaining uncertainty is around production-side context interpretation, timing/caching, or downstream transport gating.
 - Use the current support path while direct Flagship LaunchDarkly access is missing: monitor the Tauf thread, follow the outreach path to Jeffrey O'Leary, package the scenario for GitHub Copilot with build settings and tool details, and ask Aylwing for a quick perspective if available.
@@ -70,6 +71,7 @@ tags:
 - 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.
+- Jeff later confirmed that this `PicoSDK` / `SampleApp` cleanup is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, including the transitive sample-app path. Keep the nuance explicit that this update affects `SampleApp`, not the `XFlowSDK` production runtime directly.
 - 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.
@@ -80,4 +82,4 @@ tags:
 
 ## Sequencing
 
-- This story is assigned to the next sprint and remains sequenced before `PDIAP-15836`.
+- This story remains sequenced before `PDIAP-15836`.