When it comes to calling completion handlers for asynchronous operations, the established convention within the Apple developer community has for long been to simply continue executing on whatever DispatchQueue that the operation itself (or at least its final part) was performed on.

For example, when using the built-in URLSession API to perform a data task-based network call, our attached completion handler will be executed on a queue that’s managed internally by URLSession itself:

let task = URLSession.shared.dataTask(with: url) {
    data, response, error in

    // This code will be executed on an internal URLSession queue,
    // regardless of what queue that we created our task on.
    ...
}

The above convention does arguably make complete sense in theory — as it encourages us to write asynchronous code that’s non-blocking, and since it tends to reduce the overhead involved in jumping between queues when doing so isn’t needed. However, it can also very often lead to different kinds of bugs and race conditions if we’re not careful.

That’s because, at the end of the day, the vast majority of the code within the vast majority of applications isn’t going to be thread-safe. Making a class, function, or another kind of implementation thread-safe typically involves a fair amount of work, especially when it comes to UI-related code, since all of Apple’s core UI frameworks (including both UIKit and SwiftUI) can only be safely used from the main thread.

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Remembering to dispatch UI updates on the main queue

Let’s take a look at an example, in which we’ve built a ProductLoader that uses the above mentioned URLSession API to load a given Product based on its ID:

class ProductLoader {
    typealias Handler = (Result<Product, Error>) -> Void

    private let urlSession: URLSession
    private let urlResolver: (Product.ID) -> URL
    
    ...

    func loadProduct(withID id: UUID,
                     completionHandler: @escaping Handler) {
        let task = urlSession.dataTask(with: urlResolver(id)) {
            data, response, error in

            // Decode data, perform error handling, and so on...
            ...
            
            handler(result)
        }

        task.resume()
    }
}

The above class follows that established convention of not dispatching its completionHandler call on any specific queue, and instead simply calls that closure inline within its own completion handler, which is in turn called by URLSession on that previously mentioned internal background queue.

Because of that, whenever we’re using our ProductLoader within any kind of UI-related code, we need to remember to always explicitly dispatch any resulting UI updates on our application’s main DispatchQueue — for example like this:

class ProductViewController: UIViewController {
    private let productID: Product.ID
    private let loader: ProductLoader
    private lazy var nameLabel = UILabel()
    private lazy var descriptionLabel = UILabel()
    
    ...

    func update() {
        loader.loadProduct(withID: productID) { [weak self] result in
            DispatchQueue.main.async {
                switch result {
                case .success(let product):
                    self?.nameLabel.text = product.name
                    self?.descriptionLabel.text = product.description
                case .failure(let error):
                    self?.handle(error)
                }
            }
        }
    }
}

Having to remember to perform the above kind of DispatchQueue calls within our asynchronous closures might not actually be a huge issue in practice, since (just like the classic weak self dance) it’s something that we have to do incredibly often when developing apps for Apple’s platforms, so it’s not something that we’re likely to forget.

Plus, if we ever do forget to add that call (or if someone’s just getting started with app development and haven’t learned about that aspect yet), then Xcode’s Main Thread Checker will quickly trigger one of its purple warnings as soon as we run any code that accidentally calls a main queue-only API from a background thread.

However, what if we’re not using closures? For example, let’s imagine that our ProductLoader instead used the delegate pattern, and rather than calling a completion handler, it would instead call a delegate method whenever it finished one of its operations:

class ProductLoader {
    weak var delegate: ProductLoaderDelegate?
    ...

    func loadProduct(withID id: UUID) {
        let task = urlSession.dataTask(with: urlResolver(id)) {
            [weak self] data, response, error in

            guard let self = self else { return }

            // Decode data, perform error handling, and so on...
            ...
            
            self.delegate?.productLoader(self,
    didFinishLoadingWithResult: result
)
        }

        task.resume()
    }
}

If we now go back to our ProductViewController and update it accordingly, it’s no longer very clear that the call site (its delegate protocol implementation in this case) is handling the result of an asynchronous operation, which makes it much more likely that we’ll forget to perform our UI updates asynchronously on the main queue.

So although Xcode will still give us a runtime error when the following method is called (and our UI updates are performed on a background queue), it’s not very obvious that its implementation is incorrect just by looking at it:

extension ProductViewController: ProductLoaderDelegate {
    func productLoader(
        _ loader: ProductLoader,
        didFinishLoadingWithResult result: Result<Product, Error>
    ) {
        switch result {
        case .success(let product):
            nameLabel.text = product.name
            descriptionLabel.text = product.description
        case .failure(let error):
            handle(error)
        }
    }
}

Granted, the delegate pattern is not as hip and trendy as it used to be (I still like it, though), but the above problem is definitely not unique to that particular pattern. In fact, if we now look at a very modern, Combine-based version of our ProductLoader and its associated view controller — we can see that it has the exact same problem as our delegate-based implementation — it’s not at all obvious that our UI updates will currently end up being performed on a background queue:

class ProductLoader {
    ...

    func loadProduct(withID id: UUID) -> AnyPublisher<Product, Error> {
        urlSession
            .dataTaskPublisher(for: urlResolver(id))
            .map(\.data)
            .decode(type: Product.self, decoder: JSONDecoder())
            .eraseToAnyPublisher()
    }
}

class ProductViewController: UIViewController {
    ...
    private var updateCancellable: AnyCancellable?

    func update() {
        updateCancellable = loader
            .loadProduct(withID: productID)
            .convertToResult()
            .sink { [weak self] result in
                switch result {
                case .success(let product):
                    self?.nameLabel.text = product.name
                    self?.descriptionLabel.text = product.description
                case .failure(let error):
                    self?.handle(error)
                }
            }
    }
}

Above we’re using the custom convertToResult operator from “Extending Combine with convenience APIs” to be able to easily handle our Combine pipeline’s output as a Result value.

So, to summarize, regardless of which pattern that we choose to implement our asynchronous operations, there’s always a risk that we’ll forget to manually dispatch our UI updates on the main queue — especially when it’s not obvious that a given callback might be performed on a background queue.

Explicit queue injection

So how can we fix the above problem? Is it even worth fixing, or should we just assume that every Swift developer with a certain amount of experience will always remember to ensure that their UI updates will be performed on the main queue?

