A Skeptics view on SwiftUI
Everyone is all over Apples new UI Framework, called SwiftUI. If you haven’t heard of it, you can watch this WWDC video (the part about SwiftUI starts about 4 minutes in) on it, but basically, the gist of it is that it’s a new, declarative way to define your user interface.
Declarative UI isn’t a new thing: it is used in React, Flutter, and Android with Jetpack Compose (probably amongst others). I’ve had the chance to work with all of these technologies over the past year and since I’m used to using AutoLayout and Storyboards to create views, I always viewed declarative views as an unnecessary hurdle to overcome.
That has changed now, though: with the release of this framework it’s clear that Apple sees this as the way to go moving forward. I decided to flip this mental UISwitch and dive into the documentation for SwiftUI to form a well-rounded opinion on this “next big thing”. If you have the time I invite you to do the same, but at the very least it’ll be advantageous to take a glance at this introduction page to get a general idea of what SwiftUI is and which problems it promises to solve. At the bottom of that page, you can start a tutorial which will get you started out with the new framework.
As I mentioned earlier, I’ve worked with multiple different technologies that tackle view building in a declarative way, and I’ve always had a few things I didn’t really like about working with them. I’ll first try to highlight the reason for my skepticism and later in the article, I’ll try to dive into how those things are tackled in SwiftUI to see if my skepticism holds any merit.
A thing I hear many people talk about when discussing the advantages of using declarative UI is the readability. While I can definitely see why people consider the simpler examples (I’m looking at you, counter apps) of declarative code to be easy to read, with my imperative background I can’t imagine a larger codebase to maintain the same grade of readability they promote in the sample applications and tutorials. The second you start abstracting components (or widgets) into separate functions to keep the code readable, in my opinion, you lose out on a lot of the “see at a glance what this view does” effect.
And that ties into another issue I face: I’m curious if these declarative ways of defining views still fulfill their main functions (ease of use, readability) when the codebase grows and you need some fine-grained control over a view element. Consider the following effect:
This can be achieved with (relative) ease in UIKit, but I’m curious to see how such effects are achieved in SwiftUI, and if it’ll maintain the readability of the code.
You might have guessed that this was coming from my wording in the first two points I highlighted: my largest concern is about the maintainability of the application once the scope starts to grow and you’re a few years down the line. As highlighted before, the examples given are often simple and don’t require that much code, and as such, don’t get to the level of complexity I’m talking about. When you look at some larger Flutter repositories, however, you’ll often find tightly coupled code that doesn’t show the readability it advocates at all.
On the topic of readability, I think SwiftUI is taking the right approach. Take Flutter for example, with the “everything is a Widget” philosophy. If you’d need padding around something, you would add a Padding widget around it. This, in my opinion, instantly makes the code a lot less readable, since you’re not just looking at UI elements anymore, you’re also looking at their styling. SwiftUI tackles that by using chaining instead of wrapping views around everything. If you want to add some padding, you’d simply call the padding function on the view. This way, the only views that contain other views are actual containers like a horizontal StackView or a button that contains text. For me, this improves readability a lot.
My second concern regarding the fine-grained control over view elements is definitely something to take a closer look at. From my limited testing, I’ve found that SwiftUI simply integrates default functionality really well. You get nice looking animations and dark mode support out of the box, and there are probably lots of other nice features that I haven’t run into yet.
Maybe it’s good to assume that in its current form, it isn’t meant for the fine-grained control we’re used to with the imperative way of building our views. But this problem has been “solved” by allowing us to easily interface with UIKit views so we can still get the desired level of control.
Basically, I feel that using SwiftUI results in an app that adheres to the native design style that people are used to while taking a lot less time to do so. Whenever you need to dive a little bit deeper the easy API to interface with UIKit allows you to do just that and create a customized experience.
My concern about the maintainability is something we simply can’t address right now. It’s safe to say that in a year we’ll probably have some well-defined standards regarding building our applications with SwiftUI, but we’ll have to give it some time to mature first.
While I was skeptical at first, in the short time I’ve had to play around with SwiftUI I’ve had quite some fun with it and I feel like the framework addresses some of the issues I’ve had with getting into other declarative UI frameworks.
It feels like a great tool to make quick iterations of a project: not just because of the declarative UI and all the functionality you get out of the box, but also because the preview functionality in Xcode looks incredibly powerful for quickly testing changes to your views on multiple devices.
I’d love to hear what you think about SwiftUI. From how well Xcode integrates with it, it’s pretty clear Apple is serious about moving forward in this direction, and I’m very excited to spend more time with it in the coming weeks. Combined (pun intended) with the release of the new Combine framework, this is undoubtedly a huge and interesting moment of change in the Swift community. You can expect more articles in the coming weeks in which I’ll try to do a deeper dive into SwiftUI and explain some of the things going on under the hood.