To say that SwiftUI’s List is the equivalent of UIKit’s UITableView is both true and false at the same time. It’s definitely true that List offers a built-in way to construct list-based UIs that are rendered using the same overall appearance as when using UITableView — however, when it comes to mutations, we instead have to turn to SwiftUI’s core engine for constructing and managing views based on collections of data — the ForEach type.

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Moving and deleting

In general, list editing typically involves two separate kinds of edits — item-specific and list-wide ones. To start with the first variant, here’s an example using the list binding syntax that was introduced in Swift 5.5 — in which we’re rendering a TodoList view that enables the user to directly edit the text of each item using a TextField:

struct TodoItem: Identifiable {
    let id: UUID
    var title: String
}

struct TodoList: View {
    @Binding var items: [TodoItem]

    var body: some View {
        NavigationView {
            VStack {
                List {
    ForEach($items) { $item in
        TextField("Title", text: $item.title)
    }
}
                TodoItemAddButton { newItem in
                    items.append(newItem)
                }
            }
            .navigationTitle("Todo list")
        }
    }
}

In this example, our array of TodoItem models is stored outside of our view and is then passed in using a Binding. To learn more about that pattern, check out this guide to SwiftUI’s state management system.

Now let’s say that we wanted to add support for list-wide mutations as well — specifically moves and deletions. The good news is that SwiftUI ships with built-in modifiers for both of those tasks, but it turns out that they’re not available on the List type itself, but rather only on ForEach.

That’s because, in SwiftUI, List can sort of be seen more as a styling component, rather than as a view responsible for managing a collection of subviews. So whenever we wish to mutate such a collection, we need to work directly with ForEach — like this:

struct TodoList: View {
    @Binding var items: [TodoItem]

    var body: some View {
        NavigationView {
            VStack {
                List {
                    ForEach($items) { $item in
                        TextField("Title", text: $item.title)
                    }
                    .onMove { indexSet, offset in
    items.move(fromOffsets: indexSet, toOffset: offset)
}
.onDelete { indexSet in
    items.remove(atOffsets: indexSet)
}
                }
                ...
            }
            .navigationTitle("Todo list")
        }
    }
}

However, even though our list now technically supports both moves and deletions, there’s currently no way for the user to enter “edit mode” to start moving items. To address that, let’s use the toolbar modifier to insert an instance of SwiftUI’s built-in EditButton into our app’s navigation bar:

struct TodoList: View {
    @Binding var items: [TodoItem]

    var body: some View {
        NavigationView {
            VStack {
                ...
            }
            .navigationTitle("Todo list")
            .toolbar { EditButton() }
        }
    }
}

Note that if you’re working on an iOS app that needs to support iOS 13, you’ll need to use the now deprecated navigationBarItems modifier instead, since the toolbar API was introduced in iOS 14 (and the rest of Apple’s 2020 operating systems).

With that change in place, we now have a fully editable list that supports both inline item edits, as well as list-wide moves and deletions. Really nice!

A reusable abstraction

Depending on what kind of app that we’re working on, we might need to build multiple lists that each should support the above set of editing features — and while it’s certainly possible to accomplish that by simply copying and pasting the modifiers and EditButton code that we just added to our TodoList, it would arguably be much nicer to instead have some form of editable list that we could easily reuse across our code base.

So, let’s build one! Thankfully, because SwiftUI was designed with such a heavy emphasis on composition, implementing a completely reusable EditableList type simply involves moving our previous editing code into that new view’s body, and then adding an initializer that’ll let us inject the data that we wish to render, as well as a closure for constructing the view for each item within our list:

struct EditableList<Element: Identifiable, Content: View>: View {
    @Binding var data: [Element]
    var content: (Binding<Element>) -> Content

    init(_ data: Binding<[Element]>,
         content: @escaping (Binding<Element>) -> Content) {
        self._data = data
        self.content = content
    }

    var body: some View {
        List {
            ForEach($data, content: content)
                .onMove { indexSet, offset in
                    data.move(fromOffsets: indexSet, toOffset: offset)
                }
                .onDelete { indexSet in
                    data.remove(atOffsets: indexSet)
                }
        }
        .toolbar { EditButton() }
    }
}

Note that we don’t strictly need to implement a custom initializer for the above type (unless we want to vend it as public, outside of the module it was defined in), but the benefit of doing so is that our EditableList API now works the same way as SwiftUI’s built-in List, which will make switching between the two much easier.

With the above new type in place, all that we now have to do when we wish to render an editable list is to create an EditableList instance with the array that we want to enable our users to edit — like this:

struct TodoList: View {
    @Binding var items: [TodoItem]

    var body: some View {
        NavigationView {
            VStack {
                EditableList($items) { $item in
    TextField("Title", text: $item.title)
}
                TodoItemAddButton { newItem in
                    items.append(newItem)
                }
            }
            .navigationTitle("Todo list")
        }
    }
}