If you ask me, I think that any truly great API shouldn’t rely on its caller remembering (or even knowing) certain conventions — those conventions should ideally be baked into the API design itself. After all, a quite rock-solid way to ensure that an API doesn’t ever get used incorrectly is to make it impossible (or at least very hard) to do so — by leveraging tools like Swift’s type system to validate each call at compile time.

One way to do that in this case would be to always call our completion handlers on the main queue, which would completely eliminate the risk of having any of our call sites accidentally perform UI updates on a background queue:

class ProductLoader {
    ...

    func loadProduct(withID id: UUID,
                     completionHandler: @escaping Handler) {
        let task = urlSession.dataTask(with: urlResolver(id)) {
            data, response, error in

            ...

            DispatchQueue.main.async {
    completionHandler(result)
}
        }

        task.resume()
    }
}

However, the above pattern can also end up causing issues of its own, especially if we’re looking to use our ProductLoader within contexts where we do want to continue executing on a background queue in a non-blocking way.

So here’s a much more dynamic version, which still uses the main queue as the default for all completion handler calls, but also enables an explicit DispatchQueue to be injected — giving us the flexibility to both use our ProductLoader within concurrent environments that operate away from the main thread, and within our UI code, all while significantly reducing the risk of performing UI updates on the wrong queue:

// Completion handler-based version:

class ProductLoader {
    ...

    func loadProduct(
        withID id: UUID,
        resultQueue: DispatchQueue = .main,
        completionHandler: @escaping Handler
    ) {
        let task = urlSession.dataTask(with: urlResolver(id)) {
            data, response, error in

            ...

            resultQueue.async {
    completionHandler(result)
}
        }

        task.resume()
    }
}

// Combine-based version:

class ProductLoader {
    ...
    
    func loadProduct(
        withID id: UUID,
        resultQueue: DispatchQueue = .main
    ) -> AnyPublisher<Product, Error> {
        urlSession
            .dataTaskPublisher(for: urlResolver(id))
            .map(\.data)
            .decode(type: Product.self, decoder: JSONDecoder())
            .receive(on: resultQueue)
            .eraseToAnyPublisher()
    }
}

Of course, the above pattern does rely on us remembering to add that resultQueue argument to each of our asynchronous APIs (we could’ve also implemented it as an initializer parameter instead), but at least now we don’t have to remember to always use DispatchQueue.main.async at every single call site — which I personally think is a big win.

Support Swift by Sundell by checking out this sponsor:

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Conclusion

While there’s no such thing as a completely error-proof API, and developing apps for any kind of platform is always going to involve learning and remembering certain conventions, if we can make the APIs that we design within our own apps as easy to use (or as hard to misuse) as possible, then that tends to result in code bases that are robust and straightforward to work with.

Defaulting to calling completion handlers on the main queue might just be a small part of that, but it might turn out to be a quite important part, especially within code bases that make heavy use of asynchronous operations that result in UI updates.

If you want to hear more thoughts on this topic, then I really recommend listening to my recent podcast conversation with Brent Simmons, which focused on how to orchestrate concurrent code within iOS and Mac apps.

Thanks for reading!

Often when writing Combine-powered data pipelines, we want those pipelines to emit values as quickly as possible, as soon as each operation finishes. However, sometimes we might also want to introduce certain delays in order to prevent unnecessary work from being performed, or to be able to retry a failed operation after a certain amount of time.

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Debouncing

One type of situation in which we might want to wait for a small amount of time before triggering a given pipeline is when our operations are based on some kind of free-form user input.

For example, let’s say that we’re building a controller that manages a list of items that are loaded from a Database, and that the user can choose to apply a string-based filter to the items that are being loaded.

To prevent too many database queries from being performed if the user rapidly types into the text field that our filter value is connected to, we could apply the debounce operator right before we perform our database call. That way, Combine will only continue executing our pipeline once no new values have come in for a certain amount of time (0,3 seconds in this case):

final class ItemListController: ObservableObject {
    @Published private(set) var items = [Item]()
    @Published var filter = ""

    init(database: Database) {
        $filter
            .removeDuplicates()
            .debounce(for: 0.3, scheduler: DispatchQueue.main)
            .map(database.loadItemsMatchingFilter)
            .switchToLatest()
            .assign(to: &$items)
    }
}

To learn more about the above technique, including why the switchToLatest operator is used, check out "Connecting and merging Combine publishers in Swift", which goes into much more detail on this topic.

Delayed retries

Like its name implies, Combine’s built-in retry operator lets us automatically retry a pipeline’s operations if an error was encountered. When using it, we simply have to specify the maximum amount of retries that we’d like to perform, and Combine will take care of the rest. Here we’re using that operator within a customized version of the standard Combine-powered URLSession data task API, which will let us automatically retry any failed network request a certain amount of times:

extension URLSession {
    func decodedDataTaskPublisher<T: Decodable>(
        for url: URL,
        retryCount: Int = 3,
        decodingResultAs resultType: T.Type = T.self,
        decoder: JSONDecoder = .init(),
        returnQueue: DispatchQueue = .main
    ) -> AnyPublisher<T, Error> {
        dataTaskPublisher(for: url)
            .map(\.data)
            .decode(type: T.self, decoder: decoder)
            .retry(retryCount)
            .receive(on: returnQueue)
            .eraseToAnyPublisher()
    }
}

However, with the above implementation, each retry will be performed instantly as soon as an error was encountered, but what if we instead wanted to apply a certain delay between each retried operation?

For that, let’s turn to Combine’s delay operator, which lets us introduce a fixed amount of delay between two operations. Since we’re only looking to delay our retries in this case, we’ll use the catch operator to create a separate pipeline that applies our desired delay to a constant Void output value, and then calls flatMap to trigger our upstream pipeline once more -- like this:

extension Publisher {
    func retry<T: Scheduler>(
        _ retries: Int,
        delay: T.SchedulerTimeType.Stride,
        scheduler: T
    ) -> AnyPublisher<Output, Failure> {
        self.catch { _ in
            Just(())
                .delay(for: delay, scheduler: scheduler)
                .flatMap { _ in self }
                .retry(retries > 0 ? retries - 1 : 0)
        }
        .eraseToAnyPublisher()
    }
}

Note that we have to subtract 1 from the passed number of retries, since our flatMap operator will always run at least once. However, we also have to be careful not to turn that number negative, since that will cause Combine to perform an infinite number of retries.

With the above in place, we can update our custom data task API from before to now look like this:

