Sendable Protocol Implementation for Services - Swift 6 Best Practices

[zalogatomek]

I have a question about Sendable implementation for services that I'd like to clarify after completing the course.

While I understand that all data models should be Sendable (since we "send" them between threads), I'm unclear about whether and why services should also implement this protocol. The concept of "sending" services across concurrency domains doesn't feel as natural to me.

For better context, let's consider public protocols that might be defined for example in some package - a situation where we can't rely on "implicit conformance to Sendable" as it happens with internal actors. Also, please consider writing a new code in Swift 6, not a migration case.

Example:

public protocol UserProvider {
    func fetchUsers() async throws -> [User]
}

My understanding is that such a protocol would likely be used by a single type (e.g., a ViewModel), and I don't see how isolation changes would occur in this scenario. Or even if used in multiple parts of the app - each use case would just have its own, separate instance.

Questions:

• Should UserProvider conform to Sendable? What are the implications if it doesn't?
• When implementing a service, should actor be the default solution? Or...
• ... are there any specific patterns or best practices when implementing services?
• In other words, summarizing all of the above - should we make sure that everything is Sendable (no matter if implicitly or explicitly)

I'd appreciate any clarification on this topic, as it would help me better understand the practical application of Sendable in real-world scenarios. If possible, I would love to see some examples why everything (if it's correct) should be Sendable