Today we are going to look at what the completion handler pattern is and the main problem it solves. We'll look at how completion handlers are actually implemented in Swift. And we'll look at some downsides to the pattern and some examples of how to work around them.

What Is A Completion Handler?

At the most basic level, a completion handler is a block of work that is passed as an argument to a function so that it can run at a later time. There are many reasons why we might want to use them, but they are especially powerful when we have a task that will take a long time to finish and we don't want that task to block other work. That's a pretty abstract sentence, so let's think through an example.

Imagine a user taps a button in your app that is supposed to load some data. Let's say it is a list of pets who need to be adopted in the zip code the user entered. (It doesn't matter what the data is, but why not imagine cute animals?) The button tap will be handled on the main thread (which is used for all UI updates on iOS) and that will kick off a network request to load the data, and when that returns it will update the UI to show the list of adorable pets. The simplest way to code this would be to just kick off the network request and then sit and wait for it to return and then update the UI when it does.

But what if that request took 2 seconds? or 5 seconds? The user wouldn't be able to do anything while they waited. They couldn't navigate around the rest of the app, they couldn't scroll or tap any other buttons or anything else, because that is all code that has to run and we're already waiting for the network request to return. We're blocking other work. That is a terrible user experience.

We have very little control over how long that network request will take, but we can improve the UX here. Instead of waiting, we'll put the work that takes a long time (in this case the network request) on another thread that won't block our UI thread. (Pretty much all of the abstractions that are used for network requests on iOS do exactly that for us under the hood.) That solves the problem of blocking the user from being able to use the app. But what about when the data comes back? How do we get that data to show up in our UI?

That is where completion handlers come in. When we kick off the network request in the first place, we'll give it a completion handler – block of work to run once the request returns. We'll trigger our UI update in that block of work.

Now that we have a high-level idea of what a completion handler is and what problem they solve, let's dig into what they actually look like in Swift. To do that, we need to look at the concept of closures as a whole and a little bit about their semantics.

A Brief Diversion On Closures

As the Swift Language Guide says:

Closures are self-contained blocks of functionality that can be passed around and used in your code.

In other languages you might see them referred to as "blocks" or "lambdas", but in Swift the name comes from their ability to capture or "close over" constants and variables in the context where they are defined. We'll touch on that more in a minute.

So a closure is a block of code that can take arguments and returns some value. Sounds a lot like a function, right? That's because in Swift functions are actually a specialized type of closure. They have a name and some special syntax, but you can pass a function anywhere you can pass a closure. Just as long as the signature matches.

That means a function which takes a completion handler is actually a closure that takes another closure to run at some later point. It's closures all the way down! This is usually where I see people's eyes start to glaze over, but it is worth understanding if you can stick with it.

In Swift these are all closures, and they would all do the same thing:

func firstAdd(_ a: Int, _ b: Int) -> Int { return a + b }

let secondAdd: (Int, Int) -> Int = { a, b in return a + b }

let thirdAdd = { (a: Int, b: Int) -> Int in return a + b }

let fourthAdd: (Int, Int) -> Int = { $0 + $1 }

The first one is a normal function that you are probably used to seeing. The second defines the signature of the closure and then the closure itself, giving names ("a" and "b") to the arguments. The third defines the signature and names together within the closure. The fourth uses the anonymous argument labels ("$0" meaning the first argument, "$1" meaning the second, and so on) and omits the return keyword, which is allowed because this is a one line closure and the return value can be inferred as the result of that line.

If you wanted to add two values you could call any of these in the same way:

firstAdd(2, 2)
secondAdd(2, 2)
thirdAdd(2, 2)
fourthAdd(2, 2)

Capturing Values

This is great if you have the values you want to pass to the closure and the logic is trivial like it is here. But what if we want to keep track of some state beyond an individual run of the closure? That is where capturing variables comes in. Let's say we have a game and we're keeping track of a score for a given user. We might model our logic like this:

// simple object to encapsulate different difficulties in our game
struct Difficulty {
    let pointValue: Int

    static let easy = Difficulty(pointValue: 10)
    static let hard = Difficulty(pointValue: 6)
}

// global function for generating a new counter of a given difficulty
func scoreCounter(diffculty: Difficulty = .easy) -> () -> Int {
    var score: Int = 0

    let adder: () -> Int = {
        score += diffculty.pointValue
        return score
    }
    return adder
}

let easyCounter = scoreCounter()
print(easyCounter()) // 10
print(easyCounter()) // 20

let hardCounter = scoreCounter(diffculty: .hard)
print(hardCounter()) // 6
print(hardCounter()) // 12

Look at the scoreCounter function. We are going to give it a Difficulty and it is going to give us a closure which takes no value and returns an Int. Internally, it declares a variable called score and sets it to 0. Then it makes a closure called adder which itself adds the difficulty's pointValue to the score and then returns the new score. Finally, it returns the adder.

The magic here is that the closure "captures" a reference to the score variable and also to the difficulty's pointValue. So it will actually increase each time we call the closure, even though we're not holding onto that score variable anywhere. And each instance of the counter will have its own score variable.

Escaping

This may not seem like much, and in all honesty, it is probably not the best way to model a score counter, but when we combine it with the next feature of closures we start to see where it all comes together. Closures can also "escape" the scope where they are passed.

That means they can outlive the scope of where they are passed. This is a fairly confusing concept, but it basically boils down to a function (A) saying that the closure it accepts (B) may run after the function has returned (C). In our score counter example it might look like this:

// A.
func scoreCounter(modify: @escaping (Int) -> Int) -> (Int) -> Int {
    var score: Int = 0

    let adder: (Int) -> Int = {
        score += modify($0) // C.
        return score
    }
    return adder
}

let modify: (Int) -> Int = { $0 * 8 / 10 } // B.
let customCounter = scoreCounter(modify: modify)
print(customCounter(10)) // 8
print(customCounter(10)) // 16

The scoreCounter function takes a modify closure and it is going to build an adder closure to return. Since the modify closure it takes as an argument is going to be called by the adder closure it returns, it may be called after scoreCounter has finished its work, so we have to mark it as @escaping.

Back To Completion Handlers

So for our example we might write something like this, with a completion handler:

func fetchPets(then completion: @escaping ([Pet]) -> Void) { ... }

The caller of the function will pass a block of work that it wants to do with the fetched array of pets. Then it can continue with whatever work comes next without being blocked by the the work that needs to be done to fetch the pets. The "fetching pets work" will happen on a background thread and when it is done the "completion handler" work that the caller defined will run.

The the call site would look something like this:

// in PetListViewController
fetchPets { pets in
    self.updateUI(with: pets)
}

The pet list view controller says "I want to you to fetch the list of pets, and when you're done I want you to call my update UI function with the pets that you fetched".

I don't know about you, but I find that it is a lot easier to follow the logic if I personify the different classes and objects in my code and imagine them having conversations with each other.

Now we've made it all the way through the diagram! We sent our long running work to a background thread where it doesn't block the UI and we've used a completion handler to update our UI when it is finished. You can see that the completion handler is marked as @escaping, because it will be called after the fetchPets function has returned. And it is easy to miss, but we are actually capturing a reference to self here. The closure will hold onto a reference to the pet list view controller (which is what self refers to in this case) as long as it (the closure) remains in memory.

It seems like we've solved our problem. That's great, but what can go wrong? Let's look at some things you should watch out for as you use completion handlers in your code.

Some Pitfalls

UI Work On A Background Thread

One of the most common mistakes I see beginners make with completion handlers is updating their UI on the background thread a network response it returned on. This usually stems from the the fact that you almost never have to dispatch your network request to a background thread in the first place (it is done for you) and so many people don't realize their completion handler will even be called on a background thread. Plus it is easy to forget and it usually won't lead to outright crashes, just odd behavior.

Fortunately it is relatively easy to fix. We just need to make sure the UI work runs on the UI queue. We can do that using this function called DispatchQueue.async(group:qos:flags:execute:), not to be confused with the async keyword introduced in Swift 5.5. This function takes a closure and runs it on the queue it is called on asynchronously (there is also a synchronous version called sync), with some optional configuration. In our example it would look like this:

// in PetListViewController
fetchPets { pets in
    DispatchQueue.main.async { self.updateUI(with: pets) }
}

Another tool that helps here is the "Main Thread Checker", which you can enable in the Scheme Editor, on the "Run" tab, under "Diagnostics". This will cause your app to pause execution when your app is running and you try to update the UI from any thread other than the main one. It will even try to show you where you're doing it, although I find in real usage that it isn't always 100% accurate.

Retention Cycles

Another common mistake that people make with completion handlers is causing a retain cycle. To really get to the bottom of what that means and why it can be a problem we'd have to dive deep into how Swift handles memory management. I'm not going to do that in this article, but you can read more about it here if you're interested. For now, let's just say that a retain cycle is when two or more objects each have a strong reference (one which adds to the retain count) to one another so that there is a closed loop of references which will hold those objects in memory indefinitely. And let's say that is generally a bad thing that we want to avoid.

We can avoid that cycle if we break one of the references. In Swift we can do that with either the weak or unowned keywords. Both of these keywords will keep a reference to the object without adding to its retain count. weak references must be Optional, to acknowledge it may not be there in the future when you try to access it. unowned is similar to an implictly unwrapped optional, in that you are telling the compiler to treat the reference as always being there even though it is possible for it to not be. There are times when unowned is the right method to use, but generally speaking it is safer to use weak and that is probably what you should do unless you have a good reason to do otherwise.

Some examples of when to use unowned would be if the captured reference will never become nil, or when the closure and the instance it captures will always refer to each other and will always be deallocated at the same time. In either of these cases though, you could use weak and it will still resolve the retain cycle it just may be slightly less performant.

In a closure you can make a reference weak or unowned with the "capture list". So far when we've captured references in a closure it has been implicit – the compiler just handles it for us if we use a reference in the closure. But we can also explicitly capture references using the capture list. You do that by putting them in square brackets before the argument definition in the closure. That looks like this:

fetchPets { [weak self] pets in
    DispatchQueue.main.async { self?.updateUI(with: pets) }
}

So now we are telling the compiler to keep a weak reference to self. That means self now has a type of PetListViewController? and so we use optional chaining on it before calling updateUI. If self is no longer there this block will just return. That safely avoids the retain cycle.

You might notice that this is the same method we use to avoid a retain cycle in the delegate pattern, it just looks a little different here because we're using closure semantics. The main difference is that in the delegate pattern, the weak reference is handled as a part of the implementation and in the completion handler pattern it is handled at the call site. This is one reason why I generally prefer the delegate pattern. In that pattern you avoid retain cycles in one easy to check (and lint) place and users of your code don't have to worry about it at the call site. With the completion handler pattern you give that power to the users of your method, which may be more versatile, but also means that they have to do some extra work to avoid retain cycles.

Wrap Up

We've looked at how the completion handler pattern is just giving some other code a block of work to do later. We've looked at how this pattern solves the problem of not wanting to block important work in the short term with something that will take a long time. We've looked at the semantics and how to implement completion handlers in Swift. They may look a little funky at first, especially with some of the syntactic sugar, but they just make use of a combination of Swift features that we use elsewhere. And we've looked at the two main problems people run into with completion handlers – updating the UI from a background thread and inadvertently causing retain cycles – and how to avoid those problems.

My journey to start developing software as my livelihood took a while. Looking back, I realize that I was always sort of around computers. I grew up in the age when regular people started using the internet. I had to take a few typing and computer classes in school as a kid. I had a few classes that touched on web development with various tools. My dad also did some work with computers and we always had at least one desktop around the house, and often more than one. I even helped him take a few apart and make minor repairs and upgrades over the years.

But it never clicked for me. Code seemed esoteric and boring and I never had a clear picture of what the possibilities were. I played the emulators that my dad would download and set up for me. I used Facebook and Myspace all the time (yes, I was in middle school when Myspace launched). I loved my iPod and the ability it gave me to take all my music wherever I wanted to go. But I never connected the dots that I could be a part of making things like that in the world.

It wasn't until much later that I would catch the bug. After I had earned a Bachelor's degree that I had no real intention of using. After I had spent years learning and working with audio, video and lighting for live production environments (think concerts, conferences, and churches). After I had begun to pay for rent and insurance and taxes, and get a taste of what life is like as an adult.

The Spark

In my first job out of school I was the grunt worker on a team of five very capable production managers at a church of about 5,000 members. As a team we were responsible for maintaining and operating any and all equipment related to audio, video or lighting used in weekend services and auxiliary events. My main role was scheduling the twenty or so volunteers that we needed to make things run every weekend, and I would run sound or lights or direct video for various events and services. And, as the junior member of the team, I would do pretty much whatever else needed to be done.

A few months into the job I was given a task. We used Basecamp as our project management tool. Everything we needed to get done as a team was kept track of in there. But there was a problem. Occasionally there were events, scheduled by other departments in the church, that didn't make it into our system. On more than one occasion, no one told us that they needed our support for an event until the day of that event! I don't know if you have ever been unexpectedly asked to stay at work for an additional six hours. If you have, it probably wasn't to manage a microphone and music in a room full of two hundred teenagers. But I'm sure you can imagine that those were not the best days.

Now when people would schedule an event they would fill out a form in another piece of software and there were even some questions on that form that asked about what AVL equipment/support they would need. But it was their responsibility to make sure we got that form if we needed it, which often meant we didn't get it. So I was asked to find a way to bridge the gap. To find some automated way of connecting this other piece of software over there to our Basecamp over here.

I dove in on finding a solution. I started learning about a few programming languages. I learned some python and some ruby. We had access to a website called Lynda.com which had educational videos on a variety of topics, including some basic computer science and language material. I watched some of those every day and learned all sorts of things. I wrote some scripts that moved files and folders around on the computer and I felt like a god. I worked and worked on a terrible little script that would solve this problem at work, and I finally accomplished it.

After a few weeks of focused learning and a lot of trial and error I had a script I could run that would copy events over from the church's software to Basecamp. It was very poorly organized. I'm sure it was full of bugs and security vulnerabilities. I would be embarrassed to show it to anyone today (fortunately, I don't have it so I can't show it to anyone even if I wanted to 😁).

My plan was to set it up as a cron job on one of the desktops that lived at the church and have it run every day or so. Since people filled out this form weeks before their event, that would get the information into our system with plenty of time for us to plan for it. But as it happened, we discovered a new web service for connecting various tools called Zapier just as I finished up my script. This was obviously a better solution with support from actual developers and it could serve as the glue between a few other services we used as well. So my script got trashed and we went with Zapier instead.

But this experience was the spark that lit the coding fire in me. I got a taste of a language that felt like magic. I could type some characters into a computer and it would do whatever I told it to. And some of the things I could tell it to do would solve actual problems that I had in my own life or that I knew other people had. I had found a new passion.

My advice for myself (or anyone else) in this stage would be to stay open. Be willing to say yes and try new things. You never know what mundane and trivial project you take at work might actually be the start of a whole new career for you.

Smouldering

I kept learning, going through courses on Lynda. I stumbled upon Stanford's computer science courses. (They put all the material online and you have access to it all for free, so no excuses if you're trying to get started.) I went through CS 193 which was called "Developing Apps for iOS" and I got my first few apps running in a simulator. They were ugly and not very functional and it was the Swift 2 days so the code itself was pretty ugly too. But I had written a piece of software that had a UI, and it could run on the phone in my pocket all on its own. I could hardly believe it.

It would be another four years before I decided to switch fully into software development. I kept dabbling in things over time. I went through a bunch of Free Code Camp's material and I read some books and blogs and watched videos on YouTube, etc. But I never felt like I was qualified to get a job.

Throughout this time I learned a lot, and I do not think it was totally wasted time. I established my underlying understanding of how computers work and how programming languages generally work and the sort of logic that programmers use. I slowly saturated myself in the tech world and familiarized myself with the jargon, etc. I still draw on a lot of this base knowledge today.

But I didn't make much actual progress because I didn't take action, or at least I didn't commit to the actions that I took. I built toy apps and websites. I made a "portfolio" website that I never deployed. I never learned Git. I had no stake in the game. It was fun to learn and make pomodoro timers, but if nothing came of it I didn't lose anything but a little time.

My advice for myself (or anyone else) in this stage would be to find a way to get a stake in the game. There is infinite material out there to learn and more tutorial projects than you will ever be able to complete. Once you have a hang of the basics, find a way to give yourself something to gain (or lose). You'll be amazed at how much faster you progress. Buy a course. Pay for a bootcamp. Get a contract for a project that is reasonably out of your comfort zone. Make a bet with your friend. Post about your goal on your social media platform of choice. Do something that will have a real cost if you don't accomplish it. Just make sure it is a cost you can recover from.

Fanning the Flames

In the fall of 2018 I decided to quit my job and go through a pretty intense bootcamp that (at the time) was called Lambda School. The internet seems to have pretty mixed reviews on them, but my experience was exactly what I needed. They had enough structure and accountability to keep me going (it was fully remote, so I was spending all day every day alone in front of a computer). And they built in enough space that I could try things out and learn how to find answers for myself (which is a huge part of the actual job of software development). The iOS cohorts were also pretty small and I met some incredible people along the way.

I got my first job right as I was finishing up my time at Lambda. I had applied for over a hundred, interviewed for a couple, and got an offer for one. It had taken almost a year since I quit my old job, a lot of work, a lot of learning and reading and coding. But I got there. I found someone willing to pay me to write code for an iOS app, and my starting salary was 40% higher than any other job I had ever had in my life.

But that was merely the start. I still had so much to learn. I had to learn about how to work in the context of a team. I had to learn about Agile practices and what "scrum" and "sprint" and "epic" and "story" meant. I had to learn about the lifecycle of a feature in a company. How it goes from idea to plan to design to implementation to testing to release to maintenance. I had to learn about the push and pull from various parts of the organization from leadership to marketing and sales to design to engineering and how to balance the tension. I had to learn how to communicate my ideas to people who had no context or understanding of the technical constraints and to people who would be implementing the idea themselves. I had to learn how to document decisions and write tests and give demos. I had to learn how to debug CI/CD and network requests. Etc.

In short there was a whole other world of things to learn that I had no idea about before I got an actual job. Tech companies move very fast and structure their work in a very different way from anywhere else I had ever worked. It was a lot to digest while also trying to put out a decent quality and quantity of code as a junior developer. But those lessons and experience are what took me from being a junior developer to being a senior developer.

My advice for myself in this stage would be to view yourself as a student. Stay curious. Ask questions. Even (especially) if you feel like they make you look dumb. Listen to the answers and take them to heart. Take the advice that is given to you by the engineers around you. It may come across as a rude comment in a PR review but it is intended to make the code (and you) better. View bugs as opportunities to learn something. View features as opportunities to learn something. View code reviews (both given and received) as opportunities to learn something. Especially as you begin to gain seniority and get paid more it gets easier and easier to think that you have all the answers. But you don't. You'll do yourself a disservice by acting like you do (not to mention those around you, and your users, and your stakeholders).

The Fire Rages

Lately I feel I have hit my stride. I have a good rhythm of work and play and learning and rest. I have a job that I enjoy, working on a product that I know improves a lot of people's lives, with people I respect and constantly learn from. I am spending more time mentoring people who a newer to this than I am, doing what I can to help people like innumerable people helped me. I am spending more time sharing what I learn in so others can (hopefully) benefit from it. I am trying to find the balance between having contentment and striving to grow and be better. I am where I wanted to be four years ago.

I don't know that I have advice for myself in this stage because I am still in the midst of it. But maybe you do. What advice would you have for someone in this stage of their development journey? Let me know and I'll update this post with any of the good ones.

In an exploratory phase this is usually fine. Maybe you're writing a little script to solve some problem for yourself and no one else has to deal with it. Maybe you're just trying to figure out how something works and this code will never see the light of day anyways. Whatever the reason, it is probably ok to not handle all the edge cases and errors at first.

But one place I see a lot of newer iOS developers get stuck is when they think they've got the code for the happy path written, they go to run it, and it just doesn't work.

I had a psychology professor who used to say "When people don't know what to do, they do what they know how to do." He was saying it in the context of people with various addictions, but it is true of all people, and this is another good example. When newer devs get stuck here, they will reach for tools they are familiar with. They will add print statements and set break points and try to narrow down where the problem is. Sometimes this helps. It depends on where the bug is coming from. But there are many types of bugs that these tools are not particularly helpful in solving. One of those areas is in decoding.

I have lost count of the number of newer developers I have helped figure out decoding bugs, and I often see the same mistake. They throw away errors that would help them track down the bug. In this article we're going to look at some decoding bugs. They are a good example of a class of bug where the errors that are thrown are often the best tool for understanding what has gone wrong. It also happens to be a context where it is fairly easy to show a few specific examples, so it works well for an article of this size. But the message is true everywhere. Errors and the messages they carry are there for a reason and they are often a helpful tool for finding bugs and making your code more robust.

So don't throw them away!

Let's look at a specific example. To protect the egos of the various people I have helped with decoding bugs over the years (at least one of whom now works at Apple), I have made a sample project instead of using someone's actual code. But it is illustrative of the exact kinds of issues I have seen people run into in the real world.

Sample App Overview

My sample app lets you look up random characters from the television show "Bob's Burgers". You can tap a button and it will load in a random character, show you their picture, their name, occupation and who voiced the character. There is also a link to the fandom wiki for that character. It uses this api to fetch the information. Here's how it is organized:

There is a character model:

struct Character: Codable {
    let id: Int
    let name: String
    let image: URL
    let occupation: String
    let voicedBy: String
    let wikiUrl: URL

    enum CodingKeys: String, CodingKey {
        case id, name, image, occupation
        case voicedBy = "voiced_by"
        case wikiUrl = "wiki_url"
    }
}

There is a class that encapsulates access to the api with this interface:

class BobsBurgersApi {
    static let shared = BobsBurgersApi()

    func fetchCharacter(id: Int) async -> Character? { ... }
}

There is a view model that interacts with the api and provides the primitive building blocks for the view to display:

@MainActor
class CharacterViewModel: ObservableObject {

    @Published var character: Character?

    var title: String { character?.name ?? "" }
    var subtitle: String { character?.occupation ?? "" }
    var detail: String { (character?.voicedBy).map { "Voiced by: \($0)" } ?? "" }
    var learnMore: URL { character?.wikiUrl ?? URL(string: "https://bobs-burgers.fandom.com")! }

    private var api: BobsBurgersApi { .shared }

    func changeCharacter() {
        Task {
            character = await api.fetchCharacter(id: .random(in: 1...501))
        }
    }
}

And finally there is a SwiftUI view that shows the information:

struct CharacterView: View {
    @StateObject var viewModel = CharacterViewModel()

    var body: some View {
        VStack {
            AsyncImage(url: viewModel.character?.image) { phase in
                phase.image?.resizable()
            }
            .aspectRatio(contentMode: .fit)
            .frame(width: 300, height: 300, alignment: .center)
            Spacer()
            Text(viewModel.title)
                .font(.title)
            Text(viewModel.subtitle)
            Text(viewModel.detail)
                .font(.caption)
            if !viewModel.title.isEmpty {
                Link("Learn More", destination: viewModel.learnMore)
                    .font(.caption)
            }
            Button("New Character") {
                viewModel.changeCharacter()
            }.padding()
        }
        .multilineTextAlignment(.center)
        .padding()
    }
}