extension URLSession {
    func decodedDataTaskPublisher<T: Decodable>(
        for url: URL,
        retryCount: Int = 3,
        decodingResultAs resultType: T.Type = T.self,
        decoder: JSONDecoder = .init(),
        returnQueue: DispatchQueue = .main
    ) -> AnyPublisher<T, Error> {
        dataTaskPublisher(for: url)
            .map(\.data)
            .decode(type: T.self, decoder: decoder)
            .retry(retryCount, delay: 3, scheduler: returnQueue)
            .receive(on: returnQueue)
            .eraseToAnyPublisher()
    }
}

A three-second delay will now be applied between each retry, which is particularly useful in this case, since the user’s connection might’ve been temporarily offline when we first initiated our network call.

However, worth pointing out is that the above code sample is not meant to be a complete ready-to-use networking implementation, since we’d probably want to only retry when certain errors were encountered. For example, if we’re performing an authenticated network call and the user’s access token has become outdated, retrying such a call with the same parameters would just be a waste of battery and bandwidth.

To implement that kind of per-error logic, we could use the tryCatch operator instead, and then throw the errors that we don’t wish to perform a retry for. When doing that, our pipeline would immediately fail, and trigger whatever error handling that we’ve added at the call site.

Just like how we sometimes might want to introduce artificial delays within certain pipelines, there are also cases when we might want to completely defer a publisher’s execution until a subscriber was attached to it. This is exactly what the special Deferred publisher lets us do, which often becomes particularly useful when using Combine’s Future type.

For example, let’s say that we’re currently using Future to retrofit a FeaturedItemsLoader with Combine support -- by sending the promise closure that’s passed into our future to our previous, closure-based API as a completion handler:

extension FeaturedItemsLoader {
    var itemsPublisher: Future<[Item], Error> {
        Future { [weak self] promise in
            self?.loadItems(then: promise)
        }
    }
}

The above works perfectly fine if we want each loading operation to start immediately, and if we never want to retry such an operation. However, doing something like the following won’t actually work as expected:

featuredItemsLoader.itemsPublisher
    .retry(5)
    .replaceError(with: [])
    .sink { items in
        // Handle items
        ...
    }

The reason the above doesn’t work is because a Future is always only run once, and then caches its result regardless if it succeeded or failed -- meaning that even if the above pipeline will indeed be retried 5 times if an error was encountered, each of those retries will receive the exact same output from our Future-based itemsPublisher.

To fix that problem, let’s wrap our Future creation code within a Deferred publisher -- which will both defer the creation of our underlying publisher until a subscriber started requesting values from it, and will also let us properly retry our pipeline, since doing so will now cause a new Future instance to be created for each retry:

extension FeaturedItemsLoader {
    var itemsPublisher: AnyPublisher<[Item], Error> {
        Deferred {
            Future { [weak self] promise in
                self?.loadItems(then: promise)
            }
        }
        .eraseToAnyPublisher()
    }
}

However, while Deferred is incredibly useful, we shouldn’t necessarily use it every single time that we use a Future. Think of Deferred as the Combine equivalent of a lazy property -- it doesn’t make sense to make every single property lazy, but it’s a useful tool to have in our toolbox for when we want the characteristics that lazy evaluation gives us.

Support Swift by Sundell by checking out this sponsor:

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Conclusion

Just like how Combine’s pipeline-oriented design can be truly wonderful when it comes to setting up reactive data flows and observations, it can also make implementing things like precise timing and retries a bit challenging, but hopefully this article has provided you with a few insights on how to do just that.

If you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email. If you enjoyed this article and want to support my work, then two fantastic ways to do so are to either share this article with a friend, or to check out this week’s sponsor.

Thanks for reading!

SwiftUI’s built-in frame modifier can both be used to assign a static width or height to a given view, or to apply “constraints-like” bounds within which the view can grow or shrink depending on its contents and surroundings.

At the very basic level, this is what two common usages of the frame modifier could look like:

// A view that displays a 30x30 fixed-sized icon using an SFSymbol:
struct Icon: View {
    var name: String
    var tintColor: Color = .blue

    var body: some View {
        Image(systemName: name)
            .foregroundColor(tintColor)
            .frame(width: 30, height: 30)
    }
}

// A view that displays a decorative image that's resized according
// to its aspect ratio, with a maximum width of 200 points:
struct DecorativeImage: View {
    var name: String

    var body: some View {
        Image(name)
            .resizable()
            .aspectRatio(contentMode: .fit)
            .frame(maxWidth: 200)
    }
}

While the above two ways of using the frame modifier are both incredibly useful, sometimes we might not want to specify any kind of fixed metric when deciding how our views should be sized. Thankfully, there’s also a way to make a given view expand infinitely, which can come in handy in many different kinds of situations.

For example, let’s say that we’re working on a view that displays an array of categories as a two-column grid using SwiftUI’s LazyVGrid type:

Preview

struct CategoryGrid: View {
    var categories: [Category]

    var body: some View {
        LazyVGrid(columns: columns) {
            ForEach(categories) { category in
                Text(category.name)
                    .padding()
                    .background(category.color)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }
        }
        .padding()
    }

    private var columns: [GridItem] {
        let item = GridItem(.flexible(minimum: 50, maximum: .infinity))
        return [item, item]
    }
}

As you can see by using the above PREVIEW button, our grid currently doesn’t look that great, since each cell ends up being a different size based on the text that it’s rendering.

That might initially seem a little bit strange — given that we’re specifying that both of our columns should be flexible with an infinite max width — but since a Text view doesn’t stretch itself to fit its container, each view’s background color will just end up occupying the size of the text itself.

Thankfully, this is another problem that can easily be solved using the frame modifier in combination with the CGFloat.infinity constant that we also used above when creating the GridItem values representing our columns. By inserting such a modifier before rendering our background, we can now make our grid look much nicer:

Preview

struct CategoryGrid: View {
    var categories: [Category]

    var body: some View {
        LazyVGrid(columns: columns) {
            ForEach(categories) { category in
                Text(category.name)
                    .padding()
                    .frame(maxWidth: .infinity)
                    .background(category.color)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }
        }
        .padding()
    }

    ...
}

Once again, you can use the PREVIEW button to see what the above code sample looks like when rendered.

So applying the frame modifier with either an infinite max width or max height can be a great way to tell a given SwiftUI view to stretch itself to fill all available space on either the horizontal or vertical axis.

