SwiftUI’s various stacks are some of the framework’s most fundamental layout tools, and enable us to define groups of views that are aligned either horizontally, vertically, or stacked in terms of depth.

When it comes to the horizontal and vertical variants (HStack and VStack), we might sometimes end up in a situation where we want to dynamically switch between the two. For example, let’s say that we’re building an app that contains the following LoginActionsView, which lets the user pick from a list of actions when logging in:

Preview

struct LoginActionsView: View {
    ...

    var body: some View {
        VStack {
            Button("Login") { ... }
            Button("Reset password") { ... }
            Button("Create account") { ... }
        }
        .buttonStyle(ActionButtonStyle())
    }
}

struct ActionButtonStyle: ButtonStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.label
            .fixedSize()
            .frame(maxWidth: .infinity)
            .padding()
            .foregroundColor(.white)
            .background(Color.blue)
            .cornerRadius(10)
    }
}

Above, we’re using the fixedSize modifier to prevent our button labels from getting truncated, which is something that we should only do if we’re sure that a given view’s content won’t ever be larger than the view itself. To learn more, check out part three of my guide to SwiftUI’s layout system.

Currently, our buttons are stacked vertically, and fill all of the available space on the horizontal axis (you can use the above code sample’s PREVIEW button to see what that looks like). While that looks great on iPhones that are in portrait orientation, let’s say that we instead wanted to use a horizontal stack when our UI is rendered in landscape mode.

GeometryReader to the rescue?

One way to do that would be to use a GeometryReader to measure the currently available space, and based on whether the width of that space is larger than its height, we render our content using either an HStack or a VStack.

While we could definitely place that logic right within our LoginActionsView itself, chances are quite high that we’ll want to reuse that code at some point in the future, so let’s instead create a dedicated view that’ll perform our dynamic stack-switching logic as a stand-alone component.

To make our code even more future-proof, we won’t hard-code what alignment or spacing that our two stack variants will use. Instead, let’s do what SwiftUI itself does, and parametrize those attributes while also assigning the same default values that the framework uses — like this:

struct DynamicStack<Content: View>: View {
    var horizontalAlignment = HorizontalAlignment.center
var verticalAlignment = VerticalAlignment.center
var spacing: CGFloat?
    @ViewBuilder var content: () -> Content

    var body: some View {
        GeometryReader { proxy in
            Group {
                if proxy.size.width > proxy.size.height {
                    HStack(
                        alignment: verticalAlignment,
                        spacing: spacing,
                        content: content
                    )
                } else {
                    VStack(
                        alignment: horizontalAlignment,
                        spacing: spacing,
                        content: content
                    )
                }
            }
        }
    }
}

Since we made our new DynamicStack use the same kind of API that HStack and VStack use, we can now simply swap out our previous VStack for an instance of our new, custom stack within our LoginActionsView:

Preview

struct LoginActionsView: View {
    ...

    var body: some View {
        DynamicStack {
            Button("Login") { ... }
            Button("Reset password") { ... }
            Button("Create account") { ... }
        }
        .buttonStyle(ActionButtonStyle())
    }
}

Neat! However, like the above code sample’s PREVIEW shows, using a GeometeryReader to perform our dynamic stack switching does come with a quite significant downside, in that geometry readers always fill all of the available space on both the horizontal and vertical axis (in order to actually be able to measure that space). In our case, that means that our LoginActionsView will no longer just stretch out horizontally, but it’ll now also move to the top of the screen.

While there are various ways that we could address those problems (for example by using a technique similar to the one we used to make multiple views have the same width or height in this Q&A article), the question is really whether measuring the available space is really a good approach when it comes to determining the orientation of our dynamic stacks.

A case for size classes

Instead, let’s use Apple’s size class system to decide whether our DynamicStack should use an HStack or a VStack under the hood. The benefit of doing that is not just that we’ll be able to retain the same compact layout that we had before introducing a GeometryReader into the mix, but also that our DynamicStack will start behaving in a way that’s very similar to how built-in system components behave across all devices and orientations.