Really neat! Another benefit of encapsulating our list editing code within a stand-alone type is that we’ll now be able to keep adding editing features in a single location, and all of our editable lists will then get those features for free. For example, we might want to add support for drag and drop, sorting, and so on.

Alright, it’s time for the bonus round! While the above EditableList implementation works perfectly fine as long as our list data always comes in the form of an Array, it would arguably be nice to also make it support any Collection type that List and ForEach are capable of working with (including custom ones).

To make that happen, we’re going to have to change our generic Element type to instead refer to any Data collection that conforms to the same set of standard library protocols that SwiftUI requires to make our list editable. This implementation will have to require iOS 15, though, since SwiftUI’s Binding type gained support for the standard library’s RandomAccessCollection protocol in that OS version:

@available(iOS 15, *)
struct EditableList<
    Data: RandomAccessCollection & MutableCollection & RangeReplaceableCollection,
    Content: View
>: View where Data.Element: Identifiable {
    @Binding var data: Data
    var content: (Binding<Data.Element>) -> Content

    init(_ data: Binding<Data>,
         content: @escaping (Binding<Data.Element>) -> Content) {
        self._data = data
        self.content = content
    }

    var body: some View {
        List {
            ForEach($data, content: content)
                .onMove { indexSet, offset in
                    data.move(fromOffsets: indexSet, toOffset: offset)
                }
                .onDelete { indexSet in
                    data.remove(atOffsets: indexSet)
                }
        }
        .toolbar { EditButton() }
    }
}

We now have a completely generic EditableList implementation that can be used with any compatible collection — with the caveat that it’s only compatible with iOS 15 and later. But, if we need to support earlier iOS versions as well, we could likely just use our previous Array-based version, which is fully backward compatible.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Conclusion

List is arguably one of the most polarizing SwiftUI views. On one hand, it provides a lot of built-in functionality that enables us to relatively easily build lists that look and behave exactly like the ones found throughout Apple’s own apps, as well as iOS itself.

However, although List has become much more flexible since it was introduced in 2019, building completely custom-looking lists using it is still quite difficult. So, for those use cases we’ll likely have to fall back to either UIKit or AppKit, depending on what platform that we’re targeting. Still, even though it might be limited when it comes to its visuals, List is an incredibly useful and powerful part of SwiftUI.

I hope that this article has given you a few insights into exactly what kind of editing capabilities that SwiftUI’s List and ForEach types support, and if you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

As a general rule of thumb, all of the APIs and system features that Apple introduces in a given version of iOS can only be used when targeting that particular version, or any subsequent ones.

However, this year there are a few very interesting exceptions to that rule, in that certain SwiftUI APIs that were introduced in iOS 15 can actually be used and deployed all the way back to iOS 13. Let’s take a look at what some of those APIs are and how come it’s possible for them to be fully backward compatible.

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Static styling

A very neat syntax improvement this year is that we can now refer to instances of SwiftUI’s various styling protocols using static APIs, rather than having to explicitly instantiate those values. For example, here’s a before-and-after comparison between using the old and new syntax when applying a ListStyle to a SwiftUI List:

// Before:

List(items) { item in
    ...
}
.listStyle(GroupedListStyle())

// After:

List(items) { item in
    ...
}
.listStyle(.grouped)

The above is using a new Swift language feature which enables us to define static protocol APIs that can be used to create instances that conform to that protocol (see this article for more information). But how come Apple is able to make SwiftUI’s implementation of that new language feature backward compatible with earlier OS versions?

Always emit into client

This is where a relatively new attribute called _alwaysEmitIntoClient comes in, which enables framework authors to tell the Swift compiler to emit the implementation of a given function, computed property, or subscript into the binary that is consuming that framework. This new attribute is part of Swift’s library evolution effort, which aims to provide a set of tools for smoothly evolving framework and library APIs over time.

While this is still an underscored attribute (which, in the world of Apple API design basically means “technically public, but shouldn’t be considered public”), it’s what makes it possible for us to use the above new styling APIs on older operating system versions — since by annotating those APIs with @_alwaysEmitIntoClient, Apple is telling the compiler to embed the implementation of those APIs within our app binary, rather than linking to implementations provided by the OS.

Bindable list elements

Another new List (and ForEach) capability that’s fully backward compatible is how we can now create lists that contain Binding references to the collection elements that are being rendered.

Previously, this required quite a lot of code to implement reliably, but now, we can create bindable list elements using the same $-prefixing syntax that we use when referencing other bindings — like this:

struct TodoList: View {
    @Binding var items: [Item]

    var body: some View {
        List($items) { $item in
            TextField("Item", text: $item.text)
        }
    }
}

Neat! Just like the styling APIs that we took a look at earlier, the above new feature is backward compatible thanks to a combination of new Swift compiler capabilities and @_alwaysEmitIntoClient annotations.

