1.0.0 Alpha 5

This is the fifth Alpha Release of Apollo iOS 1.0. This first major version will include a new code generation engine, better generated models, and many syntax and performance improvements across the entire library. The primary goal of Apollo iOS 1.0 is to stabilize the API of the model layer and provide a foundation for future feature additions and evolution of the library.

• Test Mocks are now supported!
  • Test mocks can be generated to make it much easier to create mocks of your generated selection sets for unit testing.
  • This long requested feature can be enabled in your code generation config with the option config.output.testMocks.
  • Once you've generated test mocks, import the new ApolloTestSupport target (as well as your generated mocks) in your unit tests to start.
  • More documentation for test mocks will be coming soon. In the mean time, here is some example usage:

let mockDog = Mock<Dog>()
mock.species = "Canine"
mock.height = Mock<Height>(feet: 3, inches: 6)

// To mock an object in a generated operation:
let generatedDogMock: AnimalQuery.Data.Animal = AnimalQuery.Data.Animal.mock(from: mockDog)

// To mock an entire query:
let queryMock = Mock<Query>()
queryMock.animals = [mockDog]
let generatedSelectionSetMock: AnimalQuery.Data = AnimalQuery.Data.mock(from: queryMock)

• GraphQLNullable and GraphQLEnum from the ApolloAPI target are now exported by your generated operations. This prevents you from having to import ApolloAPI everywhere that you are consuming your generated models.
• CacheKeyProvider now supports grouping multiple types that share key uniqueness.
• Lots of performance improvements
  • Using StaticString instead of String in generated files.
  • Added @inlinable to many ApolloAPI functions consumed by generated code.
  • And more!

1.0.0 Alpha 4

This is the fourth Alpha Release of Apollo iOS 1.0. This first major version will include a new code generation engine, better generated models, and many syntax and performance improvements across the entire library. The primary goal of Apollo iOS 1.0 is to stabilize the API of the model layer and provide a foundation for future feature additions and evolution of the library.

• Client Controlled Nullability (CCN) is now supported!
  • CCN is an experimental new feature addition to GraphQL. This feature allows you to override the optionality of fields from a schema in your client operations. CCN can help you create cleaner generated models that require less optional unwrapping.
  • You can read more about CCN here.
  • Because CCN is an experimental feature, the API is subject to change before its final release.
  • Apollo iOS 1.0.0 is the first client to provide support for this new functionality! Huge thanks to @twof!
• Fixed - Names of generated objects are now correctly uppercased.
• Fixed - Names of inline fragments with inclusion conditions were sometimes generated incorrectly.
• Fixed - __typename field is now selected by executor on all entities automatically.

1.0.0 Alpha 3

This is the third Alpha Release of Apollo iOS 1.0. This first major version will include a new code generation engine, better generated models, and many syntax and performance improvements across the entire library. The primary goal of Apollo iOS 1.0 is to stabilize the API of the model layer and provide a foundation for future feature additions and evolution of the library.

• Include/Skip Directives are now supported!
  • Adding @include/@skip directives to fields, inline fragments, or fragment spreads will now generate code that respects the optionality of these conditionally included selections.
• Changed - Generated TypeCase renamed to InlineFragment These are now used for both type cases and inline fragments that are conditionally included using @include/@skip directives.
• Custom Scalars are now supported!
  • Template Files will be generated for custom scalars. The template files typealias each custom scalar to a String by default. These generated files can be edited to provide custom functionality for advanced custom scalars. Custom scalar template files that have been edited will not be overwritten on later code generation executions.
• Improved multi-module support
  • Including your generated code using package managers other than SPM can be done using the .other option for moduleType in your code generation configuration.
• Nil Coalescing Operator added to GraphQLNullable
  • This allows for optional variables to easily be used with GraphQLNullable parameters and a default value

var myVar: GraphQLNullable<String>
let optionalString: String?

// Before
myVar = optionalString.map { .some($0) } ?? .none

// After
myVar = optionalString ?? .none

• Fixed - fragments not accessible on generated SelectionSets.
• Fixed - __typename is now added to all operation and fragment definitions.
• Fixed - Missing Generated Interface Types
  • Interface types that were only referenced as an implemented interface of a referenced concrete type were not being generated previously.

Version 0.51.2