To start observing the current horizontal size class, all we have to do is to use SwiftUI’s environment system — by declaring an @Environment-marked property (with the horizontalSizeClass key path) within our DynamicStack, which will then let us switch on the current sizeClass value within our view’s body:

Preview

struct DynamicStack<Content: View>: View {
    ...
    @Environment(\.horizontalSizeClass) private var sizeClass

    var body: some View {
        switch sizeClass {
        case .regular:
            hStack
        case .compact, .none:
            vStack
        @unknown default:
            vStack
        }
    }
}

private extension DynamicStack {
    var hStack: some View {
        HStack(
            alignment: verticalAlignment,
            spacing: spacing,
            content: content
        )
    }

    var vStack: some View {
        VStack(
            alignment: horizontalAlignment,
            spacing: spacing,
            content: content
        )
    }
}

With the above in place, our LoginActionsView will now dynamically switch between having a horizontal layout when rendered using the regular size class (for example in landscape on larger iPhones, or in either orientation when running full-screen on iPad), and a vertical layout when any other size class configuration is used. All while still using a compact vertical layout that doesn’t use any more space than what’s needed to render its content.

Using the Layout protocol

Although we’ve already ended up with a neat solution that works across all iOS versions that support SwiftUI, let’s also explore a few new layout tools that are being introduced in iOS 16 (which at the time of writing is still in beta as part of Xcode 14).

One such tool is the new Layout protocol, which both enables us to build completely custom layouts that can be integrated directly into SwiftUI’s own layout system (more on that in a future article), while also providing us with a new way to dynamically switch between various layouts in a very smooth, full animatable way.

That’s because it turns out that Layout is not just an API for us third-party developers, but Apple have also made SwiftUI’s own layout containers use that new protocol as well. So, rather than using HStack and VStack directly as container views, we can instead use them as Layout-conforming instances that are wrapped using the AnyLayout type — like this:

private extension DynamicStack {
    var currentLayout: AnyLayout {
        switch sizeClass {
        case .regular, .none:
            return horizontalLayout
        case .compact:
            return verticalLayout
        @unknown default:
            return verticalLayout
        }
    }

    var horizontalLayout: AnyLayout {
        AnyLayout(HStack(
            alignment: verticalAlignment,
            spacing: spacing
        ))
    }

    var verticalLayout: AnyLayout {
        AnyLayout(VStack(
            alignment: horizontalAlignment,
            spacing: spacing
        ))
    }
}

The above works since both HStack and VStack directly conform to the new Layout protocol when their Content type is EmptyView (which is the case when we don’t pass any content closure to such a stack), as we can see if we take a peak at SwiftUI’s public interface:

extension VStack: Layout where Content == EmptyView {
    ...
}

Note that, due to a regression, the above conditional conformance was omitted from Xcode 14 beta 3. According to Matt Ricketson from the SwiftUI team, a temporary workaround would be to instead use the underlying _HStackLayout and _VStackLayout types directly. Hopefully that regression will be fixed in future betas.

Now that we’re able to resolve what layout to use through our new currentLayout property, we can now update our body implementation to simply call the AnyLayout that’s returned from that property as if it was a function — like this:

struct DynamicStack<Content: View>: View {
    ...

    var body: some View {
        currentLayout(content)
    }
}

The reason that we can apply our layout by calling it as a function (even though it’s actually a struct) is because the Layout protocol uses Swift’s “call as function” feature.

So what’s the difference between our previous solution and the above, Layout-based one? The key difference (besides the fact that the latter requires iOS 16) is that switching layouts preserves the identity of the underlying views that are being rendered, which isn’t the case when swapping between an HStack and a VStack. The result of that is that animations will be much smoother, for example when switching device orientations, and we’re also likely to get a small performance boost when performing such changes as well (since SwiftUI always performs best when its view hierarchies are as static as possible).

Picking the view that fits

But we’re not quite done yet, because iOS 16 also gives us another interesting new layout tool that could potentially be used to implement our DynamicStack — which is a new view type called ViewThatFits. Like its name implies, that new container will pick the view that best fits within the current context, based on a list of candidates that we pass when initializing it.