Let’s take a look at another example, in which we’ve built an InfoView that can be used to display a piece of information text along with a title. Our intent is for these info views to always be displayed across the entire width of the screen (minus some padding), which they most likely will on iPhones running in portrait orientation, but in landscape (or on iPads) there might not be enough text to cover the entire width of the screen:

Preview

struct InfoView: View {
    var title: String
    var text: String

    var body: some View {
        HStack(alignment: .top, spacing: 15) {
            Image(systemName: "info.circle")
            VStack(alignment: .leading, spacing: 10) {
                Text(title).font(.headline)
                Text(text)
            }
        }
        .padding()
        .foregroundColor(.white)
        .background(Color.blue)
        .cornerRadius(20)
    }
}

One way to fix that problem would be to use a Spacer to fill out the remaining horizontal space — which would effectively make our InfoView always render across the full width of its container. However, while spacers are truly an essential part of SwiftUI’s layout system, in this case, adding a Spacer to our view could actually end up breaking its portrait layout — since spacers always occupy a minimum amount of space by default, and since our HStack applies 15 points of spacing between each of its elements:

Preview

struct InfoView: View {
    ...

    var body: some View {
        HStack(alignment: .top, spacing: 15) {
            Image(systemName: "info.circle")
            VStack(alignment: .leading, spacing: 10) {
                Text(title).font(.headline)
                Text(text)
            }
            Spacer()
        }
        ...
    }
}

Like the above PREVIEW shows, because of our added Spacer, our text can no longer be rendered across all of our view’s available width.

This is once again another great use case for the frame modifier, which in this case can sort of act as a spacer if we not only specify infinity as its maxWidth, but also tell it to align its contents according to the leading edge — like this:

Preview

struct InfoView: View {
    ...

    var body: some View {
        HStack(alignment: .top, spacing: 15) {
            Image(systemName: "info.circle")
            VStack(alignment: .leading, spacing: 10) {
                Text(title).font(.headline)
                Text(text)
            }
            .frame(maxWidth: .infinity, alignment: .leading)
        }
        ...
    }
}

Note how we need to specify .leading as the alignment for both our VStack and its frame modifier, since the former aligns the stack’s content (or two texts), while the latter aligns the stack itself within its surrounding frame.

Of course, rather than using .infinity as our maxWidth, we could’ve also opted to specify a fixed value in order to prevent our view from stretching too much on larger devices, such as the iPad. But that’s a decision that’ll ultimately come down to what sort of design that we’re going for when implementing each view.

Support Swift by Sundell by checking out this sponsor:

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Localizing an app into multiple languages can often significantly boost its chances for success on the App Store, as many users tend to prefer using apps that support their own, native language.

However, while Apple does provide many APIs and other kinds of infrastructure for handling resources like localized strings, things can often get quite tricky if we want to incorporate some form of mixed styling into the strings that we render within our apps.

For example, let’s say that we’re working on an app that shows lists of new movies, and that we’d like to emphasize the word “New” within the title of one of our UIs. If our app wasn’t localized, then doing so would be quite straightforward — we could simply search the title string for that particular word and then treat it differently when rendering its label — but what if our app does indeed support multiple languages?

One approach on how to handle that type of situation would be to mark what part of each string that we wish to emphasize within our localized string files — like this:

// English
"NewMovies" = "**New** movies";

// Swedish
"NewMovies" = "**Nya** filmer";

// Polish
"NewMovies" = "**Nowe** filmy";

Looking at the above example, it might seem like another option could be to simply emphasize the first word within each string. However, that would be a quite fragile solution, since not all languages use the same word order, and what if we’d add some form of prefix to our strings in the future?

Next, we’re going to have to parse the above string format in order to turn each piece of text into either an NSAttributedString (for UIKIt-based UIs), or a SwiftUI Text instance.

To get started, let’s define a dedicated LocalizedString type, in which we’ll be able to implement all of the required logic. Initially, we could implement APIs for initializing an instance with a localized string key, as well as for resolving a raw String using the built-in NSLocalizedString function:

struct LocalizedString {
    var key: String

    init(_ key: String) {
        self.key = key
    }

    func resolve() -> String {
        NSLocalizedString(key, comment: "")
    }
}

extension LocalizedString: ExpressibleByStringLiteral {
    init(stringLiteral value: StringLiteralType) {
        key = value
    }
}

We also make it possible to express a LocalizedString value using a string literal, which will come very much in handy once we start to integrate our new type with both UIKit and SwiftUI.

With the above type in place, let’s now move on to our actual parsing and rendering, starting with NSAttributedString.

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Attributed strings

Like the name of the type implies, an NSAttributedString enables us to add rendering attributes to a plain String, which in this case make it possible for us to encode that certain parts of a given localized string should be emphasized.

To make that happen, let’s extend our LocalizedString type with a method that splits a given raw localized string into components using our chosen marker (**, Markdown-style), and then picks either a default or bold font depending on whether the index of a given component is even or odd:

extension LocalizedString {
    typealias Fonts = (default: UIFont, bold: UIFont)

    static func defaultFonts() -> Fonts {
        let font = UIFont.preferredFont(forTextStyle: .body)
        return (font, .boldSystemFont(ofSize: font.pointSize))
    }

    func attributedString(
        withFonts fonts: Fonts = defaultFonts()
    ) -> NSAttributedString {
        let components = resolve().components(separatedBy: "**")
        let sequence = components.enumerated()
        let attributedString = NSMutableAttributedString()

        return sequence.reduce(into: attributedString) { string, pair in
            let isBold = !pair.offset.isMultiple(of: 2)
            let font = isBold ? fonts.bold : fonts.default

            string.append(NSAttributedString(
                string: pair.element,
                attributes: [.font: font]
            ))
        }
    }
}

To learn more about the above use of tuples to define lightweight types, check out this article.

Using the above new API, we’ll now be able to render localized strings with mixed styling using UIKit classes like UILabel and UITextView, which both support attributed strings.

Now, before we continue by implementing a SwiftUI equivalent of the above functionality, let’s take a quick moment to refactor our actual string parsing and rendering logic into a reusable utility that we’ll be able to call from both implementations, as to avoid code duplication.

One way to do that would be to implement a generic, reduce-style rendering function that takes an initial result, as well as a handler that performs the actual string concatenation — for example like this:

private extension LocalizedString {
    func render<T>(
        into initialResult: T,
        handler: (inout T, String, _ isBold: Bool) -> Void
    ) -> T {
        let components = resolve().components(separatedBy: "**")
        let sequence = components.enumerated()

        return sequence.reduce(into: initialResult) { result, pair in
            let isBold = !pair.offset.isMultiple(of: 2)
            handler(&result, pair.element, isBold)
        }
    }
}

