Sendable types

[calvincestari]

Use case

Ensure that schema generated types, such as generated enums can conform to Sendable.

Describe the solution you'd like

More context in https://apollograph.slack.com/archives/C049FKX5N74/p1700467655099039

Original context is for generated types to conform to Sendable something like this:

// @generated
// This file was automatically generated and should not be edited.

import Apollo

public extension SomeNamespace {
  enum SomeType: String, EnumType {
    case a = "A"
    case b = "B"
    case c = "C"
  }
}

becomes..

// @generated
// This file was automatically generated and should not be edited.

import Apollo

public extension SomeNamespace {
  enum SomeType: String, EnumType, Sendable {
    case a = "A"
    case b = "B"
    case c = "C"
  }
}

[vsanthanam]

Would be curious to know if some of this can be adopted earlier than the eventual 2.0 release -- I think at the minimum the immutable generated types, as well as configuration enums like CachePolicy can add conformance without any actual implementation changes to the types themselves.

[dfed]

Is the Apollo graph slack something that external folk can join? I'd love to have a sense of where you're going with Swift Concurrency so I can design my abstractions in a future-proofed way.

[calvincestari]

Is the Apollo graph slack something that external folk can join?

Not the org internal Slack no. We do have the Apollo GraphQL Community on Discord though which has sections for clients, etc.

I'll edit the description to put the context there instead.

I'd love to have a sense of where you're going with Swift Concurrency so I can design my abstractions in a future-proofed way.

We don't have anything to share right now. It's a bunch of disconnected conversations and issues; it needs to get brought into a single document where we can talk about everything collectively.

[BrentMifsud]

Is the Apollo graph slack something that external folk can join?

Not the org internal Slack no. We do have the Apollo GraphQL Community on Discord though which has sections for clients, etc.

I'll edit the description to put the context there instead.

I'd love to have a sense of where you're going with Swift Concurrency so I can design my abstractions in a future-proofed way.

We don't have anything to share right now. It's a bunch of disconnected conversations and issues; it needs to get brought into a single document where we can talk about everything collectively.

With the recent announcement of Swift 5.10 being the last Swift 5 release, I think this needs higher priority. As we're likely going to see people using Swift 6 in their code bases starting in June with the Xcode 16 beta.

[BrentMifsud]

any updates on this?

[ArtyCodingart]

Hello. Any news?

[birwin93]

Hi there! Also curious to know when this is going to be shipped. Had to do some hacks to migrate my codebase to swift 6

[AnthonyMDev]

I am actively working on this right now. A lot of our types were not designed for Sendable and there is going to have to be some significant changes to make this work.

I'm anticipating this is going to be a breaking change that requires some sort of migration. I'm working on making that migration as painless as possible for as many people as possible. I will give more updates as soon as I have them.

[AnthonyMDev]

As I'm going through and attempting to make things Sendable, I'd love to know what particular types people need to be Sendable. Please post any types that your application needs Sendable conformance for here.

We're planning on doing an entire networking re-write to use async/await and Strict Concurrency as a major new version of the library. But for now, I'm hoping to just get 1.0 working with Strict Concurrency.

I know we need to make the generated models and related types Sendable, but I'm not currently planning on making the actual ApolloClient APIs Sendable (eg. ApolloStore, RequestChain, InterceptorProvider, HTTPRequest`, etc.).

Is anyone currently having issues with Swift 6 related to those types?

[dfed]

For me, the bar is being able to use ApolloClient's async APIs without any warnings or errors in Swift 6. For this to be the case, I believe the bare minimum of types that must be Sendable (or @unchecked Sendable assuming there is thread-safety under the hood) are:

• ApolloClient
• Generated Data types that are returned from perform(mutation:)
• The types mentioned in Apollo code-gen fails to compile on Xcode 15.3 with StrictConcurrency enabled #3348

[BrentMifsud]

As far as my project goes, aside from the generated models, I'd say maybe things like cache policy.

I'll add more if I can think of it.

[jimisaacs]

I think I'd be in need of the following, in addition to generated Data types that have been mentioned:

• ApolloStore
• ApolloClient
• GraphQLError
• GraphQLResult
• GraphQLResult.Source
• GraphQLResultHandler
• GraphQLOperation
• CachePolicy
• Record

I don't think that list is completely definitive, as I'm also seeing how much road the following will take me down:

@preconcurrency import Apollo
@preconcurrency import ApolloAPI
@preconcurrency import ApolloSQLite

[dfed]

Adding one more to the list: WebSocketTransport would be great to make Sendable. It looks like it's already nominally thread-safe too.

If you expect a type to work safely across thread boundaries it'd be great to at least mark as @unsafe Sendable if we can't reasonably get to Sendable. I've been trusting y'all to get threading right thus far – I have no reason to stop now.

[AnthonyMDev]

Thank you all for the valuable feedback!

After a lot of research, we've come to the conclusion that providing proper support for Swift 6 and structured concurrency is going to require breaking changes.

I have put up an RFC for a 2.0 version of Apollo iOS that will support Swift 6. Please check it out and respond with any concerns or suggestions you have!