In our case, that means that we could pass it both an HStack and a VStack, and it’ll automatically switch between them on our behalf:

struct DynamicStack<Content: View>: View {
    ...

    var body: some View {
        ViewThatFits {
            HStack(
                alignment: verticalAlignment,
                spacing: spacing,
                content: content
            )

            VStack(
                alignment: horizontalAlignment,
                spacing: spacing,
                content: content
            )
        }
    }
}

Note that it’s important that we place the HStack first in this case, since the VStack will likely always fit, even within contexts where we want our layout to be horizontal (such as in full-screen mode on iPad). It’s also important to point out that the above ViewThatFits-based technique will always attempt to use our HStack, even when rendered with the compact size class, and will only pick our VStack-based layout when the HStack doesn’t fit.

Conclusion

So that’s four different ways to implement a dedicated DynamicStack view that dynamically switches between an HStack and a VStack depending on the current context. I hope you enjoyed this article, and if you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email.

Thanks for reading!

Combining Swift’s flexible generics system with protocol-oriented programming can often lead to some really powerful implementations, all while minimizing code duplication and enabling us to establish clearly defined levels of abstraction across our code bases. However, when writing that sort of code before Swift 5.7, it’s been very common to run into the following compiler error:

Protocol 'X' can only be used as a generic constraint because it
has Self or associated type requirements.

Let’s take a look at how Swift 5.7 (which is currently in beta as part of Xcode 14) introduces a few key new features that aim to make the above kind error a thing of the past.

Opaque parameter types

Like we took a closer look at in the Q&A article “Why can’t certain protocols, like Equatable and Hashable, be referenced directly?”, the reason why it’s so common to encounter the above compiler error when working with generic protocols is that as soon as a protocol defines an associated type, the compiler starts placing limitations on how that protocol can be referenced.

For example, let’s say that we’re working on an app that deals with various kinds of groups, and to be able to reuse as much of our group handling code as possible, we’ve chosen to define our core Group type as a generic protocol that lets each implementing type define what kind of Item values that it contains:

protocol Group {
    associatedtype Item

    var items: [Item] { get }
    var users: [User] { get }
}

Now, because of that associated Item type, we can’t reference our Group protocol directly — even within code that has nothing to do with a group’s items, such as this function that computes what names to display from a given group’s list of users:

// Error: Protocol 'Group' can only be used as a generic constraint
// because it has Self or associated type requirements.
func namesOfUsers(addedTo group: Group) -> [String] {
    group.users.compactMap { user in
        isUserAnonymous(user) ? nil : user.name
    }
}

One way to solve the above problem when using Swift versions lower than 5.7 would be to make our namesOfUsers function generic, and to then do what the above error message tells us, and only use our Group protocol as a generic type constraint — like this:

func namesOfUsers<T: Group>(addedTo group: T) -> [String] {
    group.users.compactMap { user in
        isUserAnonymous(user) ? nil : user.name
    }
}

There’s of course nothing wrong with that technique, but it does make our function declaration quite a bit more complicated compared to when working with non-generic protocols, or any other form of Swift type (including concrete generic types).

Thankfully, this is a problem that Swift 5.7 neatly solves by expanding the some keyword (that was introduced back in Swift 5.1) to also be applicable to function arguments. So, just like how we can declare that a SwiftUI view returns some View from its body property, we can now make our namesOfUsers function accept some Group as its input:

func namesOfUsers(addedTo group: some Group) -> [String] {
    group.users.compactMap { user in
        isUserAnonymous(user) ? nil : user.name
    }
}

Just like when using the some keyword to define opaque return types (like we do when building SwiftUI views), the compiler will automatically infer what actual concrete type that’s passed to our function at each call site, without requiring us to write any extra code. Neat!

Primary associated types

Sometimes, though, we might want to add a few more requirements to a given parameter, rather than just requiring it to conform to a certain protocol. For example, let’s say that we’re now working on an app that lets our users bookmark their favorite articles, and that we’ve created a BookmarksController with a method that lets us pass an array of articles to bookmark:

