REST or GraphQL for a mobile app

Recommendation: REST.

Deciding factor: There is one client and one team that controls both sides. GraphQL's main benefit is letting many different clients, often built by different teams, each request exactly the data shape they need without negotiating backend changes. With a single mobile app and a single frontend team, you don't have that coordination problem. You can shape endpoints to the app's screens directly, and you avoid GraphQL's overhead: schema and resolver design, N+1 query handling, query-cost limiting, more complex caching, and a less familiar security surface. For a startup, that's time better spent on the product.

When I'd choose GraphQL instead: If you expect the API to serve multiple distinct clients soon (for example, mobile, web, a partner integration, and a watch app, each wanting different data shapes), or if the app's screens aggregate data from many related resources and you're already seeing endpoint sprawl or over/under-fetching that hurts performance on slow mobile networks. In that case the flexibility starts paying for its complexity.

A practical note: if you pick REST, keep your responses tidy and consider a few purpose-built "screen" endpoints for heavy views. That handles most of the over-fetching concern without adopting GraphQL.

Recommendation: Use REST.

Deciding factor: You have one mobile app, one frontend team, and control both the client and API, so REST will be simpler to build, debug, cache, secure, document, and operate. GraphQL’s main benefits are less compelling when there is not a large variety of clients or teams needing different shapes of data.

Choose GraphQL instead if: the app has many screens needing highly different nested data shapes, REST would cause constant over-fetching/under-fetching, or you expect multiple clients/teams — for example iOS, Android, web, partners — to consume the same API with different data needs.