2023-06-01 Roadmap Update (#3055)

ROADMAP.md

@@ -1,6 +1,6 @@
 # 🔮 Apollo iOS Roadmap
 
-**Last updated: 2023-05-18**
+**Last updated: 2023-06-01**
 
 For up to date release notes, refer to the project's [Changelog](https://github.com/apollographql/apollo-ios/blob/main/CHANGELOG.md).
 
@@ -23,25 +23,39 @@ As we identify feature sets that we intend to ship, we'll add to and update the
 
 ### [`@defer` support](https://github.com/apollographql/apollo-ios/issues/2395)
 
-_Approximate Date: Early June 2023_
+_Approximate Date: 2023-06-30_
 
-The `@defer` directive enables your queries to receive data for specific fields asynchronously. This is helpful whenever some fields in a query take much longer to resolve than others.  [Apollo Kotlin](https://www.apollographql.com/docs/kotlin/fetching/defer/) and [Apollo Client (web)](https://www.apollographql.com/docs/react/data/defer/) currently support this syntax, so if you're interested in learning more check out their documentation.  Apollo iOS will release support for this directive in a `1.x` minor version.  More details TBD.
+The `@defer` directive enables your queries to receive data for specific fields asynchronously. This is helpful whenever some fields in a query take much longer to resolve than others.  [Apollo Kotlin](https://www.apollographql.com/docs/kotlin/fetching/defer/) and [Apollo Client (web)](https://www.apollographql.com/docs/react/data/defer/) currently support this syntax, so if you're interested in learning more check out their documentation.  Apollo iOS will release support for this directive in a `1.x` minor version.  This will be released as an experimental feature.
+
+### [Paginated watchers for GraphQL queries](https://github.com/apollographql/apollo-ios/pull/3007)
+
+_Approximate Date: 2023-07-12_
+
+- Support for Relay-style (cursor-based), offset-based, and arbitrary pagination patterns
+- `@connection` directive support
 
 ### [Improve fragment merging and code generation performance](https://github.com/apollographql/apollo-ios/milestone/67)
 
-_Approximate Date: 2023-06-14_
+_Approximate Date: 2023-07-26_
 
 - Add configuration for disabling merging of fragment fields
 - Recognize when multiple selection set types will end up being identical and use a shared model object with typealiases to reduce generated code
 - Fix retain cycles and memory issues causing code generation to take very long on certain large, complex schemas with deeply nested fragment composition
 
 ### [Reduce generated schema types](https://github.com/apollographql/apollo-ios/milestone/71)
 
-_Approximate Date: Early July 2023_
+_Approximate Date: Late August 2023_
 
 - Right now we are naively generating schema types that we don't always need. A smarter algorithm can reduce generated code for certain large schemas that are currently having every type in their schema generated
 - Create configuration for manually indicating schema types you would like to have schema types and TestMocks generated for
 
+### Declarative caching
+
+_Approximate Date: TBD_
+
+- Similar to Apollo Kotlin [declarative caching](https://www.apollographql.com/docs/kotlin/caching/declarative-ids) via the `@typePolicy` directive
+- Provide ability to configure cache keys using directives on schema types as an alternative to programmatic cache key configuration
+
 ## [2.0](https://github.com/apollographql/apollo-ios/milestone/60)
 
 _Approximate Date: TBD_
@@ -60,6 +74,7 @@ These are the major initiatives planned for 3.0/3.x:
 
 - **Cache Improvements**: Here we are looking at bringing across some features inspired by Apollo Client 3 and Apollo Kotlin
   - Better pagination support. Better support for caching and updating paginated lists of objects.
+  - Result model improvements
   - 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.