I'm only loosely familiar with SwiftUI and I used this opportunity to explore it a little bit, so I am sure there are better/more idiosyncratic/efficient ways to write this view, but it isn't really the point of this article. Any SwiftUI experts out there, feel free to let me know how I could improve this. If I like it better than what I've written I'll up date this article and credit you (if you would like me to).

Fixing the Decoding

Now that you have an overview of the app as a whole, let's take a deeper look at how the decoding is working currently. Here's where we're starting:

// in BobsBurgersApi
private static let baseUrl = URL(string: "https://bobsburgers-api.herokuapp.com")!

func fetchCharacter(id: Int) async -> Character? {
    let url = Self.baseUrl
        .appendingPathComponent("character")
        .appendingPathComponent("\(id)")
    guard let (data, _) = try? await URLSession.shared.data(from: url) else {
        return nil
    }
    let character = try? JSONDecoder().decode(Character.self, from: data)
    return character
}

Very often I will come across code that is written like this, at least at first. The logic is fairly straightforward.

1. It builds the url by appending "character" and the given id to the api's base url
2. It tries to get the data from that url
3. It tries to make a Character from that data
4. If it is successful, it returns that character otherwise it returns nil

Right now, we'll find that this always fails to load a character and we don't get any feedback. So, reaching for familiar tools, we might add print statements like this:

func fetchCharacter(id: Int) async -> Character? {
    let url = Self.baseUrl
        .appendingPathComponent("character")
        .appendingPathComponent("\(id)")
    guard let (data, _) = try? await URLSession.shared.data(from: url) else {
        print("Couldn't fetch data")
        return nil
    }
    let character = try? JSONDecoder().decode(Character.self, from: data)
    if character == nil { print("Couldn't decode character") }
    return character
}

// prints: Couldn't decode character

This helps us a tiny bit, because now we can see that it is the decoding that is failing and not fetching the data, but it doesn't tell us anything about why it is failing. Next, we could try printing the data itself out with something like this:

if character == nil { print(String(data: data, encoding: .utf8)!) }

// prints: {"error":"Error while retreiving data with id 157 in route character."}

Again this is a little more helpful. And in this case, it is enough to track down the problem. The api is not returning a character model. This is not a decoding problem, but either a problem with the server or with the request we are making. Looking back at the documentation I notice that the route is actually /characters/:id, not character/:id. So we update our code to use "characters" and now it prints:

{"id":3,"name":"Adam","image":"https://bobsburgers-api.herokuapp.com/images/characters/3.jpg","gender":"Male","hairColor":"Brown","relatives":[{"name":"Unnamed wife"}],"firstEpisode":"\"Mr. Lonely Farts\"","voicedBy":"Brian Huskey","url":"https://bobsburgers-api.herokuapp.com/characters/3","wikiUrl":"https://bobs-burgers.fandom.com/wiki/Adam"}

So now we get an actual character model back, but the decoding is still failing. What is the problem?

We could look through the keys and values one by one and make sure they line up with the Character struct that we have defined. This could work in this context because it is a relatively small model, but it can get very cumbersome if you are fetching a long list or a large/complex model. A better way (and the point of this whole article) is to use the error we get to give us some clues. So lets modify our fetchCharacter function to catch those errors instead of throwing them away and turning things in to optionals. Now it looks like this:

func fetchCharacter(id: Int) async -> Character? {
    let url = Self.baseUrl
        .appendingPathComponent("characters")
        .appendingPathComponent("\(id)")
    do {
        let (data, _) = try await URLSession.shared.data(from: url)
        let character = try JSONDecoder().decode(Character.self, from: data)
        return character
    } catch {
        print(error)
        return nil
    }
}
// note that this code is basically the same amount of code as we had before
// so don't try to use concision as a reason throw away errors

And it prints this when we run it:

keyNotFound(CodingKeys(stringValue: "voiced_by", intValue: nil), Swift.DecodingError.Context(codingPath: [], debugDescription: "No value associated with key CodingKeys(stringValue: \"voiced_by\", intValue: nil) (\"voiced_by\").", underlyingError: nil))

This may look intimidating (and that might be the reason many newer developers discard these errors), but it isn't as bad as it may seem and it is here to help. The error is keyNotFound and if we look a little further we see that the key it couldn't find is "voiced_by". So if we hop back over to the documentation and scroll down to the "Character Schema", we see that the key is actually called "voicedBy". At the same time we might notice that the one we have defined as "wiki_url" is actually "wikiUrl". (If we didn't happen to notice, the error would tell us the next time we ran it.)

So let's fix that, and re-run. In this case we can actually just get rid of the CodingKeys enum because all of our property names match the keys in the JSON.

//enum CodingKeys: String, CodingKey {
//    case id, name, image, occupation
//    case voicedBy = "voiced_by"
//    case wikiUrl = "wiki_url"
//}

Now we can re-run and see some actual characters on screen!

However, if you tap through characters long enough, you'll find that some of them fail to decode. Let's see what the errors have to say:

keyNotFound(CodingKeys(stringValue: "voicedBy", intValue: nil), Swift.DecodingError.Context(codingPath: [], debugDescription: "No value associated with key CodingKeys(stringValue: \"voicedBy\", intValue: nil) (\"voicedBy\").", underlyingError: nil))

Interesting. It is the same error as before, only now we know that we have the key name right. Back to the documentation! Down in the "Character Schema" section we can see:

That is this api's way of communicating that voicedBy will be a String if there is one, or it will be undefined (or nil) if there isn't. In Swift that is actually a different type that we call an optional string (String?, or Optional<String>), so let's update our model. While we're at it, let's check if anything else should be optional.

The only other one I see is occupation, so we'll update that one as well. Now our model looks like this:

struct Character: Codable {
    let id: Int
    let name: String
    let image: URL
    let occupation: String?
    let voicedBy: String?
    let wikiUrl: URL
}

Now, we can tap through Bob's Burger's characters to our heart's content and the decoding should never fail. But if it did, we'd still be printing that error to the console and should be able to track down the issue quickly.

Nested Example

I noticed in the docs that some characters have a relatives array. If a certain character has known relatives who are also in the system, it will return them in an array of a slimmed down character model. That seems like interesting information, so let's add it to our app.

I'll call this version of the model Relative to make it clear what we're dealing with:

extension Character {
    struct Relative: Codable {
        let name: String
        let wikiUrl: URL
        let url: URL
    }
}

// in Character struct
let relatives: [Relative]?

Then, so we can see the relatives on screen, I'll add a new property to the view model and display it on the view:

// in CharacterViewModel
var subtitle2: String {
    let relatives = character?.relatives?.map(\.name).joined(separator: ", ")
    return relatives.map { "Relatives: \($0)" } ?? ""
}

// in CharacterView, after subtitle
if !viewModel.subtitle2.isEmpty {
    Text(viewModel.subtitle2)
}

Now, if you tap through characters, you'll find that many of them don't have relatives but the ones that do will show up in that list. Occasionally though, you'll find one that will fail decoding and it will print something like this error:

keyNotFound(CodingKeys(stringValue: "wikiUrl", intValue: nil), Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "relatives", intValue: nil), _JSONKey(stringValue: "Index 0", intValue: 0)], debugDescription: "No value associated with key CodingKeys(stringValue: \"wikiUrl\", intValue: nil) (\"wikiUrl\").", underlyingError: nil))

It may take a little more effort to get to the bottom of what this error is talking about. It says that it can't find a wikiUrl and we might be tempted to think that is the wikiUrl on our Character model, because it has one of those. But if we keep reading, we can see in the DecodingError.Context that it is looking at the key relatives (which we know is an array), at the 0th index item (meaning the first item in the array), and there it can't find a key called wikiUrl. That means that the first relative in our array doesn't have a wikiUrl.

This is an interesting one because the docs say that wikiUrl is non-optional, but apparently it is. I printed out the json for this character and here is what it returns for relatives:

"relatives" : [
    {
        "name" : "Unnamed child"
    }
]

Apparently, there is at least one Relative who doesn't have a wikiUrl or a url, which we can account for in our model by making those optional (or just not decoding them, since we aren't using them).

struct Relative: Codable {
    let name: String
    let wikiUrl: URL?
    let url: URL?
}

struct Relative: Codable {
    let name: String
//    let wikiUrl: URL
//    let url: URL
}

This is a good reminder that the docs are a good place to start, but they aren't always up to date. If you have access to the developer who is maintaining the backend, it would be good to alert them to the discrepancy so they can either bring the backend logic up to spec or update the docs to match the actual logic. Or, if it is an open source API, you could open an Issue and/or make a contribution!

You can see from this slightly more complex example that these errors are helpful for getting to the root issue even if the problem is deeply nested in your JSON. They may not be in the most human-readable form, but it is possible to work your way down them and gain valuable insights. And, as with most things, you'll get better with practice and will eventually be able to skim them to get everything you need.

Wrap up

The examples in this simple app may seem trivial, but they are reflective of the sort of debugging that is common to work through when you're trying to get a new network interface up and running. I have seen people spend lots of time trying to work out what is wrong with their decoding and come up with all sorts of odd and complex ways to try to pinpoint the problem. But as we have looked at today, errors, while they might seem intimidating and hard to read at first, are often full of helpful information that tells us exactly what the problem is.

So next time you're tempted to throw that error away, don't!

Let me know your opinions on errors and when/when not to use them in the comments. And find the full starter project on this branch and the full finished product on this branch.

Post Scripts

Not all errors are as helpful in debugging your code as they are in the context of decoding. Just as a screw driver is very helpful for driving screws, but less so for driving nails, errors are helpful for tracking down and fixing some problems and less so for others. My intention here was just to point out that they are a useful tool and that they are often overlooked by newer developers. Part of growing as a developer is learning the tools that are available to you and over time you will develop a sense of which one(s) will be helpful in different situations.

Another thing that we did not explore in this article is when/how to communicate to the user that some error has occurred. This will depend on your content/context and a little bit on personal taste. But generally speaking it is good practice to throw errors up the chain at least to the layer where your business logic lives. That way you at least have the information there and can make decisions about how to handle it in ways that make sense for your app.

Whatever the reasons, I think we should stop it. We should strive to write understandable code instead. In this article we will take a look at how it is saves time, it is easier to share with other people, it is easier to fix and it is easier to modify. And then I'll share a few simple tactics for writing more readable code.

Why

Almost all the reasons I could come up with boil down to the fact that it saves time to write longer, more understandable code. It saves you time. It saves time for everyone you work with. It saves time for your users. And time is our most valuable resource. It is one of the few things we cannot get more of, so let's try to make the most of it.

You read code more than you write it. Be mindful during almost any work day and you'll find that this is true. You spend time looking up existing functionality to answer your colleague's question. You spend a bunch of time trying to find the right spot to fix a bug, and then write the one line to fix it. You spend time planning where and how to add a new feature, and then some time writing it. But writing it isn't just a straight shot where you start at the first line and move on to each subsequent one. You reference docs or example code. You check against other parts of the code base to find reusable elements, and to make sure you're not breaking something. You read back over the code you've just written to make sure it does what you think it does. And so on.

So if you spend so much more time reading code than writing it, it makes sense to optimize for readability. Make it easier to reason about. Easier to load into your RAM when you come back to it in six months. Not only will this save you time, but it will also scale better. Other people have to understand your code. You have to understand other people's code. Would you rather spend six hours trying to tease out what a dense block of code actually does or be able to scan it, get the gist, and move on to adding your feature? Or even worse, maybe you didn't take the time to fully understand that dense block of code and you introduce a hard-to-find bug that will be the bane of your existence for the next year. (Not that this has ever happened to me 😁)

The more readable code is, the easier it is to debug. You are less likely to introduce bugs in the first place because they aren't obscured by the complexity. But with the ones that do get through, they are easier to track down because the flow of the logic is obvious. There is nowhere for them to hide.

Finally, the only constant is change. Your code base will change. The developers working on it will change. You will need to onboard new developers when they join the team and you will need to take ownership over code you didn't write when people leave. You will need to change functionality over time. Having readable code makes all of those things easier.

On top of that the language/libraries you are using will probably change over time and there is a high correlation between short/clever code and the most sugary of syntax. That cutting-edge syntax is way more likely to change over time than the fundamentals. This isn't a huge problem, but it is one more way that you are likely to waste some time if you insist on writing the shortest code.

Do This Instead

So how do we write this mythical "readable" code? There is no single thing you can do that will magically make your code readable. But there are many things you can do which will make it more readable. It starts with your mindset. Right now, when you sit down to write some code you may be in the habit of asking yourself something like this "how will I write this in the best/most efficient/most elegant/shortest way possible?" I know that was my mindset for a long time. But now I would advocate that we should instead ask ourselves "how can I write this in such a way that it will make the logic obvious and understandable?" Simply re-framing things in this way is a huge step in the right direction, but I've also got a few practical tips that I try to keep in mind along the way:

Name variables for their role, not their type. Especially in strongly-typed languages like Swift, it isn't necessary to add type information to a variable's name. That information already lives somewhere. But the compiler can't really know what that variable is for. Why is it there? What does it contribute to this piece of code? Give future readers a huge clue by naming that variable in a way that communicates this information.

// don't do this
let redColor = UIColor.red
let array = [24, 31, 27, 45, 37]

// do this instead
let error = UIColor.red
let userAges = [24, 31, 27, 45, 37]

Do one thing at a time. Break code up into discrete pieces of logic. I often come across code where someone is trying to save time or improve performance by mashing multiple pieces of logic into one loop or something. There may be places where that becomes necessary for performance reasons, but it is very difficult to estimate performance of software ahead of time and in my experience developers are pretty bad at estimating the actual causes of performance bugs. It is much better to write it the clear and slow way first, and then test to look for places to improve the performance if necessary. Most of the time the "slow" way will be fast enough.

// don't do this
var ages: [Int] = []
var names: [String] = []

for user in users {
    ages.append(user.age)
    names.append(user.name)
}

// do this instead
let ages = users.map { user in user.age }
let names = users.map { user in user.name }

Prefer clarity over brevity. That is just a fancy way of saying that it is more important to write clear code than short code. Use as longer names for functions if it helps. Name anonymous closer arguments. Name a variable even if it is only used once. Break down large functions into smaller parts. Etc.

// both versions assume this extension
extension String {
    func orIfEmpty(_ replacement: String) -> String { isEmpty ? replacement : self }
}

// don't do this, real solution I found online by googling "Fizz Buzz solutions"
(1...15).map { (($0 % 3 == 0 ? "Fizz" : "") + ($0 % 5 == 0 ? "Buzz" : "")).orIfEmpty("\($0)") }.forEach { print($0) }

// do this instead
// name the function so that it is clear what it does at the call site
func playFizzBuzz(from start: Int = 1, to end: Int) {
    playFizzBuzz(start...end)
}

// allow users to user whichever interface makes sense at call site
func playFizzBuzz(_ range: ClosedRange<Int>) {
    let answers = range.map { number in // name closure arguments
        singleFizzBuzz(for: number)
    }

    answers.forEach { answer in
        print(answer)
    }
}

// pull out discrete pieces of logic to separate functions
private func singleFizzBuzz(for number: Int) -> String {
    // use language-provided functions where you can
    var wordReplacement = number.isMultiple(of: 3) ? "Fizz" : ""
    wordReplacement += number.isMultiple(of: 5) ? "Buzz" : ""
    return wordReplacement.orIfEmpty("\(number)")
}

// maybe a bit overkill for fizz buzz, but it illustrates the principle

Follow the conventions of the language and codebase. If you're an iOS developer writing Swift like I am, a good start is to read through the API design guidelines (where you'll notice some similarities with my advice here). If the code base you're working in has agreed-upon conventions, follow them! Even if it goes against your personal preference. Clarity is more important that your opinions. If you really care about something, get the team to agree upon a new convention and offer to migrate the existing code as much as you are able.

Finally, always be refactoring. If you don't know how, read Martin Fowler's book on the topic. (Even if you do know how, you should probably read it anyways.) Make a lot of small changes in the direction of cleaner/simpler/easier to understand code over time and it will add up. Any time you make changes to some part of the code stop and ask yourself this question: "What could I do in five minutes that would make it easier for the next person to understand?" Don't waste a ton of time on it, that is the opposite of what we're trying to do. But give it a couple minutes and you'll find something. Rename a variable. Break up the function. Add a signpost comment. Follow the boy scout rule. Always leave the code cleaner than you found it.

Wrap Up

That's all I've got for today. Spend less time making your code short and clever and spend more time making it readable. Shift your mindset. Make lots of small changes to improve readability. They will compound into massive improvements over time. And they will save you time, they will make your code easier to change, easier to debug and easier to communicate.

Let me know what you think. How do you go about making your code more readable? What are the cases where short and clever code is better?

If you don't already know, my day job is working on an app called Hallow. It is a prayer and meditation app (in the vein of Calm or Headspace) with Christian-themed content, but this is a crash that you could run into in practically any iOS app. And a lot of the process is relevant to finding/fixing bugs in any environment, not just iOS apps.

The Report

A few weeks ago I was looking through our bug reports (we use bugsnag) and I noticed a crash in our app. It was reported as having been introduce in the latest version of the app. It was listed as "unhandled". And every instance had a very short stacktrace which ended in a view that very few users ever see. The error message was EXC_BAD_ACCESS, with this detail: Attempted to dereference garbage pointer 0x10. The address of the garbage pointer was different in various instances (though many of them were 0x10 and 0x20) but everything else was the same.

My Thoughts

Here are some of my initial thoughts on this crash, as I remember them now and from looking back through Slack messages to my coworkers.

• the view in the stacktrace was probably irrelevant. I'm not sure why it is showing up consistently, but there were way more of these crashes than users who ever get to that view. Probably a red herring
• the crash was grouped in the reports by stacktrace, but this was a memory bug, having to do with a bad pointer. That meant a couple of things. There were probably other crashes with different stacktraces but with the same root cause. This bug may not have been introduced in the latest version, but bugsnag may just be unable to link the crashes in previous versions with the same cause
• EXC_BAD_ACCESS is not a particularly helpful error message, but knowing that we are trying to deference a garbage pointer gives me something to go off of. Instruments has a tool for profiling zombies which is helpful for tracking down exactly that sort bug.

Discovery

I confirmed the first two thoughts by doing a cursory glance of the other crashes in our logs. There were several other ones with the same Attempted to dereference garbage pointer 0x10. but with different stacktraces in the same version of the app. I took that to mean that the view bugsnag claimed was the issue was not actually the issue. There were also similar numbers of crashes in the last several versions of the app with that same message, which I took to mean that the version of the app that bugsnag claimed introduced it actually did not. That helped me broaden my scope as I looked through recent code changes. In retrospect, I should have dug back through versions and tried to find the version where this bug actually was introduced, but I didn't think of it at the time.

I also spent twenty minutes or so digging through the code looking into things that I thought might be the issue. In the grand scheme of things, this was not a particularly good use of time because I didn't really have enough information to go off of and I didn't find anything helpful. I should have gone straight to the zombie profiler.

Profiling The App

I knew Instruments has a tool called "Zombies" which is used to track down over-released objects (which is what leads to garbage pointers), but I had only used it once several years ago, so I did some googling and found this article about how to use it. I skimmed it and felt equipped enough to dive in and see what I could find.

Fortunately for me, it was incredibly easy. I started the app in Instruments, tapped on a piece of content and it immediately crashed and told me I had over-released an object. I clicked into the flag, as described in that article, and found that the object was a view controller representing a certain block of content in the app. I tried profiling several other times and found the same object every time, so I felt pretty confident that I knew where to dig in on the code.

The Culprit?

The specifics of the bug in the case are not terribly important. I am trying to document the process I went through to find it and fix it more than trying to document this specific fix, but for those of you who are curious, it basically boiled down to this:

• We have a collection view cell that we use to wrap views.
• We were sticking the aforementioned view controller's view into this cell in collectionView(_:cellForItemAt:)
• Nothing was holding on to that view controller, just a local reference. It was never added as a child view controller to any other view controller.

The fix? Our first attempt was to just keep a reference to that view controller in the collection view cell, and remove it on reuse.

Validation

I re-ran the zombie profiler after implementing this fix and found that I could navigate all around the app without it crashing, which I took to mean that the issue had been resolved. But I knew that we wouldn't know if it really fixed the issue until we got it out to users and saw how it acted in the real world. So that's what we did. We merged the fix in for the next release and then closely monitored how it acted.

Here's what we saw:

As you can see, the stability for the version with the fix consistently stays above the stability for the version before it. It's not a huge percentage difference (because we have quite a few users and only a small number of them ever encountered this crash), but it got rid of a few hundred crashes per day, so it probably made a few people's day better, even if they didn't realize it. 🙌🏼

Wrap up

So what can we learn from this experience? I have a couple of takeaways. First, take a breath. It always pays to spend some time thinking through, reasoning about, and talking out bugs that you don't understand. If I had just taken the stack trace and tried to dig into that specific view I would have wasted a bunch of time. Second, it is important to do your homework thoroughly in cases where there is not a clear line between the crash report and the bug causing it. If I had spent a little more time investigating crash reports, I may have been able to narrow down the version that introduced the bug, which may have made the fix more obvious to me. Third, get familiar with the tools available. Most iOS developers I know are pretty comfortable with print statements and breakpoints, but way fewer of them are comfortable with Instruments (or have ever even opened it). It probably doesn't make sense to become an expert in of all the various tools before you actually need them, but you should at least learn about what is available to you so when the time comes that you need one, you'll know that it exists. This should get you started.

And finally, sometimes you can actually fix bugs that are beyond your ability! I know it can feel hopeless when you're looking at a cryptic crash log and trying to reason about something that is theoretical. And sometimes you won't find the answer. But if you stick with it, keep trying, and seek out the help you need, you can actually fix some of these bugs and grow as a developer in the process. When it happens, it feels amazing, but even when it doesn't you can still learn from the experience.

Let me know about a time you tried to tackle a bug that you felt was too hard for you. Did you find the fix? What did you learn?

Then he did something you should do when you have those feelings. He reached out to people who knew him, people he trusted, and people who had been through similar situations. He asked for advice. Advice on what do to about imposter syndrome and advice on how to spin up at a new job quickly. I happened to be one of the people he asked and so I wrote him a message with my thoughts. It seemed to help him, so I decided to spruce it up a little bit and give the same advice to you.

This advice assumes that you have had at least one job where you felt like you knew what you were doing when you left it. It also assumes that you objectively have the technical and soft skills necessary to do the job that you're hired for. That is, it assumes that you are not actually an imposter. (Don't try to trick people into thinking that you know more than you do to get a better job title. It won't work for very long.) And, it assumes that your new job is a good and healthy work environment. There are places where this advice will not work and my advice to you then would be to find a new place to work. With all that said, let's go.

It Will Feel Like You Don't Know Enough