Replacing single-view arguments with view builder closures

Finally, let’s take a look at how we can now use the full power of SwiftUI’s ViewBuilder API when creating certain built-in views that previously required us to pass some of its View-based arguments as separate values. For example, here’s how we can now use a ViewBuilder closure when creating the destination for a NavigationLink:

// Before:

NavigationLink(
    article.title,
    destination: ArticleView(article: article)
)

// After:

NavigationLink(article.title) {
    ArticleView(article: article)
}

Not only can the above new closure-based API make our code easier to read (especially when we wish to apply modifiers directly to the view that’s being passed as an argument), but it also enables us to use any ViewBuilder-compatible expression when computing our arguments. For example, here’s how we could now easily return separate views for a navigation link’s destination depending on what data that it’ll represent:

NavigationLink(article.title) {
    if article.isFeatured {
        FeaturedArticleView(article: article)
    } else {
        ArticleView(article: article)
    }
}

Other views that have been upgraded with similar, fully backward compatible APIs include Section (which now accepts ViewBuilder-powered closures for its header and footer arguments), and Picker (which now lets us use a closure when constructing its label).

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Conclusion

I’m really happy to see Apple start exploring the idea of making certain new APIs backward compatible with earlier OS versions, as that lets us third party developers take advantage of those new system features without requiring us to increase our minimum deployment target, or use availability checks.

Granted, these backward compatible APIs don’t include any brand new components, or any new user-facing functionality — but just like how most new Swift language features enable us to evolve our code without breaking backward compatibility, these new APIs should let us improve our SwiftUI-based code in somewhat significant ways — especially when working with bindable list elements.

Let me know what you think, and feel free to ask me any questions or send me feedback, by reaching out via email.

Thanks for reading!

By default, the various navigation APIs that SwiftUI provides are very much centered around direct user input — that is, navigation that’s handled by the system in response to events like button taps and tab switching.

However, sometimes we might want to take more direct control over how an app’s navigation is performed, and although SwiftUI still isn’t nearly as flexible as UIKit or AppKit in this regard, it does offer quite a few ways for us to perform completely programmatic navigation within the views that we build.

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Switching tabs

Let’s start by taking a look at how we can take control over what tab that’s currently displayed within a TabView. Normally, tabs are switched whenever the user manually taps an item within each tab bar, but by injecting a selection binding into a given TabView, we can both observe and control what tab that’s currently displayed. Here we’re doing just that to switch between two tabs that are tagged using the integers 0 and 1:

struct RootView: View {
    @State private var activeTabIndex = 0

    var body: some View {
        TabView(selection: $activeTabIndex) {
            Button("Switch to tab B") {
                activeTabIndex = 1
            }
            .tag(0)
            .tabItem { Label("Tab A", systemImage: "a.circle") }

            Button("Switch to tab A") {
                activeTabIndex = 0
            }
            .tag(1)
            .tabItem { Label("Tab B", systemImage: "b.circle") }
        }
    }
}

What’s really great, though, is that we’re not just limited to using integers when identifying and switching tabs. Instead, we can freely represent each tab using any Hashable value — for example by using as an enum that contains cases for each tab that we’re looking to display. We could then encapsulate that piece of state within an ObservableObject that we’ll be able to easily inject into our view hierarchy’s environment:

enum Tab {
    case home
    case search
    case settings
}

class TabController: ObservableObject {
    @Published var activeTab = Tab.home

    func open(_ tab: Tab) {
        activeTab = tab
    }
}

With the above in place, we can now tag each of the views within our TabView using our new Tab type, and if we then inject our TabController into our view hierarchy’s environment, then any view within it will be able to switch which tab that’s displayed at any time:

struct RootView: View {
    @StateObject private var tabController = TabController()

    var body: some View {
        TabView(selection: $tabController.activeTab) {
            HomeView()
                .tag(Tab.home)
                .tabItem { Label("Home", systemImage: "house") }

            SearchView()
                .tag(Tab.search)
                .tabItem { Label("Search", systemImage: "magnifyingglass") }

            SettingsView()
                .tag(Tab.settings)
                .tabItem { Label("Settings", systemImage: "gearshape") }
        }
        .environmentObject(tabController)
    }
}

For example, here’s how our HomeView could now switch to the settings tab using a completely custom button — it just needs to obtain our TabController from the environment, and it can then call the open method to perform its tab switch — like this:

struct HomeView: View {
    @EnvironmentObject private var tabController: TabController

    var body: some View {
        ScrollView {
            ...
            Button("Open settings") {
                tabController.open(.settings)
            }
        }
    }
}

Neat! Plus, since TabController is an object that’s under our complete control, we could also use it to switch tabs from outside our main view hierarchy as well. For example, we might want to switch tabs in response to a push notification or some other kind of server event, which could now be done simply by calling the same open method that we’re using within the above view code.