• Fixed - APQ Retrying Failing in 0.51.1: Fixes a bug introduced in the last version that broke APQs. #2206 - Thanks to Kyle Browning for bringing this to our attention.

Version 0.51.1

• Expose request body creation to better support custom interceptors: Enable lazy access to the request body creation for leverage in custom built interceptors, since JSONRequest.toURLRequest() encapsulates the creation. This enables the GraphQLMap to be accessed without re-creating the body. #2184 - Thanks to Rick Fast for the contribution.

Version 0.51.0

• Allow periods in arguments to be ignored when parsing cacheKeys: If your query arguments include periods they will no longer cause broken cache keys. This means the cached data for those queries can be correctly found and returned. The caveat with this change though is that if you use a persisted cache, after the upgrade you could see cache misses and the data would be refetched. #2057 - Thanks to Hesham Salman for the contribution.
• Fixed - Sendable class JavaScriptError cannot inherit from another class other than NSObject: Xcode 13.3 introduced some additional requirements for Error types and JavaScriptError did not conform causing compile errors in ApolloCodegenLib. This change disables Sendable type checking for JavaScriptError while maintaining type-safety across concurrency boundaries. #2147 - Thank you to Tiziano Coroneo for the contribution.
• Fixed - Watcher using a policy that shouldn't hit the network, can still hit the network: If the cache policy given to the watch(query:cachePolicy:) method of ApolloClient was .returnCacheDataDontFetch it could still trigger a remote fetch of the query. - Thank you to Peter Potrebic for raising the issue.
• BREAKING CHANGE - graphql-ws Protocol Support: We've added official support for the graphql-ws library and its graphql-transport-ws protocol. This is a breaking change because the WebSocket initializers now require you to specify which protocol to use.

1.0.0 Alpha 2

This is the second Alpha Release of Apollo iOS 1.0. This first major version will include a new code generation engine, better generated models, and many syntax and performance improvements across the entire library. The primary goal of Apollo iOS 1.0 is to stabilize the API of the model layer and provide a foundation for future feature additions and evolution of the library.

• Operation Variables and Field Arguments are now supported!
• Fixed - Capitalized field names generate code that doesn't compile #2167

1.0.0 Alpha 1

This is the first Alpha Release of Apollo iOS 1.0. This first major version will include a new code generation engine, better generated models, and many syntax and performance improvements across the entire library. The primary goal of Apollo iOS 1.0 is to stabilize the API of the model layer and provide a foundation for future feature additions and evolution of the library.

What’s New

• The size of generated code has been reduced dramatically. In the most complex operations, the generated code can be up to 90% smaller than in the previous version.
• Generated response objects are more powerful and easier to consume.
  • The response objects now intelligently merge fields from not only their parents, but also other matching sibling fragments.