The first point is that it will almost certainly feel like you know less than you did at your previous job. Because you do. You probably haven't lost any of your technical skills (you may even be sharper after brushing up for interviews and whatnot), but what you don't have now is familiarity. And unfortunately for you, familiarity is going to be strongly correlated with velocity. This can compound in a couple of way that leave you feeling useless.

You have switched from a context where you had a lot of familiarity to one where you have very little. And because you are a human with recency bias, you will compare your velocity now with your velocity when you left your last job. But really, you should compare it with your velocity when you started your last job. Did it take you two weeks to merge your first PR at the last job? If it takes you one week this time, you've cut that ramp up time in half. Regardless of actual metrics, know that it will take you less time to reach the same level of familiarity at the new company as it did at your last company because you have a whole set of experience under your belt now that you didn't then. Disclaimer: You shouldn't only look at ramp up time because this is also largely dependent on the quality of your new employer's documentation and onboarding process.

You have switched from a context where you may have been one of the people with the most familiarity to one where you likely have the least. The people around you at the new job will be familiar with the processes/patterns/technologies/code/etc in ways that you are not (yet). It will feel like everyone you work with is flying and you're trying to keep up on a unicycle. That's (probably) not because they are better developers than you, it is largely because they have been here longer and are more familiar with the requirements at this particular job. You will get there in time too.

Regardless of how you feel, try to remind yourself that they wouldn't have hired you as a senior if they didn't think you were qualified for that title. No one knows everything. And you probably know a lot more than you feel like you do. I can tell you from experience that if you make any effort at all to continue learning and growing as an engineer after you get a job, you are already on trajectory to reach the upper echelon of engineers.

How to Spin Up Like A Senior

Write down anything that doesn't make sense to you. Anything you get stuck on. Any questions you have (this includes questions about how the business works and why things are the way they are). Then you can just fire them off one after another whenever you meet with your onboarding buddy or manager or whoever, and you'll look really prepared. No one expects that you will have a high velocity right when you first start, but they will be impressed if you are actively participating in the process and pushing forward. Bonus points if you use those questions/answers to improve their existing documentation for the next person who has to onboard.

Look for quality of life improvements that you can make for other people. Tackle tech debt and refactors where you can because they are helpful for the team and they will help you get familiar with the codebase/patterns. I'm not saying take on every bit of menial work that exists, but everywhere I've ever worked has had at least a couple of things that they have been meaning to get to and no one has time for. You typically don't have too many responsibilities right when you first start, so use that time to knock a couple of things off the list. Refactor those last few legacy classes to the current pattern, fix the dark mode or accessibility bug, or whatever it is that needs to be done.

Stick to the style guide. Code style is not the place to differentiate yourself when you start. If there is a style guide at your new company, it probably took a while to get to and there is probably at least one person with very strong opinions about it. Do your best to stick to it when you start and if there is something that you have strong opinions about, you'll have a much better idea of when/where to bring it up in three to six months. If there isn't an existing style guide, see if you can head up the process to establish one and get a linter in place.

Meet as many people as you can (especially if you're remote). Ask lots of questions about them, their role at the company and how the business works. It has been incredibly helpful in my own career to figure out who does what (meaning, who I should ask about different kinds of things) and what the levers of the business are so you can understand why decisions are made and when to speak up with ideas if you have them. On top of that, people like to work with people that they like. Be personable, develop your soft skills and make some friends.

Starting a new job is basically the same as getting over a cold. Prepare to feel out of sorts for a few weeks (or months), but know that you'll get over it eventually. Get lots of sleep and drink lots of fluids. Work hard and do your best, but make sure you establish a good work/life balance from the start.

Wrap Up

So there you go, that is my advice as it stands today. Have confidence in yourself, know that your familiarity (and velocity) will grow over time, and there are things you can do that both provide value and help you accelerate growing that familiarity. How about you? What has your experience been? What advice would you give a friend to help them get over imposter syndrome or spin up at a new job?

Header photo by Marten Bjork on Unsplash.

And please excuse the quality of the gifs. Gradients don't play super well with a limited palette, but it was the easiest way I could find to have some simple examples of what the movement of these sheets looks like.

Finding The Sheet Presentation Controller

The first thing I noticed is that the sample code doesn't actually compile (at least not on the version of Xcode I'm running). UIViewController doesn't have a property called sheetPresentationController. It is accessible through the presentationController property, assuming the modalPresentationStyle is set to pageSheet or formSheet, but you have to cast it as a UISheetPresentationController to access the new properties. I added this shim for now to get the sample code to run, but I assume the new sheetPresentationController property will be made available eventually.

extension UIViewController {
 var sheetPresentationController: UISheetPresentationController? {
   presentationController as? UISheetPresentationController
 }
}

With that available, I had a route to start adding some sheets:

override func viewDidLoad() {
    super.viewDidLoad()

    view.backgroundColor = .systemTeal
    presentSheet()
}

override func viewDidAppear(_ animated: Bool) {
    presentSheet()
}

private func presentSheet() {
    let viewController = UIViewController()
    viewController.view.backgroundColor = .systemOrange

    let sheet = viewController.sheetPresentationController
    sheet?.detents = [.medium(), .large()]

    present(viewController, animated: true)
}

That gives us a bottom sheet like this:

Making It Look Nice

It's pretty cool out of the box. It looks good, you can expand it up to full height and back and dismiss it like you would expect. But I wanted to see how customizable it is, see what it is good for and what it isn't, etc. And I want it to look good in the process, so let's get some gradients in there.

First, I'm using this simple GradientView which is a UIView subclass that has a CAGradientLayer as its layer class and provides direct access to it.

class GradientView: UIView {
    override class var layerClass: AnyClass {
        return CAGradientLayer.self
    }

    var gradientLayer: CAGradientLayer {
        return layer as! CAGradientLayer
    }
}

Then, I set the view of ViewController to be that GradientView

private lazy var contentView: GradientView = .init()

override func loadView() {
    view = contentView
}

And then make some semi-random combinations of colors:

let colorSets: [[UIColor]] = [
    [.systemTeal, .systemGreen, .systemOrange],
    [.systemRed, .systemPurple, .systemBlue],
    [.systemPink, .systemIndigo, .systemTeal],
    [.systemPink, .systemYellow, .systemGreen],
    [.systemGreen, .systemTeal, .systemPurple],
    [.systemYellow, .systemPink, .systemIndigo],
    [.systemRed, .systemYellow, .systemTeal]
]

// in viewDidLoad()
contentView.gradientLayer.colors = colorSets.randomElement()!
                                            .map(\.cgColor)

To add a little more variety, I also added a couple of different start points:

let startPoints: [CGPoint] = [
    CGPoint(x: 0.5, y: 0),
    CGPoint(x: 0, y: 0.3),
    CGPoint(x: 0.5, y: 1),
    CGPoint(x: 0, y: 0.8),
    CGPoint(x: 1, y: 0.3),
    CGPoint(x: 1, y: 0.8),
]

extension CGPoint {
    func opposite() -> CGPoint {
        let x = 1 - self.x
        let y = 1 - self.y
        return CGPoint(x: x, y: y)
    }
}

// in viewDidLoad()
let start = startPoints.randomElement()!
contentView.gradientLayer.startPoint = start
contentView.gradientLayer.endPoint = start.opposite()

FInally, to add new sheets, I added a button instead of doing it automatically in viewDidAppear. This allows it to be recursive, so you can just keep adding new iterations onto the stack. This is using the new UIButtonConfiguration, which I won't go into detail on here, but maybe in a future article. Needless to say, it is also pretty nice.

private let addButton = UIButton(configuration: .plain())

// in viewDidLoad()
let arrowConfig = UIImage.SymbolConfiguration(pointSize: 36,
                                              weight: .black)
let arrow = UIImage(systemName: "arrow.clockwise",
                    withConfiguration: arrowConfig)
addButton.configuration?.image = arrow
addButton.tintColor = .white
let addAction = UIAction { _ in self.presentSheet() }
addButton.addAction(addAction, for: .primaryActionTriggered)

view.addSubview(addButton)
addButton.centerAnchors == view.centerAnchors

// in presentSheet()
sheetPresentationController?.animateChanges {
    sheetPresentationController?.selectedDetentIdentifier = .large
}

let viewController = ViewController()

That leads to something that looks like this.

Customizing Things

Now that's looking a lot more fun! And it gives us a pretty solid foundation to mess with some of the interface talked about in the WWDC session. The first thing I tried as messing with the preferredCornerRadius, which I found is not yet a property on UISheetPresentationController. But there is a private version called __preferredCornerRadius, which, again, I'm assuming will be fixed before the release of the GM. To mess around with this, I added a slider, that will let us set it in the app.

static var preferredCornerRadius: CGFloat = 24
private let cornerRadiusSlider = UISlider()

// in viewDidLoad()
cornerRadiusSlider.maximumValue = 60
cornerRadiusSlider.minimumValue = 0
cornerRadiusSlider.maximumTrackTintColor = .white.withAlphaComponent(0.3)
cornerRadiusSlider.minimumTrackTintColor = .white
cornerRadiusSlider.value = Float(Self.preferredCornerRadius)

let updateRadiusAction = UIAction { _ in self.updateRadius() }
cornerRadiusSlider.addAction(updateRadiusAction, for: .primaryActionTriggered)

view.addSubview(cornerRadiusSlider)
cornerRadiusSlider.horizontalAnchors == view.readableContentGuide.horizontalAnchors + 20
cornerRadiusSlider.topAnchor == addButton.bottomAnchor + 20

// in presentSheet()
sheet?.__preferredCornerRadius = Self.preferredCornerRadius

private func updateRadius() {
    let radius = CGFloat(cornerRadiusSlider.value)
    sheetPresentationController?.__preferredCornerRadius = radius
    Self.preferredCornerRadius = radius
}

This works pretty much as you would expect. As you move the slider, the corner radius updates.

Interestingly, setting the preferred corner radius on the sheet presenter doesn't affect the view behind if it is at half-height, but it does at full height.

Even more interesting, it only affects the view immediately behind it, even at full height.

Most of these things shouldn't really affect much in practice, because how often are you presenting sheet on top of sheet on top of sheet, or allowing the user to change the corner radius of a view at will? But it is good to know where it might fall down.

prefersGrabberVisible, prefersEdgeAttachedInCompactHeight, and smallestUndimmedDetentIdentifier are all accessible and work expected. I added these methods to expose them in the app, and hooked them up to respective buttons.

private func updateGrabber() {
    showsGrabberButton.isSelected.toggle()
    sheetPresentationController?.animateChanges {
        sheetPresentationController?.prefersGrabberVisible = showsGrabberButton.isSelected
    }
}

private func updateEdgeAttached() {
    edgeAttachedButton.isSelected.toggle()
    sheetPresentationController?.animateChanges {
        sheetPresentationController?.prefersEdgeAttachedInCompactHeight = edgeAttachedButton.isSelected
    }
}

private func updateDimming(_ detent: Detent) {
    sheetPresentationController?.animateChanges {
        sheetPresentationController?.smallestUndimmedDetentIdentifier = detent.identifier
    }
}

And it all works well on iPad too, although you have to access the sheet controller through popoverPresentationController?.adaptiveSheetPresentationController if your view is presented in a popover.

One thing that is really cool is that, if you set the sheet to not dim the view behind it, you can still interact with the view controller behind it. That doesn't mean much in this toy app, but the WWDC video had a good example of showing an image picker on the bottom (in the front view controller) and displaying the image picked on the top (in the back view controller).

Wrap Up

All in all, I think it looks pretty slick and (mostly) works like you would expect it to out of the box. If they get the last few pieces of the interface cleaned up before the GM release, I'll definitely be using it my apps when the design calls for it. Download my toy app and play around with this stuff for yourself in this repo.

• For all the illustrations in the app I just took screenshots of the actual app and cropped them to size. They are not the full versions of the illustrations and they are not really even formatted correctly for use in an iOS app. I tried to spend as little time as possible on that prep.
• We will get the fonts, colors and icons as close as we can with just using the system versions. I am pretty sure the font and icons that Airbnb actually uses would require a license and I don't care that much about making this exact. With the way we organize it, it would be pretty easy to swap in the real ones if you want to take that step yourself.
• We will not do any business logic. We will hard code all the data and not handle any user actions. Again, this is not meant to be production code, just an exploration of some UI techniques.
• There is a good chance that Airbnb will look different by the time you see this. Honestly, there's a non-zero chance that it will change before I finish writing this, so the live app will probably look different than what you see me build, but the layout/principles should be pretty much the same. (Editorial note: it has already changed before I was able to finish writing this series, but I have a few screenshots of what the app looked like before, and we'll just build up to the spec that I created.)

Here's what our final product will look like:

With all that said, let's go.

Animating The Header

Now that we have the collection view built out, the only thing left to do is deal with the header. Let's start by laying that out. It basically consists of a "card" with a background image, and search bar which has its own little container, a big title label with a button and a separator at the bottom to separate it from the collection view.

// In HeaderView.swift

private let card = UIView()
private let imageView = UIImageView()
private let searchContainer = UIView()
private let searchBar = UIButton(type: .roundedRect)
private let titleLabel = UITextView()
private let button = UIButton(type: .roundedRect)
private let separator = UIView()

A couple of things to call out. The "search bar" is just a button. I'm doing that primarily because it is what the Airbnb app is doing. If you go look in the app you'll find if you tap on the search bar it is just a button that navigates you to a "search view". And the title label is actually a text view. I went with that because it was the easiest way I could find to get the line height to look the way it is in the Airbnb app. You'll see why in a moment.

Next, we need to do some updates so these things all look like they should:

// In HeaderView.swift

// in configure()
backgroundColor = .black

card.layer.maskedCorners = [.layerMaxXMinYCorner, .layerMinXMinYCorner]
card.layer.cornerRadius = 20
card.layer.masksToBounds = true

imageView.contentMode = .scaleAspectFill
imageView.image = UIImage(named: "background")

searchContainer.backgroundColor = .systemBackground
searchContainer.setBackgroundAlpha(0)

searchBar.backgroundColor = .secondarySystemBackground
searchBar.layer.cornerRadius = 22
searchBar.setTitle("Where are you going?", for: .normal)
searchBar.setTitleColor(.label, for: .normal)
searchBar.setImage(UIImage(systemName: "magnifyingglass"), for: .normal)
searchBar.tintColor = .systemPink
searchBar.titleLabel?.font = .custom(style: .button)
searchBar.imageView?.contentMode = .scaleAspectFit
searchBar.imageEdgeInsets = .init(top: 14, left: 0, bottom: 14, right: 4)

titleLabel.text = "Go\nNear"
titleLabel.textColor = .white
titleLabel.font = .custom(style: .largeTitle)
titleLabel.setLineHeightMultiple(to: 0.7)
titleLabel.isScrollEnabled = false
titleLabel.isEditable = false
titleLabel.isSelectable = false
titleLabel.backgroundColor = .clear

button.backgroundColor = .secondarySystemBackground
button.layer.cornerRadius = 6
button.setTitle("Explore nearby stays", for: .normal)
button.setTitleColor(.label, for: .normal)
button.titleLabel?.font = .custom(style: .button)
button.contentEdgeInsets = .init(top: 8, left: 8, bottom: 8, right: 8)

separator.backgroundColor = .quaternaryLabel

// in constrain()
addSubviews(card, titleLabel, button, separator)
card.addSubviews(imageView, searchContainer)
searchContainer.addSubview(searchBar)

heightAnchor == 600

card.topAnchor == 40
card.horizontalAnchors == horizontalAnchors
card.bottomAnchor == bottomAnchor

imageView.edgeAnchors == card.edgeAnchors

searchContainer.topAnchor == card.topAnchor
searchContainer.horizontalAnchors == card.horizontalAnchors
searchContainer.heightAnchor >= 60

searchBar.heightAnchor == 44
searchBar.topAnchor >= searchContainer.topAnchor + 24
searchBar.topAnchor >= safeAreaLayoutGuide.topAnchor + 12
searchBar.horizontalAnchors == searchContainer.horizontalAnchors + 24
searchBar.bottomAnchor == searchContainer.bottomAnchor - 12

titleLabel.topAnchor == safeAreaLayoutGuide.topAnchor + 160
titleLabel.leadingAnchor == leadingAnchor + 24

button.topAnchor == titleLabel.bottomAnchor
button.leadingAnchor == titleLabel.leadingAnchor

separator.heightAnchor == 1
separator.horizontalAnchors == horizontalAnchors
separator.bottomAnchor == bottomAnchor

You'll notice that we're using a couple of new fonts here, and a few new helper methods that we haven't written yet. Let's add the button font and the large title font:

// In Extensions/UIFont+Custom.swift

private static var largeTitle: UIFont {
    return UIFontMetrics(forTextStyle: .largeTitle)
        .scaledFont(for: .systemFont(ofSize: 64, weight: .heavy))
}

private static var button: UIFont {
    UIFontMetrics(forTextStyle: .headline)
        .scaledFont(for: .systemFont(ofSize: 13, weight: .semibold))
}

// in Style
case largeTitle
case button
// other cases...

// in custom(style:)
case .largeTitle: return largeTitle
case .button: return button

Then we'll add a helper on UIView that will just let us adjust the alpha component of the background a little more concisely.

// In Extensions/UIView+Helpers.swift

func setBackgroundAlpha(_ alpha: CGFloat) {
    backgroundColor = backgroundColor?.withAlphaComponent(alpha)
}

Finally, we'll add a helper on UITextView which will allow us to set the line height multiple to match the design.

// In Extensions/UITextView+Helpers.swift

func setLineHeightMultiple(to lineHeightMultiple: CGFloat = 0.0) {

    let paragraphStyle = NSMutableParagraphStyle()
    paragraphStyle.lineHeightMultiple = lineHeightMultiple

    let attributedString: NSMutableAttributedString
    if let attributedText = attributedText {
        attributedString = NSMutableAttributedString(attributedString: attributedText)
    } else if let text = text {
        attributedString = NSMutableAttributedString(string: text)
    } else {
        return
    }

    attributedString.addAttribute(.paragraphStyle,
                                  value:paragraphStyle,
                                  range:NSMakeRange(0, attributedString.length))

    attributedText = attributedString
}

If you run the app right now you'll see that it looks pretty close to the spec.

One difference is that the space above the card is not quite right. That is because we're not accounting for the safe area yet. Let's do that now.

// In HeaderView.swift

// add a properties for holding the height and a reference to the constraint
private var maxTopSpace: CGFloat = 40
private var topSpaceConstraint = NSLayoutConstraint()

// capture the reference in constrain()
topSpaceConstraint = card.topAnchor == topAnchor + maxTopSpace

// update the height and constraint whenever the safe area insets change
override func safeAreaInsetsDidChange() {
    maxTopSpace = 40 + safeAreaInsets.top
    topSpaceConstraint.constant = maxTopSpace
}

Another difference is that the status bar isn't the right color. We'll need to fix that in HomeViewController:

// In HomeViewController.swift

private var statusBarStyle: UIStatusBarStyle = .lightContent

override var preferredStatusBarStyle: UIStatusBarStyle {
    statusBarStyle
}

Making It Collapsible

Now it looks like it should, but if you scroll the collection view, you'll find that it is stuck at the size it is. Let's fix that.

We're going to add a method called updateHeader which will be what other views will call when they want the header to change size. It will take the old Y offset and the new Y offset and it will return a CGFloat which reflects an updated Y offset. We need to return the updated offset so the caller (the scrollview) can update its offset as its size changes. If you don't do this the scroll will look a little "bouncy" under certain circumstances. I know that is a lot, but it will all fall into place as we put the pieces together. For now, it looks like this:

// In HeaderView.swift

    func updateHeader(newY: CGFloat, oldY: CGFloat) -> CGFloat {
        // do calculations and update view

        return newY
    }

Now we need to call that method, which we're going to do in HomeView in a UIScrollViewDelegate method called scrollViewDidScroll(_:)

// In HomeView.swift

private var oldYOffset: CGFloat = 0

// in configure()
collectionView.delegate = self

// at bottom of file
extension HomeView: UICollectionViewDelegate {
    func scrollViewDidScroll(_ scrollView: UIScrollView) {
        let yOffset = scrollView.contentOffset.y

        let updatedY = headerView.updateHeader(newY: yOffset, oldY: oldYOffset)
        scrollView.contentOffset.y = updatedY

        oldYOffset = scrollView.contentOffset.y
    }
}

You can see that we are grabbing the current Y offset, passing it and the old one to updateHeader and using the returned CGFloat to update the scroll view's offset. Finally, we update the old offset to be the current one. Right now you can run the app and you'll find that it runs but doesn't do anything different. Which is what we'd expect. So far, we've just added some unnecessary function calls that pass around numbers. But now, let's make it collapse.

If we think about it for a second, we'll realize that there are three criteria we need to meet in order to collapse:

1. We need the content to be moving up. The user's finger needs to be moving the scrollview upwards.
2. We need for to be within the bounds of the content, not beyond it. (This is more important in the expanding logic.)
3. We need for there to be room to continue collapsing the header. If it is already as small as it can go, we can't collapse any more.

// In HeaderView.swift

// in updateHeader(newY:oldY)
let delta = newY - oldY

let isMovingUp = delta > 0
let isInContent = newY > 0
let hasRoomToCollapse = currentOffset > minHeight
let shouldCollapse = isMovingUp && isInContent && hasRoomToCollapse

if shouldCollapse {
    currentOffset -= delta
    return newY - delta
}

This won't compile yet, because we need to add a couple of header variables, but you should be able to see the logic. If we meet all the criteria for collapsing, we'll shrink the header by the amount the user has moved their finger, and we'll return an updated offset so the scroll view can move along with it.

Now we need to add a few more things to get this to work. We'll add a minHeight and maxHeight to keep track of the bounds of our header. We'll also add a heightConstraint variable, so we can update the constrained height as we need to. Finally, we'll add currentOffset which will just be a wrapper around the height constraint and which will call our animation function any time it changes.

// In HeaderView.swift

private lazy var minHeight: CGFloat = { 44 + 12 + 12 + safeAreaInsets.top }()
private let maxHeight: CGFloat = 600
private var heightConstraint = NSLayoutConstraint()

// in constrain()
heightConstraint = heightAnchor == maxHeight

// in animation extension
private var currentOffset: CGFloat {
    get { heightConstraint.constant }
    set { animate(to: newValue) }
}

private func animate(to value: CGFloat) {
    let clamped = max(min(value, maxHeight), minHeight)
    heightConstraint.constant = clamped
}

With that, you should be able to run the app and see the header collapse as you scroll the collection view up.

Expanding The Header

You may notice that it is only one way right now. You can collapse the header, but you can't expand it back without restarting the app. That will be the next problem we tackle. Again, we have three criteria we need to meet.

1. We need the content to be moving down.
2. We need to be beyond the scrollview's content. This means we won't expand the header any time the user scrolls down, we'll only expand it if they are at the end of the content.
3. We need to have room to expand the header.

// In HeaderView.swift

// in updateHeader(newY:oldY:)
let isMovingDown = delta < 0
let isBeyondContent = newY < 0
let hasRoomToExpand = currentOffset < maxHeight
let shouldExpand = isMovingDown && isBeyondContent && hasRoomToExpand

