--- type: work-item project: fidelity status: planned 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-21 tags: - 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. - Design direction for the Phase 1 Apollo cleanup: prefer replacing `XFlow.Slot` with a native Swift `Slot` model instead of collapsing it to `[String: String]` through the full production path. Keep `[String: String]` only at the boundary where the REST request/DTO is built in the worker or transport layer. - The current implementation state is cleaner on the model side: Apollo-generated production models have now been replaced with native Swift models/enums for the active path, so the next focus should move from model decoupling to remaining Apollo runtime/infrastructure dependencies. - 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`.