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.
• Follow-up enum validation indicates at least some Apollo-generated enum types can likely be replaced with native Swift enum Name: String definitions without preserving Apollo EnumType behavior. For the currently checked production callers, Copilot reported no Apollo-specific enum API dependency for XFlow.ContentType, XFlow.ScreenshotFormat, and XFlow.NextTransitionType; current behavior relies on rawValue, equality/switch use, and init?(rawValue:)-style parsing.
• The currently observed fallback behavior is simple and code-local: unknown ContentType values are skipped by converter guards, unknown ScreenshotFormat values fall back to PDF in downstream callers, and unknown NextTransitionType values currently propagate as nil where the target property is optional.
• 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.