To learn more about environment objects, and the rest of SwiftUI’s state management system, check out this guide.

Controlling navigation stacks

Just like tab views, SwiftUI’s NavigationView can also be controlled programmatically as well. For example, let’s say that we’re working on an app that shows a CalendarView as the root view within its main navigation stack, and that the user can then open a CalendarEditView by tapping an edit button located within the app’s navigation bar. To connect those two views, we’re using a NavigationLink, which automatically pushes a given view onto the navigation stack whenever it was tapped:

struct RootView: View {
    @ObservedObject var calendarController: CalendarController

    var body: some View {
        NavigationView {
            CalendarView(
                calendar: calendarController.calendar
            )
            .toolbar {
                ToolbarItem(placement: .navigationBarTrailing) {
                    NavigationLink("Edit") {
    CalendarEditView(
        calendar: $calendarController.calendar
    )
    .navigationTitle("Edit your calendar")
}
                }
            }
            .navigationTitle("Your calendar")
        }
        .navigationViewStyle(.stack)
    }
}

In this case, we’re using the stack navigation style on all devices, even iPads, rather than letting the system pick which navigation style to use.

Now let’s say that we wanted to enable our CalendarView to programmatically display its edit view, without having to construct a separate instance of it. To do that, we could inject an isActive binding into our edit button’s NavigationLink, which we then pass into our CalendarView as well — like this:

struct RootView: View {
    @ObservedObject var calendarController: CalendarController
    @State private var isEditViewShown = false

    var body: some View {
        NavigationView {
            CalendarView(
                calendar: calendarController.calendar,
                isEditViewShown: $isEditViewShown
            )
            .toolbar {
                ToolbarItem(placement: .navigationBarTrailing) {
                    NavigationLink("Edit", isActive: $isEditViewShown) {
                        CalendarEditView(
                            calendar: $calendarController.calendar
                        )
                        .navigationTitle("Edit your calendar")
                    }
                }
            }
            .navigationTitle("Your calendar")
        }
        .navigationViewStyle(.stack)
    }
}

If we now also update CalendarView to so that it accepts the above value using an @Binding-marked property, then we can now simply set that property to true whenever we’d like to display our edit view, and our root view’s NavigationLink will automatically be triggered:

struct CalendarView: View {
    var calendar: Calendar
    @Binding var isEditViewShown: Bool

    var body: some View {
        ScrollView {
            ...
            Button("Edit calendar settings") {
                isEditViewShown = true
            }
        }
    }
}

Of course, we could also have chosen to encapsulate our isEditViewShown property within some form of ObservableObject, for example a NavigationController, just like we did when working with TabView earlier.

So that’s how we can programmatically trigger a NavigationLink that’s displayed within our UI — but what if we wanted to perform that kind of navigation without giving the user any direct control over it?

For example, let’s now say that we’re working on a video editing app that includes an export feature. When the user enters the export flow, a VideoExportView is shown as a modal, and once the export operation was completed, we’d like to push a VideoExportFinishedView onto that modal’s navigation stack.

Initially, that might seem very tricky to do, given that (since SwiftUI is a declarative UI framework) there’s no push method that we can call whenever we’d like to add a new view to our navigation stack. In fact, the only built-in way to push a new view within a NavigationView is to use NavigationLink, which needs to be a part of our view hierarchy itself.

That being said, those navigation links doesn’t actually have to be visible — so one way to accomplish our goal in this case would be to add a hidden NavigationLink to our view, which we could then programmatically trigger whenever our video export operation was finished. If we then also hide the system-provided back button within our destination view, then we can completely lock the user out of being able to navigate between those two views manually:

struct VideoExportView: View {
    @ObservedObject var exporter: VideoExporter
    @State private var didFinish = false
    @Environment(\.presentationMode) private var presentationMode

    var body: some View {
        NavigationView {
            VStack {
                ...
                Button("Export") {
                    exporter.export {
    didFinish = true
}
                }
                .disabled(exporter.isExporting)

                NavigationLink("Hidden finish link", isActive: $didFinish) {
                    VideoExportFinishedView(doneAction: {
                        presentationMode.wrappedValue.dismiss()
                    })
                    .navigationTitle("Export completed")
                    .navigationBarBackButtonHidden(true)
                }
                .hidden()
            }
            .navigationTitle("Export this video")
        }
        .navigationViewStyle(.stack)
    }
}

struct VideoExportFinishedView: View {
    var doneAction: () -> Void

    var body: some View {
        VStack {
            Label("Your video was exported", systemImage: "checkmark.circle")
            ...
            Button("Done", action: doneAction)
        }
    }
}