if shouldCollapse || shouldExpand {
    currentOffset -= delta
    return newY - delta
}

The logic for what we need to do if we want to expand will be the same as when we collapse, because the delta will be negative so it will have the effect of adding to the currentOffset. That means we can put it all in one if block.

Polishing The Animation

Now we've got it working, but it does not quite match the spec. The card needs to move up and the search container needs to fade in, but neither of them start until we're halfway through the movement. So let's take a couple of steps to match that. First, let's get a normalized value of where we're at in the transition. That means a number from 0.0 to 1.0 which will reflect what percentage of the way through we currently are. Then, we'll use that to break out into a function that will handle animations 0-50% and another that will handle 50-100%.

// In HeaderView.swift

//in animate(to:)
let normalized = (value - minHeight) / (maxHeight - minHeight)
switch normalized {
case ..<0.5:
    animateToFifty(normalized)
default:
    animateToOneHundred(normalized)
}

private func animateToFifty(_ normalized: CGFloat) {
    let newTop = normalized * 2 * maxTopSpace
    topSpaceConstraint.constant = newTop
    searchContainer.setBackgroundAlpha(1 - normalized * 2)
}

private func animateToOneHundred(_ normalized: CGFloat) {
    topSpaceConstraint.constant = maxTopSpace
    searchContainer.setBackgroundAlpha(0)
}

Updating The Status Bar

Now that's looking pretty good! The last thing that we need to fix is the status bar. It doesn't automatically update when we put white content behind it, so we need to do that update ourselves. As we discussed earlier though, we need to handle that in the view controller. So we'll need to send delegate methods up to let the view controller know that it might want to update the status bar. First, let's define a delegate protocol, add a delegate to our view and a local property to keep track of what the view thinks the style should be.

// In HeaderView.swift

protocol HeaderViewDelegate: AnyObject {
    func updateStatusBarStyle(to style: UIStatusBarStyle)
}

//in HeaderView
weak var delegate: HeaderViewDelegate?

private var statusBarStyle: UIStatusBarStyle = .lightContent {
    didSet { delegate?.updateStatusBarStyle(to: statusBarStyle) }
}

Then we need to move up a layer to the HomeView and do the same thing, to pass the message along:

// In HomeView.swift

protocol HomeViewDelegate: AnyObject {
    func updateStatusBarStyle(to style: UIStatusBarStyle)
}

// in HomeView
weak var delegate: HomeViewDelegate?

// in configure()
headerView.delegate = self

// at the bottom of the file
extension HomeView: HeaderViewDelegate {
    func updateStatusBarStyle(to style: UIStatusBarStyle) {
        delegate?.updateStatusBarStyle(to: style)
    }
}

Then we need to adopt the delegate protocol in the HomeViewController

// In HomeViewController.swift

// in loadView()
contentView.delegate = self

// at the bottom of the file
extension HomeViewController: HomeViewDelegate {
    func updateStatusBarStyle(to style: UIStatusBarStyle) {
        statusBarStyle = style
        UIView.animate(withDuration: 0.4) {
            self.setNeedsStatusBarAppearanceUpdate()
        }
    }
}

Finally, we just need to make a check in animateToFifty to see if we should change the status bar style or not.

// In HeaderView.swift

if newTop < 24 && statusBarStyle != .darkContent {
    statusBarStyle = .darkContent
} else if newTop > 24 && statusBarStyle != .lightContent {
    statusBarStyle = .lightContent
}

I picked 24 points as a rough estimate of when the card passes by the status bar. It's not perfect, but it still feels pretty good.

There is just one minor problem left, and it is one that the actual Airbnb app doesn't have to handle. In our app, we are supporting dark mode (as good iOS citizens should), but in even in dark mode we want the space behind the card to be black. That means the status bar style is right when the header is expanded (it should still be white), but it should also stay white when the header is collapsed, because the search container background is now black too. All we need to do to fix that is add a check in the view controller. If the new status bar style is light and the user interface style is dark, we'll just return early:

// In HomeViewController.swift

// in updateStatusBarStyle(to:)
if statusBarStyle == .lightContent && traitCollection.userInterfaceStyle == .dark {
    return
}

And now it looks great! It matches the spec, and it even works nicely in dark mode.

Caveats

• There are still some parts of the animation that aren't exactly right. In the real version, it bounces past the final height of the header if you pull on it, and you can swipe in the header itself to do the animation. Both of those things should be accomplishable within the framework I've set up, but I'll leave that as an exercise for you.
• In the actual Airbnb app the "Explore nearby stays" button animates a little bit when it is highlighted, rather than changing the color of the text. I didn't want to take the time to go into that here, but it should be pretty simple to add.

Wrap Up

In this article we laid out the header view, we looked at one technique for animating a header based on the user's interaction in a scroll view, and we looked at some techniques for customizing that animation that keep our code fairly straightforward and easy to read. This is the last article in this series and I hope that you learned something or at least had fun. See you in the next one!

Check out the code up to this point in this repo.

• For all the illustrations in the app I just took screenshots of the actual app and cropped them to size. They are not the full versions of the illustrations and they are not really even formatted correctly for use in an iOS app. I tried to spend as little time as possible on that prep.
• We will get the fonts, colors and icons as close as we can with just using the system versions. I am pretty sure the font and icons that Airbnb actually uses would require a license and I don't care that much about making this exact. With the way we organize it, it would be pretty easy to swap in the real ones if you want to take that step yourself.
• We will not do any business logic. We will hard code all the data and not handle any user actions. Again, this is not meant to be production code, just an exploration of some UI techniques.
• There is a good chance that Airbnb will look different by the time you see this. Honestly, there's a non-zero chance that it will change before I finish writing this, so the live app will probably look different than what you see me build, but the layout/principles should be pretty much the same. (Editorial note: it has already changed before I was able to finish writing this series, but I have a few screenshots of what the app looked like before, and we'll just build up to the spec that I created.)

Here's what our final product will look like:

With all that said, let's go.

The Footer

The last section we need to implement for the collection view is the footer. This section will be pretty similar to the first one, only with four items per group instead of two. Lets add a cell for that section:

// In Colleciton View Elements/FooterCell.swift

typealias FooterCell = ContentCell<FooterView>

final class FooterView: ProgrammaticView, ContentConfiguringView {
    private let stack = UIStackView()
    private let titleLabel = UILabel()
    private let subtitleLabel = UILabel()

    override func configure() {
        stack.axis = .vertical
        stack.spacing = 4

        titleLabel.font = .custom(style: .headline)
        subtitleLabel.font = .custom(style: .subheadline)
    }

    override func constrain() {
        addSubviews(stack)
        stack.addArrangedSubviews(titleLabel, subtitleLabel)

        stack.horizontalAnchors == horizontalAnchors
        stack.verticalAnchors == verticalAnchors + 28
    }

    func configure(with content: Content?) {
        titleLabel.text = content?.title
        subtitleLabel.text = content?.subtitle

        switch content?.style {
        case .standard: titleLabel.font = .custom(style: .headline)
        case .title: titleLabel.font = .custom(style: .title4)
        case .none: break
        }
    }
}

The Footer Section

We'll need a background for that section, since it is a different color. Fortunately, the infrastructure we set up in the last part will make this very easy:

// In Collection View Elements/BackgroundView.swift

// add view
final class SecondaryBackgroundView: BackgroundView {
    override func provideBackgroundColor() -> UIColor? {
        .secondarySystemBackground
    }
}

// add BackgroundStyle case
enum BackgroundStyle: String, CaseIterable {
    case inverted, secondary

    var elementKind: String { "background.\(rawValue)" }

    var viewClass: AnyClass {
        switch self {
        case .inverted: return InvertedBackgroundView.self
        case .secondary: return SecondaryBackgroundView.self
        }
    }
}

Then we just need to add a layout section for it:

// In Collection View Elements/NSCollectionLayoutSection+Layouts.swift

static func footer() -> NSCollectionLayoutSection {
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1),
                                          heightDimension: .estimated(60))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)

    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.7),
                                           heightDimension: .estimated(200))
    let group = NSCollectionLayoutGroup.vertical(layoutSize: groupSize,
                                                 subitems: [item, item, item, item])

    let headerSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1),
                                            heightDimension: .estimated(100))
    let header = NSCollectionLayoutBoundarySupplementaryItem.header(layoutSize: headerSize)

    let section = NSCollectionLayoutSection(group: group)
    section.orthogonalScrollingBehavior = .groupPaging
    section.boundarySupplementaryItems = [header]
    section.interGroupSpacing = 12
    section.contentInsets = .init(top: 0, leading: 20, bottom: 20, trailing: 20)

    section.addBackground(style: .secondary)

    return section
}

Showing The Footer

To actually see it, we'll need to uncomment the footer section and the rest of the stubbed data:

// In Models/Content.swift

enum Section: Int, Hashable, CaseIterable {
    case nearby, stays, experiences, hosting, info
}

// in headerContent() switch statment
case .info: return .init(title: "Stay informed", subtitle: nil, image: nil)

// in stubData() switch statment
case .info:
    return [
        .init(title: "For guests", subtitle: nil, image: nil, style: .title),
        .init(title: "Our COVID-19 response",
              subtitle: "Health and saftey updates",
              image: nil),
        .init(title: "Cancellation options",
              subtitle: "Learn what's covered",
              image: nil),
        .init(title: "Help Center",
              subtitle: "Get support",
              image: nil),

        .init(title: "For hosts", subtitle: nil, image: nil, style: .title),
        .init(title: "Message from Brian Chesky",
              subtitle: "Hear from our CEO",
              image: nil),
        .init(title: "Resources for hosting",
              subtitle: "What's impacted by COVID-19",
              image: nil),
        .init(title: "Providing frontline stays",
              subtitle: "Learn how to help",
              image: nil),

        .init(title: "For COVID-19 responders", subtitle: nil, image: nil, style: .title),
        .init(title: "Frontline stays",
              subtitle: "Learn about our program",
              image: nil),
        .init(title: "Sign up",
              subtitle: "Check for housing options",
              image: nil),
        .init(title: "Make a donation",
              subtitle: "Support nonprofit organizations",
              image: nil),

        .init(title: "More", subtitle: nil, image: nil, style: .title),
        .init(title: "Airbnb Newsroom",
              subtitle: "Latest announcements",
              image: nil),
        .init(title: "World Health Organization",
              subtitle: "Education and updates",
              image: nil),
        .init(title: "Project Lighthouse",
              subtitle: "Finding and fighting discrimination",
              image: nil),
    ]

And we'll need to update the collection view and data source to show the content in the right section:

// In HomeView.swift

// in makeCollectionView() switch statement
case .info:
    return .footer()

// in makeDataSource() switch statement
case .info:
    let registration = FooterCell.registration()
    return view.dequeueConfiguredReusableCell(using: registration,
                                              for: indexPath,
                                              item: item)

And with that, the footer section is visible and looks pretty good. The only thing we're missing is the separators.

Adding Separators

I went back and forth on the best way to implement this and where I landed was to break it up into a couple of parts so things can stay decoupled. We'll define another protocol to provide a method to show a separator or not, we'll let individual cells decide if they want to have a separator at all, and we'll pass a closure as an argument to registration to allow the data source to define if a specific cell should show its separator or not.

First, let's add a view to the FooterCell that will be our separator:

// In Colleciton View Elements/FooterCell.swift

private let separator = UIView()

// in configure()
separator.backgroundColor = .quaternaryLabel

// in constrain()
addSubviews(stack, separator)
// other stuff...
separator.topAnchor == bottomAnchor
separator.horizontalAnchors == stack.horizontalAnchors
separator.heightAnchor == 1

Then we'll add a protocol with the showSeparator method and have our content cell forward it on to the view, if the view has adopted the protocol:

// In Colleciton View Elements/ContentCell.swift

protocol SeparatorShowing: AnyObject {
    func showSeparator(_ shouldShow: Bool)
}

extension ContentCell: SeparatorShowing where View: SeparatorShowing {
    func showSeparator(_ shouldShow: Bool) {
        view.showSeparator(shouldShow)
    }
}

Then we need our FooterView to conform to this protocol:

// In Colleciton View Elements/FooterCell.swift

extension FooterView: SeparatorShowing {
    func showSeparator(_ shouldShow: Bool) {
        separator.alpha = shouldShow ? 0.8 : 0
    }
}

Then we need a way to decide if we should show the separator or not. In this case, we'll want to show it for the items at indexes 0, 1, 2 and hide it for 3, then show it for 4, 5, 6 and hide it for 7, etc. We have access to that index in the registration, but really the data source should be the one making the decision so we'll pass the index back to the data source in a closure and get a boolean back:

static func registration(showSeparator: @escaping (IndexPath) -> Bool = { _ in false }) -> UICollectionView.CellRegistration<ContentCell<View>, Content> {
    UICollectionView.CellRegistration { cell, indexPath, content in
        cell.configure(with: content)
        if let cell = cell as? SeparatorShowing {
            let shouldShow = showSeparator(indexPath)
            cell.showSeparator(shouldShow)
        }
    }
}

Giving the closure a default value will mean that we only need to provide this if we care about it, which is good because we only care about it in this one section. And casting the cell as SeparatorShowing before calling that closure ensures that it only gets called if the cell can actually do something with the information.

Now we just need to update makeDataSource to provide the closue in the .info section:

// In HomeView.swift

case .info:
    let registration = FooterCell.registration() { indexPath in
        indexPath.item % 4 != 3
    }

If you're not familiar with modulo math this check will divide the item index by 4 and look at the remainder. If it is 3, we'll return false (to hide the separator) and otherwise we'll return true (to show the separator). If you try that out with the sequence of numbers outlined above, you'll find that this leads to the exact sequence we wanted. Or you can just run the app and see it for yourself.

Wrap Up

In this post we added a footer cell, we added a footer section with a background color, and we looked at one method for adding separators to cells. In the last part, we'll totally shift gears and get the collapsing header set up!

Check out the code up to this point in this repo.

• For all the illustrations in the app I just took screenshots of the actual app and cropped them to size. They are not the full versions of the illustrations and they are not really even formatted correctly for use in an iOS app. I tried to spend as little time as possible on that prep.
• We will get the fonts, colors and icons as close as we can with just using the system versions. I am pretty sure the font and icons that Airbnb actually uses would require a license and I don't care that much about making this exact. With the way we organize it, it would be pretty easy to swap in the real ones if you want to take that step yourself.
• We will not do any business logic. We will hard code all the data and not handle any user actions. Again, this is not meant to be production code, just an exploration of some UI techniques.
• There is a good chance that Airbnb will look different by the time you see this. Honestly, there's a non-zero chance that it will change before I finish writing this, so the live app will probably look different than what you see me build, but the layout/principles should be pretty much the same. (Editorial note: it has already changed before I was able to finish writing this series, but I have a few screenshots of what the app looked like before, and we'll just build up to the spec that I created.)

Here's what our final product will look like:

With all that said, let's go.

Backgrounds, Inverted Sections and Dark Mode

Inverted Colors

The next thing we're missing from the spec is the dark section. In the pre-dark-mode era we probably would have considered this a "dark" section and the others "light" sections and given them colors accordingly. What I would like to do is consider this an "inverted" section so that it stands out equally whether the user is looking at the app in dark mode or light mode. (Note, the actual Airbnb app does not support dark mode as I write this, so hopefully they'll steal my ideas.) Fortunately, this is pretty easy to do with the API Apple has given us for colors, just by adding a couple of extensions. First we're going to add an extension on UITraitCollection which returns itself, but with just the userInterfaceStyle flipped:

// In Extensions/UITraitCollection+Inverted.swift

extension UITraitCollection {
    private static let lightStyle: UITraitCollection = .init(userInterfaceStyle: .light)
    private static let darkStyle: UITraitCollection = .init(userInterfaceStyle: .dark)

    func invertedStyle() -> UITraitCollection {
        switch userInterfaceStyle {
        case .dark:
            return UITraitCollection.init(traitsFrom: [self, Self.lightStyle])
        case .light, .unspecified:
            return UITraitCollection.init(traitsFrom: [self, Self.darkStyle])
        @unknown default:
            return self
        }
    }
}

Then we'll add a couple of "inverted" versions of the static colors on UIColor:

// In Extensions/UIColor+Inverted.swift

extension UIColor {
    static let invertedBackground: UIColor = .init { traits in
        systemBackground.resolvedColor(with: traits.invertedStyle())
    }

    static let invertedLabel: UIColor = .init { traits in
        label.resolvedColor(with: traits.invertedStyle())
    }
}

And now we have versions of the system provided semantic colors that will render for the opposite user interface style that we are currently in.

Using The Colors

Now, to render the LargeSquareCell with an inverted label color, we'll need a variant of that class which uses the inverted color. To do that, I'm going to use a combination of subclassing and our cell wrapper. First, we'll define a ColorStyle to determine if we should render the view in the standard way or in the inverted way:

// In Extensions/UIColor+Inverted.swift

enum ColorStyle {
    case standard, inverted
}

Next, we'll add a color style property to the LargeSquareCell:

// In Collection View Elements/LargeSquareCell.swift

private lazy var style: ColorStyle = provideStyle()

// in configure
let textColor: UIColor = style == .inverted ? .invertedLabel : .label
titleLabel.font = .custom(style: .headline)
titleLabel.textColor = textColor
subtitleLabel.font = .custom(style: .subheadline)
subtitleLabel.textColor = textColor

// at bottom of class
func provideStyle() -> ColorStyle { .standard }

This may look a little weird, but it gives us everything we need to define an inverted version in just a couple of lines:

// In Collection View Elements/LargeSquareCell.swift

typealias InvertedLargeSquareCell = ContentCell<InvertedLargeSquareView>

class InvertedLargeSquareView: LargeSquareView {
    override func provideStyle() -> ColorStyle { .inverted }
}

Everything about this cell will be exactly the same as LargeSquareCell, with the only difference being this one will use inverted colors. And we'll do the same thing to make an inverted header:

// In Collection View Elements/SectionHeader.swift

private lazy var style: ColorStyle = provideStyle()

// in configure
let textColor: UIColor = style == .inverted ? .invertedLabel : .label

titleLabel.textColor = textColor

subtitleLabel.textColor = textColor

// at bottom of class
func provideStyle() -> ColorStyle { .standard }

And then we'll add the InvertedHeader

// In Collection View Elements/SectionHeader.swift

typealias InvertedHeader = ContentHeader<InvertedHeaderView>

final class InvertedHeaderView: SectionHeaderView {
    override func provideStyle() -> ColorStyle { .inverted }
}

Adding A Background

Now we need a way to change the color of the background of one section. In UICollectionViews this is done with a decorator item, which needs to be a subclass of UICollectionViewReusableView. We're going to do a similar subclassing thing here as well, because it will make it easier when we need to add the background for the footer section. First we'll define a BackgroundView class to be the parent for all of our backgrounds:

// In Collection View Elements/BackgroundView.swift

class BackgroundView: UICollectionReusableView {

    override init(frame: CGRect) {
        super.init(frame: frame)
        backgroundColor = provideBackgroundColor()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        backgroundColor = provideBackgroundColor()
    }

    func provideBackgroundColor() -> UIColor? {
        return nil
    }
}

And then we'll define the background with inverted colors:

// In Collection View Elements/BackgroundView.swift

final class InvertedBackgroundView: BackgroundView {
    override func provideBackgroundColor() -> UIColor? {
        .invertedBackground
    }
}

And we'll add some helpers which will make things a little more convenient when we're defining sections. We'll add an enum where we define all of our background styles, which will provide a name to use for the "element kind", so we can avoid typing strings when we don't need to, and will map the enum cases to which class of background we should use.

// In Collection View Elements/BackgroundView.swift

enum BackgroundStyle: String, CaseIterable {
    case inverted

    var elementKind: String { "background.\(rawValue)" }

    var viewClass: AnyClass {
        switch self {
        case .inverted: return InvertedBackgroundView.self
        }
    }
}

Then we'll add an extension on UICollectionViewLayout which will register all our backgrounds for us, because as far as I can tell, there is currently no way to use a cell registration for decoration items like you can with cells or headers:

// In Collection View Elements/BackgroundView.swift

extension UICollectionViewLayout {
    func registerBackgrounds() {
        BackgroundStyle.allCases.forEach {
            register($0.viewClass, forDecorationViewOfKind: $0.elementKind)
        }
    }
}

And we'll add an extension on NSCollectionLayoutSection which will let us add a background to that section by just passing it what style we want. Two cheers for auto-complete.

// In Collection View Elements/BackgroundView.swift

extension NSCollectionLayoutSection {
    func addBackground(style: BackgroundStyle) {
        decorationItems.append(.background(elementKind: style.elementKind))
    }
}

Using the Inverted Views

Now we need to update our collection view and data source to actually use all the new views we've defined. First lets add a new section that will use the inverted background.

// In Collection View Elements/NSCollectionLayoutSection+Layouts.swift

static func invertedSideScrollingOneItem() -> NSCollectionLayoutSection {
    let section = sideScrollingOneItem()
    section.addBackground(style: .inverted)
    return section
}

Then lets update the collection view to use it. And don't forget to register the backgrounds or it will crash.

// In HomeView.swift

// in makeCollectionView()
let layout = UICollectionViewCompositionalLayout { sectionIndex, layoutEnvironment in
    let section = Section.allCases[sectionIndex]
    switch section {
    case .experiences:
        return .invertedSideScrollingOneItem()
    // other cases...
    }
}
layout.registerBackgrounds()
return UICollectionView(frame: .zero, collectionViewLayout: layout)

Then we need to update our data source to use the InvertedLargeSquareCell registration for the "experiences" section.

// In HomeView.swift

// in the switch statement in makeDataSource()
case .experiences:
    let registration = InvertedLargeSquareCell.registration()
    return view.dequeueConfiguredReusableCell(using: registration,
                                              for: indexPath,
                                              item: item)

And we'll need to update the supplementaryViewProvider for the data source as well, to get the inverted header:

// In HomeView.swift

// at the bottom of makeDataSource()
let headers = Section.allCases.map { $0.headerContent }
let headerRegistration = SectionHeader.registration(headers: headers)
let invertedHeaderRegistration = InvertedHeader.registration(headers: headers)
dataSource.supplementaryViewProvider = { collectionView, string, indexPath in
    let section = Section.allCases[indexPath.section]
    switch section {
    case .experiences:
        return collectionView
            .dequeueConfiguredReusableSupplementary(using: invertedHeaderRegistration,
                                                    for: indexPath)
    default:
        return collectionView
            .dequeueConfiguredReusableSupplementary(using: headerRegistration,
                                                    for: indexPath)
    }
}

And that gets us a beautiful inverted section that works in both dark mode and light mode!

Wrap Up

In this part we added some convenience extensions for inverting colors, regardless of wether we're in dark mode or light mode. We added support for inverted versions of our cell and section header types. And we added the ability to have background in our sections. In the next part we'll add the footer which will use a new cell, a new layout and a new background.

Check out the code up to this point in this repo.

