---
type: work-item
project: fidelity
status: in-progress
ticket: PDIAP-15838
title: "Remove Apollo for iOS"
systems: [xflowsdk]
workstreams: [rest-migration]
people: [jeff-dewitte, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
related: [launchdarkly, github-copilot]
updated: 2026-04-20
tags:
  - work-item
  - fidelity
  - rest
  - graphql
---
# PDIAP-15838 - Remove Apollo for iOS

## Status

- In Progress
- Current top priority within this story is back to the GraphQL-removal / LaunchDarkly-toggle cleanup after Adam reported the latest build activating REST correctly
- Sized at `8` points

---

## Context

- This ticket covers the REST migration cleanup on iOS.
- The approved title is `Remove Apollo for iOS`.

---

## Approved Scope

- Remove Apollo from iOS.
- Remove GraphQL-specific networking code.
- Remove related tests and mocks.
- Remove transport feature flags so REST remains.

---

## Current Guidance

- 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.
- Treat the REST-activation investigation as the immediate priority before resuming broader Apollo-removal cleanup.
- 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.
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so the story should shift back to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
- Keep the real-device-only scenario in mind as a useful fallback hypothesis if the issue returns: environment-specific differences such as LaunchDarkly context, timing, or cached toggle state may explain behavior that does not reproduce in the simulator.
- Adam was the reported source of the REST activation problem, and his side validates behavior on real devices.
- Current codebase analysis suggests the main remaining source-level blockers are no longer transport selection but residual Apollo model/runtime coupling: `XFlow.Slot` usage in the page interactor/worker path, `NetworkClient` references still touched by init/session lifecycle, and Apollo/AppSync config surface that may still behave like public API.
- Follow-up analysis suggested `XFlow.Slot` might be the only Apollo-generated production model still used outside the GraphQL-generated folder, but local trial changes surfaced additional Apollo-dependent models/build errors. Treat the `XFlow.Slot` simplification as a promising first step, not as a fully validated statement about the whole codebase.
- The suggested simplification is to remove the current round-trip `stagedValues() -> [String: String] -> XFlow.Slot -> [String: String] -> XFlowUpdateSlotsRequest.slots` and instead pass `[String: String]` straight through to `XFlowUpdateSlotsRequest.slots`, keeping `SlotVariable: Encodable` in the REST model layer for request serialization.
- The next AI follow-up should focus only on the first step and ask GitHub Copilot to corroborate residual Apollo-model dependencies by using `xcodebuild` failures, not just static reference search.
- 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.

---

## Sequencing

- This is the next story to work on before `PDIAP-15836`.