With the above in place, we can heavily simplify our NSAttributedString-based method from before, since it can now be focused on just annotating and combining the strings that were passed into its handler:

extension LocalizedString {
    ...

    func attributedString(
        withFonts fonts: Fonts = defaultFonts()
    ) -> NSAttributedString {
        render(
            into: NSMutableAttributedString(),
            handler: { fullString, string, isBold in
                let font = isBold ? fonts.bold : fonts.default

                fullString.append(NSAttributedString(
                    string: string,
                    attributes: [.font: font]
                ))
            }
        )
    }
}

With that little refactoring task finished, let’s now start implementing our SwiftUI-based string rendering.

SwiftUI texts

One somewhat “hidden” feature of SwiftUI’s Text type is that multiple text values can be directly concatenated using the add operator, just as if they were raw String values — which still preserves the styling of each individual instance.

So all that we have to do to add a SwiftUI-based rendering API to our LocalizedString type is to call our new render method, and to then combine each of strings that it gives us — like this:

extension LocalizedString {
    func styledText() -> Text {
        render(into: Text("")) { fullText, string, isBold in
            var text = Text(string)

            if isBold {
                text = text.bold()
            }

            fullText = fullText + text
        }
    }
}

Time to integrate

Next, to make both our UIKit and SwiftUI-based methods a bit easier to use, let’s also extend both UILabel and Text with convenience APIs that let us directly initialize a label using a LocalizedString value:

extension UILabel {
    convenience init(styledLocalizedString string: LocalizedString) {
        self.init(frame: .zero)
        attributedText = string.attributedString()
    }
}

extension Text {
    init(styledLocalizedString string: LocalizedString) {
        self = string.styledText()
    }
}

With the above in place, we can now use the fact that LocalizedString values can be expressed using string literals to create styled, localized labels using either SwiftUI or UIKit, simply by doing this:

// UIKit
UILabel(styledLocalizedString: "NewMovies")

// SwiftUI
Text(styledLocalizedString: "NewMovies")

Very nice! However, currently we’re always re-parsing each string every time that it’s requested, which might not be an issue if we’re not updating our UI too often, but let’s also explore how we could add caching to our implementation as well.

Caching

Since all of the strings that we’re parsing are loaded from a static resource (our localized strings file for the user’s current language), we should be able to cache them quite aggressively. One way to do that would be to use the Cache type that we built in “Caching in Swift”, and to then modify our render function so that it supports reading and writing from such a cache — like this:

private extension LocalizedString {
    static let attributedStringCache = Cache<String, NSMutableAttributedString>()
static let swiftUITextCache = Cache<String, Text>()

    func render<T>(
        into initialResult: @autoclosure () -> T,
        cache: Cache<String, T>,
        handler: (inout T, String, _ isBold: Bool) -> Void
    ) -> T {
        if let cached = cache.value(forKey: key) {
    return cached
}

        let components = resolve().components(separatedBy: "**")
        let sequence = components.enumerated()

        let result = sequence.reduce(into: initialResult()) { result, pair in
            let isBold = !pair.offset.isMultiple(of: 2)
            handler(&result, pair.element, isBold)
        }

        cache.insert(result, forKey: key)
        return result
    }
}

The reason we now mark our initialResult parameter with the @autoclosure attribute is to prevent it from being evaluated in case a cached value was found. To learn more, check out this article.

Note that our attributedStringCache stores NSMutableAttributedString instances, which is because that’s the type that we’re working with when calling render from our attributedString method. While there’s no real harm in using such mutable instances internally within our LocalizedString type, we should now definitely copy all attributed strings before returning them, as to prevent any accidental sharing of mutable state.

So let’s do that, while also updating both of our string rendering methods to support our new caching functionality:

extension LocalizedString {
    ...

    func attributedString(
        withFonts fonts: Fonts = defaultFonts()
    ) -> NSAttributedString {
        let string = render(
            into: NSMutableAttributedString(),
            cache: Self.attributedStringCache,
            handler: { fullString, string, isBold in
                ...
            }
        )

        return NSAttributedString(attributedString: string)
    }

    func styledText() -> Text {
        render(
            into: Text(""),
            cache: Self.swiftUITextCache,
            handler: { fullText, string, isBold in
                ...
            }
        )
    }
}

And with that final piece in place, our new LocalizedString API is finished, and we can now render fully localized, styled strings in a performant and predictable manner, using either SwiftUI or UIKit.

Supporting multiple styles, and HTML as an alternative

Of course, the system that we built in this article currently only supports turning parts of a string bold, but we could always continue iterating on it in case we wanted to add support for multiple kinds of styles, although that might require somewhat more sophisticated string parsing techniques.

For example, we could either use the open source Sweep library to identify ranges that should be styled with a given set of attributes, or use techniques like the ones that were covered in “String parsing in Swift” to make that happen.

Another option, which has its own set of tradeoffs, would be to render certain strings as HTML, which NSAttributedString actually has complete support for. That way, we could place any sort of HTML styles (such as <b> or <em>) within our localized strings and then turn them into fully renderable attributed strings like this:

extension LocalizedString {
    func attributedString() throws -> NSAttributedString {
        let data = Data(resolve().utf8)

        return try NSAttributedString(
            data: data,
            options: [
                .documentType: NSAttributedString.DocumentType.html,
                .characterEncoding: String.Encoding.utf8.rawValue
            ],
            documentAttributes: nil
        )
    }
}

However, one big downside of the above technique is that it requires our localized string files to contain HTML code (which could easily get malformed as multiple people, including external translators, might edit those files over time). Also, since we would be rendering those strings as if they were web clips, we’d then also have to style each such label using web technologies as well, which could quickly make our setup quite complex and hard to maintain.

Support Swift by Sundell by checking out this sponsor:

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Conclusion

Combining localization with dynamically rendered content or styles can at times be quite difficult — even something relatively simple as emphasizing parts of a given string can require a fair bit of code to implement. Hopefully this article has shown you a few tips and tricks on how that can be done, and perhaps the techniques covered can provide a starting point for building your own system for rendering styled, localized strings.

If you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email.

Thanks for reading!