class BookmarksController {
    ...

    func bookmarkArticles(_ articles: [Article]) {
        ...
    }
}

However, not all of our call sites might store their articles using an array. The following ArticleSelectionController, for instance, uses a ‌dictionary to keep track of what articles that have been selected for what IndexPath within a UITableView or UICollectionView. So, when passing that collection of articles to our bookmarkArticles method, we first need to manually convert it into an array — like this:

class ArticleSelectionController {
    var selection = [IndexPath: Article]()
    private let bookmarksController: BookmarksController
    ...

    func bookmarkSelection() {
        bookmarksController.bookmarkArticles(Array(selection.values))
        ...
    }
}

But if we instead wanted to update that bookmarkArticles method to work well for any kind of Collection that contains Article values, then we couldn’t simply change its parameter type to some Collection, since that wouldn’t be enough to specify that we’re looking for a collection that has a specific Element type as input.

We could, however, once again use a set of generic type constraints to solve that problem:

class BookmarksController {
    ...

    func bookmarkArticles<T: Collection>(
        _ articles: T
    ) where T.Element == Article {
        ...
    }
}

Again, nothing wrong with that — but Swift 5.7 once again introduces a much more lightweight way to express the above kind of declaration, which works the exact same way as when specializing a concrete generic type (such as Array<Article>). That is, we now can simply tell the compiler what Element type that we’d like our input Collection to contain by adding that type within angle brackets right after the protocol name:

class BookmarksController {
    ...

    func bookmarkArticles(_ articles: some Collection<Article>) {
        ...
    }
}

Very cool! We can even nest those kinds of declarations — so if we wanted to make our BookmarksController capable of bookmarking any kind of value that conforms to a generic ContentItem protocol, then we could specify some ContentItem as our collection’s expected Element type, rather than using the concrete Article type:

protocol ContentItem: Identifiable where ID == UUID {
    var title: String { get }
    var imageURL: URL { get }
}

class BookmarksController {
    ...

    func bookmark(_ items: some Collection<some ContentItem>) {
        ...
    }
}

The above works thanks to a new Swift feature called primary associated types, and the fact that Swift’s Collection protocol declares Element as such an associated type, like this:

protocol Collection<Element>: Sequence {
    associatedtype Element
    ...
}

Of course, being a proper Swift feature, we can also use primary associated types within our own protocols as well, using the exact same kind of syntax.

Existentials and the ‘any’ keyword

Finally, let’s take things one step further by also turning our ArticleSelectionController into a generic type that can be used to select any ContentItem-conforming value, rather than just articles. As we’re now looking to mix multiple concrete types that all conform to the same protocol, the some keyword won’t do the trick — since, like we saw earlier, it works by having the compiler infer a single concrete type for each call site, not multiple ones.

This is where the new any keyword (which was introduced in Swift 5.6) comes in, which enables us to refer to our ContentItem protocol as an existential. Now, doing that does have certain performance and memory implications, as it effectively works as an automatic form of type erasure, but in situations where we want to be able to dynamically store a heterogeneous collection of elements, it can be incredibly useful.

For example, by simply using any ContentItem as our selection dictionary’s value type, we’ll now be able to store any value conforming to that protocol within that dictionary:

class ContentSelectionController {
    var selection = [IndexPath: any ContentItem]()
    private let bookmarksController: BookmarksController
    ...

    func bookmarkSelection() {
        bookmarksController.bookmark(selection.values)
        ...
    }
}

However, making that change does introduce a new compiler error, since our BookmarksController is expecting to receive a collection that contains values that all have the exact same type — which isn’t the case within our new ContentSelectionController implementation.

Thankfully, fixing that issue is as simple as replacing some ContentItem with any ContentItem within our bookmark method declaration:

class BookmarksController {
    ...

    func bookmark(_ items: some Collection<any ContentItem>) {
        ...
    }
}

We’re even able to mix any and some references, and the compiler will automatically help us translate between the two. For example, if we wanted to introduce a second, single-element bookmark method overload, which our first one then simply calls, then we could do so like this (even though the first method’s items collection contains any ContentItem and the second method accepts some ContentItem):