The reason we’re injecting a doneAction closure into our VideoExportFinishedView, rather than having it retrieve the current presentationMode itself, is because we’re looking to dismiss our entire modal flow, rather than just that specific view. To learn more about that, check out “Dismissing a SwiftUI modal or detail view”.

Using a hidden NavigationLink like that could definitely be considered a somewhat “hacky” solution, but it works wonderfully, and if we look at a navigation link more like a connection between two views within a navigation stack (rather than just being a button), then the above setup does arguably make sense.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Conclusion

Although SwiftUI’s navigation system still isn’t nearly as flexible as those offered by UIKit and AppKit, it’s powerful enough to accommodate quite a lot of different use cases — especially when combined with SwiftUI’s very comprehensive state management system.

Of course, we also always have the option to wrap our SwiftUI view hierarchies within hosting controllers and only use UIKit/AppKit to implement our navigation code. Which solution that will be the most appropriate will likely depend on how much custom and programmatic navigation that we actually want to perform within each project.

I hope that you found this article useful, and feel free to share it if you did. If you have any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

Starting in Xcode 13, SwiftUI views can now be previewed in landscape orientation using the new previewInterfaceOrientation modifier. For example, here we’re previewing a MenuView in both portrait and landscape by creating two instances of our view within its PreviewProvider:

struct MenuView_Previews: PreviewProvider {
    static var previews: some View {
        MenuView()
        MenuView().previewInterfaceOrientation(.landscapeRight)
    }
}

Note how we only need to apply the above modifier when we want to preview a given view using an orientation other than portrait, since that orientation is used by default.

However, while the above code works perfectly fine when working on a project that has iOS 15 as its minimum deployment target, we’ll end up getting a compiler error if our app also supports earlier system versions, since (even though this is preview-specific code) we’re using an API that was introduced in iOS 15.

To solve that problem, we could either use an inline availability check:

struct MenuView_Previews: PreviewProvider {
    static var previews: some View {
        MenuView()

        if #available(iOS 15, *) {
            MenuView().previewInterfaceOrientation(.landscapeRight)
        }
    }
}

Or, we could make our entire preview provider require iOS 15:

@available(iOS 15.0, *)
struct MenuView_Previews: PreviewProvider {
    static var previews: some View {
        MenuView()
        MenuView().previewInterfaceOrientation(.landscapeRight)
    }
}

Both of the above solutions work, but it would arguably be quite inconvenient to have to insert those availability statements every single time that we want to preview one of our views in landscape.

One way to address that would be to wrap the new previewInterfaceOrientation modifier in a custom method that performs the required availability check, and then falls back to simply rendering our view as-is if previewing on an older OS version (which, at the time of writing, doesn’t even seem to be possible when using Xcode 13):

extension View {
    @ViewBuilder
    func previewInLandscape() -> some View {
        if #available(iOS 15, *) {
            previewInterfaceOrientation(.landscapeRight)
        } else {
            self
        }
    }
}

To learn more about annotating functions with the @ViewBuilder attribute, and why doing so is required in the above kind of situation, check out this short article.

With the above in place, we can now simply use our new, custom modifier method whenever we want to preview one of our views in landscape, without having to add any availability checks at each call site:

struct MenuView_Previews: PreviewProvider {
    static var previews: some View {
        MenuView()
        MenuView().previewInLandscape()
    }
}

Being able to preview SwiftUI views in landscape is a fantastic addition to Xcode’s preview system, and using the above extension we’ll be able to use this new feature without having to make our preview code any more complicated.

Hope you’ll find this tip useful, and thanks for reading!

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

When writing asynchronous code using Combine, we might sometimes want to share the result of a given set of concurrent operations, rather than performing duplicate work for each one. Let’s take a look at how the share operator can enable us to do that in a really neat way.

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Duplicate, concurrent network calls

As an example, let’s say that we’re working on the following ArticleLoader, which uses URLSession to load an Article model from a given URL:

class ArticleLoader {
    private let urlSession: URLSession
    private let decoder: JSONDecoder

    init(urlSession: URLSession = .shared,
         decoder: JSONDecoder = .init()) {
        self.urlSession = urlSession
        self.decoder = decoder
    }

    func loadArticle(from url: URL) -> AnyPublisher<Article, Error> {
        urlSession
            .dataTaskPublisher(for: url)
            .map(\.data)
            .decode(type: Article.self, decoder: decoder)
            .eraseToAnyPublisher()
    }
}

Now let’s say that we’re expecting the above loadArticle method to be called multiple times, in either parallel or quick succession, with the same URL — which currently would lead to duplicate network requests, as each call to our method produces a brand new publisher.

Reusing publishers

To address that, let’s store each of the publishers that we create within a dictionary (keyed by the URL that each publisher is for), and then when we receive a loadArticle call, we’ll first check if that dictionary contains an existing publisher that can be reused — like this:

class ArticleLoader {
    typealias Publisher = AnyPublisher<Article, Error>

