-
Notifications
You must be signed in to change notification settings - Fork 730
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Community Updates - ROADMAP/README (#1867)
* Update ROADMAP per latest planning * Update README * Keep us accountable to updating the roadmap * Better explanation of the network stack changes * Spelling correction * Settle on wording for 1.0
- Loading branch information
1 parent
84e28fe
commit abf1ece
Showing
2 changed files
with
68 additions
and
40 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,45 +1,41 @@ | ||
| # Roadmap | ||
| # Apollo iOS Roadmap - _Last Updated July 2021_ | ||
|
|
||
| This document is meant to give the community some idea of where we're going with the iOS SDK in the short and longer term. | ||
| _If this document has not been updated within the past three months, please [file an issue](https://github.com/apollographql/apollo-ios/issues/new/choose) asking the [maintainers](https://github.com/apollographql/apollo-ios#maintainers) to update it._ | ||
|
|
||
| This document was last updated on January 4th, 2020 | ||
| Releases adhere to the [Semantic Versioning Specification](https://semver.org/). Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. | ||
|
|
||
| ^ If that's more than three months ago, please file an issue asking [@designatednerd](https://github.com/designatednerd) to update this document. 😃 | ||
| ## 0.x - _Current_ | ||
|
|
||
| This version is being used in many Production codebases, and we're committed to resolving issues and bugs raised by the community. We are not considering any further substantial work to be done in this version. | ||
|
|
||
| ## Short-Term | ||
| ## 1.0 - _Estimated Release Q4 2021_ | ||
|
|
||
| These are things we plan to be working on **within the next 3 months**. | ||
| These are the three guiding principles we're aiming for in a 1.0 release. | ||
| - **Stability**: Achieve a stable foundation that can be trusted for years to come, maintaining backwards compatibility within major version releases. | ||
| - **Completeness**: There are three main parts to the SDK: code generation, network fetching/parsing, and caching. These must provide enough functionality to be a good foundation for incremental improvements in future releases without requiring breaking changes. | ||
| - **Clarity**: Everything must be clearly documented with as many working samples as possible. | ||
|
|
||
| - **Swift Codegen Rewrite, Continued**: As outlined in much greater detail in the [RFC issue](https://github.com/apollographql/apollo-ios/issues/939), we're rewriting our code generation. This has taken ~~somewhat~~ ~~a lot~~ colossally longer than expected, but the following phases are still in progress: | ||
|
|
||
| - **Start generating code with Swift instead of Typescript**. This will allow much easier community contribution to code generation, and allow us to take on a bunch of improvements like `Hashable`, `Equatable`, and potentially `Identifiable` without having to fight with Typescript to do it. | ||
| - **Add immutable caching to new generated code**. Caching is currently heavily tied into our existing parsing mechanism. We're going to separate that out in two phases: The first will allow caching that *cannot* be changed by the consumer. | ||
| - **Add mutable caching to new generated code**. This is the final stage of updating caching: Allowing caching that *can* be changed by the consumer. | ||
| - **Remove Old Codegen**. Once all this is built, older codegen will be deprecated. | ||
|
|
||
| You can follow this effort through the [Swift Codegen GitHub project](https://github.com/apollographql/apollo-ios/projects/2). | ||
|
|
||
| - **Cache Improvements**: We've had a ton of requests for this and we've got some extra muscle now, so we're going to be working on many requests. First up, some features inspired by Apollo Client 3 for the web: | ||
| - **Better pagination support**. Better support for caching and updating paginated lists of objects. | ||
| - **Reducing over-normalization**. Only separating out results into individual records when something that can identify them is present | ||
| - **Codable Support**: Which will allow easier moving between any storage method and objects, along with working better with updated codegen. | ||
|
|
||
| - **General bug-bashing**: There are always a few outstanding general issues and small feature requests I'd like to address, and we'll be dealing with any new issues as they come up. | ||
| These are the major initiatives planned for 1.0. | ||
| - **Swift Codegen Rewrite**: The code generation is being rewritten with a Swift-first approach instead of relying on scripting and Typescript. This will allow easier community contribution to code generation and provide the opportunity to improve various characteristics such as generated code size and performance. | ||
| - We are finishing the spec at the moment which will then be published as an RFC for review and feedback. | ||
| - Once we're ready to begin implementation those details and development phases will be shared here. | ||
|
|
||
| - **Networking Stack Improvements**: The goal is to simplify and stabilise the networking stack. | ||
| - The [updated network stack](https://github.com/apollographql/apollo-ios/issues/1340) solved a number of long standing issues with the old barebones NetworkTransport but still has limitations and is complicated to use. Adopting patterns that have proven useful for the web client, such as Apollo Link, will provide more flexibility and give developers full control over the steps that are invoked to satisfy requests. | ||
|
|
||
| ## Long-Term | ||
| - **Improved Documentation and Tutorials**: We want developers to be able to self-serve as much as possible and having comprehensive, guiding documentation is essential to that experience. | ||
|
|
||
| These are things we plan to be working on **beyond the next 3 months**. | ||
| ## 1.x/2.0 - _Future_ | ||
|
|
||
| We're very open to any help we can get on these if your goals would be advanced by making these things work better sooner. | ||
| These are subject to change and anything that dramatically changes APIs or breaks backwards compatibility with 1.x releases will be reserved for the next major version. | ||
|
|
||
| - **Moar Cache Stuff**: Some additional improvements to the cache to | ||
| - **Real cache eviction & dangling reference collection**. There's presently a way to manually remove a value for a given key, but AC3's given us a roadmap for how to handle some of this stuff much more thoroughly and safely. | ||
| - **Cache metadata**. Ability to add per-field metadata if needed, to allow for TTL and time-based invalidation, along with other possible goodies. | ||
| - **Cache Improvements**: Here we are looking at bringing across some features inspired by Apollo Client 3 and Apollo Android | ||
| - **Better pagination support**. Better support for caching and updating paginated lists of objects. | ||
| - **Reducing over-normalization**. Only separating out results into individual records when something that can identify them is present | ||
| - **Real cache eviction & dangling reference collection**. There's presently a way to manually remove objects for a given key or pattern, but Apollo Client 3 has given us a roadmap for how to handle some of this stuff much more thoroughly and safely. | ||
| - **Cache metadata**. Ability to add per-field metadata if needed, to allow for TTL and time-based invalidation, etc. | ||
|
|
||
| - **Dependency Manager test suite**. We've seen a few issues around things that work well for at least one of the three major iOS dependency managers, but causes problems in others. We plan to make a repo that we can use to automatically test for common issues against new versions of the library on CocoaPods, Carthage, and Swift Package Manager *before* they're released. | ||
|
|
||
| - **Wrapper libraries**. A very highly voted suggestion in our fall 2019 developer survey was wrapper libraries for concurrency helpers like RxSwift, Combine, and PromiseKit. | ||
|
|
||
| Note that we are **not** locked into any particular set of other dependencies to support yet, but we anticipate these will be wrappers in a separate repository that have Apollo as a dependency. As individual wrappers move into nearer-term work, we'll outline which specific ones we'll be supporting. | ||
| - **Wrapper libraries**. A very highly voted suggestion in our fall 2019 developer survey was wrapper libraries for concurrency helpers like RxSwift, Combine, PromiseKit, and Async/Await. | ||
| - Note that we are **not** locked into any particular set of other dependencies to support yet, but we anticipate these will be wrappers in a separate repository that have Apollo as a dependency. As individual wrappers move into nearer-term work, we'll outline which specific ones we'll be supporting. |