Bridging interfaces with the Adapter pattern in Swift

Sometimes, we adopt libraries or frameworks that don't match our app's internal abstractions. Or, as our architecture evolves, existing components no longer fit with newer code cleanly. Instead of rewriting working code, we can adapt it with the Adapter pattern.

Let's look at how to do it with a practical example.

Architecture & Design Patterns for iOS

This book is a practical guide to essential architectural principles and design patterns for iOS development. It covers strategies for building maintainable apps with Swift and SwiftUI, including dependency injection, navigation, common patterns, and modularization.

LEARN MORE

Let's say our app expects a SearchService protocol that defines how search functionality should work across different parts of the app:

protocol SearchService {
    func search(query: String) async throws -> [SearchResult]
}

But we're integrating a third-party SDK with the following interface:

class ThirdPartySearch {
    func runSearch(term: String, completion: @escaping ([Any]) -> Void) {
        // ...
    }
}

The SDK's API uses different method names, a completion handler instead of async/await, and returns untyped results.

Here's how we can bridge that gap:

class ThirdPartySearchAdapter: SearchService {
    private let thirdPartySearch = ThirdPartySearch()

    func search(query: String) async throws -> [SearchResult] {
        try await withCheckedThrowingContinuation { continuation in
            thirdPartySearch.runSearch(term: query) { rawResults in
                let results = rawResults.compactMap { $0 as? SearchResult }
                continuation.resume(returning: results)
            }
        }
    }
}

Now, we can use ThirdPartySearchAdapter anywhere a SearchService is expected.

The Adapter pattern helps us preserve encapsulation and maintain clean separation between domains, making our code more resilient to change.