fidelity-ai-workspace/project-knowledge/02-work-items/pdiap-15838.md

type, project, status, ticket, title, systems, workstreams, people, related, updated, tags

type	project	status	ticket	title	systems	workstreams	people	related	updated	tags
work-item	fidelity	planned	PDIAP-15838	Remove Apollo for iOS	xflowsdk	rest-migration	jeff-dewitte adam-abdelhadi tauf jeffrey-oleary aylwing-olivas	launchdarkly github-copilot	2026-04-21	work-item fidelity rest graphql

PDIAP-15838 - Remove Apollo for iOS

Status

• Planned for next sprint
• Not the current sprint's active implementation story
• 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.
• 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.
• 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.
• Adam later reported that the latest build is activating REST correctly, so the story context returned 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 story is assigned to the next sprint and remains sequenced before PDIAP-15836.