    private let urlSession: URLSession
    private let decoder: JSONDecoder
    private var publishers = [URL: Publisher]()
    ...

    func loadArticle(from url: URL) -> Publisher {
        if let publisher = publishers[url] {
    return publisher
}

        let publisher = urlSession
            .dataTaskPublisher(for: url)
            .map(\.data)
            .decode(type: Article.self, decoder: decoder)
            .handleEvents(receiveCompletion: { [weak self] _ in
                self?.publishers[url] = nil
            })
            .eraseToAnyPublisher()

        publishers[url] = publisher
        return publisher
    }
}

Note how we also remove each publisher from our dictionary once it completes, as to avoid keeping old publishers around in memory. We use receiveCompletion, rather than receiveOutput, to also be notified whenever an error was encountered.

Now, looking at the above code, it might initially seem like we’ve solved our problem. However, if we look at our network logs (or simply put a print("Done") call within our handleEvents closure), then it turns out that we’re actually still performing multiple, duplicate operations. How can that be?

It turns out that even if we are indeed reusing our publisher instances, that doesn’t guarantee that we’re actually reusing the work that those publishers are performing. In fact, by default, each publisher will run through our entire data pipeline for each subscriber that attaches to it. That might initially seem rather odd, so let’s examine that behavior from a slightly different angle.

New subscriber, new values

As another quick example, here we’re creating a publisher that uses a Timer to publish a new random number every second, and we’re then attaching two separate subscribers to that publisher, both of which simply print the numbers that they receive:

var cancellables = Set<AnyCancellable>()

let randomNumberGenerator = Timer
        .publish(every: 1, on: .main, in: .common)
        .autoconnect()
        .map { _ in Int.random(in: 1...100) }

randomNumberGenerator
    .sink { number in
        print(number)
    }
    .store(in: &cancellables)

randomNumberGenerator
    .sink { number in
        print(number)
    }
    .store(in: &cancellables)

It would arguably be a bit strange if both of our subscribers were given the exact same number every second, given that we’re expecting each number to be completely random (and therefore somewhat “unique”). So, from that perspective, the fact that Combine publishers produce separate output for each subscriber does arguably make a lot of sense.

But, going back to our ArticleLoader, how can we then modify that default behavior to prevent duplicate network calls from being performed?

Using the share operator

The good news is that all that we have to do is to use the share operator, which (like its name implies) modifies a given Combine pipeline so that the result of its work is automatically shared among all subscribers:

class ArticleLoader {
    ...

    func loadArticle(from url: URL) -> Publisher {
        if let publisher = publishers[url] {
            return publisher
        }

        let publisher = urlSession
            .dataTaskPublisher(for: url)
            .map(\.data)
            .decode(type: Article.self, decoder: decoder)
            .handleEvents(receiveCompletion: { [weak self] _ in
                self?.publishers[url] = nil
            })
            .share()
            .eraseToAnyPublisher()

        publishers[url] = publisher
        return publisher
    }
}

With just that tiny change in place, we’ve now completely solved our problem. Now, even if multiple loadArticle calls happen in quick succession, only a single network call will be performed, and its result will be reported to each of those call sites.

Well, perhaps “complete solved” isn’t entirely true, because our implementation still has one potential issue — it currently doesn’t account for the fact that our ArticleLoader is likely to be called on a different thread than what URLSession returns its data task output on. While it’s likely that this will never end up causing any actual problems, how about we do a quick bonus round and make our implementation completely thread-safe while we’re at it?

To do that, let’s make a few tweaks to our loadArticle implementation. First, we’ll base our Combine pipeline on our input URL, and we’ll then immediately jump over to an internal DispatchQueue, which we’ll also use when receiving a completion event from one of our publishers. That way, we can guarantee that our publishers dictionary will always be both read and written to on the exact same queue:

class ArticleLoader {
    ...
    private let queue = DispatchQueue(label: "ArticleLoader")

    func loadArticle(from url: URL) -> Publisher {
        Just(url)
            .receive(on: queue)
            .flatMap { [weak self, urlSession, queue, decoder] url -> Publisher in
                if let publisher = self?.publishers[url] {
                    return publisher
                }

                let publisher = urlSession
                    .dataTaskPublisher(for: url)
                    .map(\.data)
                    .decode(type: Article.self, decoder: decoder)
                    .receive(on: queue)
                    .handleEvents(receiveCompletion: { [weak self] _ in
                        self?.publishers[url] = nil
                    })
                    .share()
                    .eraseToAnyPublisher()

                self?.publishers[url] = publisher
                return publisher
            }
            .eraseToAnyPublisher()
    }
}

With those tweaks in place, we now have a completely thread-safe implementation that successfully reuses publishers to avoid having to perform any duplicate work. A potential next step could be to add caching to the above implementation (we currently just rely on the default caching mechanism that URLSession provides out of the box), if that’s something that we think would be useful.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Conclusion