class BookmarksController {
    ...

    func bookmark(_ items: some Collection<any ContentItem>) {
        for item in items {
            bookmark(item)
        }
    }

    func bookmark(_ item: some ContentItem) {
        ...
    }
}

Again, it’s important to emphasize the using any does introduce type erasure under the hood, even if it’s all done automatically by the compiler — so using static types (which is still the case when using the some keyword) is definitely the preferred way to go whenever possible.

Conclusion

Swift 5.7 doesn’t just make Swift’s generics system more powerful, it arguably makes it much more accessible as well, as it reduces the need to use generic type constraints and other more advanced generic programming techniques just to be able to refer to certain protocols.

Generics is definitely not the right tool for every single problem, but when it turns out to be, being able to use Swift’s generics system in a much more lightweight way is definitely a big win.

I hope that you found this article useful. If you have any questions, comments, or feedback, then feel free to reach out via either Twitter or email. For more information about these new generics features, I recommend watching the excellent “What’s new in Swift” and “Embrace Swift generics” sessions from this year’s WWDC.

Thanks for reading!

Swift 5.7 introduces a new, more concise way to unwrap optional values using if let and guard let statements. Before, we always had to explicitly name each unwrapped value, for example like this:

class AnimationController {
    var animation: Animation?

    func update() {
        if let animation = animation {
            // Perform updates
            ...
        }
    }
}

But now, we can simply drop the assignment after our if let statement, and the Swift compiler will automatically unwrap our optional into a concrete value with the exact same name:

class AnimationController {
    var animation: Animation?

    func update() {
        if let animation {
            // Perform updates
            ...
        }
    }
}

Neat! The above new syntax also works with guard statements:

class AnimationController {
    var animation: Animation?

    func update() {
        guard let animation else {
            return
        }

        // Perform updates
        ...
    }
}

It can also be used to unwrap multiple optionals all at once:

struct Message {
    var title: String?
    var body: String?
    var recipient: String?

    var isSendable: Bool {
        guard let title, let body, let recipient else {
            return false
        }

        return ![title, body, recipient].contains(where: \.isEmpty)
    }
}

A small, but very welcome feature. Of course, we still have the option to explicitly name each unwrapped optional if we wish to do so — either for code style reasons, or if we want to give a certain optional a different name when unwrapped.

Ever since its original introduction in 2019, SwiftUI has had really strong interoperability with UIKit. Both UIView and UIViewController instances can be wrapped to become fully SwiftUI-compatible, and UIHostingController lets us render any SwiftUI view within a UIKit-based view controller.

However, even though macOS has had an NSHostingView for inlining SwiftUI views directly within any NSView (no view controller required) since the very beginning, there has never been a built-in way to do the same thing on iOS. Sure, we could always grab the underlying view from a UIHostingController instance, or add our hosting controller to a parent view controller in order to be able to use its view deeper within a UIView-based hierarchy — but neither of those solutions have ever felt entirely smooth.

That brings us to iOS 16 (which is currently in beta at the time of writing). Although Apple haven’t introduced a fully general-purpose UIHostingView as part of this release, they have addressed one of the most common challenges that the lack of such a view presents us with — which is how to render a SwiftUI view within either a UITableViewCell or UICollectionViewCell.

Just a quick note before we begin: All of this article’s code samples will be entirely UITableView-based, but the exact same techniques can also be used with UICollectionView as well.

Say hello to UIHostingConfiguration

In iOS 14, Apple introduced a new way to configure cells that are being rendered as part of a UITableView or UICollectionView, which lets us use so-called content configurations to decouple the content that we’re rendering from the actual subviews that our cells contain. This API has now been extended with a new UIHostingConfiguration type, which lets us define a cell’s content using any SwiftUI view hierarchy.

So wherever we’re configuring our cells — for example using the good-old-fashioned UITableViewDataSource dequeuing method — we can now opt to assign such a hosting configuration to a given cell’s contentConfiguration property, and UIKit will automatically render the SwiftUI views that we provide within that cell:

