Why GitHub’s mobile apps run on GraphQL
GitHub’s iOS and Android clients are powered by GraphQL, and the shift has removed much of the overhead that normally comes with mobile networking. The schema-driven API lets the mobile team define exactly what data each screen needs, with no endpoint sprawl and no over-fetching. Using Apollo’s open-source clients on both platforms, the team avoided building and maintaining custom networking layers, freeing engineers to spend time on product work rather than on response modeling and API stability.
A different mental model: types, not endpoints
GraphQL requires a mindset change for developers accustomed to REST. In a REST world, you reason in terms of HTTP verbs and endpoints: GET and POST requests, each returning a predefined shape. GraphQL replaces that with a schema — a machine-readable definition of types, queries, and mutations. Clients hold a copy of that schema, which must be manually refreshed when the backend changes.
Once you’re in GraphQL territory, the request language is reduced to two operation kinds. A query retrieves data (the equivalent of GET), and a mutation modifies server state, covering what would otherwise be POST, PUT, DELETE, or PATCH. Because the client specifies the response shape, engineers can write queries tailored to a particular view instead of stitching together responses from multiple endpoints.
In practice, this model is simpler to work with. There are no endpoints to track and no separate response structures to remember — just the schema’s available types, mutations, and their inputs.
Code generation removes a whole class of work
A major advantage of GraphQL on mobile is static code generation for network models. In a typical REST setup, developers manually define network models and handle encoding/decoding strategies. Even with modern conveniences like iOS’s Codable and Kotlin’s built-in serialization, you still have to keep model keys in sync with the server, and a structural change to a response is often a breaking change for older clients.
With Apollo’s tooling, network responses are statically typed, so clients know exactly what data they’re receiving. The generated models stay current with backend changes each time the schema is refreshed. Since GraphQL APIs support field-level deprecation, backend updates don’t silently break mobile consumers — deprecated fields are communicated in advance rather than abruptly removed.
Fragments keep queries and models consistent
Fragments are reusable pieces of GraphQL, and GitHub’s mobile team relies on them heavily. They keep data and API behavior consistent across models while reducing the total number of generated model files. A common example is the actorFields fragment:
An Actor in the GitHub API represents any object that can take actions — typically a user. The fragment is re-used across timeline events and many other parts of the app, so each query that references it stays short and the generated models stay uniform.
Fragments are also composable. For example, requesting a User could pull in actor fields along with info about their followers and the people they follow:
That composability reduces repetition across queries and, more importantly, limits the number of models generated. The response object for SomeQuery reuses two already-existing models. The same fragments can then be used to assemble smaller, type-specific view models into larger ones.
Where iOS and Android diverge
The Apollo implementations on iOS and Android aren’t identical. Both platforms have introduced their own reactive primitives, and while Apollo’s Kotlin support is still young, it’s already stable enough for production use. Full combined support between the two is listed as a long-term goal on the Apollo roadmap.
One notable difference is that some fragments — particularly those performing on interfaces — can only be generated on iOS. This rarely becomes a blocker, but it does require more explicit adherence to the types Apollo recognizes.
Despite these differences, the generated code from Apollo is similar enough across languages that it can be used in much the same way on both platforms. The Apollo team is also working to align and reduce differences across all Apollo Client projects, web and mobile alike.
The net effect
GraphQL plus Apollo’s tooling has let the GitHub mobile team operate efficiently. It abstracts away many traditional mobile concerns — network modeling, response maintenance, and client-side API stability. Every part of every network request becomes useful, and the team no longer has to manually maintain network responses as the backend evolves.