So that’s how the share operator can be used to avoid duplicate work within a Combine pipeline. I hope you found this article useful and interesting, and if you did, feel free to share it with a friend or on social media. That always helps me out a lot! And, if you’ve got any questions, comments, or feedback, then feel free to reach out via email.

Thanks for reading!

One of the major advantages of Swift’s built-in Codable API is how the compiler is able to automatically synthesize many different encoding and decoding implementations when using it. In many cases, all that we have to do to enable a Swift type to be serialized into formats like JSON is to mark it as Codable, and the compiler takes care of the rest.

Let’s take a look at how that automatic synthesis works for enums specifically, and how that part of the system has been upgraded in Swift 5.5.

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Raw representable enums

Enums generally come in two variants — those that are backed by raw values (such as Int or String), and those that contain associated values. Ever since the introduction of Codable in Swift 4.0, enums that belong to the former category have always supported compiler synthesis.

So, for example, let’s say that we’re working on an app that includes the following String-backed enum, which conforms to Codable:

enum MediaType: String, Codable {
    case article
    case podcast
    case video
}

Since the compiler is able to automatically synthesize all of the code needed to encode and decode enums with raw values, we typically don’t have to write any more code than that ourselves — meaning that we’re now free to use the above enum within other Codable types, like this:

struct Item: Codable {
    var title: String
    var url: URL
    var mediaType: MediaType
}

If we now were to encode an instance of the above Item type into JSON, then we’d get the following kind of output (since MediaType values will automatically be encoded and decoded using the raw String values that back them):

{
    "title": "Swift by Sundell",
    "url": "https://swiftbysundell.com/podcast",
    "mediaType": "podcast"
}

So far so good. But what if we instead wanted to encode or decode an enum that supports associated values? Let’s take a look at that next.

Associated values

Before Swift 5.5, if we wanted to make an enum that contains associated values conform to Codable, then we’d have to write all of that code manually. However, that’s no longer the case, as the compiler has received an upgrade that now makes it capable of auto-synthesizing serialization code for such enums as well.

For example, the following Video enum can now be made Codable without requiring any custom code on our part:

enum Video: Codable {
    case youTube(id: String)
    case vimeo(id: String)
    case hosted(url: URL)
}

To see what the above type looks like when encoded, let’s create an instance of a VideoCollection that stores an array of Video values:

struct VideoCollection: Codable {
    var name: String
    var videos: [Video]
}

let collection = VideoCollection(
    name: "Conference talks",
    videos: [
    .youTube(id: "ujOc3a7Hav0"),
    .vimeo(id: "234961067")
]
)

If we then encode the above collection value into JSON, then we’ll get the following result:

{
    "name": "Conference talks",
    "videos": [
        {
            "youTube": {
    "id": "ujOc3a7Hav0"
}
        },
        {
            "vimeo": {
    "id": "234961067"
}
        }
    ]
}

So, by default, when we let the compiler automatically synthesize the Codable conformance for an enum with associated values, then the names of our cases and the labels for the associated values within them will be used when calculating that type’s serialization format.

For unlabelled associated values, underscored numeric keys (like _0, _1, and so on) will be used by default.

Key customization

Just like when working with structs and classes, we’re able to customize what keys that will be used when encoding or decoding an enum’s cases and associated values, and we can even use that capability to omit certain cases entirely.

For example, let’s say that we wanted to extend our Video enum to add support for local videos, but that there’s no reasonable way for us to serialize the data for those videos.

While we could always create a completely separate type for representing such videos, we could also use a nested CodingKeys enum to tell the compiler to ignore the local case when generating our Video type’s Codable implementation.

Here we’ve done just that, and we’ve also customized the hosted case so that it’s referred to as custom when serialized:

enum Video: Codable {
    case youTube(id: String)
    case vimeo(id: String)
    case hosted(url: URL)
    case local(LocalVideo)
}

extension Video {
    enum CodingKeys: String, CodingKey {
        case youTube
        case vimeo
        case hosted = "custom"
    }
}

If needed, we could even customize what keys that are used for the associated values within a specific case. For example, here’s how we could declare that we’d like the youTube case’s id value to be serialized as youTubeID:

extension Video {
    enum YouTubeCodingKeys: String, CodingKey {
        case id = "youTubeID"
    }
}

The above YouTubeCodingKeys enum is matched to our youTube case by name, so if we also wanted to customize the vimeo case, then we could add a VimeoCodingKeys enum for that.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Conclusion

Although Codable’s automatic synthesis does have its limits (particularly when working with serialized formats that are vastly different from how we’d like to organize the data within our Swift types), it’s incredibly convenient — and is often particularly useful when working with locally stored values, such as when caching values on disk, or when reading bundled configuration files.