Swift’s result builders feature is arguably one of the most interesting recent additions to the language, as it plays a core part in making SwiftUI’s declarative, DSL-like API work the way it does. In fact, result builders were first introduced as a semi-official language feature called “function builders” as part of the Swift 5.1 release that accompanied the introduction of SwiftUI, but has since been promoted into a proper part of the language as of Swift 5.4.

In this article, let’s take a closer look at how result builders work and how we can use them, as well as how they can give us some really valuable insights into how SwiftUI’s API operates under the hood.

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Setting things up

For me, one of the best ways to truly understand how a given Swift feature works is to actually build something with it, so that’s what we’ll do. As an example, let’s say that we’re working on an app that includes an API for defining various settings — using a Setting type that looks like this:

struct Setting {
    var name: String
    var value: Value
}

extension Setting {
    enum Value {
        case bool(Bool)
        case int(Int)
        case string(String)
        case group([Setting])
    }
}

The above example type uses associated enum values to ensure complete type safety even though various settings can contain different types of values. To learn more about that pattern, check out the Basics article about enums.

Since the above type includes support for nested settings (through its group value), we’re able to use it to construct hierarchies. For example, here we’ve created a dedicated group for all of our settings that are considered experimental:

let settings = [
    Setting(name: "Offline mode", value: .bool(false)),
    Setting(name: "Search page size", value: .int(25)),
    Setting(name: "Experimental", value: .group([
        Setting(name: "Default name", value: .string("Untitled")),
        Setting(name: "Fluid animations", value: .bool(true))
    ]))
]

While there’s certainly nothing really wrong with the above API (in fact, it’s quite nice!), let’s see what it could end up looking like if we were to give it a “result builders makeover” — which in turn could let us transform it into more of a DSL, similar to what SwiftUI offers.

The basics of how result builders work

Like its name implies, Swift’s result builders feature essentially lets us build a result by combining multiple expressions into a single value. Within SwiftUI, that’s used to transform the contents of one of its many containers (such as HStack or VStack) into a single enclosing view, which can be seen by calling the type(of:) function on such a container instance:

import SwiftUI

let stack = VStack {
    Text("Hello")
    Text("World")
    Button("I'm a button") {}
}

// Prints 'VStack<TupleView<(Text, Text, Button<Text>)>>'
print(type(of: stack))

In general, anytime we see TupleView when using SwiftUI, that means that a result builder has been used to combine multiple views into one.

SwiftUI uses a number of different result builder implementations, such as ViewBuilder and SceneBuilder, but since we’re not able to look into the source code for those types, let’s instead build our own result builder for the settings API that we took a look at above.

Just like a property wrapper, a result builder is implemented as a normal Swift type that’s annotated with a special attribute — @resultBuilder in this case. Then, specific method names are used to implement its various capabilities. For example, a method named buildBlock with zero arguments is used to build the result of an empty function or closure:

@resultBuilder
struct SettingsBuilder {
    static func buildBlock() -> [Setting] { [] }
}

The return type of the above function (an array of Setting values in our case) then determines the type of function or closure that our builder can be applied to. For example, we might choose to implement our top-level settings API as a global function that applies our new SettingsBuilder to any closure that was passed into it — like this:

func makeSettings(@SettingsBuilder _ content: () -> [Setting]) -> [Setting] {
    content()
}

With the above in place, we can now call makeSettings with an empty trailing closure and we’ll get an empty array back:

let settings = makeSettings {}

While our new API is not yet very useful, it’s already showed us a few aspects of how result builders work. But now, let’s actually start building some proper results.

Combining multiple values into a single result

To enable our SettingsBuilder to accept input, all that we have to do is to declare additional overloads of buildBlock with arguments matching the input that we’re looking to receive. In our case, we’ll simply implement a single method that accepts a list of Setting values, which we’ll then return as an array — like this:

extension SettingsBuilder {
    static func buildBlock(_ settings: Setting...) -> [Setting] {
        settings
    }
}

Above we’re using a variadic argument list, which SwiftUI can’t currently use, since its View protocol contains an associated type. Instead, SwiftUI’s ViewBuilder defines 10 different overloads of buildBlock, each with a different number of arguments — which is why a SwiftUI view can’t have more than 10 children. However, that limitation does not apply to our SettingsBuilder.

With that new buildBlock overload in place, we’ll now be able to fill any closure that we’re passing to makeSettings with Setting values, and our result builder (with some help from the compiler) will combine all of those expressions into an array, which is then returned:

let settings = makeSettings {
    Setting(name: "Offline mode", value: .bool(false))
    Setting(name: "Search page size", value: .int(25))

    Setting(name: "Experimental", value: .group([
        Setting(name: "Default name", value: .string("Untitled")),
        Setting(name: "Fluid animations", value: .bool(true))
    ]))
}

While the above is arguably already a slight improvement over the inline array that we were previously using, let’s continue to take inspiration from SwiftUI, and also add a result builder-powered API for defining groups. To make that happen, let’s start by defining a new SettingsGroup type that also annotates a closure (this time stored in a property) with the @SettingsBuilder attribute in order to connect it to our result builder:

struct SettingsGroup {
    var name: String
    @SettingsBuilder var settings: () -> [Setting]
}

An alternative approach would’ve been to instead implement a custom initializer (rather than relying on Swift’s memberwise initializers feature) and to then immediately call our settings closure and store its result, rather than storing a reference to the closure itself. That has the benefit of avoiding having to make our closure escaping at the cost of a slightly more verbose implementation that could prove to be a bit more performant, but also less flexible (as the closure will now only be called once, up front):

struct SettingsGroup {
    var name: String
    var settings: [Setting]

    init(name: String,
         @SettingsBuilder builder: () -> [Setting]) {
        self.name = name
        self.settings = builder()
    }
}

With either of the above two implementations in place (let’s go with the first one for now), we’re now able to define groups the exact same way as when defining top-level settings — by simply expressing each nested Setting within a closure, like this:

SettingsGroup(name: "Experimental") {
    Setting(name: "Default name", value: .string("Untitled"))
    Setting(name: "Fluid animations", value: .bool(true))
}

However, if we actually try to place the above group within our makeSettings closure, we’ll end up getting a compiler error — since our result builder’s buildBlock method currently expects a variadic list of Setting values, and our new SettingsGroup is a completely different type.

To fix that issue, let’s introduce a thin abstraction that can be shared between both Setting and SettingsGroup, for example in the shape of a protocol that lets us convert any instance of those types into an array of Setting values:

