Apollo iOS Documentation

repository·main·Indexed 26 days ago

https://github.com/apollographql/apollo-ios

A professional GraphQL client for Swift supporting iOS, macOS, watchOS, tvOS, and visionOS. Features include intelligent in-memory or SQLite caching, robust code generation for GraphQL models, and intuitive APIs. The 1.0 codegen introduces immutable response objects, GraphQLNullable for precise nullability handling, and support for multi-module projects via SPM and CocoaPods.

Tokens
9.2K
Snippets
15
Records
47
Agent score
88%

What's inside Apollo iOS

  1. Understand the Apollo iOS Codegen design goals

    main

    The new Apollo iOS Codegen is designed to address limitations in previous versions by focusing on the following key areas:

    • Swift-native Tooling: Moving away from TypeScript and NPM dependencies to a Swift-based implementation, making it easier for iOS engineers to use and for the community to contribute.
    • Performance & Memory: Using lightweight structs that store a single pointer to a data dictionary. This minimizes memory overhead and avoids the data duplication associated with mapping fields to stored properties.
    • Reduced Complexity: Aiming for smaller generated code size and improved readability for developers.
    • Compilation Speed: Minimizing build time impact by providing explicit types where possible to aid type inference.
    • Ease of Use: Providing strict type safety, nullability handling, and intuitive access to merged fields and fragments to maximize the utility of generated objects without needing custom adapters/view models.
  2. Planned feature: Caching overhaul for version 3.0

    main

    A major overhaul of the caching mechanisms is planned for the 3.0 release. Key initiatives include:

    • Improved pagination support (caching and updating paginated lists).
    • Result model improvements.
    • Reduced over-normalization (only separating results into individual records when an identifier is present).
    • Robust cache eviction and dangling reference collection.
    • Cache metadata support (e.g., for TTL and time-based invalidation).
    • Ability to query or sort cached data by field values.
  3. Understand the role of ApolloAPI

    main

    The ApolloAPI library contains the internal models shared between the Apollo client and the models generated by ApolloCodegenLib.

    Important Usage Note: For most use cases, you should not need to import ApolloAPI directly into your code. The models generated by the Apollo code generator already import ApolloAPI and expose the necessary functionality. You can typically use your generated models without importing the full Apollo client.

  4. Understand key changes in Apollo iOS 1.0 Codegen

    main

    The Apollo iOS 1.0 code generation introduces several architectural changes designed to reduce generated code size and improve readability. Key improvements include:

    • Immutable Response Objects: Generated response models are now immutable. Manual cache mutations via response objects are deprecated; instead, use mutable fields on generated Schema Types (planned for 1.0).
    • Generated Schema Types: New types representing the GraphQL schema itself. These provide metadata for the Apollo Client and will support local cache mutations.
    • Automatic Fragment Merging: Fragment fields are now always merged into the parent SelectionSet, simplifying data consumption.
    • Improved Nullability: Replaces double optionals (??) with a dedicated GraphQLNullable enum to clearly distinguish between GraphQL null and Swift nil.
    • Multi-Module Support: Support for generating code for projects using SPM or CocoaPods, with options for single-target or modular distribution.
    • Optimized Type Cases: Type cases now only select additional fields specific to the matching __typename, making execution more efficient and code more compact.
  5. Planned feature: Codegen of operations without response models

    main
    A planned feature (API design in progress) will allow generating models that expose only the minimal data necessary for networking and caching. Instead of generated response models, data would be exposed as a simple JSONObject (i.e., [String: AnyHashable]). This is intended for projects with custom data models or strict binary size constraints.
  6. Compose multiple types using nested fragments

    main

    You can configure your generated response objects to provide data in a specific shape by explicitly copying a referenced fragment into a nested field on a TypeCase. This allows you to create composed types (e.g., a type that is both Pet and WarmBlooded) even if the selections are redundant in the GraphQL query. This ensures your generated models provide fields in the exact way you want to consume them in your application.

    query {
      allAnimals {
        species
        ... on Pet {
          ...PetDetails
          ... on WarmBlooded {
            ...WarmBloodedDetails
          }
        }
        ...WarmBloodedDetails
      }
    }
    
    fragment PetDetails on Pet {
     humanName
     favoriteToy
    }
    
    fragment WarmBloodedDetails on WarmBlooded {
      bodyTemperature
    }