If you’ve had the chance to check out recent announcements from WWDC, you’ll certainly be aware of a new and upcoming framework called SwiftUI. This surprise introduction for creating interface components creates fantastic new opportunities and will undoubtedly have an impact on how all of us write apps. This essay reviews its key concepts for those preparing for their next technical interview.
Goodbye Quartz, UIKit, Autolayout...
Back when I started iOS development, the tools needed to write code and build user interfaces were separated into two applications: Xcode and Interface Builder. Beyond the introduction of Storyboards and Autolayout, how we create interfaces has remained largely the same. This includes the use of Core Graphics, Core Animation and Quarts when subclassing UIView. Often, implementing custom interfaces felt foreign when compared to the typical flow of an app. This was largely due to the code’s procedural design and lack of object-oriented principals. For example:
//draw a line using Quartz
- (void)drawRect:(CGRect)rect {
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetLineWidth(context, 2.0);
CGColorSpaceRef colorspace = CGColorSpaceCreateDeviceRGB();
CGFloat components[] = {0.0, 0.0, 1.0, 1.0};
CGColorRef color = CGColorCreate(colorspace, components);
CGContextSetStrokeColorWithColor(context, color);
...
}
If you don’t recognize this style, don’t worry. It’s likely much of it will fade away with the introduction of SwiftUI. Entire techniques such as Storyboards, Autolayout or the entire UIKit are yet to be seen.
Hello SwiftUI
To understand the flow of SwiftUI, let’s test some basic concepts you can apply to your next technical interview. Consider the following:
imports SwiftUI
struct HelloView: View {
var body: some View {
Text("Hello World..")
}
}
Assuming you’re running Xcode 11 or later, the following is all you need to build a simple View with the words “Hello World..” displayed on screen. Even though we just have a few lines of code, note how there are no import references to UIKit and that the HelloWorld struct conforms to the new View protocol. Another important highlight is that aView should not be confused with a traditional UIView. In addition, the body of our code is defined as a computed property.
Taking Action
With a basic View defined, let’s proceed to add a Button. With SwiftUI, the typical target/ action sequence has been replaced with a two-closure method signature for action and label respectively:
struct HelloView: View {
var body: some View {
Button(action: processAction) {
Text("First Button")
}
}
}
func processAction() -> Void {
print("First Button Pressed..")
}
Declarative Statements
Experienced developers may be skeptical of the (over) simplification of the tools needed to build complex user interfaces - (will this really work)? What makes the new modeling technique both exciting and powerful is its declarative style. This means SwiftUI features aren’t based on a strict OO composition design pattern, but can be blended to a make a custom design of your choosing. To see how this works, let’s enhance our button with an image :
struct HelloView: View {
var body: some View {
Button(action: processAction) {
HStack {
Image(systemName: "pencil.tip")
Text("First Button")
}
}
}
}
...
Assuming we wanted to replicate the same design with UIButton we’d have to first check to ensure our object supported properties for UILabel and UIImageView. With SwiftUI, we can nest seemingly incompatible objects to achieve our desired layout.
Working with Lists
Beyond basic controls let’s consider how SwiftUI handles list-based content such as tableViews. As we’ll see, this area has also been refined and simplified. To illustrate, assume I want to extend my current iOS interview email course as an app. To start, I would have users choose from a list of possible topic categories. Defined as Topics , the metadata would be as follows:
imports SwiftUI
struct Topic: Identifiable {
var id = UUID()
var name: String
}
What’s new is the Identifiable protocol. This will allow our Topic to employ fast-enumeration when working with native SwiftUI objects. To see how this works, let’s define some test data and create a new List :
struct ListView: View {
//list of topics
let topics = [
Topic(name: "Syntax"),
Topic(name: "Design Patterns"),
Topic(name: "Algorithms"),
Topic(name: "System's Design"),
Topic(name: "Project Management")
]
var body: some View {
List(topics) { element in
Text(element.name)
}
}
}
This code generates a basic list, but doesn’t yet function like a regular TableView. Let’s enhance our model with a NavigationView :
struct Topic: Identifiable {
var id = UUID()
var name: String
var image: String
}
struct ListView: View {
//list of topics
let topics = [
Topic(name: "Syntax", image: "pencil.tip"),
Topic(name: "Design Patterns", image: "rectangle.stack.fill"),
Topic(name: "Algorithms", image: "cube.box"),
Topic(name: "System's Design", image: "skew"),
Topic(name: "Project Management", image: "doc.text")
]
var body: some View {
NavigationView {
List(topics) { element in
NavigationButton(destination: Text(element.name)) {
HStack {
Image(systemName: element.image)
Text(element.name)
}
}
}
.navigationBarTitle(Text("Flashcards"))
}
}
}
These enhancements now provide us with the desired effect. Things to note include the implementation of the NavigationButton as well as the use of the new SF Symbols icon library, seen with the syntax Image(systemName:).
Room with a View
Arguably the most important aspect of SwiftUI is that all items are treated as a View. This could make traditional challenges like casting and inheritance a thing of the past. Considering our example, this allows us to not only push traditional subViews (to the Stack), but is flexible enough to push non-standard items like Text or Buttons:
...
NavigationButton(destination: Text(element.name))
With such profound changes to the iOS ecosystem, developers should be studying SwiftUI now as hiring managers will eventually seek candidates who have an understanding of the new model to refactor new and existing applications. The introduction of SwiftUI has been well received. As a result, one should double down on their mastery of Swift language syntax as Xcode development moves toward a more fluid model between WYSIWYG and code-based tools.