protocol SettingsConvertible {
    func asSettings() -> [Setting]
}

extension Setting: SettingsConvertible {
    func asSettings() -> [Setting] { [self] }
}

extension SettingsGroup: SettingsConvertible {
    func asSettings() -> [Setting] {
        [Setting(name: name, value: .group(settings()))]
    }
}

Then, we simply have to modify our result builder’s buildBlock implementation to accept SettingsConvertible instances, rather than concrete Setting values, and we’ll then flatten that new argument list using flatMap:

extension SettingsBuilder {
    static func buildBlock(_ values: SettingsConvertible...) -> [Setting] {
        values.flatMap { $0.asSettings() }
    }
}

With the above in place, we can now define all of our settings in a very “SwiftUI-like” way, by constructing groups just like how we’d organize our various SwiftUI views using stacks and other containers:

let settings = makeSettings {
    Setting(name: "Offline mode", value: .bool(false))
    Setting(name: "Search page size", value: .int(25))

    SettingsGroup(name: "Experimental") {
        Setting(name: "Default name", value: .string("Untitled"))
        Setting(name: "Fluid animations", value: .bool(true))
    }
}

Really nice! So the buildBlock overloads that a given result builder contains directly determines what type of expressions that we’ll be able to place within each closure or function that has been annotated to use that builder.

Conditionals

Next, let’s take a look at how we can add support for evaluating conditionals within our result builder-powered closures. Initially, it might seem like that should “just work”, given that Swift itself supports all kinds of different conditionals. However, that’s not the case — so with our current SettingsBuilder implementation we’ll end up getting a compiler error if we try to do something like this:

let shouldShowExperimental: Bool = ...

let settings = makeSettings {
    Setting(name: "Offline mode", value: .bool(false))
    Setting(name: "Search page size", value: .int(25))

    // Compiler error: Closure containing control flow statement
    // cannot be used with result builder 'SettingsBuilder'.
    if shouldShowExperimental {
        SettingsGroup(name: "Experimental") {
            Setting(name: "Default name", value: .string("Untitled"))
            Setting(name: "Fluid animations", value: .bool(true))
        }
    }
}

The above example once again shows us that the code that’s being executed within a result builder-annotated closure isn’t treated the same way as “normal” Swift code — as each expression needs to be explicitly handled by our builder, including conditionals like if statements.

To add that sort of handling code, we’ll need to implement the buildIf method, which is what the compiler will map each stand-alone if statement to. Since each such statement can evaluate to either true or false, we’ll get its body expression passed as an optional — which in our case will look like this:

// Here we extend Array to make it conform to our SettingsConvertible
// protocol, in order to be able to return an empty array from our
// 'buildIf' implementation in case a nil value was passed:
extension Array: SettingsConvertible where Element == Setting {
    func asSettings() -> [Setting] { self }
}

extension SettingsBuilder {
    static func buildIf(_ value: SettingsConvertible?) -> SettingsConvertible {
        value ?? []
    }
}

With the above in place, our if statement from before now works just as we’d expect. But let’s also add support for combined if/else statements, which can be done by implementing two overloads of the buildEither method — one with the parameter label first, and one with second, each corresponding to the first and second branch of a given if/else statement:

extension SettingsBuilder {
    static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
        first
    }

    static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
        second
    }
}

We’ll now be able to add an else clause to our if statement from before, for example in order to let users request access to our app’s experimental settings if those are not yet shown:

let settings = makeSettings {
    Setting(name: "Offline mode", value: .bool(false))
    Setting(name: "Search page size", value: .int(25))

    if shouldShowExperimental {
        SettingsGroup(name: "Experimental") {
            Setting(name: "Default name", value: .string("Untitled"))
            Setting(name: "Fluid animations", value: .bool(true))
        }
    } else {
        Setting(name: "Request experimental access", value: .bool(false))
    }
}

Finally, those buildEither methods that we just implemented now (as of Swift 5.3) also enable switch statements to be used within result builder contexts, without requiring any additional build methods.

So for example, let’s say that we’re looking to refactor our above shouldShowExperimental boolean into an enum, in order to support multiple access levels. We could then simply switch on that enum within our makeSettings closure, and the Swift compiler will automatically route those expressions into our buildEither methods from before:

enum UserAccessLevel {
    case restricted
    case normal
    case experimental
}

let accesssLevel: UserAccessLevel = ...

let settings = makeSettings {
    Setting(name: "Offline mode", value: .bool(false))
    Setting(name: "Search page size", value: .int(25))

    switch accesssLevel {
    case .restricted:
        Setting.Empty()
    case .normal:
        Setting(name: "Request experimental access", value: .bool(false))
    case .experimental:
        SettingsGroup(name: "Experimental") {
            Setting(name: "Default name", value: .string("Untitled"))
            Setting(name: "Fluid animations", value: .bool(true))
        }
    }
}

One additional thing worth noting about the above code is that we’re using a new Setting.Empty type within our switch statement’s .restricted case. That’s because we’re not (yet) able to use the break keyword within a result builder switch statement, so we’ll need to express some kind of value within each code branch. So just like how SwiftUI has EmptyView, our new Settings API now has a Setting.Empty type for those kinds of situations:

extension Setting {
    struct Empty: SettingsConvertible {
        func asSettings() -> [Setting] { [] }
    }
}

And with that, our new result builder-powered settings API is now finished! It’s really quite fascinating just how little code that’s required to build a SwiftUI-like DSL using this new language feature.

Support Swift by Sundell by checking out this sponsor:

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Conclusion

With features like property wrappers and result builders, Swift is moving into some very interesting new territories, by enabling us to add our own logic to various fundamental language mechanisms — like how expressions are evaluated, or how properties are assigned and stored.

Granted, those new features do also make Swift more complicated, even though (at least in the best of worlds), they could also let library designers — both at Apple and in the wider developer community — hide that complexity behind well-formed APIs.

What do you think? Are you looking forward to using result builders within your own code, and did you gain some additional insight into how SwiftUI’s API works by reading this article? If so, feel free to share it, and you’re also more than welcome to contact me (either via Twitter or email) if you have any questions, comments, or feedback.

Thanks for reading! 🚀

Generating formatted string representations of various kinds of values can often be quite tricky, especially if we want those strings to be fully adapted to the user’s language, locale and other system-wide preferences.