query AnimalQuery {
  allAnimals {
    species
    ... on Pet {
      name
    }
    ... on Cat {
      furColor
    }
}

In the past, the AsCat model would have fields for species, and furColor, but to access the name field, you would need to keep a reference to the AllAnimal object and call AsPet.name. This means that you couldn’t just pass the AsCat object to a UI component.

In 1.0, because we know that Cat implements the Pet interface, the name field is merged into the Cat object.

Any property that should exist based on the type of the object will be accessible. This makes consuming our generated response objects in your applications much easier. This should greatly reduce the need for view models to wrap our generated response objects.

• The code generation engine is now written in native Swift! This makes it easier for Swift developers to contribute to the project or alter the generated code for their specific needs! In future iterations, we hope to open up the code generation templating API to allow for even easier customization of your generated code!
• Computation of Cache Keys is protocol oriented now. Instead of a single cacheKeyForObject closure on your ApolloClient, you can implement cache key computation on individual object types with the CacheKeyProvider protocol. See Cache Key Resolution in the RFC for more information.

What’s Next - (Things Not Supported in Alpha 1)

• Operation Variables and Field Arguments
• @include/@Skip Directives
• Cocoapods and Carthage Support for Generated Objects
  • Currently, the generated code supports creating an SPM package you can include as a target in your Package.swift file. Cocoapods and Carthage support will be coming soon.
  • In the mean time, you can still generate your operations and manually include the generated code in your project.
• Automatically Persisted Queries
• Cache Mutations
  • We are re-writing the entire cache mutation system to be easier to work with. Instead of exposing the cache via the operations you have defined, you’ll be able to access the cache through custom generated types that have a view of the entire cache at once. *This means no more writing query operations that are only used for local cache mutations.

Feedback we are looking for

While any and all feedback about the API design, structure, and usability of the library is appreciated, this Alpha version version focuses on the new generated operation models. We would love to hear about your experiences with:

• Generating your models using the SwiftScripts method
• Consuming the new generated models in your application code
  • Are there any use cases that were supported in the previous versions that are not supported or regress in the Alpha? (Other than the known cases listed above that will be supported soon.)
  • Do the new generated models make working with your data easier or more difficult?
  • Do you have specific suggestions for things that can be added or altered in the generated objects to make them more useful?

Expected Alpha Roadmap

• Operation Variables and Field Arguments
  • ASAP - Planned for next Alpha release within a week or two.
• @include/@Skip Directives
  • Next priority after variables and arguments. Maybe the same release, maybe the next release after that
• Cocoapods and Carthage Support for Generated Objects
  • Probably a little while out, but shouldn’t be too hard. So maybe after the two above this.
• Automatically Persisted Queries
  • This is mostly done, just need to actually figure out how to compute the operation identifier hash and generate the operationIds.json file. This is lower priority though, since not a ton of people use it.
• Cache Mutations
  • This is going to take a long time still. We won’t move into Beta until we have the solution for this ready to test, but it’s only about 70% solved so far, and the implementation is not written yet.
  • I’m considering exposing an API to mutate the cache just using the stringly-typed dictionary of data in the mean time, to unblock people from trying out the Alpha in their applications while we solve this. This would be unsafe and not great for production, but should work just fine and be quick and easy to implement as a stop-gap.

Installation

Currently, only SPM is fully supported. Because the generated models can’t easily be consumed by a Cocoapods project yet, we have not included support for installation of the client with Cocoapods. This will be included in an upcoming release shortly.

SPM

.package(name: "Apollo",
         url: "https://github.com/apollographql/apollo-ios.git", 
         from: "1.0.0-alpha.1")

Run codegen using the instructions from the Swift scripting documentation.

Version 0.50.0

• Dropped SPM support for Swift 5.2: The minimum version of the Swift tools and language compatibilty required to process the SPM manifest is Swift 5.3. This means a minimum of Xcode version 12 is required for Swift Package Manager support. #1992
• Removed unnecessary assertion failure: The completion handler on returnResultAsyncIfNeeded is defined as optional but if not included would cause debug builds to crash with an assertionFailure in the case of a failure of the Result. #2005 - Thank you to Richard Topchii for raising this issue!
• CachePolicy.default is now a stored property: It is now easier to configure a different default value for the CachePolicy property on any ApolloClient instance instead of having to override it in a subclass. #1998 - Thank you to Tiziano Coroneo for the contribution!
• Exposed cacheKey function as public: The access modifier of this function on GraphQLField has changed from internal to 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!
• GET method support for ApolloSchemaDownloader: Introspection-based schema downloads can now be queried using a GET request. #2010 - Thank you to Mike Pitre for the contribution!
• Updated to version 2.33.9 of the Apollo CLI: This update will add __typename fields to inline fragments in operations to match the output from the client:push CLI command which used for operation safelisting. This should not affect the behaviour of your operations. #2028.
• Updated to version 0.13.1 of SQLite.swift: This update brings in some iOS 14 fixes and new table functionality such as upsert and insertMany. #2015 - Thank you to Hesham Salman for the contribution.

Version 0.49.1

• ApolloSchemaDownloadConfiguration.HTTPHeader initializer was not public: The struct initializer that Swift automatically generates is marked with the internal access level, which meant that custom HTTP headers could not be added to an instance of ApolloSchemaDownloadConfiguration. #1962 - Thank you to Nikolai Sivertsen for the contribution!
• Documentation update: Fixed an inline code block that had specified language where such specification is not supported. #1954 - Thank you to Kim Røen for the contribution!
• Fix - ApolloCodegenOptions could not find schema input file: - If you created ApolloSchemaDownloadConfiguration and ApolloCodegenOptions objects using only output folders the default output filename for the schema download was different from the default schema input filename for codegen. #1968 - Thank you to Arnaud Coomans for finding this issue!