Thoughts on SwiftUI vs UIKit

Because the concept of object identity is critical in SwiftUI, if the position of an item is relevant to the UI, we must architecture our view’s state model around this fact and provide/predict it in advance alongside everything else that is relevant to the view:

struct ListIndexable<T>: Identifiable {
    let id = ... // How this is implemented depends
    // on what the model represents in practice and how it should be updated
    let index: Int
    let object: T
}

This means that trying to add new behavior to views can result in the entire architecture of that view needing to be refactored, which is a trade-off that developers creating complicated apps would want to avoid at all costs.

But before we continue, we must mention something very important in this area. Astute readers that have used SwiftUI before might look at this example and point out that you don’t really need to do any of these, because there’s a variation of ForEach that allows you to manually provide the Hashable value that SwiftUI will use deep-down to enforce uniqueness. This allows you to skip the Identifiable requirement and solve the .enumerated() problem with zero extra code, and if you look up this problem in StackOverflow you can even find plug-and-play extensions for this exact use-case:

private func ForEachEnumerated<T: Hashable, U: View>(_ arr: Binding<[T]>, @ViewBuilder content: @escaping (Int, Binding<T>) -> U) -> some View {
    let arr = Array(arr.enumerated())
    return ForEach(arr, id: \.offset, content: content)
}

You need to be very careful when using snippets like this in SwiftUI, because trying to out-smart the framework is a very easy way to end up with cryptic and undebuggable rendering problems. In this case the problem with the snippet is that using the index itself as the definition of uniqueness has serious implications for how SwiftUI will draw updates to that particular list, which might not be what you’re expecting for your particular use-case. This is the same reason why I’ve refrained from implementing let id in the examples above.

When working with frameworks like SwiftUI and React, you should always avoid shortcuts and take the extra time to think how to architect your view’s state in a static and predictable way. I’ve found that this forces you to put quite a lot of pre-thinking into what you want a certain view to do, because if you forget something down the line it can be very hard to recover from it. This won’t be a big deal for simple products, but if you’re developing a very complicated app, you might not be willing to make that trade-off.

Rendering issues are impossible to debug

Almost nothing you write in SwiftUI is “real” Swift code. With Property Wrappers and Function Builders at its core, almost everything you write will result in the compiler generating additional wiring code for you.

The fact that SwiftUI relies heavily on generated code is not a problem by itself, because as long you know what that wiring code is, you can generally follow along and debug issues just as if that wasn’t the case. When the wiring code leads to closed source code however, the story is different.

Here’s an example of how this can negatively affect your work. In Burnout Buddy, it’s possible to shortcut your way into configuring time schedules for an entire week by setting just one of them and asking the tool to copy the values into the remaining days. In code, I attempted to achieve this by creating a custom Binding object that pastes Monday’s schedule into the rest of the week:

let weekdayBinding = Binding<[TimeRange]> {
    schedule.days[0]
} set: { range, transaction in
    schedule.days[0] = range
    schedule.days[1] = range
    schedule.days[2] = range
    schedule.days[3] = range
    schedule.days[4] = range
}

The code above however did not work. To be very specific, it does quite literally nothing. While I could breakpoint the set closure and see that it was being called correctly with the right values, the view was not being updated accordingly. To make things worse, I was also seeing other completely unrelated things being updated as a result of this code that made no sense whatsoever!

The reason it didn’t work? I don’t know, because Binding is closed source. It took me multiple hours to even realize that this particular piece of code was the source of the problem as there was no feedback from SwiftUI itself that there was something wrong, meaning the only thing I could do was re-write parts of the app aimlessly and hope for the best.

I eventually managed to solve the problem by slightly re-shaping how the closure is executed. Instead of setting each array entry one by one, I chose to copy the entire structure, change it accordingly, and then apply it back to the original bound state object. Because I couldn’t actually debug the problem, I can only speculate that the bug has something to do with State not being able to process more than one update in a single stack frame.

let weekdayBinding = Binding<[TimeRange]> {
    schedule.days[0]
} set: { range, transaction in
    var days = schedule.days
    days[0] = range
    days[1] = range
    days[2] = range
    days[3] = range
    days[4] = range
    schedule.days = days
}

This is not a problem with SwiftUI itself, but with Apple deciding to hide critical logic (in this case, what causes a view to re-render) from you. In contrast, you’d not see problems like this in UIKit because the important bits are always handled on your side of the field (e.g when to call addSubview, layoutIfNeeded, etc).

The good news is that SwiftUI is already able to warn you when you make a rendering mistake in certain cases, so Apple is definitely aware of this problem and is working on ways to make it less disruptive.

Should I learn SwiftUI?

Ever since the dawn of software engineering, there have been people engaging in “platform wars”. They’ll evangelize for the “best architecture”, “best framework”, “best OS”, “best design pattern”, and claim that theirs is the only option and everything else is a mistake. This is no different for iOS development, and “SwiftUI vs UIKit” is, sure enough, the new “conflict’ of choice.

As a software engineer, it’s critical for you to realize that there is no such thing as “best X”. Everything is a tool, and whether or not you should use them depends only on what you’re trying to achieve. Even Objective-C still has its uses! (If you want more examples of that, I’ve written a full article about how there is no right or wrong in tech.)

SwiftUI and UIKit do not cancel each other; they are both good and bad in different ways, and whether or not you should pick SwiftUI specifically will depend on the details of what you’re trying to build.

After building a SwiftUI app myself, these are the guidelines that I would personally follow for my next projects:

• Simple UI, Simple Logic: Would make it 100% with SwiftUI.
• Simple UI, Not-so-simple Logic: I’d start with a 100% SwiftUI app, but if it got too tough I’d fall back to using SwiftUI for the UI itself and UIKit for the more complex pieces of logic (via UIViewRepresentable).
• Not-so-simple UI, Simple Logic: Will greatly depend on what’s being built. I find that more complex pieces of UI can be a lot harder to pull off with SwiftUI when compared to UIKit.
• Not-so-simple UI, Not-so-simple Logic: Probably best to go 100% UIKit to avoid issues in the long run.

What should beginners learn first?

I think the situation right now is very similar to when Swift was released. I started with iOS exactly when that happened, and the way I learned it was by first learning as much I could about Objective-C and then using that knowledge to seamlessly move over to Swift and making that my main tool of choice. As the years went by and everyone migrated to Swift, it became less and less necessary to strictly learn Objective-C to the point where nowadays you can defer learning it until you reach a point where you want/need to expand your knowledge of the platform itself.

This is how I think beginners should approach SwiftUI vs UIKit. While people will always want to learn the shiny new thing, you should always learn both whilst focusing on what the majority of people use right now to maximize your hiring opportunities. I expect that as the years go the majority of UIKit projects will move over to SwiftUI, but it’s still too early to tell if UIKit will completely go away given SwiftUI’s current issues when used in more complicated projects.