class ListViewController: UIViewController, UITableViewDataSource {
    private var items: [Item]
    private let databaseController: DatabaseController
    private let cellReuseID = "cell"
    private lazy var tableView = UITableView()
    ...

    func tableView(_ tableView: UITableView,
                   cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(
            withIdentifier: cellReuseID,
            for: indexPath
        )

        let item = items[indexPath.row]

        cell.contentConfiguration = UIHostingConfiguration {
            HStack {
                Text(item.title)
                Spacer()
                Button(action: { [weak self] in
                    if let indexPath = self?.tableView.indexPath(for: cell) {
                        self?.toggleFavoriteStatusForItem(atIndexPath: indexPath)
                    }
                }, label: {
                    Image(systemName: "star" + (item.isFavorite ? ".fill" : ""))
                        .foregroundColor(item.isFavorite ? .yellow : .gray)
                })
            }
        }

        return cell
    }

    private func toggleFavoriteStatusForItem(atIndexPath indexPath: IndexPath) {
        items[indexPath.row].isFavorite.toggle()
        databaseController.update(items[indexPath.row])
    }
}

Neat! As the above code sample shows, we can easily send events back from our cell’s SwiftUI views to our view controller using closures, but there are a few things that are good to keep in mind when doing so.

First, you might’ve noticed that we’re asking the table view for our cell’s current index path before passing it to our toggleFavoriteStatusForItem method. That’s because, if our table view supports operations such as moves and deletions, our cell might be at a different index path once our favorite button is tapped — so if we were to capture and use the indexPath parameter that was passed into our cell configuration method, then we might accidentally end up updating the wrong model.

Second, we have to remember that we still very much remain in the world of UIKit, which means that we have to take memory management into account (at least, more so than when operating in the wonderful value type-based world of SwiftUI). Hence the above [weak self] closure capture, in order to avoid retain cycles between our view controller and its UITableView.

Finally, there’s state management, and just like when bridging the gap between UIKit and SwiftUI using tools like UIHostingController or UIViewRepresentable, we probably need to write a little bit of custom code to ensure that our cell’s SwiftUI view hierarchy is rendering the latest version of our view controller’s data.

Managing state updates

For example, when the user taps our cell’s favorite button, our cell is not currently updated to reflect its Item model’s new state. That’s because we’re not actually using SwiftUI’s declarative state management system to drive those updates, so there’s no way for our nested SwiftUI view hierarchy to know that its data model was modified.

One way to address that would be to use UIKit to react to those changes, rather than using SwiftUI’s view updating mechanisms. We could, for instance, call our table view’s reloadRows method whenever an item’s favorite status was changed — like this:

class ListViewController: UIViewController, UITableViewDataSource {
    ...

    private func toggleFavoriteStatusForItem(atIndexPath indexPath: IndexPath) {
        items[indexPath.row].isFavorite.toggle()
        databaseController.update(items[indexPath.row])
        tableView.reloadRows(at: [indexPath], with: .none)
    }
}

That works great, since it’ll make the table view call our data source cell configuration method, which’ll give us a chance to update the changed item’s cell and the SwiftUI views that are embedded within it.

But let’s say that we instead wanted to use SwiftUI’s state management system to keep track of when our cell’s state was modified. One way to make that happen would be to introduce some form of ObservableObject that our view controller could then inject into each cell’s SwiftUI view hierarchy.

A side-benefit of introducing such a type in this case is that it’ll also give us a neat place to encapsulate all view-related logic that’s tied to our Item model, such as the code that’s used to compute our favorite button’s title and foreground color. Let’s go ahead and introduce such a class, which we’ll call ItemViewModel:

class ItemViewModel: ObservableObject {
    @Published private(set) var item: Item
    private let onItemChange: (Item) -> Void

    init(item: Item, onItemChange: @escaping (Item) -> Void) {
        self.item = item
        self.onItemChange = onItemChange
    }

    func toggleFavoriteStatus() {
        item.isFavorite.toggle()
        onItemChange(item)
    }
}

