Introduced at WWDC 2019, SwiftUI is a declarative UI framework from Apple that enables developers to build native user interfaces for apps running on either iOS, iPadOS, watchOS, tvOS or macOS. Its highly declarative API makes it quite different from Apple’s previous UI frameworks, such as UIKit and AppKit, which in turn often requires us to adopt a somewhat different set of patterns and conventions when starting to use it.
On this Discover page, you’ll find links to lots of articles, tips and other content that all aims to give you a thorough understanding of some of those patterns, as well as how SwiftUI’s built-in suite of APIs and features work.
SwiftUI features a brand new layout system that in many ways encourages us to write more dynamic UIs that can scale and adjust according to factors like what device that our code is being run on, what accessibility settings that the user has enabled, and what locale that is currently being used.
What that means in practice is that, similar to when using Auto Layout, we need to write our layout code in a way that makes fewer assumptions about the overall environment that a given view will be rendered in. However, unlike Auto Layout, a SwiftUI layout is determined entirely by the view hierarchy itself, rather than by using dedicated objects like constraints.
When building our views declaratively, we also need to define our state in a declarative manner as well. Thankfully, SwiftUI ships with a comprehensive suite of state management tools, that range from property wrappers like
@Binding, to powerful dependency management mechanisms, such as the
What better way to learn more about SwiftUI than to hear from some of the people who actually built it? These two podcast episodes feature Josh Shaffer, engineering director with the UIKit and SwiftUI team, and Eliza Block, engineer on Xcode Previews, and contain a ton of interesting behind-the-scenes information on how these developer tools are designed, built and used by Apple.
At first glance, it might seem like adopting SwiftUI requires us to rewrite our entire user interface using it, but that couldn’t be further from the truth.
In fact, one of SwiftUI’s most powerful features is its UIKit and AppKit interoperability, which both enables us to bring in
NSView instances (as well as their view controller equivalents) into the declarative world of SwiftUI, and vice versa.
That gives us a ton of flexibility when it comes to adopting SwiftUI within an existing project, as we can start by building just a single view using it, all while leveraging our existing views and components. The following articles cover various ways to do just that:
Next, a quick message from this week’s sponsor
Swift by Sundell is completely free for everyone, but if you’d like to support my work, then please take just a few minutes to check out the following sponsor, since doing so really helps me out financially.
RevenueCat: Easily build and manage iOS and Android in-app purchases. With just a few lines of code RevenueCat provides IAP infrastructure, customer analytics, data integrations, and gives you time back from dealing with edge cases and updates across all platforms.
Next, let’s take a look under the hood of SwiftUI’s very “DSL-like” API. While SwiftUI is a closed-source project that’s privately implemented by Apple, we can get a quite good understanding of how it operates by examining a few key Swift features that its API makes heavy use of. Let’s dive in, shall we?
The fact that SwiftUI views are declared using structs and other value types gives us many different options when it comes to what kind of architecture that we’d like to use when building an app’s view layer. The following articles cover some of those options, along with tips and techniques that can be good to keep in mind along the way.
Just like when using other UI frameworks, such as UIKit and AppKit, what kind of structure that we use to organize each view’s implementation can have a huge impact on the overall readability and maintainability of our code. Here are a few tips on how maintain a solid structure within each of our SwiftUI views:
Using SwiftUI’s ViewBuilder attribute with functions
Annotating properties with SwiftUI’s ViewBuilder attribute in Swift 5.4
Creating custom SwiftUI container views
Passing methods as SwiftUI view actions
Using multiple computed properties to form a SwiftUI view’s body
SwiftUI extensions using generic type constraints
While SwiftUI was definitely designed around making it as easy as possible to build views that are based on system components, it also offers several APIs and features that enable us to create UIs that are rendered in more custom ways. Here are two examples:
Next, let’s take a look at how we can improve the overall speed and experience of developing a SwiftUI-based app, both using the built-in tools that ship as part of Xcode, and by creating our own utilities as well.
SwiftUI is of course a very frequent topic on the Swift by Sundell podcast, with special guests from around the community sharing their tips and experiences of working with SwiftUI in different ways.
Meng To’s top tips on how to build scalable and flexible UIs using SwiftUI
Kaya Thomas on how SwiftUI is a huge step forward in terms of iOS app accessibility
David Smith shares his learnings from deploying SwiftUI in production
How Tobias Due Munk uses SwiftUI to build tools and prototypes
An in-depth discusssion about the SwiftUI layout system with Chris Eidhof
Adam Bell talks about using SwiftUI to visualize audio
Brent Simmons on how SwiftUI marks the start of a new era for Apple
Comparing SwiftUI and Catalyst with Benedikt Terhechte
Finally, let’s explore the topic of deciding whether to adopt SwiftUI within a given project, and also how building internal tools and prototypes can provide a great way to get started with SwiftUI, while also minimizing the risks associated with being an early adopter.