All Versions
101
Latest Version
Avg Release Cycle
10 days
Latest Release
-

Changelog History
Page 2

  • v1.0.0-beta.1 Changes

    📚 This is the first Beta Release of Apollo iOS 1.0. The Beta version has full feature parity with the 0.x.x releases. The API is expected to be mostly stable. Some breaking changes may occur due to user feedback prior to General Availability (GA) Release. The Beta does not have complete documentation or usage guides, which will be completed prior to GA.

    🐎 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.

    • 🆕 New: Additional Generated Code Output Configuration Options.
      • queryStringLiteralFormat: Configures how the generated operations render the operation document source. Either multi-line (as defined in operation definition) or minified to a single line.
      • schemaDocumentation: Documentation of fields and objects from your schema will now be included as in-line documentation on generated objects. This can be disabled by setting schemaDocumentation to .excluded in your codegen configuration.
      • warningsOnDeprecatedUsage: Adds warning annotation when using fields and arguments in generated operations that are deprecated by the schema.
      • additionalInflectionRules: Allows you to configure custom singularization rules for generated fields names.
    • 🆕 New: Support Automatic Persisted Queries: APQs are now fully functional. Note: Legacy operation safelisting support may experience issues in some cases. If you have problems using operation safelisting, please create an issue so that we may understand and resolve the edge cases in the safelisting process.
    • 🛠 Fixed: Singularization of plural names for non-list fields.
    • 🛠 Fixed: Runtime failure on execution of operations with InputObjects.
    • 🛠 Fixed: __typename field no longer generated when manually included: __typename is automatically included in all operations and fragments and has a default property on all Selection Sets. Generating the field was redundant and caused compilation errors.

  • v1.0.0-alpha.8 Changes

    🚀 This is the eighth 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.

    • 🆕 New: Added Equatable and Hashable Conformance to public API Models: Object's like GraphQLRequest and GraphQLError now can be compared!
    • 🆕 New: Code Generation now supports Schema Extensions.
    • 🛠 Fixed: Namespacing and Access Control on Generated Models: Generated models were failing to compile due to namespacing and access control issues in certain code generation configurations. This is fixed now!
    • 👌 Improved: Custom Scalar Default Float Behavior: If the response for a custom scalar is provided as a Float, it will automatically be converetd to a String (just like it's always done for Int).
    • 👌 Improved: GraphQL Float now treated as Swift Double: The Float defined in the GraphQL spec is actually compliant with a Swift Double. Generated code will now generate Swift code with fields of type Double for GraphQL Float.
    • 👌 Improved: Rename SelectionSet.data to SelectionSet.__data: This is to prevent naming conflicts with GraphQL fields named data.
    • 🛠 Fixed: graphql_transport_ws protocol now sends 'complete' to end subscription: The protocol implementation was previously sending the wrong message to close the connection.
    • 👌 Improved: Generated Operations Folder Structure: The generated output folder structure for fragments and operations are now organized into sub-folders.
    • 🆕 New: Introspection Schema Download can output JSON: Schema downloads via Introspection now support output as JSON instead of only SDL. Note that Apollo Registry schema downloads still only support SDL as the output.

  • v1.0.0-alpha.7 Changes

    🚀 This is the seventh 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.

    • 🆕 New: Local Cache Mutations are now supported: In order to perform a local cache mutation, define a .graphql file with an operation or a fragment and mark it with the directive @apollo_client_ios_localCacheMutation. This will ensure the code generator generates a mutable cache mutation operation.
      • Note: Local Cache Mutation operations cannot be used for fetching from the network! You should define separate GraphQL operations for network operations and local cache mutations.
      • Example Usage:
    /// SampleLocalCacheMutation.graphql
query SampleLocalCacheMutation @apollo_client_ios_localCacheMutation {
  allAnimals {
    species
    skinCovering
    ... on Bird {
      wingspan
    }
  }
}

/// SampleLocalCacheMutationFragment.graphql
fragment SampleLocalCacheMutationFragment on Pet @apollo_client_ios_localCacheMutation {
  owner {
    firstName
  }
}
    • 🆕 New: Support Code Generation Configuration Option: deprecatedEnumCases: If deprecatedEnumCases is set to exclude, deprecated cases in graphql enums from your schema will not be generated and will be treated as unknown enum values.
    • 🛠 Fixed - Compilation Errors in Generated Code When Schema was Embedded In Target: When embedding the generated schema in your own target, rather than generating a separate module for it, there were compilation errors due to access control and namespacing issues. These are resolved. This fixes #2301 & #2302. Thanks @kimdv for calling attention to these bugs!
      • Note: Compilation Errors for Test Mocks are still present. We are aware of ongoing issues with generated test mocks. We are actively working on fixing these issues and they will be resolved in a future alpha release soon.
    • 🛠 Fixed: Crash When Accessing a Conditionally Included Fragment That is Nil. This is fixed now and will return nil as it should. This fixes #2310.

  • v1.0.0-alpha.6 Changes

    🚀 This is the sixth 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.

    • 🆕 New: Objects and InputObjects are now equatable: Many objects now conform to AnyHashable bringing with them the ability to conform to Equatable, this should make tests easier to write.
    • 🔄 Change: GraphQLOperation fields are now static: Previously an instance of a GraphQLOperation was required to query any of it's properties, you can do that on the type now.
    • 🛠 Fixed - Nested fragment type cases: Nested fragment type cases were not being generated causing a crash in selection set generation.
    • 🆕 New - Code generation now has a CLI: A new command line executable has been built and will be available on Homebrew very soon! Check it out here.
    • 🛠 Fixed - SelectionSet and InlineFragment protocol definitions: These were incorrectly being generated within the namespace when a module of type .embeddedInTarget was being used.
    • 🛠 Fixed - Test mock convenience initializers: These were incorrectly definining parameter types for Interface and Union fields and the generated package could not successfully build.

  • v1.0.0-alpha.5 Changes

    🚀 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!

  • v1.0.0-alpha.4 Changes

    🚀 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.

  • v1.0.0-alpha.3 Changes

    🚀 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
    class MyQuery: GraphQLQuery {

  var myVar: GraphQLNullable<String>

  init(myVar: GraphQLNullable<String> { ... }
 // ...
}

let optionalString: String?

// Before

let query = MyQuery(myVar: optionalString.map { .some($0) } ?? .none)

// After
let query = MyQuery(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.

  • v1.0.0-alpha.2 Changes

    🚀 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

  • v1.0.0-alpha.1 Changes

    🚀 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 siblings.
    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.

  • v0.53.0 Changes

    • ✂ Remove all instances of bitcode as not supported in Xcode 14: Starting with Xcode 14, bitcode is no longer required for watchOS and tvOS applications, and the App Store no longer accepts bitcode submissions from Xcode 14. #2398 - Thanks to [@stareque-atlassian](stareque-atlassian) for the contribution!