Regardless, the fact that enums with associated values can now join the auto-synthesis party is definitely a good thing in terms of consistency, and should prove to be quite useful within many different code bases — including my own.

Got questions, comments, or feedback? You’re more than welcome to reach out via email.

Thanks for reading!

New in Swift 5.5: It’s now possible to conditionally compile postfix member expressions using Swift’s #if compiler directive. Let’s take a look at what kinds of situations that this new feature could be really useful in.

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Working around platform differences

Although many of the built-in APIs and frameworks work exactly the same way across Apple’s platforms, there are certain differences that we might need to work around. For example, when using SwiftUI to build an app that runs on both iOS and the Mac, we might find ourselves in the following type of situation — in which we’re getting an error when attempting to apply the iOS-specific InsetGroupedListStyle to a List:

struct ItemList: View {
    var items: [Item]

    var body: some View {
        List {
            ...
        }
        // Error: 'InsetGroupedListStyle' is unavailable in macOS
        .listStyle(InsetGroupedListStyle())
    }
}

In general, these kinds of issues can be worked around using a compile-time platform check — but before Swift 5.5, we’d have to first break our List out into a separate expression, and then apply different listStyle modifiers separately using an #if-based operating system condition:

struct ItemList: View {
    var items: [Item]

    var body: some View {
        let list = List {
            ...
        }

        #if os(iOS)
        list.listStyle(InsetGroupedListStyle())
        #else
        list.listStyle(InsetListStyle())
        #endif
    }
}

In isolation, the above code doesn’t look that bad, but if our ItemList view were to gain additional subviews (or if we’d need to perform additional compile-time checks within it), then its body could quickly become quite hard to read.

So perhaps a more robust solution to this problem would be to instead extract the above platform check into a dedicated modifier method — for example like this:

extension View {
    func defaultListStyle() -> some View {
        #if os(iOS)
        listStyle(InsetGroupedListStyle())
        #else
        listStyle(InsetListStyle())
        #endif
    }
}

With the above in place, we can simply apply our new defaultListStyle modifier within our ItemList view, and we no longer have to deal with any platform differences when constructing our actual UI:

struct ItemList: View {
    var items: [Item]

    var body: some View {
        List {
            ...
        }
        .defaultListStyle()
    }
}

However, while the above is certainly a neat technique when working with modifiers and styles that we’re looking to reuse multiple times across a project, always having to define a dedicated method each time we encounter a platform difference can become quite tedious.

This is where Swift 5.5’s new support for #if conditions within postfix member expressions comes in.

Inline checks within expressions

When using Swift 5.5, we now have the option to inline #if directives right within our expressions. So, going back to our ItemList, we can now conditionally apply each of our listStyle modifiers completely inline — without first having to break our expression up into multiple parts:

struct ItemList: View {
    var items: [Item]

    var body: some View {
        List {
            ...
        }
        #if os(iOS)
        .listStyle(.insetGrouped)
        #else
        .listStyle(.inset)
        #endif
    }
}

Above we’re also making use of another new language feature that enables us to refer to SwiftUI list styles (and other kinds of protocol-based types) using dot syntax. Check out “Using static protocol APIs to create conforming instances” to learn more about that.

Nice! Of course, this new capability also works for other kinds of #if-based compile-time checks — including using the standard DEBUG flag to check if our app is being compiled using its debug build configuration, and any custom compiler flags that we might’ve defined.

As an example, here’s how we could use a custom flag to conditionally visualize the final rendering size of one of our views:

struct DynamicIcon: View {
    var name: String

    var body: some View {
        Image(systemName: name)
            .resizable()
            .aspectRatio(contentMode: .fit)
            #if SHOW_ICON_SIZES
            .overlay(GeometryReader { geo in
                Text("\(Int(geo.size.width)) x \(Int(geo.size.height))")
                    .font(.footnote)
                    .background(Color.blue)
                    .foregroundColor(.white)
            })
            #endif
    }
}

To learn more about how to define and use custom compiler flags, check out “Using compiler directives in Swift”.

Support Swift by Sundell by checking out this sponsor:

Essential Developer: If you want to become a complete senior iOS developer, join this free online crash course starting on October 18th. Learn how to apply truly scalable iOS app architecture patterns through a series of lectures and practical coding sessions. Click to learn more.

Conclusion

So, how should we pick between these new inline #if conditions versus creating dedicated modifiers for working around platform differences and for performing other kinds of compile-time checks? While every developer will certainly have their own preferences — for me, it all depends on whether a given pattern will be repeated within a code base, or whether it’s something that we’re only performing once.

For repeated compile-time checks, I still prefer to create dedicated functions, since that lets me wrap those checks up into a much simpler API, but when working around minor platform differences (like we did above), I prefer the new inline style. It’s already proving to be quite useful when working on cross-platform SwiftUI-based projects.

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

Thanks for reading!