• For all the illustrations in the app I just took screenshots of the actual app and cropped them to size. They are not the full versions of the illustrations and they are not really even formatted correctly for use in an iOS app. I tried to spend as little time as possible on that prep.
• We will get the fonts, colors and icons as close as we can with just using the system versions. I am pretty sure the font and icons that Airbnb actually uses would require a license and I don't care that much about making this exact. With the way we organize it, it would be pretty easy to swap in the real ones if you want to take that step yourself.
• We will not do any business logic. We will hard code all the data and not handle any user actions. Again, this is not meant to be production code, just an exploration of some UI techniques.
• There is a good chance that Airbnb will look different by the time you see this. Honestly, there's a non-zero chance that it will change before I finish writing this, so the live app will probably look different than what you see me build, but the layout/principles should be pretty much the same. (Editorial note: it has already changed before I was able to finish writing this series, but I have a few screenshots of what the app looked like before, and we'll just build up to the spec that I created.)

Here's what our final product will look like:

With all that said, let's go.

Filling Out The Collection View

We're going to be adding a couple of different cells for this app and even though they will all use the same Content struct to render data on screen, they will use different views to do that. So what I want to do is make the SmallSquareCell wrapper that we wrote last time into a generic ContentCell wrapper that will have some view it will configure with content. So let's add a new file and start by adding a protocol that the view will need to conform to:

// In Collection View Elements/ContentCell.swift

import Anchorage
import UIKit

protocol ContentConfiguringView: UIView {
    func configure(with content: Content?)
}

Then we'll just cut/paste the SmallSquareCell class from last time into this file and make some changes to it:

// In Collection View Elements/ContentCell.swift

// change name and make it generic
final class ContentCell<View: ContentConfiguringView>: UICollectionViewCell {

    // change the view to be View instead of SmallSquareView
    private lazy var view: View = .init()

    // other stuff...

    // change registration so it returns its type is <ContentCell<View>, Content>
    static func registration() -> UICollectionView.CellRegistration<ContentCell<View>, Content> {
        UICollectionView.CellRegistration { cell, indexPath, content in
            cell.configure(with: content)
        }
    }
}

And with that our cell wrapper is generic! It won't compile yet, because we our view doesn't conform to the protocol and we no longer have a class called SmallSquareCell, so let's fix both of those:

// In Collection View Elements/SmallSquareCell.swift

// add a type alias for convenience
typealias SmallSquareCell = ContentCell<SmallSquareView>

// make the view adopt the new protocol,
// which it already conforms to
final class SmallSquareView: ProgrammaticView, ContentConfiguringView {

Now the app should run again and will look the same as before.

Second Cell

Now that we have a generic cell, we can just write our view and toss it in there. It is pretty similar to the SmallSquareView, with a slightly different layout, so I'm not going to go into too much detail. Here's what it looks like:

// In Collection View Elements/LargeSquareCell.swift

typealias LargeSquareCell = ContentCell<LargeSquareView>

class LargeSquareView: ProgrammaticView, ContentConfiguringView {

    private let mainStack = UIStackView()
    private let imageView = UIImageView()
    private let labelStack = UIStackView()
    private let titleLabel = UILabel()
    private let subtitleLabel = UILabel()

    override func configure() {
        mainStack.axis = .vertical
        mainStack.spacing = 10

        imageView.backgroundColor = .secondarySystemFill
        imageView.layer.cornerRadius = 8
        imageView.layer.masksToBounds = true

        labelStack.axis = .vertical
        labelStack.spacing = 2

        titleLabel.font = .custom(style: .headline)
        titleLabel.textColor = .label
        subtitleLabel.font = .custom(style: .subheadline)
        subtitleLabel.textColor = .label
    }

    override func constrain() {
        addSubviews(mainStack)
        mainStack.addArrangedSubviews(imageView, labelStack)
        labelStack.addArrangedSubviews(titleLabel, subtitleLabel)

        mainStack.edgeAnchors == edgeAnchors

        imageView.widthAnchor == imageView.heightAnchor
    }

    func configure(with content: Content?) {
        titleLabel.text = content?.title
        subtitleLabel.text = content?.subtitle
        imageView.image = UIImage(named: content?.image)
    }
}

Second Section

We'll also need a new layout for this new cell type. Again, it is basically the same as the last one just with only one item per group this time.

// In Collection View Elements/NSCollectionLayoutSection+Layouts.swift

static func sideScrollingOneItem() -> NSCollectionLayoutSection {
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1),
                                          heightDimension: .estimated(312))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)

    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.7),
                                           heightDimension: .estimated(312))
    let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize,
                                                 subitems: [item])

    let section = NSCollectionLayoutSection(group: group)
    section.orthogonalScrollingBehavior = .groupPaging
    section.interGroupSpacing = 12
    section.contentInsets = .init(top: 20, leading: 20, bottom: 20, trailing: 20)
    return section
}

Using The New Stuff

Now it is time to uncomment all of the remaining sections except the last one. We'll also need to uncomment the related stub data:

// In Models/Content.swift

enum Section: Int, Hashable, CaseIterable {
    case nearby, stays, experiences, hosting//, info
}

// in stubData()
case .stays:
    return [
        .init(title: "Entire homes", subtitle: nil, image: "entire-homes"),
        .init(title: "Cabins and cottages", subtitle: nil, image: "cabins-cottages"),
        .init(title: "Unique stays", subtitle: nil, image: "unique-stays"),
        .init(title: "Pets welcome", subtitle: nil, image: "pets-welcome"),
    ]
case .experiences:
    return [
        .init(title: "Online Experiences",
              subtitle: "Travel the world without leaving home.",
              image: "online-experiences"),
        .init(title: "Experiences",
              subtitle: "Things to do wherever you are.",
              image: "experiences"),
        .init(title: "Adventures",
              subtitle: "Multi-day trips with meals and stays.",
              image: "adventures"),
    ]
case .hosting:
    return [
        .init(title: "Host your home",
              subtitle: nil,
              image: "host-your-home"),
        .init(title: "Host an Online Experience",
              subtitle: nil,
              image: "host-online-experience"),
        .init(title: "Host an Experience",
              subtitle: nil,
              image: "host-experience"),
    ]

Then we'll also need to update makeDataSource and makeCollectionView to account for those new sections:

// In HomeView.swift

// in the switch statement in makeCollectionView()
default:
    return .sideScrollingOneItem()

// in the switch statement in makeDataSource()
default:
    let registration = LargeSquareCell.registration()
    return view.dequeueConfiguredReusableCell(using: registration,
                                              for: indexPath,
                                              item: item)

Now, if you run the app, you'll see three new sections full of content!

Adding Headers

If we look at the spec we're going off of, we'll find that these subsequent sections all have a header. In collection views we add those with a UICollectionReusableView. To keep things consistent, I'm going to follow the same pattern we used with the cells, making a generic wrapper for that which holds a view where we will define the actual layout.

// In Collection View Elements/SectionHeader.swift

import Anchorage
import UIKit

protocol ContentConfiguringHeader: UIView {
    func configure(with content: Content?)
}

class ContentHeader<View: ContentConfiguringHeader>: UICollectionReusableView {

    private lazy var view: View = .init()

    override init(frame: CGRect) {
        super.init(frame: frame)
        constrain()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        constrain()
    }

    private func constrain() {
        addSubview(view)
        view.edgeAnchors == layoutMarginsGuide.edgeAnchors
    }

    func configure(with content: Content?) {
        view.configure(with: content)
    }

    static func registration(headers: [Content?]) -> UICollectionView.SupplementaryRegistration<ContentHeader<View>> {
        UICollectionView.SupplementaryRegistration(kind: .header) { header, string, indexPath in
            let content = headers[indexPath.section]
            header.configure(with: content)
        }
    }
}

The supplementary registrations use a String to keep track of the element kind, and I try to keep things a little more tightly reined than that, so I'll add an enum which will have a case for each kind of supplementary view that my app will use, and I'll add a convenience initializer for UICollectionView.SupplementaryRegistration which takes that enum and passes it on as a String.

// In Collection View Elements/SectionHeader.swift

extension UICollectionView {
    enum ElementKind: String {
        case header
    }
}

extension UICollectionView.SupplementaryRegistration {
    init(kind: UICollectionView.ElementKind,
         handler: @escaping UICollectionView.SupplementaryRegistration<Supplementary>.Handler) {
        self.init(elementKind: kind.rawValue, handler: handler)
    }
}

Then we need to add the view:

// In Collection View Elements/SectionHeader.swift

typealias SectionHeader = ContentHeader<SectionHeaderView>

class SectionHeaderView: ProgrammaticView, ContentConfiguringHeader {

    private let titleLabel = UILabel()
    private let subtitleLabel = UILabel()

    override func configure() {
        directionalLayoutMargins = .init(top: 24, leading: 0, bottom: 0, trailing: 0)
        titleLabel.font = .custom(style: .title2)
        titleLabel.adjustsFontForContentSizeCategory = true
        titleLabel.numberOfLines = 0
        titleLabel.textColor = .label
        subtitleLabel.font = .custom(style: .title4)
        subtitleLabel.numberOfLines = 0
        subtitleLabel.textColor = .label
    }

    override func constrain() {
        let stackView = UIStackView(arrangedSubviews: [titleLabel, subtitleLabel])
        stackView.axis = .vertical
        stackView.spacing = 4

        addSubview(stackView)
        stackView.edgeAnchors == layoutMarginsGuide.edgeAnchors
    }

    func configure(with content: Content?) {
        titleLabel.text = content?.title
        subtitleLabel.text = content?.subtitle
    }
}

You'll notice that we're using a couple new font styles in this view, so we need ot add those as well.

// In Extensions/UIFont+Custom.swift

private static var title2: UIFont {
    UIFontMetrics(forTextStyle: .title2)
        .scaledFont(for: .systemFont(ofSize: 18, weight: .bold))
}

private static var title4: UIFont {
    UIFontMetrics(forTextStyle: .title3)
        .scaledFont(for: .systemFont(ofSize: 15, weight: .light))
}

// in Style
case title2
case title4

// in switch statement in custom(style:)
case .title2: return title2
case .title4: return title4

Using The Headers

Now we need to content for the headers. Let's uncomment the headerContent property on Section:

// In Models/Content.swift

var headerContent: Content? {
    switch self {
    case .nearby: return nil
    case .stays: return .init(title: "Live anywhere", subtitle: nil, image: nil)
    case .experiences: return .init(title: "Experience the world",
                                    subtitle: "Unique activities with local experts—in person or online.",
                                    image: nil)
    case .hosting: return .init(title: "Join millions of hosts on Airbnb", subtitle: nil, image: nil)
//        case .info: return .init(title: "Stay informed", subtitle: nil, image: nil)
    }
}

Then we need to update makeDataSource to take that header content and stick it in header views.

// In HomeView.swift

// at the end of makeDataSource()
let headers = Section.allCases.map { $0.headerContent }
let headerRegistration = SectionHeader.registration(headers: headers)
dataSource.supplementaryViewProvider = { collectionView, string, indexPath in
    collectionView.dequeueConfiguredReusableSupplementary(using: headerRegistration,
                                                          for: indexPath)
}
return dataSource

Finally, we'll add another couple of helpers that set some default values for us and let us use element types that are constrained by an enum. Then we just need to add the layout information to our section definition.

// In SectionHeader.swift

extension NSCollectionLayoutBoundarySupplementaryItem {
    convenience init(layoutSize: NSCollectionLayoutSize,
                     kind: UICollectionView.ElementKind,
                     alignment: NSRectAlignment) {
        self.init(layoutSize: layoutSize,
                  elementKind: kind.rawValue,
                  alignment: alignment)
    }

    static func header(layoutSize: NSCollectionLayoutSize) ->
    NSCollectionLayoutBoundarySupplementaryItem {
        .init(layoutSize: layoutSize, kind: .header, alignment: .top)
    }
}

// In Collection View Elements/NSCollectionLayoutSection+Layouts.swift

// in sideScrollingOneItem()
let headerSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1),
                                        heightDimension: .estimated(100))
let header = NSCollectionLayoutBoundarySupplementaryItem.header(layoutSize: headerSize)

let section = NSCollectionLayoutSection(group: group)
section.boundarySupplementaryItems = [header]

And with that, you can run the app and we'll see headers in the sections that have them!

Wrap Up

In this part we really took advantage of the groundwork we made in the last part. We made our cell wrapper more reusable by making it generic. We defined a new cell layout and used it with the next several sections of content. And we added headers for the sections that have them. In the next part we'll take a look at adding backgrounds and dark mode support.

Check out the code up to this point in this repo.

• For all the illustrations in the app I just took screenshots of the actual app and cropped them to size. They are not the full versions of the illustrations and they are not really even formatted correctly for use in an iOS app. I tried to spend as little time as possible on that prep.
• We will get the fonts, colors and icons as close as we can with just using the system versions. I am pretty sure the font and icons that Airbnb actually uses would require a license and I don't care that much about making this exact. With the way we organize it, it would be pretty easy to swap in the real ones if you want to take that step yourself.
• We will not do any business logic. We will hard code all the data and not handle any user actions. Again, this is not meant to be production code, just an exploration of some UI techniques.
• There is a good chance that Airbnb will look different by the time you see this. Honestly, there's a non-zero chance that it will change before I finish writing this, so the live app will probably look different than what you see me build, but the layout/principles should be pretty much the same. (Editorial note: it has already changed before I was able to finish writing this series, but I have a few screenshots of what the app looked like before, and we'll just build up to the spec that I created.)

Here's what our final product will look like:

With all that said, let's go.

First Cell and Section

The first thing we need to do is lay out the home view. It will be separated into basically two parts, the header and the collection view, so let's add those:

// In HomeView.swift

// add views, just using an empty collection view for now
private let headerView = HeaderView()
private let collectionView = UICollectionView(frame: .zero,
                                              collectionViewLayout: .init())

override func configure() {
     // change the collection view's background color so we know where it is
    collectionView.backgroundColor = .systemPink
}

override func constrain() {
    // use the helper to add the subviews
    addSubviews(headerView, collectionView)

    // header should be tied to the top,
    // leading and trailing edges of the view
    // and the bottom to the top of the collection view
    headerView.topAnchor == topAnchor
    headerView.horizontalAnchors == horizontalAnchors
    headerView.bottomAnchor == collectionView.topAnchor

    // collection view is constrained to take
    // the rest of the available space
    collectionView.horizontalAnchors == horizontalAnchors
    collectionView.bottomAnchor == bottomAnchor
}

If you run the app right now, you'll find that the whole screen is teal, which is the header's color. This is because we aren't constraining it's height anywhere, so it taking up the whole view is a valid layout according to the constraints we have. For this project, we're going to have the header manage it's own height so we can encapsulate all the animation stuff into that one view. For now, let's just give it a static height.

// In HeaderView.swift

override func constrain() {
    heightAnchor == 100
}

Now if we run it, it looks roughly the same proportions as Airbnb when the header is in the fully-collapsed state and that's what we want for now.

Add The SmallSquareView

To make things easier for ourselves, we're going to define our cells' views as ProgrammaticViews and just use the UICollectionViewCell as a wrapper around that. So add a file called SmallSquareCell.swift and let's write the view:

// In Collection View Elements/SmallSquareCell.swift

import Anchorage
import UIKit

final class SmallSquareView: ProgrammaticView {

    private let imageView = UIImageView()
    private let stack = UIStackView()
    private let titleLabel = UILabel()
    private let subtitleLabel = UILabel()

    override func configure() {
        imageView.backgroundColor = .secondarySystemFill
        imageView.layer.cornerRadius = 8
        imageView.layer.masksToBounds = true

        stack.axis = .vertical
        stack.spacing = 8
    }

    override func constrain() {
        addSubviews(imageView, stack)
        stack.addArrangedSubviews(titleLabel, subtitleLabel)

        imageView.verticalAnchors == verticalAnchors
        imageView.leadingAnchor == leadingAnchor
        imageView.widthAnchor == imageView.heightAnchor

        stack.leadingAnchor == imageView.trailingAnchor + 10
        stack.trailingAnchor == trailingAnchor
        stack.centerYAnchor == centerYAnchor
    }
}

That gets us most of the way there, but we need two more things. We need to set the fonts of the labels, and we need a way to get the content into this view. For the fonts, I like to define semantically named static constants on UIFont, whose names roughly match the ones that Apple provides, but whose style matches my app. I also like to define a function called custom(style:) that returns one of those styles to make it clear in code that this is our app's font, not a system font. That looks like this:

// In Extensions/UIFont+Custom.swift

extension UIFont {
    private static var headline: UIFont {
        UIFontMetrics(forTextStyle: .headline)
            .scaledFont(for: .systemFont(ofSize: 14, weight: .semibold))
    }

    private static var subheadline: UIFont {
        UIFontMetrics(forTextStyle: .subheadline)
            .scaledFont(for: .systemFont(ofSize: 12, weight: .light))
    }
}

extension UIFont {
    enum Style {
        case headline
        case subheadline
    }

    static func custom(style: Style) -> UIFont {
        switch style {
        case .headline: return headline
        case .subheadline: return subheadline
        }
    }
}

This gives us a central place to define the fonts for our app, it builds in support for dynamically-sized fonts and it gives us a clear and consistent api to use at the call site:

// In SmallSquareView.configure

titleLabel.font = .custom(style: .headline)
subtitleLabel.font = .custom(style: .subheadline)

We also need a way to give this view some Content that it will then display. We're going to do that with this function:

// In Collection View Elements/SmallSquareCell.swift

func configure(with content: Content?) {
    titleLabel.text = content?.title
    subtitleLabel.text = content?.subtitle
    imageView.image = UIImage(named: content?.image) // using our UIImage initializer
}

Our First Cell

Now we need to use that view in a collection view cell, so it can actually be displayed. I try to keep this as simple as possible, just a straight wrapper that passes things through to the view.

final class SmallSquareCell: UICollectionViewCell {

    private lazy var view: SmallSquareView = .init()

    override init(frame: CGRect) {
        super.init(frame: frame)
        constrain()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        constrain()
    }

    private func constrain() {
        contentView.addSubview(view)
        view.edgeAnchors == contentView.edgeAnchors
    }

    func configure(with content: Content?) {
        view.configure(with: content)
    }
}

Now that we have a full-fledged cell that we can use, but we need a layout and a data source for the collection view.

Our First Section

We're going to use the relatively new UICollectionViewCompositionalLayout for our collection view, which will be composed of several sections. To make things easier to read and reason about, I am going to split up the section definitions into their own functions, which also conveniently makes them resuable. This first one needs to be a side-scrolling section with groups of two items stacked on top of each other, so I'm going to call it sideScrollingTwoItem().

// In Collection View Elements/NSCollectionLayoutSection+Layouts.swift

static func sideScrollingTwoItem() -> NSCollectionLayoutSection {
    // Define the individual items:
    // We want the items to be the same width as their group and
    // to take as much height as they need, which could change
    // because we support dynamically sized fonts
    let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1),
                                          heightDimension: .estimated(85))
    let item = NSCollectionLayoutItem(layoutSize: itemSize)
    item.contentInsets = .init(top: 8, leading: 0, bottom: 8, trailing: 0)

    // Define the groups:
    // We want the next group to be poking in from the edge
    // of the screen, so we'll make the groups a little bit 
    // less than the full width of the section.
    // We also want 2 items per group.
    let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.65),
                                           heightDimension: .estimated(180))
    let group = NSCollectionLayoutGroup.vertical(layoutSize: groupSize,
                                                 subitem: item,
                                                 count: 2)
    // Define the section:
    // We want each group to snap into place as you scroll so 
    // we'll use the group paging orthogonal scrolling behavior.
    let section = NSCollectionLayoutSection(group: group)
    section.orthogonalScrollingBehavior = .groupPaging
    section.interGroupSpacing = 12
    section.contentInsets = .init(top: 20, leading: 20, bottom: 20, trailing: 20)
    return section
}

The Section Model

Now we need some content to show in this section so we are going to add a new type called Section that will define the content for the different sections on our screen. I'll add them all now, but comment out all but the first.

// In Models/Content.swift

enum Section: Int, Hashable, CaseIterable {
    case nearby //, stays, experiences, hosting, info
}

While we're here, we can also uncomment the stub data for the first section:

// In Models/Content.swift

extension Section {
    func stubData() -> [Content] {
        switch self {
        case .nearby:
            return [
                .init(title: "Estes Park", subtitle: "1.5 hour drive", image: "estes-park"),
                .init(title: "Breckenridge", subtitle: "2.5 hour drive", image: "breckenridge"),
                .init(title: "Grand Lake", subtitle: "3 hour drive", image: "grand-lake"),
                .init(title: "Idaho Springs", subtitle: "2 hour drive", image: "idaho-springs"),
                .init(title: "Glenwood Springs", subtitle: "4.5 hour drive", image: "glenwood-springs"),
                .init(title: "Pagosa Springs", subtitle: "7.5 hour drive", image: "pagosa-springs"),
            ]
        // other cases commented out...
        }
    }
}

Making The Collection View

Now that we have a section layout defined, and a data model in place, we can build our collection view. It is really pretty simple, UICollectionViewCompsitionalLayout has an initializer that takes a closure where we are given a section index and a layout environment and we need to return a NSCollectionLayoutSection. Since we defined our layout as a static function on NSCollectionLayoutSection, we can just pick the layout using dot syntax. It looks like this:

// In an extension on HomeView

func makeCollectionView() -> UICollectionView {
    let layout = UICollectionViewCompositionalLayout { sectionIndex, layoutEnvironment in
        let section = Section.allCases[sectionIndex]
        switch section {
        case .nearby:
            return .sideScrollingTwoItem()
        }
    }
    return UICollectionView(frame: .zero, collectionViewLayout: layout)
}

We don't really need the switch statment right now, since there is only one case. But it will set us up well for adding the rest of the sections in subsequent articles. Now we just need to use this function to initialize our collection view:

// In HomeView

private lazy var collectionView = makeCollectionView()

Making The Data Source

Finally, we'll need a data source to provide the content for the collection view. We're going to write another function that will create a UICollectionViewDiffableDataSource, and this is going to take the nested closures thing to a whole other level. The data source is initialized with a collection view and a closure that is given a collection view and an index path and needs to return a configured cell. To configure the cell we're going to use a UICollectionView.CellRegistration, and its initializer also takes a closure which is given a cell, an index path and some content. It can take some time to wrap your head around how all this is working, especially if you're used to the old UICollectionViewDataSource methods. It definitely took me some trial and error. Here's what it will look like:

// In an extension on HomeView

func makeDataSource() -> UICollectionViewDiffableDataSource<Section, Content> {
    let registration = UICollectionView.CellRegistration<SmallSquareCell, Content> {
    cell, indexPath, content in
        cell.configure(with: content)
    }
    let dataSource = UICollectionViewDiffableDataSource<Section, Content>(
        collectionView: collectionView) { view, indexPath, item in
        let section = Section.allCases[indexPath.section]
        switch section {
        case .nearby:
            return view.dequeueConfiguredReusableCell(using: registration,
                                                      for: indexPath,
                                                      item: item)
        }
    }
    return dataSource
}