extension ItemViewModel {
    var favoriteButtonIconName: String {
        "star" + (item.isFavorite ? ".fill" : "")
    }

    var favoriteButtonColor: Color {
        item.isFavorite ? .yellow : .gray
    }
}

Note that we’re enabling an onItemChange closure to be passed into our view model, which’ll let our view controller observe whenever the view model’s copy of the underlying Item model was modified. We could definitely have chosen to use Combine here instead, by having our view controller hook into the publisher that’s connected to the view model’s item property, but a simple closure will get the job done in this case.

Next, let’s extract our cell-embedded SwiftUI code into a dedicated View type, which will let us make our view hierarchy observe our new view model as an ObservedObject:

struct ItemView: View {
    @ObservedObject var viewModel: ItemViewModel

    var body: some View {
        HStack {
            Text(viewModel.item.title)
            Spacer()
            Button(action: viewModel.toggleFavoriteStatus) {
                Image(systemName: viewModel.favoriteButtonIconName)
                    .foregroundColor(viewModel.favoriteButtonColor)
            }
        }
    }
}

Finally, all that remains is to update our view controller to use our newly introduced types, which will also let us remove the toggleFavoriteStatusForItem method that we were previously using to manage each item’s favorite status:

class ListViewController: UIViewController, UITableViewDataSource {
    ...

    func tableView(_ tableView: UITableView,
                   cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(
            withIdentifier: cellReuseID,
            for: indexPath
        )

        let viewModel = ItemViewModel(
            item: items[indexPath.row],
            onItemChange: { [weak self] item in
                guard let indexPath = self?.tableView.indexPath(for: cell) else {
                    return
                }
            
                self?.items[indexPath.row] = item
                self?.databaseController.update(item)
            }
        )

        cell.contentConfiguration = UIHostingConfiguration {
    ItemView(viewModel: viewModel)
}

        return cell
    }
}

Very nice! Of course, the above implementation only handles internal data model changes that are performed by our view controller and its nested SwiftUI views. If those models could also be modified elsewhere, then we’d have to notify our view controller whenever that happens, and reload our table view’s data accordingly. However, the fact that we’re using SwiftUI and the new UIHostingConfiguration API doesn’t really affect the way we’d do that, since any such external updates would lead to us re-configuring our cells anyway.

Bridged swipe actions

Another neat aspect of the new UIHostingConfiguration API and the way it bridges the gap between UIKit and SwiftUI is that it’ll automatically convert any SwiftUI swipeActions that our view hierarchy contains into UIKit-based swipe actions.

So for example, if we wanted to add a delete swipe action to each of our item cells, then we could do that using a modifier placed right within our UIHostingConfiguration closure — like this:

cell.contentConfiguration = UIHostingConfiguration {
    ItemView(viewModel: viewModel).swipeActions {
        Button(role: .destructive, action: { [weak self] in
            guard let indexPath = self?.tableView.indexPath(for: cell) else {
                return
            }

            self?.items.remove(at: indexPath.row)
            self?.databaseController.delete(viewModel.item)
            self?.tableView.deleteRows(at: [indexPath], with: .automatic)
        }, label: {
            Label("Delete", systemImage: "trash")
        })
    }
}

However, while the above is really neat, it’s important to point out that (at the time of writing) not every aspect of SwiftUI is automatically bridged that way. For example, if we were to place a NavigationLink within our UIHostingConfiguration, then that wouldn’t automatically be wired up to any UINavigationController that our view controller is embedded in (which does happen when using UIHostingController). Hopefully that’s something that’ll be addressed at a later time.

Conclusion

The interoperability between SwiftUI and UIKit keeps getting more and more powerful, which in turn enables us to continue mixing the two UI frameworks within the apps that we build. The introduction of UIHostingConfiguration is especially welcome, since UITableView and UICollectionView (which supports this new hosting configuration API in the exact same way) still offer much more functionality than their SwiftUI counterparts — so being able to inline SwiftUI views within them should definitely prove to be very useful.

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

Thanks for reading!