Thankfully, Apple ships a quite comprehensive suite of fully localized formatters as part of each of their platforms, and while we’ve already taken a look at the most commonly used among those — like DateFormatter and NumberFormatter — in this article, let’s instead explore some of the lesser-known Formatter subclasses, and how they can prove to be incredibly useful in certain situations.

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Names of people

If there’s one thing that all Formatter types that come built into the system have in common is that they’re all performing tasks that are much more complicated than what they initially might seem like.

Take user names, or names of people in general, as an example. Let’s say that we’re working on an app that stores each user’s full name using a single fullName property defined within a User data model — like this:

struct User {
    var fullName: String
    ...
}

Then, let’s say that we’re currently making the assumption that if we split a given user’s fullName string into space-separated components, then the first component will always be the user’s “first name” — which we then use as that user’s “display name” across our app’s UI:

extension User {
    func displayName() -> String {
        String(fullName.split(separator: " ")[0])
    }
}

The above is an incredibly common mistake to make. Not only does the preferred order of a name’s various components differ between different languages, countries, and cultures around the world — names can also often have many more components than just “first name” and “last name”, which our code currently doesn’t account for.

For example, what if a user entered “Dr. John Appleseed” as their full name? Then that user’s display name would currently be computed as “Dr.”. Not great.

Thankfully, this is a problem that our friends at Apple have already solved. Enter PersonNameComponentsFormatter, which handles all of the complexities involved in correctly parsing and formatting a person’s name. Here’s how we could update our displayName method to use that formatter instead:

extension User {
    func displayName() -> String {
        let formatter = PersonNameComponentsFormatter()
        let components = formatter.personNameComponents(from: fullName)
        return components?.givenName ?? name
    }
}

Not only will the above new version yield results that are much more correct regardless of the user’s name or locale, but the intent of our code is now arguably much more clear as well.

PersonNameComponentsFormatter also enables us to turn a set of name components into a fully localized name as well, which can be incredibly useful when dealing with user names that are already split up into separate components — like this:

struct User {
    var firstName: String
    var lastName: String
    ...
}

extension User {
    func fullName() -> String {
        let formatter = PersonNameComponentsFormatter()

        var components = PersonNameComponents()
        components.givenName = firstName
        components.familyName = lastName

        return formatter.string(from: components)
    }
}

The reason that we’ve implemented all of our name computation code as methods, rather than computed properties, is to clearly show that our logic requires some amount of processing, since it’s not just returning a value that can be computed in O(1) time. To learn more about that approach, check out “Computed properties in Swift”.

Addresses

Next, let’s take a look at a Formatter type that ships as part of the Contacts framework — CNPostalAddressFormatter, which provides an easy way to format addresses into localized strings.

Just like names, the way addresses are supposed to be formatted varies a lot between different countries, and handling all of that complexity ourselves would be quite overwhelming.

As an example, let’s say that we’re working on some form of shopping app that contains the following ShippingAddress type:

struct ShippingAddress {
    var street: String
    var postalCode: String
    var city: String
    var country: String
}

If we now wanted to generate a formatted string representation of such an address (for example to show the user what address that a given product will be shipped to), then all that we have to do is to convert our shipping address data into a CNPostalAddress instance (which can be done using its mutable counterpart, CNMutablePostalAddress), and then ask CNPostalAddressFormatter to convert that instance into a string — like this:

import Contacts

extension ShippingAddress {
    func formattedString() -> String {
        let formatter = CNPostalAddressFormatter()

        let address = CNMutablePostalAddress()
        address.street = street
        address.postalCode = postalCode
        address.city = city
        address.country = country

        return formatter.string(from: address)
    }
}

Of course, if we’re dealing with addresses retrieved using the Contacts framework itself, then those will already be represented using CNPostalAddress instances, so the above type conversion is only necessary when working with a custom way of storing addresses.

Relative time

Although the standard DateFormatter type is quite well-known and commonly used within all sorts of applications, it also has a somewhat lesser-known “cousin” called RelativeDateTimeFormatter which can be used to generate localized strings that describe the relative time interval between two dates.

For example, here’s how we could use that specialized formatter to compute a string that tells the user how much time that’s left until a given Event starts:

struct Event {
    var title: String
    var startDate: Date
    ...
}

extension Event {
    func relativeTimeString() -> String {
        let formatter = RelativeDateTimeFormatter()
        formatter.dateTimeStyle = .named
        formatter.formattingContext = .beginningOfSentence
        return formatter.localizedString(for: startDate, relativeTo: Date())
    }
}

What’s really cool is that by specifying that we want to use the named date time style (like we do above), words like “Tomorrow” and “Yesterday” will be used to describe intervals that have specific names.

Lists

Finally, let’s take a quick look at ListFormatter, which perhaps isn’t as complex as some of the other formatters that we’ve explored so far, but it can still be useful in certain situations.

Essentially, ListFormatter enables us to concatenate an array of strings into a single, localized list-like string. Using it is as easy as passing the array of strings that we wish to join to its static localizedString method, and it’ll then return a formatted string based on the user’s locale and language settings:

// In English:

let ingredientsList = ListFormatter.localizedString(
    byJoining: ["Apples", "Sugar", "Flour", "Butter"]
)

print(ingredientsList) // "Apples, Sugar, Flour, and Butter"

// In Swedish:

let ingredientsList = ListFormatter.localizedString(
    byJoining: ["Äpplen", "Socker", "Mjöl", "Smör"]
)

print(ingredientsList) // "Äpplen, Socker, Mjöl och Smör"

Note how the English and Swedish versions doesn’t just differ in terms of language, but also in how commas are used. Those kinds of details might seem insignificant, but can really make an app feel much more thoroughly localized — and once again, we didn’t have to write any custom code to account for those variances — it’s all handled for us by the system.

Support Swift by Sundell by checking out this sponsor:

Architecting SwiftUI apps with MVC and MVVM: Although you can create an app simply by throwing some code together, without best practices and a robust architecture, you’ll soon end up with unmanageable spaghetti code. Learn how to create solid and maintainable apps with fewer bugs using this free guide.

Conclusion

It’s very clear that Apple’s dedication to high-quality localization isn’t just limited to their own apps and system features — their various platform SDKs also ship with numerous APIs, tools and features that we can use to elevate the localization of our own apps as well. All that we have to do is to use the right APIs when dealing with locale-dependent values — such as names, numbers, addresses and dates.

Hopefully this article has given you a few insights on how to do just that, and feel free to reach out via either Twitter or email if you have any questions or comments.

Thanks for reading!