One thing I like to do is define those registrations on the cell class itself, because that gives a convenient place to put it and it is nice and readable at the call site. So let's add this static function on SmallSquareCell:

// In SmallSquareCell.swift

static func registration() -> UICollectionView.CellRegistration<SmallSquareCell, Content> {
    UICollectionView.CellRegistration { cell, indexPath, content in
        cell.configure(with: content)
    }
}

Then, we can just do this in the .nearby section in makeDataSource:

let registration = SmallSquareCell.registration()
return view.dequeueConfiguredReusableCell(using: registration,
                                          for: indexPath,
                                          item: item)

Now we need to use makeDataSource() and set our collection view's data source:

// In HomeView

private lazy var dataSouce = makeDataSource()

override func configure() {
    collectionView.backgroundColor = .systemBackground
    collectionView.dataSource = dataSouce
}

Hooking Up The Data Source

Finally, we just need to give the actual data to the data source. For that, we're going to do two things. We'll expose a function on HomeView that will allow someone up the chain to apply an NSDiffableDataSourceSnapshot to this view. We're doing this because the view shouldn't really manage any data itself, it should just be handed content to display. Then, we'll add a function to HomeViewController that will generate the stubbed data and give it to the view. In a real app the data would be fetched by a networking or data base layer and handed to the view controller, but this will work well enough for our purposes.

// In HomeView

func apply(_ snapshot: NSDiffableDataSourceSnapshot<Section, Content>) {
    dataSouce.apply(snapshot)
}

// In HomeViewController

override func viewDidLoad() {
    super.viewDidLoad()
    updateList()
}

private func updateList() {
    var snapShot = NSDiffableDataSourceSnapshot<Section, Content>()
    snapShot.appendSections(Section.allCases)
    Section.allCases.forEach {
        snapShot.appendItems($0.stubData(), toSection: $0)
    }
    contentView.apply(snapShot)
}

And with that, we should be finally be able to see the first section on screen, fully populated with all the stubbed data!

Wrap Up

In this article we set up the view for our first cell and wrote a wrapper around it, we defined the layout for our first section, we built out the structure for our collection view and data source, and hooked it all up. In the next article we'll fill out the collection view with the rest of the content.

Check out the code up to this point on this branch in the repo.

• For all the illustrations in the app I just took screenshots of the actual app and cropped them to size. They are not the full versions of the illustrations and they are not really even formatted correctly for use in an iOS app. I tried to spend as little time as possible on that prep.
• We will get the fonts, colors and icons as close as we can with just using the system versions. I am pretty sure the font and icons that Airbnb actually uses would require a license and I don't care that much about making this exact. With the way we organize it, it would be pretty easy to swap in the real ones if you want to take that step yourself.
• We will not do any business logic. We will hard code all the data and not handle any user actions. Again, this is not meant to be production code, just an exploration of some UI techniques.
• There is a good chance that Airbnb will look different by the time you see this. Honestly, there's a non-zero chance that it will change before I finish writing this, so the live app will probably look different than what you see me build, but the layout/principles should be pretty much the same. (Editorial note: it has already changed before I was able to finish writing this series, but I have a few screenshots of what the app looked like before, and we'll just build up to the spec that I created.)

Here's what our final product will look like:

With all that said, let's go.

Laying The Ground Work

Before we actually start building stuff, we need to do some set up to make our lives easier down the line. I also promised that we'd build from scratch, so this is me showing my work. If you don't care about these set up steps and just want to get into it, jump ahead to First Cell and Section and grab this branch from the repo.

Make a new project

First, we need to make a project. It'll be an iOS App that I am going to call "Airbnb Home". It'll be a Storyboard, UIKit and Swift app.

Set Up The Storyboard

The first thing we'll do in the app is reconfigure the storyboard to have a tab controller with four empty view controllers and the one we'll be setting up. This should be the only time we need to mess with the storyboard.

Click on the view controller in the storyboard, click the "Embed In" button on the bottom right and click "Tab Bar Controller". I like to move the view controller down below the tab bar controller, because that will mimic the theoretical layout in the app.

Add another view controller, place it next to the first, control+click and drag from the tab bar view controller to the new view controller and click on "view controllers" under "Relationship Segue". This will embed the view controller in the tab bar.

Repeat three more times so there is a total of five view controllers. Now you should have a layout that looks like this:

Set the image tint to "System Pink". This is what we'll use to get close enough to Airbnb's brand color throughout the app.

Click on the first tab item and set its title to "Explore" and for the image select the "magnifyingglass" system image. For all of these I just tried to pick the closest SF Symbol that I could without spending a ton of time on it. If you want to pick your own icons you're welcome to.

For the rest I did:

• "Saved" and "heart"
• "Trips" and "scribble.variable"
• "Inbox" and "message"
• "Profile" and "person.circle"

Set Up The Resources

Delete the existing asset catalog and drag in the one that contains all the assets we'll be using. You can get just the asset catalog this from this repo. To get these I literally took screenshots these from the Airbnb app and cropped them down to the right size.

Move all the default stuff that we don't care about into a folder called 'Resources'. Right now, this is all of the files except "ViewController.swift"

If you try building at this point, you'll probably get an error saying that "Build input file could not be found..." This is because the path to the Info.plist file has changed and you need to tell the build settings that. Click on the project file, click on the "Airbnb Home" target, go to the "Build Settings", scroll down to the "Packaging" section and in the middle of that section there is a "Info.plist File" entry. Change that path to Airbnb Home/Resources/Info.plist and it will fix the problem.

Rename ViewController to be something more meaningful like HomeViewController

Pull In Helpers

Add Anchorage as a Swift Package Dependency. We want the one from RightPoint and the default values are fine.

Add a file called ProgrammaticView.swift and add the ProgrammaticView class which will be the base class for all our views. I laid out these patterns in How I Layout UI Code in Swift, so I won't go into too much detail on that here, but it looks like this:

// ProgrammaticView.swift
import UIKit

class ProgrammaticView: UIView {

    @available(*, unavailable, message: "Don't use init(coder:), override init(frame:) instead")
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override init(frame: CGRect) {
        super.init(frame: frame)

        configure()
        constrain()
    }

    func configure() {}
    func constrain() {}
}

Add some helper functions on UIView and UIStackView. I like to put these in their own files, in a folder called "Extensions":

// Extensions/UIView+Helpers.swift

import UIKit

extension UIView {
    func addSubviews(_ views: UIView...) {
        views.forEach { view in addSubview(view) }
    }
}

// Extensions/UIStackView+Helpers.swift

import UIKit

extension UIStackView {
    func addArrangedSubviews(_ views: UIView...) {
        views.forEach { view in addArrangedSubview(view) }
    }
}

Add a helper function on UIImage that seems obvious to me and I'm not sure why it isn't built in, but it makes our code a lot cleaner. UIImage(named:) is already a failable initializer, but it takes a String not a String?, so this initializer just allows us to use an optional string without unwrapping it before passing it to the initalizer:

// Extensions/UIImage+Helpers.swift

import UIKit

extension UIImage {
    convenience init?(named name: String?) {
        guard let name = name else { return nil }
        self.init(named: name)
    }
}

Finally, we'll add a file for our fonts. For now, it won't do anything but the file will just be a placeholder that we come back to when we need to add custom fonts.

// Extensions/UIFont+Custom.swift

import UIKit

extension UIFont {

}

Create Views And Model

Add an empty HomeView and make it the view of the HomeViewController. I'm setting the background color to pink here just to confirm to myself that everything is working.

// HomeView.swift

import Anchorage
import UIKit

class HomeView: ProgrammaticView {
    override func configure() {
        backgroundColor = .systemPink
    }
}

// HomeViewController.swift

class HomeViewController: UIViewController {

    private lazy var contentView: HomeView = .init()

    override func loadView() {
        view = contentView
    }
}

At this point you can run the app and it will look like this. Not quite the Airbnb app yet, but moving in the right direction.

Add an empty HeaderView. We'll lay this out later in the series, but for now we will just give it a color.

// HeaderView.swift

import Anchorage
import UIKit

class HeaderView: ProgrammaticView {
    override func configure() {
        backgroundColor = .systemTeal
    }
}

Finally, we need our Content model. This is what everything will use to hold the content that we want to render on screen and as such, it is pretty generic. This isn't necessarily how I would organize my model in a real app, but it keeps things simple for now while we're setting up the UI. I put it in a group called "Models".

// Models/Content.swift

import UIKit

struct Content: Hashable {
    enum Style {
        case standard, title
    }
    let title: String
    let subtitle: String?
    let image: String?
    let style: Style

    init(title: String, subtitle: String?, image: String?, style: Style = .standard) {
        self.title = title
        self.subtitle = subtitle
        self.image = image
        self.style = style
    }
}

This is also where we'll throw all the stubbed data, but commented out, so that you don't have to type it all up like I did.

// MARK: - Headers
//
//extension Section {
//    var headerContent: Content? {
//        switch self {
//        case .nearby: return nil
//        case .stays: return .init(title: "Live anywhere", subtitle: nil, image: nil)
//        case .experiences: return .init(title: "Experience the world",
//                                  subtitle: "Unique activities with local experts—in person or online.",
//                                  image: nil)
//        case .hosting: return .init(title: "Join millions of hosts on Airbnb", subtitle: nil, image: nil)
//        case .info: return .init(title: "Stay informed", subtitle: nil, image: nil)
//        }
//    }
//}

// MARK: - Stub Data
//
//extension Section {
//    func stubData() -> [Content] {
//        switch self {
//        case .nearby:
//            return [
//                .init(title: "Estes Park", subtitle: "1.5 hour drive", image: "estes-park"),
//                .init(title: "Breckenridge", subtitle: "2.5 hour drive", image: "breckenridge"),
//                .init(title: "Grand Lake", subtitle: "3 hour drive", image: "grand-lake"),
//                .init(title: "Idaho Springs", subtitle: "2 hour drive", image: "idaho-springs"),
//                .init(title: "Glenwood Springs", subtitle: "4.5 hour drive", image: "glenwood-springs"),
//                .init(title: "Pagosa Springs", subtitle: "7.5 hour drive", image: "pagosa-springs"),
//            ]
//        case .stays:
//            return [
//                .init(title: "Entire homes", subtitle: nil, image: "entire-homes"),
//                .init(title: "Cabins and cottages", subtitle: nil, image: "cabins-cottages"),
//                .init(title: "Unique stays", subtitle: nil, image: "unique-stays"),
//                .init(title: "Pets welcome", subtitle: nil, image: "pets-welcome"),
//            ]
//        case .experiences:
//            return [
//                .init(title: "Online Experiences",
//                      subtitle: "Travel the world without leaving home.",
//                      image: "online-experiences"),
//                .init(title: "Experiences",
//                      subtitle: "Things to do wherever you are.",
//                      image: "experiences"),
//                .init(title: "Adventures",
//                      subtitle: "Multi-day trips with meals and stays.",
//                      image: "adventures"),
//            ]
//        case .hosting:
//            return [
//                .init(title: "Host your home", subtitle: nil, image: "host-your-home"),
//                .init(title: "Host an Online Experience", subtitle: nil, image: "host-online-experience"),
//                .init(title: "Host an Experience", subtitle: nil, image: "host-experience"),
//            ]
//        case .info:
//            return [
//                .init(title: "For guests", subtitle: nil, image: nil, style: .title),
//                .init(title: "Our COVID-19 response", subtitle: "Health and saftey updates", image: nil),
//                .init(title: "Cancellation options", subtitle: "Learn what's covered", image: nil),
//                .init(title: "Help Center", subtitle: "Get support", image: nil),
//
//                .init(title: "For hosts", subtitle: nil, image: nil, style: .title),
//                .init(title: "Message from Brian Chesky", subtitle: "Hear from our CEO", image: nil),
//                .init(title: "Resources for hosting", subtitle: "What's impacted by COVID-19", image: nil),
//                .init(title: "Providing frontline stays", subtitle: "Learn how to help", image: nil),
//
//                .init(title: "For COVID-19 responders", subtitle: nil, image: nil, style: .title),
//                .init(title: "Frontline stays", subtitle: "Learn about our program", image: nil),
//                .init(title: "Sign up", subtitle: "Check for housing options", image: nil),
//                .init(title: "Make a donation", subtitle: "Support nonprofit organizations", image: nil),
//
//                .init(title: "More", subtitle: nil, image: nil, style: .title),
//                .init(title: "Airbnb Newsroom", subtitle: "Latest announcements", image: nil),
//                .init(title: "World Health Organization", subtitle: "Education and updates", image: nil),
//                .init(title: "Project Lighthouse", subtitle: "Finding and fighting discrimination", image: nil),
//            ]
//        }
//    }
//}

Wrap Up

With that, we've got all the boring stuff out of the way and we're ready to actually get started building something. See you in the next part!

Check out the code up to this point on this branch in the repo.

I have gotten a few questions about my recent article on How I Organize Layout Code in Swift, so I thought I would follow up on that and address a couple of the common ones. In this article we're going to look at some examples of how the view communicates with the view controller, how the view controller communicates back to the view, and some ways you can segue or transition to the next screen in your flow if you want to organize your layout code like I do.

View -> ViewController Communication

In my last article I sort of brushed over this, saying that I would use delegation. I realize now that specific examples are helpful for people who are learning, so let's look at what that could look like in our login view from last time. I'm going to use the last configuration we looked at, with ComposedLayoutViewController because it is the most complex and the most similar to what I actually implement in production.

First, we need to define a delegate protocol for the LoginStackView. This is where we'll put any messages that we want to communicate from this view up to whatever needs to hear it. We constrain it to AnyObject so that we know it is a reference type and LoginStackView can hold a weak reference to it.

// in LoginStackView.swift
protocol LoginStackViewDelegate: AnyObject {
    func didTapSubmit()
}

Then we add a delegate property.

class LoginStackView: ProgrammaticView {
    weak var delegate: LoginStackViewDelegate?

    // other stuff...
}

Then we add a method for the button to call, and call it when the user lifts their finger off the button, within its bounds.

class LoginStackView: ProgrammaticView {
    // other stuff...

    // in configure()
    submitButton.addTarget(self, action: #selector(submitTapped), for: .touchUpInside)

    @objc private func submitTapped() {
        delegate?.didTapSubmit()
    }
}

That's all we need in the LoginStackView. You can see how dead simple the logic is, and that's what I'm shooting for. So now we move up a level and do the same thing in ComposedLayoutView.

// in ComposedLayoutView.swift
protocol ComposedLayoutViewDelegate: AnyObject {
    func didTapSubmit()
}

class ComposedLayoutView: ProgrammaticView {
    weak var delegate: ComposedLayoutViewDelegate?

    // in configure()
    loginStack.delegate = self
}

extension ComposedLayoutView: LoginStackViewDelegate {
    func didTapSubmit() {
        delegate?.didTapSubmit()
    }
}

This is basically just passing the message along from the login stack to the composed layout view's delegate. Note that it is really important that you set loginStack's delegate somewhere, otherwise it will be sending messages that no one is receiving.

Finally, in our view controller, we just need to conform to ComposedLayoutViewDelegate and set the delegate on contentView:

class ComposedLayoutViewController: UIViewController {
    // in loadView
    contentView.delegate = self
}

extension ComposedLayoutViewController: ComposedLayoutViewDelegate {
    func didTapSubmit() {
        print("The user hit submit!")
        // handle submit
    }
}

We're not actually doing anything when the user hits submit yet, but if you run the code you can see that our print statement is showing up in the console. We'll look at how to move to the next screen in a later section, but let's think about what we've got here before we move on. In the view controller, all we know is that the user hit the submit button. We don't have any access to the strings they typed in in the text fields. For logging in, those are pretty important, so we need to get that info up to the view controller. We'll do that by adding them as parameters to our delegate method.

// in LoginStackView.swift
protocol LoginStackViewDelegate: AnyObject {
    func didTapSubmit(username: String?, password: String?)
}

// in LoginStackView.submitTapped()
delegate?.didTapSubmit(username: usernameField.text, password: passwordField.text)

// in ComposedLayoutView.swift
protocol ComposedLayoutViewDelegate: AnyObject {
    func didTapSubmit(username: String?, password: String?)
}

// in ComposedLayoutView extension
func didTapSubmit(username: String?, password: String?) {
    delegate?.didTapSubmit(username: username, password: password)
}

// in ComposedLayoutViewController extension
func didTapSubmit(username: String?, password: String?) {
    guard let username = username,
          !username.isEmpty,
          let password = password,
          !password.isEmpty else {
        return print("Don't have all the required info!")
    }
    print("The user hit submit with \(username) and \(password)!")
    // handle submit
}

Again, the logic to get the necessary information up to the view controller is very simple. That's what we want. Then all the logic for handling what to do will live in the view controller. Here we're just checking that we actually have all the information we need to make a decision. Let's see if we can clean that up a bit.

Cleaning Up

What I don't like about this is that we have to account for optionals and empty strings. And, it doesn't scale super well. We are only passing up two properties here, but what if we needed to pass up five? Or ten? Our delegate methods would get unwieldy. So we're going to wrap this data up in a struct.

struct LoginInfo {
    let username: String
    let password: String

    init?(username: String?, password: String?) {
        guard let username = username,
              !username.isEmpty,
              let password = password,
              !password.isEmpty else { return nil }
        self.username = username
        self.password = password
    }
}

Here, we check for all of our required data in a failable initializer. This means that further down the line we won't have to make all the checks, either we get a LoginData and we have everything we need, or we get nil and we know we don't have everything we need.

To use it, we just need to update the delegate methods.

// in LoginStackView.swift
protocol LoginStackViewDelegate: AnyObject {
    func didTapSubmit(loginInfo: LoginInfo?)
}

// in LoginStackView.submitTapped()
let loginInfo = LoginInfo(username: usernameField.text, password: passwordField.text)
delegate?.didTapSubmit(loginInfo: loginInfo)

// in ComposedLayoutView.swift
protocol ComposedLayoutViewDelegate: AnyObject {
    func didTapSubmit(loginInfo: LoginInfo?)
}

// in ComposedLayoutView extension
func didTapSubmit(loginInfo: LoginInfo?) {
    delegate?.didTapSubmit(loginInfo: loginInfo)
}

// in ComposedLayoutViewController extension
func didTapSubmit(loginInfo: LoginInfo?) {
    guard let loginInfo = loginInfo else {
            return print("Don't have all the required info!")
        }
    print("The user hit submit with \(username) and \(password)!")
    // handle submit
}

I like how clean that makes our logic, and it also nicely wraps up the information we'll need to pass to whatever form of authentication we'll be using in our app. But that leads us to the next question. What should we do if the user taps the submit button without the required info? Right now we are just printing a statement and doing nothing else. It is probably better UX to let the user know what the problem is. So let's see how we might handle that.

View Controller -> View Communication

First, I add a warning label to LoginStackView

private let warningLabel = UILabel()

// in configure()
warningLabel.text = "You must supply a username and password to log in."
warningLabel.numberOfLines = 0
warningLabel.textAlignment = .center
warningLabel.textColor = .systemRed
warningLabel.font = .preferredFont(forTextStyle: .callout)
// warningLabel.isHidden = true

// in constrain()
stackView.addArrangedSubviews(usernameField, passwordField, warningLabel, submitButton)

warningLabel.horizontalAnchors == horizontalAnchors

We want it to be hidden by default, but I usually comment that line out until I've got it looking the way I want. Once I do, I uncomment warningLabel.isHidden = true and move on to adding a method to show it.

func showWarning() {
    if warningLabel.isHidden {
        UIView.animate(withDuration: 0.3) {
            self.warningLabel.isHidden = false
        }
    }
}

First, I check to make sure that it is hidden and if it is, then I animate it to be shown. If it is already shown, we don't need to do anything.

So now we have our label and a function to call to show it. How do we get access to that in our view controller? There are a couple of ways and I've seen both used well, it just depends on what works best for your use case. The first is you could define a method on ComposedLayoutView (the middle man) that calls showWarning on its child LoginStackView and then call that method from ComposedLayoutViewController. That works, but it can get kind of messy if there are a lot of views involved. So here we're going to follow another method, one that Apple's frameworks use a ton. We're going to pass up a reference to the LoginStackView in the delegate method calls. Then, the view controller can just call showWarning on that. It is also a convenient way for the view controller to know which login stack called didTapSubmit, if there happen to be multiple. So first, we need to update our delegate methods again.

// in LoginStackView.swift
protocol LoginStackViewDelegate: AnyObject {
    func didTapSubmit(_ loginStack: LoginStackView, loginInfo: LoginInfo?)
}

// in LoginStackView.submitTapped()
let loginInfo = LoginInfo(username: usernameField.text, password: passwordField.text)
delegate?.didTapSubmit(self, loginInfo: loginInfo)

// in ComposedLayoutView.swift
protocol ComposedLayoutViewDelegate: AnyObject {
    func didTapSubmit(_ loginStack: LoginStackView, loginInfo: LoginInfo?)
}

// in ComposedLayoutView extension
func didTapSubmit(_ loginStack: LoginStackView, loginInfo: LoginInfo?) {
    delegate?.didTapSubmit(loginStack, loginInfo: loginInfo)
}

// in ComposedLayoutViewController extension
func didTapSubmit(_ loginStack: LoginStackView, loginInfo: LoginInfo?) {
    // same as before...
}

Now we have everything we need to show the warning when the user didn't supply all the required info.

// ComposedLayoutViewController.didTapSubmit()
guard let loginInfo = loginInfo else {
    return loginStack.showWarning()
}

That should give you a pretty good idea of how I work through the communication back and forth between the views and view controllers. There are always different scenarios and edge cases, but I pretty much always start with asking myself is this "view logic" or "business logic"? And then figure out how to get the responsibilities into their respective places.

Getting To The Next Screen

So that is a good look at how I organize the communications that goes on within a screen. But how do we get to the next one? Should we use segues? That is what most people who are used to using storyboards would reach for. And you can still use a segue if that is how you want to do it, but here I will show an easy (and somewhat naive) way to do it and then I'll show a simple example of Soroush Khalou's concept of a coordinator, which he wrote about in this blog post.

First, I'm going to add a few simple views for us to transition to. I also added a corresponding one called FailedLoginViewController, which is pretty much identical but has a different message. These aren't intended to be real views right now, just enough for us to illustrate the transition concept.

class LoggedInViewController: UIViewController {

    lazy var contentView: LoggedInView = .init()

    override func loadView() {
        view = contentView
    }
}

class LoggedInView: ProgrammaticView {
    private let label = UILabel()

    override func configure() {
        backgroundColor = .systemBackground

        label.text = "You're logged in!"
        label.textColor = .systemGreen
    }

    override func constrain() {
        addSubview(label)

        label.centerAnchors == centerAnchors
    }
}

Then I'm going to add a mock authenticator. This is going to be an object that we can give a LoginInfo instance to and it will attempt to authenticate the user. In a real app, this will involve some networking and more complex code, but it is likely that the interface you'll use will be pretty similiar. Right now, we don't care how the authentication happens, we just care what the result is.

class Authenticator {
    static let shared = Authenticator()

    private init() {}

