The main idea seems to decouple the backend from the frontend. It sounds nice! It implies to prevent waiting for every REST APIs, so that mobile devs can work on their feature quicker or without having to mock the responses.

GraphQL is a very good idea in that direction. Let's explore...

On the backend side, they integrate the Apollo Server library. They can then create resolvers, which are the functions that output data. All of what they make available to query will eventually be formalized in a schema.

On the mobile side, the dev can build its own query using a simple query language that allows the query and the response data to look very similar. See this page for more details about queries.

Apollo even makes available a website to try different queries (a playground of some sort); enter the url you use as an endpoint in your browser. (Looks like GraphQL server libraries each have their own flavours of that playground.) Be careful, you're playing with real data! Once you have a query that makes sense, you can copy that into a .graphql file.

Apollo-iOS comes with a command line tool that let you 1) download the schema (a local copy is required) and 2) generate Swift code based on the schema and the query files.

Once the code is generated, you can create an Apollo client and execute operations against it. The result will come back to you in a Result object with either a failure or a success.

What kind of operations you ask? Either a simple query (getting data), a mutation (modifying data on the backend) or a subscription (to receive live update about specific data)

So now you are free to develop your feature and adjust the operations as you wish.

In the end, the backend still has to front data and make it available through the schema. It lets mobile devs to pick and choose only what they need, but the typical scenario doesn't seem like such a big win.

It does shine better if your view combines data from multiple sources, though (given that they are all available in the schema).