It allows you to execute queries and mutations against a GraphQL server, and returns results as query-specific Swift types. This means you don’t have to deal with parsing JSON, or passing around dictionaries and making clients cast values to the right type manually. You also don't have to write model types yourself, because these are generated from the GraphQL definitions your UI uses.
As the generated types are query-specific, you're only able to access data you actually specify as part of a query. If you don't ask for a field, you won't be able to access the corresponding property. In effect, this means you can now rely on the Swift type checker to make sure errors in data access show up at compile time. With our Xcode integration, you can conveniently work with your UI code and corresponding GraphQL definitions side by side, and it will even validate your query documents, and show errors inline.
Apollo iOS does more than simply run your queries against a GraphQL server: It normalizes query results to construct a client-side cache of your data, which is kept up to date as further queries and mutations are run. This means your UI is always internally consistent, and can be kept fully up-to-date with the state on the server with the minimum number of queries required.
This combination of models with value semantics, one way data flow, and automatic consistency management, leads to a very powerful and elegant programming model that allows you to eliminate common glue code and greatly simplifies app development.
If you are new to Apollo iOS there are two ways to get started:
The roadmap is a high-level document that describes the next major steps or milestones for this project. We are always open to feature requests, and contributions from the community.
This project is being developed using Xcode 12.5 and Swift 5.4.
If you open
Apollo.xcodeproj, you should be able to run the tests of the Apollo, ApolloSQLite, and ApolloWebSocket frameworks on your Mac or an iOS Simulator.
NOTE: Due to a change in behavior in Xcode 11's git integration, if you check this repo out using Xcode, please close the window Xcode automatically opens using the Swift Package manager structure, and open the
Some of the tests run against a simple GraphQL server serving the Star Wars example schema (see installation instructions there).
If you'd like to contribute, please refer to the Apollo Contributor Guide.
Apollo builds open-source software and a graph platform to unify GraphQL across your apps and services. We help you ship faster with:
Check out the Odyssey learning platform, the perfect place to start your GraphQL journey with videos and interactive code challenges. Join the Apollo Community to interact with and get technical help from the GraphQL community.
|Last commit: 14 hours ago|
returnResultAsyncIfNeededis defined as optional but if not included would cause debug builds to crash with an
assertionFailurein the case of a
Result. #2005 - Thank you to Richard Topchii for raising this issue!
CachePolicy.defaultis now a stored property: It is now easier to configure a different default value for the
CachePolicyproperty on any
ApolloClientinstance instead of having to override it in a subclass. #1998 - Thank you to Tiziano Coroneo for the contribution!
public: The access modifier of this function on
GraphQLFieldhas changed from
public. It is not recommended to rely on internal behaviour of the cache, and this is subject to change in future major versions. #2014 - Thank you to Peter Potrebic for the discussion!
ApolloSchemaDownloader: Introspection-based schema downloads can now be queried using a GET request. #2010 - Thank you to Mike Pitre for the contribution!
__typenamefields to inline fragments in operations to match the output from the
client:pushCLI command which used for operation safelisting. This should not affect the behaviour of your operations. #2028.
insertMany. #2015 - Thank you to Hesham Salman for the contribution.