    func authenticateUser(with loginInfo: LoginInfo) -> Bool {
        return loginInfo.username.count >= 4 && loginInfo.password == "1234"
    }
}

Obviously, there are a lot of problems with this Authenticator, but this isn't an article on authentication and it is good enough for us to use for now to test out our flows.

All we need to do now is use our authenticateUser method to determine which view to show:

// ComposedLayoutViewController.didTapSubmit()
guard let loginInfo = loginInfo else {
    return loginStack.showWarning()
}
let isValidUser = Authenticator.shared.authenticateUser(with: loginInfo)
if isValidUser {
    show(LoggedInViewController(), sender: self)
} else {
    show(FailedLoginViewController(), sender: self)
}

This works, but there are a couple of problems with it. First, we are using show, which will present the view controller modally here because our ComposedLayoutViewController isn't inside of a UINavigationController. It also means that the ComposedLayoutViewController is still in the view hierarchy underneath the new view. When we're logging in, we probably want to replace the window's root view controller, so that we can clear out the views used for logging in. To do that, we need access to the window. Unfortunately, there's not a great way to get access to that from the view controller (mostly because window manipulation should be done at a higher level). Let's look at how we could do this, and then quickly move to a better way.

guard let sceneDelegate = UIApplication.shared.connectedScenes.first?.delegate as? SceneDelegate,
      let window = sceneDelegate.window else {
    return show(LoggedInViewController(), sender: self)
}
window.rootViewController = LoggedInViewController()
UIView.transition(with: window, duration: 0.3, options: .transitionFlipFromRight, animations: nil, completion: nil)

Again, this technically works. If you throw a print statement in the deint of ComposedLayoutViewController you can see that we are getting rid of that altogether, so it is no longer hanging around in memory. But it very tightly couples our ComposedLayoutViewController to the views that come next. If we keep it like this, we are likely to end up with a bunch of complex and confusing logic in this method as we come across edge cases of other places in the app that we want to authenticate the user. Imagine if the user tapped a deeplink into the app, that should take them to some specific content, but they need to log in first, or imagine if you want to A/B test different home screens, etc. Depending on the structure of your app, there might be any number of views that should come after this login view. So let's take a look at how we can decouple this a little bit.

Coordinators

The concept of coordinators was, as far as I know, first posited by Soroush Khanlou, at least in the iOS world. I'm not going to go super in depth on it here, because he's already already got some great material on what they are and how to use them. What I will do is show you how I typically use them and how it can clean up the code we're looking at here. First, we're going to define a Coordinator class. This is where the logic for the flows between individual screens will live.

class Coordinator {
    let window: UIWindow
    private var viewController: UIViewController?

    init(window: UIWindow) {
        self.window = window
    }

    func start() {
        if Authenticator.shared.isLoggedIn {
            viewController = LoggedInViewController()
        } else {
            viewController = ComposedLayoutViewController()
        }
        window.rootViewController = viewController
        window.makeKeyAndVisible()
    }
}

I usually make my top level coordinator hold a reference to the window because it make the manipulations that you do at the beginning of the app lifecycle easier to do, but you could also just pass it a reference to your root tab bar controller or navigation controller, if that makes more sense in your use case. It'll also need to hold references to the view controllers or child coordinators that it is in charge of. Finally, has a start function. This is where the person who makes this coordinator will tell it to kick off its flow. In this case, the start method checks if the user is logged in and make the correct view controller the root.

Side note, I made a slight modification to our Authenticator to get this interface:

// in Authenticator
func authenticateUser(with loginInfo: LoginInfo) -> Bool {
    isLoggedIn = loginInfo.username.count >= 4 && loginInfo.password == "1234"
    return isLoggedIn
}

private(set) var isLoggedIn = false

Then, we actually need to use our new coordinator, which we'll do in SceneDelegate:

// need to keep a reference to this so it isn't deinitialized
private var coordinator: Coordinator?

func scene(_ scene: UIScene,
           willConnectTo session: UISceneSession,
           options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
    let window = UIWindow(windowScene: windowScene)

    coordinator = Coordinator(window: window)
    self.window = window

    coordinator?.start()
}

Here, we just make a window for our scene, we hand it off to the coordinator, and we tell the coordinator to start. With just that little bit of code, our app will now check if the user is logged in during launch and only show them the view controller that is relevant to their current state. An added bonus is this means we can get rid of the Main.storyboard altogether. Then, with the exception of the launch sreen, our app is now totally initialized in code.

So what about the login logic? For that, we'll just define another delegate protocol and hand off the information from the view controller to the Coordinator.

protocol ComposedLayoutViewControllerDelegate: AnyObject {
    func attemptedLogin(with loginInfo: LoginInfo)
}

// in ComposedLayoutViewController
weak var delegate: ComposedLayoutViewControllerDelegate?

func didTapSubmit(_ loginStack: LoginStackView, loginInfo: LoginInfo?) {
    guard let loginInfo = loginInfo else {
        return loginStack.showWarning()
    }
    delegate?.attemptedLogin(with: loginInfo)
}

Notice how simple didTapSubmit is now. We check to make sure we have all the information we need to attempt a login and if we don't, we respond within this view. This is the jurisdiciton of this view controller, so it just tells the view what to do. If we're ready to move beyond this view (i.e. we have all the information we need), we just pass it up to the delegate.

Finally, the coordinator needs to adopt the delegate protocol and make itself the view controller's delegate.

// in Coordinator.start()
let loginVC = ComposedLayoutViewController()
loginVC.delegate = self
viewController = loginVC

func attemptedLogin(with loginInfo: LoginInfo) {
    let isLoggedIn = Authenticator.shared.authenticateUser(with: loginInfo)
    if isLoggedIn {
        viewController = LoggedInViewController()
        window.rootViewController = viewController
        UIView.transition(with: window, duration: 0.3, options: .transitionFlipFromRight, animations: nil, completion: nil)
    } else {
        viewController?.show(FailedLoginViewController(), sender: viewController)
    }
}

Again, this is nice and clean because our coordinator already has a reference to the window, so we don't have to jump through hoops to get that. And we are totally free to do whatever we want in this function. We could present any view controller we want, based on a feature flag or an API call, we could spin up a child coordinator and have that make the decision, etc. In this case, if the login is successful I am replacing the root view controller with the logged in view, and giving it a little animation. If it isn't successful, I just pop up a message modally to let the user know something went wrong.

Wrap Up

We've covered a lot of ground here. We looked at how I have my views communicate with my view controllers, we've looked at how those view controllers communicate back down to their views, and we've looked at a couple ways you can organize the logic for the flows between screens. As always, I hope it has been helpful and maybe given you an opportunity to think about how you organize your own code. If you have any questions or suggestions, throw them in the comments!

Check out all the code from this article on github

Sometimes you have a collection of elements that are not in the order that you need them. Fortunately, Swift gives us an easy way to get them from that chaotic state into an ordered state. In this article we're going to look at how to use the sort methods, how we can clean up the code around them, and how we can sort objects that aren't necessarily sortable as a whole.

Breaking It Down

If you've taken a computer science class, or are learning fundamentals, you have probably learned about insertion sort, quicksort or merge sort or one of the others and how to implement them. That's good stuff to know, but in practice we don't usually want to think at that level because we are likely to make mistakes in our code and there is almost always a way to optimize things further beyond what we know. So Swift has these two methods sort(by:) and sorted(by:). They provide an abstraction around what sorting method is used, so you don't have to care. They just ask you for a closure that they can call on any two elements and you have to return a boolean that lets the sort function know if those two elements are in increasing order.

mutating func sort(by areInIncreasingOrder: (Element, Element) throws -> Bool) rethrows
func sorted(by areInIncreasingOrder: (Element, Element) throws -> Bool) rethrows -> [Element]

Let's dig into that, but first I just want to note that the main difference between them is sort sorts your collection in place and sorted returns a new array with the elements sorted. I almost always use sorted, but there are times when performance can be improved significantly by using sort instead, so it is good to keep in the back of your head. For the rest of this article, I'm only going to refer to sorted.

Looking at the function signature might be a little intimidating. I know it was for me when I was first trying to read the documentation. I mean, what is rethrows? It turns out, the throws and rethrows in this context are things you can ignore until you need them. (If you can't stand not knowing, check out Paul Hudson's article on the topic.) So let's just pretend that this is the signature:

func sorted(by areInIncreasingOrder: (Element, Element) -> Bool) -> [Element]

This is a function which you can call on a collection, it's only parameter is a closure that takes two Elements and returns a Bool, and the function itself returns an [Element]. The closure is where you tell the sorter how to sort. It might look something like this:

let unsortedArray = [3, 2, 5, 1, 4]

let goingUp = unsortedArray.sorted(by: { first, second -> Bool in
    return first < second
})
// goingUp == [1, 2, 3, 4, 5]

let goingDown = unsortedArray.sorted(by: { first, second -> Bool in
    return first > second
})
// goingDown == [5, 4, 3, 2, 1]

So whatever method is actually used for sorting, it will go through and any time it needs to make a decision of "should this element go first or that one?" it will call this closure and based on the answer it will know where each element needs to go. This is already pretty powerful, but it gets even better.

Same Thing, But Shorter

We can communicate the same thing in way fewer characters because of some nice syntactic sugar in Swift. Let's see all the steps we can take to reduce our code here.

First, we can make it a trailing closure and get rid of the argument label.

let goingUp = unsortedArray.sorted() { first, second -> Bool in
    return first < second
}

We can get rid of the return type definition, because the sorted method already has that as a part of its signature so it can be inferred here. If you try to write a closure here that doesn't return a boolean, the compiler will complain.

let goingUp = unsortedArray.sorted() { first, second in
    return first < second
}

Because this is one line, we can also get rid of the return keyword at the end of the closure. The compiler will assume that you intend to return the result of this line (as long as it evaluates to a boolean).

let goingUp = unsortedArray.sorted() { first, second in
    first < second
}

We also get some free parameter names that are based on the argument position in the closure, so we can get rid of the parameter names too. $0 will be the first argument, counting up from there.

let goingUp = unsortedArray.sorted() {
    $0 < $1
}

We can also get rid of the parentheses because there are no other arguments except this trailing closure. At the same time, this is so short we can even fit it on one line.

let goingUp = unsortedArray.sorted { $0 < $1 }

That is much shorter, and it puts the central logic right in front of you. We're sorting in the order where the smaller elements will come first. But don't feel bad if you get mixed up with such short statements, especially when it hasn't made it into your muscle memory yet. I think it is a good practice to start with the fully expanded version while you're working the logic out and then go through these steps to try to condense it from there. Over time, it will become second nature for you.

In this case, we can actually take it even farther. Because operators in Swift are basically just special syntax for functions, and functions are themselves closures, and because the signature for < matches the signature for the closure we're looking for in sorted, as long as the elements in our array are Comparable we can just pass the operator as the parameter.

let goingUp = unsortedArray.sorted(by: <)

Last but not least, if we want to sort in ascending order (which we do in this case) and our elements are Comparable, we don't actually have to provide any argument because that is the default.

let goingUp = unsortedArray.sorted()

Sorting On Properties

Another thing that makes sorted so powerful is that you don't have to sort on the whole element, you can sort on one of its properties instead. This is super helpful because it is not uncommon to have an object where the whole object is not Comparable, but some of its properties are. For example, think about how you would sort a group of people. Would you sort them by age? or by name? by height? Whatever you chose, you would almost certainly sort them by some specific attribute (or combination of attributes), not by them as whole people. It’s hard to even imagine what that would mean. Besides that, in some contexts it may make sense to sort them by name, but in others it may make more sense to sort them by interest, or height, or hair color. And the same is true in our code. Fortunately, Swift makes this really easy to do.

struct Person {
    let name: String
    let createdAt: Date = Date()
}
let wayne = Person(name: "Wayne")
let derry = Person(name: "Derry")
let dan = Person(name: "Dan")

let unsortedPeople = [dan, wayne, derry]

let alphabetical = unsortedPeople.sorted { $0.name < $1.name }
// alphabetical == [dan, derry, wayne]

let oldestFirst = unsortedPeople.sorted { $0.createdAt < $1.createdAt }
// oldestFirst == [wayne, derry, dan]

In the first example, we sort on the person's name and the second we sort on the date when that person was created. If your object has further nested properties, you could sort on those too! It just comes down to whatever makes the most sense in your use case. And that is the beauty of sorted. You don't have to worry about how to sort elements, you only have to think about what you want to sort them by.

For some extra sugar, you can even add a simple extension that I picked up from John Sundell that will let you sort on a keypath. I won't go into detail here about what keypaths are or how to use them, but check out John's article if you're interested. Here's what that looks like.

extension Sequence {
    func sorted<T: Comparable>(by keyPath: KeyPath<Element, T>) -> [Element] {
        sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] }
    }
}

let alphabetical = unsortedPeople.sorted(by: \.name)
// alphabetical == [dan, derry, wayne]

A couple of things to note about this extension. First, this method assumes that you want to sort in ascending order, but you can customize it however makes sense for your use case. You could even further extend it to also take in a closure so that the sort order could be defined at the call site. But I'll leave that as an exercise for you to try out if you want.

Second, notice that the extension is on Sequence, not on Array. This is because of another very powerful feature of Swift, the collection protocols. Again, I'm not going to go into a ton of detail here, but check out Harshil Shah's article on Swift's Collection Types. It is about as close to comprehensive as I have come across, and he does a great job of making it understandable. What it means for us here is that this extension will add this sorted method to any type that conforms to Sequence. That means not only can we call it on an Array, we can also call it on a Set, a Dictionary, or even on a String(although I'm not sure how often that is useful).

let set = Set([wayne, derry, dan])
let alphabetical = set.sorted(by: \.name))
// alphabetical == [dan, derry, wayne]

let numberOfPuppers = [wayne: 6, derry: 4, dan: 9]
let byLeastDrunk = numberOfPuppers.sorted(by: \.value)
// byLeastDrunk == [(key: Derry, value: 4), (key: Wayne, value: 6), (key: Dan, value: 9)]

let sortedLetters = "Sushis and sashimis.".sorted(by: \.description)
// sortedLetters == [" ", " ", ".", "S", "a", "a", "d", "h", "h", "i", "i", "i", "m", "n", "s", "s", "s", "s", "s", "u"]

Wrap Up

So there you have it. We've looked at how to use sort/sorted even though their signatures might be a little intimidating. We've looked at how to use them with as few characters of code as possible. And we've looked at how to sort objects that may not make sense to sort as a whole, but have properties you can sort on. I hope that gives you a better picture of how to use these methods. If you have any questions, tips, tricks or stories about sorting in Swift, be sure to share them in the comments.

I was asked the other day how I organize my layout code when I am building my UI programmatically using UIKit. In this post I will walk through a variety of things that I have tried over time and end with what my typical organization now looks like. It will not teach you how auto layout works. It will also not make an argument for why you should lay out your UI this way. Different methods work for different people. If you love storyboards, run with them. All I intend to share is what I have landed on for now. (And hopefully when I look back on this article in a year, it will have further evolved, because I kept learning and growing.)

This is the layout we'll look at in these examples. All of the different pieces of code you find here should lead to this same layout.

Basic Layout

The first method I learned, and honestly what you'll see in a lot of tutorials, is to lay things out in viewDidLoad in your ViewController using a series of methods on NSLayoutAnchor called constraint. This results in code that looks like this:

class BasicLayoutViewController: UIViewController {

    // define the elements
    let usernameField = UITextField()
    let passwordField = UITextField()
    let submitButton = UIButton(type: .custom)

    override func viewDidLoad() {
        super.viewDidLoad()

         // configure them
        view.backgroundColor = .secondarySystemBackground

        usernameField.placeholder = "Username"
        usernameField.borderStyle = .roundedRect

        passwordField.placeholder = "Password"
        passwordField.textContentType = .password
        passwordField.isSecureTextEntry = true
        passwordField.borderStyle = .roundedRect

        submitButton.setTitle("Log in", for: .normal)
        submitButton.backgroundColor = .systemBlue
        submitButton.layer.cornerRadius = 8

        // add them to the view hierarchy and constrain them
        view.addSubview(usernameField)
        view.addSubview(passwordField)
        view.addSubview(submitButton)

        usernameField.translatesAutoresizingMaskIntoConstraints = false
        usernameField.leadingAnchor.constraint(equalTo: passwordField.leadingAnchor).isActive = true
        usernameField.trailingAnchor.constraint(equalTo: passwordField.trailingAnchor).isActive = true

        passwordField.translatesAutoresizingMaskIntoConstraints = false
        passwordField.topAnchor.constraint(equalTo: usernameField.bottomAnchor, constant: 8).isActive = true
        passwordField.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true
        passwordField.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20).isActive = true
        passwordField.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20).isActive = true

        submitButton.translatesAutoresizingMaskIntoConstraints = false
        submitButton.topAnchor.constraint(equalTo: passwordField.bottomAnchor, constant: 8).isActive = true
        submitButton.centerXAnchor.constraint(equalTo: passwordField.centerXAnchor).isActive = true
        submitButton.widthAnchor.constraint(equalToConstant: 200).isActive = true
    }
}

The first thing I started doing to improve this was to pull the configuration and constraining out to separate functions, so they are a little easier to find/digest when reading. That looks like this:

class BasicLayoutViewController: UIViewController {

    let usernameField = UITextField()
    let passwordField = UITextField()
    let submitButton = UIButton(type: .custom)

    override func viewDidLoad() {
        super.viewDidLoad()

        configure()
        constrain()
    }

    private func configure() {
        view.backgroundColor = .secondarySystemBackground

        usernameField.placeholder = "Username"
        usernameField.borderStyle = .roundedRect

        passwordField.placeholder = "Password"
        passwordField.textContentType = .password
        passwordField.isSecureTextEntry = true
        passwordField.borderStyle = .roundedRect

        submitButton.setTitle("Log in", for: .normal)
        submitButton.backgroundColor = .systemBlue
        submitButton.layer.cornerRadius = 8
    }

    private func constrain() {
        view.addSubview(usernameField)
        view.addSubview(passwordField)
        view.addSubview(submitButton)

        usernameField.translatesAutoresizingMaskIntoConstraints = false
        usernameField.leadingAnchor.constraint(equalTo: passwordField.leadingAnchor).isActive = true
        usernameField.trailingAnchor.constraint(equalTo: passwordField.trailingAnchor).isActive = true

        passwordField.translatesAutoresizingMaskIntoConstraints = false
        passwordField.topAnchor.constraint(equalTo: usernameField.bottomAnchor, constant: 8).isActive = true
        passwordField.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true
        passwordField.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20).isActive = true
        passwordField.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20).isActive = true

        submitButton.translatesAutoresizingMaskIntoConstraints = false
        submitButton.topAnchor.constraint(equalTo: passwordField.bottomAnchor, constant: 8).isActive = true
        submitButton.centerXAnchor.constraint(equalTo: passwordField.centerXAnchor).isActive = true
        submitButton.widthAnchor.constraint(equalToConstant: 200).isActive = true
    }
}

I also went through a phase where all my UI elements were lazy and the configuration was done in a closure. I don't do that anymore mostly because I prefer to keep all my configuration code together and to abstract out commonly used configurations, but when I did it looked something like this:

private lazy var usernameField: UITextField = {
    let textField = UITextField()
    textField.placeholder = "Username"
    textField.borderStyle = .roundedRect
    return textField
}()

Moving Out Of The View Controller

The next step was hearing in some conference talk that you should do the view stuff in the view, not the view controller. That made a lot of sense to me, so I started defining custom views like this:

class BasicLayoutView: UIView {

    private let usernameField = UITextField()
    private let passwordField = UITextField()
    private let submitButton = UIButton(type: .custom)

    override init(frame: CGRect) {
        super.init(frame: frame)

        configure()
        constrain()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func configure() {
        backgroundColor = .secondarySystemBackground

        usernameField.placeholder = "Username"
        usernameField.borderStyle = .roundedRect

        passwordField.placeholder = "Password"
        passwordField.textContentType = .password
        passwordField.isSecureTextEntry = true
        passwordField.borderStyle = .roundedRect

        submitButton.setTitle("Log in", for: .normal)
        submitButton.backgroundColor = .systemBlue
        submitButton.layer.cornerRadius = 8
    }

    func constrain() {
        addSubview(usernameField)
        addSubview(passwordField)
        addSubview(submitButton)

        usernameField.translatesAutoresizingMaskIntoConstraints = false
        usernameField.leadingAnchor.constraint(equalTo: passwordField.leadingAnchor).isActive = true
        usernameField.trailingAnchor.constraint(equalTo: passwordField.trailingAnchor).isActive = true

        passwordField.translatesAutoresizingMaskIntoConstraints = false
        passwordField.topAnchor.constraint(equalTo: usernameField.bottomAnchor, constant: 8).isActive = true
        passwordField.centerYAnchor.constraint(equalTo: centerYAnchor).isActive = true
        passwordField.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 20).isActive = true
        passwordField.trailingAnchor.constraint(equalTo: trailingAnchor, constant: -20).isActive = true

        submitButton.translatesAutoresizingMaskIntoConstraints = false
        submitButton.topAnchor.constraint(equalTo: passwordField.bottomAnchor, constant: 8).isActive = true
        submitButton.centerXAnchor.constraint(equalTo: passwordField.centerXAnchor).isActive = true
        submitButton.widthAnchor.constraint(equalToConstant: 200).isActive = true
    }
}

And the view controller would load the view like this:

class BasicLayoutViewController: UIViewController {

    // the contentView is lazily loaded so that all the work of initializing our view
    // isn't done until the view controller is actually ready to load it
    lazy var contentView: BasicLayoutView = .init()

    override func loadView() {
        view = contentView
    }
}

This works pretty well. It gets the layout into the view, and keeps the view controller pretty clean so that it is easier to find/read/add business logic there. One thing I didn't like though was that I had to provide the required init?(coder:) in all of my views, even though I wasn't using it for anything. It just cluttered up my code and added boilerplate. So I decided to add a new UIView subclass to act as the parent for classes that I intended to layout programmatically. It looks like this:

class ProgrammaticView: UIView {
    @available(*, unavailable, message: "Don't use init(coder:), override init(frame:) instead")
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override init(frame: CGRect) {
        super.init(frame: frame)

        configure()
        constrain()
    }

    func configure() {}
    func constrain() {}
}

Marking the required initializer as unavailable makes it so that you don't have to provide it in subclasses. You can see that I've also defined some template methods for configure() and constrain() and called those in the initalizer. That makes BasicLayoutView look like this:

class BasicLayoutView: ProgrammaticView {

    private let usernameField = UITextField()
    private let passwordField = UITextField()
    private let submitButton = UIButton(type: .custom)

    override func configure() {
        // same as before...
    }

    override func constrain() {
        // same as before...
    }
}

Much nicer. The view that it inherits from tells you that it is intended to be laid out programmatically, and all the code written in this class is relevant to it. You just have to add override to the configure and constrain methods.

Cleaning Up

Next, I learned about NSLayout.activate() which takes an array of NSLayoutConstraints and activates them all at once. This might be more efficient in certain cases, but it mostly means that you don't have to write .isActive = true for every constraint. I also added a couple of convenience extensions to UIView to redeuce the number of lines I have to write for every view. That looks like this:

