« Changelog History


apollo-ios v1.0.0-beta.2 Release Notes

  • 📚 This is the second 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.

    💥 Breaking: Changed API for Cache Key Configuration: Cache Key Resolution is now easier to configure. See CacheKeyInfo for examples and documentation. 💥 Breaking: Changed API for generated Schema Types to support dynamic types The API for generated schema types now initializes instances of Object, Interface, and Union for each corresponding type in your schema. These are still generated by the code generation engine. This differs from the previous API which generated static types that were subclasses of Object, Interface, and Union. The change provides the API to support the future addition of dynamic types added to your schema at runtime. 🆕 New: Codegen CLI will now automatically create output directories: You no longer are required to have already created all intermediary directories for your codegen output paths prior to running code generation. 🆕 New: Codegen CLI is built locally with CocoaPods installations: This is to ensure that the version of the Codegen CLI is the same as ApolloCodegenLib. This behaviour will be extended to Swift Package Manager installations too. 🆕 New: Swift Keywords are escaped when used as names of fields or types in generated objects: Previously, using Swift keywords (eg. self, protocol, Type) as the names of fields in your operations or types in your schema would cause compilation errors in your generated code. Now, these names will be escaped with backticks to prevent compiler errors. The names \_\_data and fragments cannot be used as field names as they conflict with Apollo's generated object APIs Using these names will result in a validation error being thrown when attempting to run the code generation engine. 🛠 Fixed: Fragments with lowercase names caused compilation errors: This bug is fixed. Fragments with lowercase names will be correctly uppercased when referencing the generated Fragment objects. 🛠 Fixed: Build errors in Xcode 14/Swift 5.7: The library was updated to support the Swift 5.7 language version. Swift 5.6 is still supported. 🛠 Fixed: Xcode 14 does not support Bitcode: 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.
    🛠 Fixed: "No such module ApolloAPI" error when using CocoaPods: The podspec was not configured to import all required source files and some import statements were unnecessary in a CocoaPods environment. A code generation configuration option was added to order to ensure generated files are generated with the correct import statements in a CocoaPods environment. When generating code for a project that includes Apollo via Cocoapods, you must set the cocoapodsCompatibleImportStatements option to true in your ApolloCodegenConfiguration. When using the Codegen CLI that is built for you during pod install the apollo-ios-cli init command will default this option to true. When building the Codegen CLI in by other method, this option will default to false.
    ✂ Removed: ApolloUtils target no longer necessary: The things that used to be shared here are actually no longer shared. There is no code shared between the Apollo and ApolloCodegenLib targets.
    ✂ Removed: ApolloCodegenConfiguration.validation: This method was incorrectly requiring destination paths to exist before code generation. Once that was removed it was no longer necessary. Any errors that are encountered with destination output paths will be raised during code generation.