|☑️ Apollo Clients User Survey
|What do you like best about Apollo iOS? What needs to be improved? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.
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 we recommend our Getting Started guide.
The Apollo iOS repo no longer contains an Xcode project, as a result if you are using Carthage or need to build XCFrameworks for use in your development environment you will want to use the apollo-ios-xcframework repo we have created that contains an Xcode project generated with Tuist that can be used for this purpose and is tagged to match the releases of Apollo iOS.
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.
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: 18 hours ago
SelectionSet generated initializers don't compile with
self parameter (#3330): Selection set initializers now use a local property name when the external property name is a Swift reserved word; see PR #257. Thanks to @grantjbutler for raising the issue.
nil if selection set empty (#3326): - The codegen logic to determine whether a selection set is composite or not has been improved to handle the case when
__typename was the only field in the selection set; see PR #261. Thanks to @vincentisambart for raising the issue.