extension UIView {
    func addConstrainedSubview(_ view: UIView) {
        view.translatesAutoresizingMaskIntoConstraints = false
        addSubview(view)
    }

    func addConstrainedSubviews(_ views: UIView...) {
        views.forEach { view in addConstrainedSubview(view) }
    }
}

// in BasicLayoutView
override func constrain() {
    addConstrainedSubviews(usernameField, passwordField, submitButton)

    NSLayoutConstraint.activate([
        usernameField.leadingAnchor.constraint(equalTo: passwordField.leadingAnchor),
        usernameField.trailingAnchor.constraint(equalTo: passwordField.trailingAnchor),

        passwordField.topAnchor.constraint(equalTo: usernameField.bottomAnchor, constant: 8),
        passwordField.centerYAnchor.constraint(equalTo: centerYAnchor),
        passwordField.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 20),
        passwordField.trailingAnchor.constraint(equalTo: trailingAnchor, constant: -20),

        submitButton.topAnchor.constraint(equalTo: passwordField.bottomAnchor, constant: 8),
        submitButton.centerXAnchor.constraint(equalTo: passwordField.centerXAnchor),
        submitButton.widthAnchor.constraint(equalToConstant: 200),
    ])
}

That is both shorter and a little bit easier to read. Again, putting the information that is relevant to this view in the view and striping out noise that we don't really care about.

Next, I started throwing UIStackViews into the mix whenever I could. I added another convenience method specific to stack views too. For this view that would look like this:

extension UIStackView {
    func addArrangedSubviews(_ views: UIView...) {
        views.forEach { view in addArrangedSubview(view) }
    }
}

class StackViewLayoutView: ProgrammaticView {
    private let stackView = UIStackView()
    private let usernameField = UITextField()
    private let passwordField = UITextField()
    private let submitButton = UIButton(type: .custom)

    override func configure() {
        // same stuff as before...

        stackView.axis = .vertical
        stackView.spacing = 8
        stackView.alignment = .center
    }

    override func constrain() {
        addConstrainedSubview(stackView)
        stackView.addArrangedSubviews(usernameField, passwordField, submitButton)

        NSLayoutConstraint.activate([
            stackView.leadingAnchor.constraint(equalTo: leadingAnchor, constant: 20),
            stackView.trailingAnchor.constraint(equalTo: trailingAnchor, constant: -20),
            stackView.centerYAnchor.constraint(equalTo: centerYAnchor),

            passwordField.widthAnchor.constraint(equalTo: stackView.widthAnchor),
            usernameField.widthAnchor.constraint(equalTo: stackView.widthAnchor),
            submitButton.widthAnchor.constraint(equalToConstant: 200),
        ])
    }
}

Anchorage

Already that is a lot cleaner than where we started and it is pretty flexible in terms of defining a variety of layouts in a fairly concise way. But I usually go a step farther when I am in a context where I can pull in third party dependencies. My favorite library for working with constraints is called Anchorage. It lets you write constraints with operators and provides some convenient proxies for doing things like setting all the sides at once or the size or whatever. It is fast to write and very easy to read. It's main downside is increased compile time, but it isn't really noticeable unless you're in a giant project and they are doing work to improve that.

Rewriting our view with Anchorage would look like this:

class AnchorageLayoutView: ProgrammaticView {
    private let usernameField = UITextField()
    private let passwordField = UITextField()
    private let submitButton = UIButton(type: .custom)

    override func configure() {
        // same as before...
    }

    override func constrain() {
        addSubviews(usernameField, passwordField, submitButton)

        passwordField.centerYAnchor == centerYAnchor
        // notice you can constrain the leading and trailing anchors at the same time
        passwordField.horizontalAnchors == horizontalAnchors + 20

        usernameField.bottomAnchor == passwordField.topAnchor - 8
        usernameField.horizontalAnchors == passwordField.horizontalAnchors

        submitButton.topAnchor == passwordField.bottomAnchor + 8
        submitButton.centerXAnchor == passwordField.centerXAnchor
        submitButton.widthAnchor == 200
    }
}

Like I said, it looks super clean and is very easy to read and write.

Putting It All Together

Finally, I started to combine Anchorage with stackviews, and compose them both with views defined elsewhere. This is closest to what my actual method is at this point in time. Basically any time I have a view that can be reused, I'll pull it out to its own ProgrammaticView subclass and then just plug it into views where it is needed like we've been doing with UITextFields and UIButtons in this example layout. With our example layout, that might look something like this:

class LoginStackView: ProgrammaticView {
    private let stackView = UIStackView()
    private let usernameField = UITextField()
    private let passwordField = UITextField()
    private let submitButton = UIButton(type: .custom)

    override func configure() {
        // same as before...
    }

    override func constrain() {
        addSubview(stackView)
        stackView.addArrangedSubviews(usernameField, passwordField, submitButton)

        stackView.edgeAnchors == edgeAnchors
        passwordField.horizontalAnchors == horizontalAnchors
        usernameField.horizontalAnchors == horizontalAnchors
        submitButton.widthAnchor == 200
    }
}

class ComposedLayoutView: ProgrammaticView {
    private let loginStack = LoginStackView()

    override func configure() {
        backgroundColor = .secondarySystemBackground
    }

    override func constrain() {
        addSubview(loginStack)

        loginStack.horizontalAnchors == horizontalAnchors + 20
        loginStack.centerYAnchor == centerYAnchor
    }
}

Pulling out the login stack to its own view may or may not be worthwhile. It would depend on how often you foresee using this specific view throughout your app. If you needed to, you could make it more configurable so that it could be reused in a wider variety of use cases. Either way, I think it illustrates the technique well.

Side note, you may be wondering how I pass information back up from all the subviews to the view controller. My last article on delegation describes exactly my process for that, so I won't go into it here.

Wrap Up

There you have it. That is basically the journey I took from first learning how to define a constraint in code to how I organize that code today. When you get down to it, what that code is doing is almost exactly the same, but I think the method I have now is easier to read (both for myself and others), it is easier to reuse, and it is faster to get something built because I don't have to remember any of the unimportant noise. I hope it has been helpful to you and maybe given you an idea or two that you can try applying in your own code. If you have questions, or ideas for how I can improve things let me know in the comments!

You can find all the code and the sample project I built for this article at this github repo.

Intro

Delegation is a commonly used pattern in Apple's frameworks, but I find that many people have a hard time wrapping their heads around it when they are first learning iOS development. And it is no wonder because the terms used to define it aren't particularly "beginner-friendly".

Take this quote from the Swift Language Guide:

This design pattern is implemented by defining a protocol that encapsulates the delegated responsibilities, such that a conforming type (known as a delegate) is guaranteed to provide the functionality that has been delegated.

Or this quote from John Sundell's article on the topic:

The core purpose of the delegate pattern is to allow an object to communicate back to its owner in a decoupled way. By not requiring an object to know the concrete type of its owner, we can write code that is much easier to reuse and maintain.

If you have been programming for a while, those sentences probably mean something to you. But if you are just starting out, there's a good chance you just experience some cognitive overload and don't really come away from it knowing anything more about what delegation is. So let's take a look at what delegation is, why we use it, and an example of how I use it in my apps.

What Is Delegation?

The concept itself is fairly simple. I can illustrate it with a metaphor. Imagine an executive has some work they would like done and a few questions they would like answered, but they either can't or won't do those things for themselves. Maybe they don't have the time, or they don't have the skill, or whatever, it doesn't really matter. This person is our "delegator". So what the delegator does is write a job description saying "I need someone who knows how to do this one task and answer these two questions." That person will be the "delegate". The delegate can be anyone in the world, as long as they sign the contract confirming that they know how to do the task and find the answers for the questions. Then, any time the delegator needs that task done or the questions answered, they just hand that off to the delegate who actually does the work and brings the result back.

In Swift, we call the "job description" a protocol. In other languages it is called an interface, so you might see that term as well. According to the Swift Language Guide: "A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality." Sounds a lot like our job description to me. And when a class adopts a protocol, that is signing the contract. It is telling me and you, and the rest of the code, and the compiler that it can do everything described in that protocol.

So if we write our example scenario as code it might look like this:

// This protocol will hold everything the manager class needs their assistant to do
protocol ManagerDelegate {
    func doLaundry(for manager: Manager, laundry: [Clothes]) -> [Clothes]
    func howMuchMoneyDidWeMake() -> Int
    func whatBearIsBest() -> String
}

class Manager {
    // the manager doesn't care what class their assistant is,
    // only that they can do what the manager needs them to do
    weak var assistant: ManagerDelegate? 

    // whenever the manager needs those tasks done, they just have the assistant do it
    func performEndOfDayTasks() {
        if today.isMonday {
            cleanClothes = assistant.doLaundry(for: self, laundry: dirtyClothes)
        } else if today.isFriday {
            let profit = assistant.howMuchMoneyDidWeMake()
            tellBoss("We made \(profit) dollars this week boss!")
        }
    }
}

// The assistant adopts the protocol and this code will not compile
// unless they meet all the requirements of the protocol
class Assistant: ManagerDelegate {
    func doLaundry(for manager: Manager, laundry: [Clothes]) -> [Clothes] {
        var cleanClothes = washClothes(laundry) 
        dryClothes(cleanClothes)
        foldClothes(cleanClothes)
        return cleanClothes
    }
    func howMuchMoneyDidWeMake() -> Int {
        return ledger.profit
    }
    func whatBearIsBest() -> String {
        return "There are basically two schools of thought..."
    }
}

Why Use Delegation?

So that explains what delegation is and what it might look like, but it doesn't explain why anyone would want to do it in the first place. Why can't the manager just do the work themselves? Like we said earlier, in the real world they might be constrained by time (not enough hours in the day) or constrained by capability (don't have the skill), or they might be constrained by desire (just don't want to do it). When we're talking about code, the metaphor breaks down here a little bit because our code is not (yet) sentient and it doesn't really have any desires. Here are a couple of reasons why we use delegation in our code: It promotes proper separation of concerns. Our Manager class can hold all the logic that is necessary for managing and not have to be cluttered up with logic for assisting. It has an assistant for that. This makes our code easier to read and easier to reason about. When you need to update the managing logic, or you are trying to track down an assisting bug, you know right where to look. It decouples our code. That means each class is not tied to the other directly. We can test each class's logic individually, we can debug them separately, and we can grow one's functionality without affecting the other. And if we want to write a new ExecutiveAssistant class, we can do that and swap it out without affecting anything about how the Manager operates, as long as it adopts the appropriate protocol(s). If we work on a team, one person can work on the Manager class and another can work on the Assistant class without conflicts. This is what people mean when they say two classes are "loosely coupled". Things would be much more "tightly coupled" if our Manager defined its assistant as var assistant: Assistant. In our real-world metaphor, loose coupling would be "I need an assistant who fits this job description" and tight coupling would be something like "I need Dwight as my assistant, no one else will do". It promotes reuse. In the real world we can (theoretically) pluck a manager from one position and place them in another, and as long as they know how to manage people in general, it shouldn't matter if they are managing these people or those people. They should continue to thrive. The same can be said for an assistant, whether they are assisting this person or that person. There are similar examples in our code. Think about a table view. There's a lot of logic used for rendering a vertically scrolling table on screen. You have to manage all the cells and it would probably be good if you make sure they are reused so that your app doesn't generate thousands of views for long lists, etc. There is a lot of logic there that you and I don't want to have to write every time we need a table in our app, so it would be great if there was a class that we could reuse for that. The hitch is that the content that we want to display in each table is different. As it happens Apple came up with a solution for us and it is called UITableView (although modern readers may want to prefer UICollectionView), and they used delegation to allow us to define the logic for our individual apps while keeping the logic for rendering tables wrapped up in its own class where it can be reused. If all those reasons aren't enough for you, I suppose you could write all of your own code without using delegation. You could use other patterns like target-action or callbacks to achieve many of the same things (with other trade-offs). But if you are developing iOS apps, you're going to have to implement at least a few delegates at some point because it is a common pattern in Apple's frameworks, so you may as well get comfortable with the pattern.

How I Use Delegation

I have been developing iOS apps for a few years, so I have implemented my fair share of UITableViewDelegates and UICollectionViewDataSources but I also like using the delegate pattern with my own views. I tend to lay out my UI in a UIView subclass, define a delegate for that view, and then pass up any events that happen to the delegate. So if there is a button in the view, the user's action of tapping on that button that gets passed to the delegate (most often its owning UIViewController). It usually looks something like this:

First, we define the delegate protocol. This will be all the messages our view needs to relay to its delegate. For this example, we'll just let them know that the button has been tapped, but in production code you would probably want to have a more specific and communicative name for this function.

protocol SomeDetailViewDelegate: AnyObject {
    func didTapButton()
}

Then the view itself. It has a delegate which is weak. The reason why is beyond the scope of this article, but the simple answer is it helps to prevent retention cycles by making sure SomeDetailView doesn't retain it's delegate. If you want, you can read more about how that works here. Also notice that we marked our protocol has being AnyObject. That is because the compiler won't let us mark it as weak in the view if it isn't known to be a reference type and that is exactly what AnyObject does.

class SomeDetailView: UIView {

    weak var delegate: SomeDetailViewDelegate?
    private let button = UIButton()

    // somewhere in the configuration and layout of button and other views
    button.addTarget(self, action: #selector(didTapButton), for: .touchUpInside)

    @objc private func didTapButton(_ sender: UIButton) {
        delegate?.didTapButton()
    }
}

You can see that the view itself is pretty dumb (meaning that it doesn't hold much, if any, business logic). It just defines what the UI looks like and then passes the messages it gets along to its delegate.

Next we have the view controller that will hold this view. It has a strong reference to the view and it is responsible for putting it on screen (not shown here). At some point, preferably before it is possible for the view to send any messages to its delegate, the view controller sets itself as the view's delegate.

class SomeDetailViewController: UIViewController {
    private lazy var detailView: SomeDetailView = {
        let detailView = SomeDetailView()
        detailView.delegate = self
        return detailView
    }()
}

Now to get that to compile, our view controller must adopt the delegate protocol. Here, I am doing it in an extension. This is not required, but it is a fairly common pattern that you'll see and it is a nice way to wrap up all the logic relating to that protocol in one place. It can even be put in a separate file if you want. Regardless of how you conform to the protocol, this is where the logic for what to do when the user taps that button lives.

extension SomeDetailViewController: SomeDetailViewDelegate {
    func didTapButton() {
        print("Do something when the user taps the button")
    }
}

This organization leads to all of the benefits discussed earlier. It separates the UI logic from the business logic, so if you have a layout bug you know where to look. It decouples our view from our view controller, allowing you to make changes to the view with no effect on the business logic and vice versa. And it promotes reuse. Any view controller (or even another view) could now plug this view in and all it needs to do is decide how to conform to the one new protocol method. And, if it is done consistently throughout a code base, anyone else can hop in to our code and know where to look with only a few minutes of explanation.

Wrap Up

So quick recap:

• Delegation is just handing off some work to someone/something else who is able to do that work.
• Use delegation to separate concerns, to decouple your classes, and to make your code more reusable
• A good place to start with delegation is between your view and your view controller

I hope this helps, especially if you're just getting started in iOS development. And if it did, let me know! Maybe you're a more experienced developer who thinks the delegate pattern is boring, or outdated, and we shouldn't use it anymore. Feel free to let me know all your thoughts and opinions too.

Algorithms

If you search Google, you’ll find that an algorithm is “a process or set of rules to be followed in calculations or other problem-solving operations, especially by a computer.” You use algorithms to search and to sort. You use algorithms to find the shortest route between two points, or to determine the next best move to take in a game. They are basically a set of instructions that you give to the computer that allows it to accomplish a task. And I know what you’re thinking, that is all code. And as far as I know, that is technically true. At least according to the definition given above. But when we talk about algorithms, we are usually talking about solving interesting problems. These are problems that seem easy for a human to do (with a small number of inputs at least) but whose solutions are not straightforward to describe in a way that computers can understand.

Algorithms tend to be described as elegant or clever. They don’t list out explicitly all the steps that a computer would use to solve the problem, they are distilled down descriptions of how to solve the problem. You and I are unlikely to ever come up with one that wasn’t already described by some computer science professor or medieval Muslim. Basically all of the good and useful ones have already been thought of, so our job when it comes to algorithms tends to be finding the right one and adapting it to solve our particular problem. Even so, it is a helpful exercise to go through trying to come up with them for yourself, as it will help you remember the algorithms when the time comes that you need to implement them in real code.

Binary Search

Binary search is a relatively simple algorithm that can save huge amounts of time/calculations when you are searching against a large sorted list. Here is an example of what this algorithm might look like in real life (or at least what it would have looked like before we had digital dictionaries): Suppose you were reading an article or book and came across the word “obeliscolychny”. If you are like me, you probably wouldn’t know what that word means, and you would probably even have difficulty parsing out any meaning from the roots by just looking at it. So you, like any good reader, would pull out your dictionary and look up the word.

How would you go about doing that? Would you start at the first page and flip through them one at a time, scanning each page until you found the word? No! You would crack it open in the middle, check what letter you landed on, and move backwards if you had gone too far or forward if you had not gone far enough. You would quickly narrow down your scope until you found the word you were looking for. (It means “lighthouse” if you haven’t already Googled it.)

That’s how binary search works. It halves the number of possible elements with each step by checking the middle element. If it is too high, it can safely disregard all the elements above that element. If it is too low, it can safely disregard all the elements below that element. (This is why it only works if you are searching a sorted list.) It keeps doing that until finds the element it is looking for. Here is an example of what it might look like in Swift:

func binarySearch<T: Comparable>(_ array: [T], for element: T) -> Int? {
    var low = 0
    var high = array.count - 1

    while low <= high {
        let mid = (low + high) / 2
        let guess = array[mid]

        if guess == element { return mid }
        if guess > element {
            high = mid - 1
        } else {
            low = mid + 1
        }
    }
    return nil
}

First, I make variables to keep track of the low and high spots to check against. Then I make a while loop that continues as long as low is less than or equal to high (meaning we still have elements to check). Each time through the loop, I get the midpoint between low and high and get the guess associated with that midpoint. If guess is the element we’re looking for, I return it. Otherwise, if guess is greater than the element we’re searching for (meaning it is too high) we set high equal to the current midpoint minus 1. If guess is less than the element (meaning it is too low) we set low equal to the current midpoint plus 1. If we get to the point were low is no longer less than or equal to high, it means the element doesn’t exist in this array, so I return nil.

In comparison, a “simple search” might look like this:

func simpleSearch<T: Equatable>(_ array: [T], for element: T) -> Int? {    
    for (index, item) in array.enumerated() {
        if item == element { return index }
    }
    return nil
}

As you can see, it is much less code. Fewer places for errors. It just starts at the beginning and moves forward until it finds the element it is looking for. If it gets all the way through and doesn’t find it, it returns nil. It may be a better option, or at least it may not make a significant difference, if you know for certain that there will be a relatively small number of elements you are searching against.

To test these functions (and illustrate how many steps they take) I made a little list and searched for an element on it using both functions:

var list: [Int] = []
for i in stride(from: 1, to: 100, by: 2) {
    list.append(i)
}

binarySearch(list, for: 99)
simpleSearch(list, for: 99)

Then I added in a couple of helper variables and printed these results out to the console:

Binary search took 6 steps and completed in 3.898143768310547e-05 seconds.
Simple search took 50 steps and completed in 7.200241088867188e-05 seconds.

Binary search takes about 0.000039 seconds and simple search takes about 0.000072. With so few elements, binary search is only slightly faster in terms of time (and basically imperceptibly), but you can see that the number of steps is way lower with binary search. We’ll look at what a difference this can mean when you have way more inputs in the next section.

Complexity

If you were only looking at the times above, you might guess that simple search takes twice as long as binary search. So if we were to search a list of 500,000 elements instead of 50, however long binary search took, simple search would take twice as long. Let’s look at how long it actually takes:

Binary search took 19 steps and completed in 6.508827209472656e-05 seconds.
Simple search took 500000 steps and completed in 0.1531449556350708 seconds.

Binary search didn’t even double in the amount of time it takes (although the number of steps more than doubled, I’m assuming that a chunk of the time it takes has to do with setting up the objects in memory, not the actual calculations), but simple search takes more than 2000 times as long as it did the first time. You can also see that the number of steps necessary for simple search is way higher than binary. So it is not just that simple search takes longer than binary, but that the number of calculations it takes to complete (in the worst case) grows at a different rate as a function of the number of inputs.

Let’s break that down. In the first example above, simple search took 50 steps to find the last element in a list of 50 items. In the second example, it took 500,000 steps to find the last element in a list of 500,000 items. This means that the number of calculations required in the worst case is the same as the number of inputs given. The way you’ll see this described when talking about algorithms is its complexity or its speed or its running time and it is communicated with Big O notation (insert sex joke here). The big O notation for simple search is O(n) because the number of calculations required is the same as the number of inputs (n stands for the number of inputs).

So what about Binary search? You don’t necessarily have to understand the math behind it, but since we are cutting the elements in half with each step, the number of calculations required in the worst case is log base2 of the number of inputs (rounded up to the nearest integer because you can’t have half a calculation). For instance log(50) is approximately 5.6 and so it took 6 steps when we had 50 items. log(500000) is about 18.9 and it took 19 steps when we had 500,000 items. So the big O notation for binary search is O(log(n)).

It is important to understand the complexity of the algorithm you are using if you are going to be calling it with more than a few inputs. Even algorithms with the worst complexity work ok with a small number of inputs, but many of them grow at a rate much faster than you might think. It is easy to write code that works with your sample data, but is totally unusable when it comes into contact with real-world data that is often a much larger set.

There are a few other common big O notations that you’ll see associated with algorithms:O(1), O(n * log(n)), O(n^2), O(2^n) and O(n!). The best is O(1) or constant time which means that it takes the same amount of time no matter how many inputs there are. One example of this in Swift is checking whether an element is contained in a Set. The next is O(log(n)) or log time which grows very slowly. Binary search is a good example of this. Next is O(n) or linear time which grows just as fast as the number of inputs. We saw this with simple search. Next is O(n * log(n)) or log-linear time. A good example of this is a the quicksort algorithm (which maybe I’ll cover in another post). Next is O(n^2) or quadratic time. An example of this is selection sort (again, I’ll link to this after I write about it). After that is O(2^n) or exponential time. One example of this is bogo sort (also known as permutation sort). Finally we have O(n!) or factorial time. An example of this is the algorithm to solve the traveling salesman problem.

Wrap Up

I hope this has been helpful. I know I learned a lot in writing it. Quick recap:

• Algorithms are condensed descriptions of how to solve a particular problem, especially for computers.
• Binary search is faster than simple search, but requires a sorted list and a little more code.
• The complexity, or the rate of the number of necessary calculations as a function of the number of inputs, of a function can be described with big O notation.

What do you think? What algorithms have you used to solve real-world problems? How has understanding them made you a better developer? Or has it?

P.S. I am (like everyone) both a human and still learning, so you find any mistakes in my writing or have suggestions for things to add, let me know!