Apollo Kotlin: a code-generating GraphQL client for Android and Kotlin Multiplatform

The problem Apollo Kotlin solves for Kotlin apps

Hand-written GraphQL clients in Kotlin tend to converge on the same mess: a string constant holding the query, a hand-written data class mirroring the response, and a parser that silently drifts when the schema changes. Nothing fails at compile time. A renamed field becomes a runtime null, usually in production.

Apollo Kotlin removes that class of bug by generating the Kotlin types from the schema and the operations you write. The README describes it as a strongly-typed, caching GraphQL client for the JVM, Android, and Kotlin multiplatform. The audience is narrow and clear: teams building Android apps or Kotlin Multiplatform apps against a GraphQL endpoint, who are willing to add a Gradle plugin to their build in exchange for type safety from the server schema down to the call site.

The repository topics confirm the same focus: android, graphql-client, kotlin, kotlin-multiplatform, multiplatform. If your client is Swift or TypeScript, this is not the library you want.

How code generation and the cache fit together

The mechanism is a two-stage pipeline. At build time the Apollo Gradle plugin reads a schema and your .graphql operation files, then emits Kotlin classes. At runtime the client executes those generated operations over HTTP and writes the results into a cache.

The README claims two cache implementations: an in-memory cache and a SQLite-backed one. The in-memory cache is per-process and dies with the app; the SQLite variant persists across launches, which is what you want when a screen must render offline. Both are normalised, meaning the client stores entities by identity rather than storing whole response payloads, so two queries touching the same object can share one entry.

That normalisation is also where the design bites. GraphQL responses do not carry a guaranteed identity for every object unless the schema provides one, so the client needs a way to key entities. If your schema has no stable id on a type, the cache either falls back to a looser key or you supply one. The README does not document the fallback rules; you have to read the documentation site for that, and it is the first thing I would check against a real schema.

The README also lists GraphOS support for Persisted Queries and @defer. Persisted queries matter for mobile: the app ships a hash instead of a full query string, which cuts request size. @defer lets a response arrive in parts, which is useful when one field is slow.

Installing Apollo Kotlin and running a first query

The README does not inline installation steps. It points to the official documentation site for a Get Started guide, and to a tutorial for building an Android app with Apollo. So the concrete commands below come from the project's own documentation entry points, and you should treat the version numbers as the ones to confirm on Maven Central before you pin them.

The library is published under the com.apollographql.apollo group on Maven Central, so the plugin is applied in your Gradle build script. A typical setup adds the plugin and declares where the schema lives:

plugins {
  id("com.apollographql.apollo")
}

apollo {
  service("main") {
    packageName.set("com.example.app")
  }
}

With that in place, you drop a .graphql file into the source set the plugin scans. A minimal query looks like a normal GraphQL document:

query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
  }
}

When the build runs, the plugin generates a GetUserQuery class. You execute it through an ApolloClient instance and read typed fields off the result, not a JSON tree. The README does not show the exact client construction snippet, so check the documentation site for the current builder API before copying anything from an older blog post; the project has gone through major versions and the API has moved.

If you are new to GraphQL entirely, the README recommends starting with the Apollo Kotlin Android tutorial rather than the reference docs.

Where Apollo Kotlin is the wrong tool

The largest cost is the build step. Code generation means your CI must have the schema available and the plugin must run before compilation. That is a real dependency: a schema fetched from a running server makes builds network-dependent, and a schema checked into the repository can silently fall behind the deployed one. Neither failure shows up as a compile error, which is the irony of a tool sold on type safety.

Second, the client assumes GraphQL. If your backend is REST or gRPC, there is nothing here for you, and the README makes no attempt to pretend otherwise.

Third, Kotlin Multiplatform support does not mean every feature works identically everywhere. The repository contains a swift-tests directory alongside the Kotlin sources, which tells you the project tests interop with Swift, but the README does not enumerate which cache or networking features are available on each target. If you are targeting a less common platform, verify feature parity before designing around the cache.

Finally, the README's own framing is promotional. It calls itself the industry-leading GraphQL client and cites production use without numbers. That tells you nothing you can verify. Judge the project on the release cadence and the changelog instead.

Alternatives and how their approach differs

The obvious alternative is not another GraphQL client but the absence of one: Retrofit or Ktor with a JSON serializer, posting a query string and parsing into hand-written data classes. That approach has zero build-time coupling and works with any HTTP API, GraphQL or not. The difference is where errors surface. With Retrofit you find out at runtime that a field was renamed; with Apollo Kotlin the generated class stops compiling. You pay for that with a Gradle plugin and a schema artifact.

A second alternative is a GraphQL client that skips code generation and builds queries from Kotlin DSL strings at runtime. That keeps the build simple and avoids schema files, but it gives up compile-time checking of field names and argument types, which is the main thing Apollo Kotlin offers. If your team already has strong schema review and integration tests, that trade may be acceptable.

A third option, if you are already inside the Apollo ecosystem, is Apollo Client for React or iOS. Those are separate libraries for different platforms, not drop-in substitutes; the README lists them as siblings. Choosing Apollo Kotlin only makes sense when the client itself is Kotlin.

Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-09-23. Recent releases are v5.2.0 on 2026-09-16, v5.1.0 on 2026-08-19, and v5.0.1 on 2026-06-25. That cadence suggests the project is being maintained, but the version numbers also carry a warning: the jump from 5.0.1 to 5.1.0 to 5.2.0 within roughly three months means minor releases arrive often, and the README's own claim to prioritise support for the latest GraphQL, Kotlin and Gradle versions implies you will occasionally be pushed to upgrade your toolchain to stay current.

The upgrade cost is concentrated in two places: the generated code, which changes when the plugin changes, and the client API, which has moved between major versions. A CHANGELOG.md sits at the repository root, so the migration notes exist; budget time to read them before bumping a major version.

The licence is MIT. That is permissive: you can use the library in closed-source apps, modify it, and redistribute it, provided the copyright notice and permission notice are preserved. This is a description of the licence text, not legal advice. If your organisation has specific obligations around attribution in an app bundle, have someone check the LICENSE file at the repository root rather than relying on a summary.

Editorial conclusion

Adopt Apollo Kotlin if your app is Kotlin-first, your backend exposes a GraphQL schema, and you want compile-time checking of every operation rather than string-built queries. Skip it if you only need a couple of REST-shaped calls, or if your build cannot run a Gradle code-generation step in CI. Before committing, verify three things: that the schema file your plugin reads matches the deployed server, that the cache normalisation keys fit your data model, and which cache implementation (memory or SQLite) your target platforms support.

Frequently asked questions

Official sources

1. apollographql/apollo-kotlin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases