What I don't want is to be limited by the specific nuances of whatever persistence framework I happen to be employing. I don't want to see @objc littering my model code, along with awkward names of collections that can sometimes come with frameworks like CoreData. I'm not saying it never makes sense to lean on something like CoreData. There's an awful lot of advanced features and benefits that can warrant allowing its tentacles to reach into your code. I'm just saying I like to resist doing so unless truly necessary.

A "service layer" is a common pattern that can take a few different forms. I like to define my services as protocols that can be implemented concretely within your integrations. For example, let's say our app needs to fetch Post objects as part of a social media feed. You might have a PostService that handles the fetching:

/// A service that fetches posts
protocol PostService {
    
    /// The result of fetching posts
    typealias FetchPostsResult = Result<[Post], Error>
    
    /// The completion handler called after an attempt to fetch posts
    typealias FetchPostsCompletion = (FetchPostsResult) -> Void
    
    /// Fetch posts for the user
    func fetchPosts(for user: User, _ completion: FetchPostsCompletion)
}

/// An HTTP API implementation of a post service
struct MyBackendPostService: PostService {
    
    func fetchPosts(for user: User, _ completion: (FetchPostsResult) -> Void) {
        // TODO: Implement URL request for fetching posts
    }
}

/// A firebase implementation of a post service
struct FirebasePostService: PostService {
    
    func fetchPosts(for user: User, _ completion: (FetchPostsResult) -> Void) {
        // TODO: Implement Firebase query for fetching posts
    }
}

It doesn't matter, because all your view code needs is some instance of PostService.

And in order to pass it into your view code, you create a ServiceProvider object as part of your Services layer, which is a bridge from your Integrations layer to your Services layer:

/// The object that provides concrete implementation of al services
struct ServiceProvider {
    
    static let postService: PostService = FirebasePostService()
}

This way, if you decide to switch up the implementation, you only need to edit the ServiceProvider struct which is in turn used by your views or store objects. Your views remain entirely unchanged!

Finally, there’s a high-level IntegrationsManager class that handles all setup and lifecycle events for all integrations. There’s nothing I hate more than littering one’s App Delegate with dependency setup, so all of that is delegated to this class.

As part of the integration, I create a FirebaseAuthenticationViewController which is a UIKit subclass of Firebase's FUIAuthPickerViewController which handles all my app-specific customization of the Firebase component. And since I'm using SwiftUI, I create a UIViewControllerRepresentable instance called FirebaseAuthenticationView that handles the translation from UIKit.

This is great because it keeps all my view code that uses the Firebase SDK with all the other integration code, separate from the guts of my app. But I also don't want to just drop in my FirebaseAuthenticationView into my view code, because that's just a more indirect way of littering my app-specific code with third-party dependencies.

Ideally, we want our own SwiftUI view called AuthenticationView that we can add to our view hierarchy as desired. Our view accepts all dependencies in it's initializer as we see fit, and is the struct we present whenever we want to enter our auth flow.

But since we are deciding that its implementation will be deferred to a third-party framework, it's perfectly reasonable to require the implementation as an initializer parameter to our native view. And this is again where services come in.

If we were not using custom UI, we'd almost certainly have something like an AuthenticationService that has login and signup functions as so:

/// A service that managers user authentication
protocol AuthenticationService {
    
    /// The result of a login attempt
    typealias LoginResult = Result<User, Error>

    /// Login with the provided email and password
    func login(email: String, password: String, _ completion: LoginResult)
}

/// A service that managers user authentication
protocol AuthenticationService {
    
        /// The view that manages authentication
    var authenticationView: AnyView { get }
}

Then we implement this service back in our integration, and return an instance of our FirebaseAuthenticationView like so:

/// A Firebase implementation of the authentication service
struct FirebaseAuthenticationService: AuthenticationService {
    
    var authenticationView: AnyView {
        return FirebaseAuthenticationView()
    }
}

This way, if we decided to use the next latest and greatest BAAS that provides a complete login flow, we'd just need to provide an alternative implementation of AuthenticationView and nothing more.

Now, I realize some of us may feel this isn't really an appropriate use of a "service." I personally have no problem with it if we just think of a service as a dependency provider. But I'm also open to using something like an AuthenticationViewProvider object and keeping services data-oriented. How you do this is up to you. The point though is that it's not so hard to abstract even view details away and designate them as dependencies to be injected via some passed in object whose API is app-specific. And if at some point we decide we want to roll our own solution, we just expand the service to include the functionality we want and remove the view.

For example, your backend JSON API will likely need Codable to serialize and deserialize models fetched and sent over HTTP. The problem is that the way your models are stored and architected on that API are not necessarily a one-to-one match with how you might optimize your models in the context of your app with the latest Swift features. Your implementations of Codable might be straightforward as adding the declaration and auto-synthesizing the implementation — or they might require logic specific to the API to translate the fetched JSON into your local model structs.

This may or may not be a problem. If your models are only ever interacting with one API, then it might be fine to implement Encodable and Decodable as extensions of the model struct but within the integration group. This way, if you swap out APIs, you can replace the implementations as needed without requiring changes to scope that effects the whole app.

For example, let’s say you have a Video model that’s used in your app to play streaming videos. Users can upload videos so they’re stored in Firebase as part of the user’s data, but your app also uses a third-party service for high-performance video hosting and streaming like JWPlayer. Thing is, the way each video is modeled in this third-party service is different from Firebase. Not only does it include less data about each video, but the data is modeled differently on JWPlayer due to API limitations.

In this case, where would you implement the Encodable and Decodable extensions? In the app-level models layer? At the top level of the integrations layer? Neither feels right. And either way, you’d have to have all this logic within that implementation to accommodate each specific case which can lead to unreadable chaos that’s impossible to maintain.

In cases like this, I find it valuable to separate the concerns completely. Firebase gets it’s own struct called FirebaseVideo that is designed around how a video is represented on Firebase. Likewise, the JWPlayer get’s its own struct called JWPlayerVideo. Each is modeled such a way that custom Encodable and Decodable implementations are straight-forward for the API. Then, any logic needed to translate back to the app specific model Video is done as an extension on the Video struct:

extension Video {
    
    init(_ video: FirebaseVideo) {
        self.id = video.id
        ...
    }
}

extension Video {
    
    init(_ video: JWPlayerVideo) {
        self.id = video.id
        ...
    }
}

Sure, it’s a little more tedious to have multiple model definitions, Codable implementations, and initializers — and I’m not saying having them is always warranted. But in a situation like this, the tedium is worth the vastly worse headache of reasoning through edge cases, not to mention that all this code gets to live exclusively within the integration for which it’s relevant.