Forem: Dillon McElhinney

Completion Handlers in Swift

Dillon McElhinney — Sat, 22 Oct 2022 00:00:00 +0000

Completion handlers are everywhere in Swift. They are commonly used in Apple's frameworks and many third-party libraries. They are often put forward as an alternative to delegation and the target action pattern, especially in the context of long-running work like fetching data over the network or processing images. You might see them referred to as "handlers" or "completion blocks", simply "completions", or maybe something else depending on the conventions of the code base you are working in.

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 Into App Development

Dillon McElhinney — Sat, 03 Sep 2022 00:00:00 +0000

The Kindling

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.

Xcode Tip: Pre Build Actions

Dillon McElhinney — Mon, 29 Aug 2022 00:00:00 +0000

I ran into this cool little piece of functionality in Xcode the other day that helped me solve a real problem. I have never seen anyone mention that you can do this, so I'm sharing it here in the hopes that it will help someone else out.

I was recently working with a framework which uses a configuration file. This file is stored in JSON and is bundled with the app. I wanted an easy way to have separate configuration files for the dev version of my app and the prod version and I already had separate schemes for these different versions. I was looking into ways to accomplish this, maybe via an argument passed on launch or a compiler flag or something. I was starting to go down the rabbit hole of the various code generation tools etc. But then I noticed something in the scheme editor.

Underneath the little drop down on "Build", there is an item called "Pre-actions". If you click into that and hit the "+" button down at the bottom you have the option to add a "Run Script Action". This means that you can run any arbitrary script before (or after) all builds (or runs or tests) of your app. And they can be different for different schemes. This seemed like a perfect way to accomplish my goal!

What I did was add an empty JSON file called "configuration.json" to my project and included it in the target. Then I put the "configuration-dev.json" and "configuration-prod.json" files into the directory of my app (so that it would be included in source control), but didn't add them to the project itself.

Then, for my dev scheme I added this script as a pre-build action:

cp "$SRCROOT/configuration-dev.json" "$SRCROOT/configuration.json"

If you're not familiar with bash, the cp command copies files from the source to the destination. In this case it'll copy the dev version of the configuration file to the one that I included in the project, overwriting whatever was there before.

I also made sure that "Provide build settings from" was set to my app target, instead of "None". This is necessary to get the SRCROOT in the script, which is the path to the directory where the project file lives.

Then I did the same thing for the prod action:

cp "$SRCROOT/configuration-prod.json" "$SRCROOT/configuration.json"

Now, any time I build the dev scheme, I have the contents of configuration-dev bundled into the app and when I build the prod scheme, I have the contents of configuration-prod.

Simple, right? You could obviously run a lot more complicated scripts here and do more if you needed to. But so far this one-line script seems to have solved this little problem I had and I haven't seen any downsides.

Stop Throwing Away Errors

Dillon McElhinney — Sat, 27 Aug 2022 00:00:00 +0000

We all know how it goes when we are trying to get something working. We want to get there as fast as we can and we get focused on the "happy path". Maybe we're not that familiar with the technology/language/concept, but we have one specific goal or task we are trying to achieve and we don't care so much about the edge cases or what will happen when things go wrong.

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.

It builds the url by appending "character" and the given id to the api's base url
It tries to get the data from that url
It tries to make a Character from that data
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:

Key	Type	Description
voicedBy	string / undefined	The voice actor for the character

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.

5 Reasons to Use Typealias

Dillon McElhinney — Wed, 25 May 2022 00:00:00 +0000

Swift has many features that allow us as the users of the language to customize how we write code, while still giving us all the protections of a statically typed language. Today we're going to talk about one of those features which seems small, but it packs a lot of punch.

The typealias keyword lets you define a "type alias", a custom name for a class, struct or any other existing type in Swift. Once you declare it you can use that new name anywhere you would have used the name of the original type.

typealias NewName = ExistingType

let newName = NewName() // the type of newName will actually be ExistingType

Simple, right? Basically you can give your type a nickname.

Reasons to use it

We’ve all had nicknames and used them for our friends and family, but unlike your childhood nicknames, type aliases can provide a lot of benefit to you as a developer. Here’s a list of the top five.

1. Clarity

One use for type aliases is to add clarity around what a type is used for. Double is a primitive type in Swift and it can be used in any number of ways, but when it is used in the context of dates and times it might be good to add a little more explanation about what we mean with the value. Foundation does exactly that by adding a type alias called TimeInterval and documenting that "A TimeInterval value is always specified in seconds…".

Another good example comes from handling money. It is relatively common practice when dealing with money in code is to multiply the value by 100 and work with it as Int values to avoid rounding errors. If that is what you're doing, you might add some clarity to your code by adding a Cents type alias to communicate what you mean with the Int value.

/// Describes the value of one-hundreth (1/100) of a dollar (USD).
typealias Cents = Int

struct Product {
    let name: String
    let price: Cents
}

func buy(product: Product, currentBalance: Cents) throws {
    guard currentBalance > product.price else { throw .NotEnoughMoney }
    currentBalance -= product.price
    currentUser.add(product)
}

That's a lot clearer than having Int all over the place and either adding comments to describe the meaning or assuming that the reader knows what it means. (You know what happens when you assume.)

2. Brevity

Another use is to take a long name and make it shorter. If you've ever worked with AVFoundation for instance, you'll know that there are some incredibly long delegate names out there (e.g. AVCaptureFileOutputRecordingDelegate) and it can be nice to provide a short alternative. Or maybe you are trying to keep the line width to a reasonable limit and the completion handler definition is too long to fit.

// Say you have this function that you are trying to make shorter
private func fetchFavorites(type: ItemType, completion: @escaping (Result<[Item], Error>) -> Void)

// you can typealias the result type
typealias ItemResult = Result<[Item], Error>

// and you can typealias the closure type
typealias ItemHandler = (ItemResult) -> Void

// then your function could look like this
private func fetchFavorites(type: ItemType, completion: @escaping ItemHandler)

Much shorter! Taking 98 characters down to 78.

3. DRY (Don't Repeat Yourself)

That leads to another good reason to use typealias. If you define a type alias for a specific result type, you can reuse that everywhere you need that result type. Maybe you have a function that gets all the items of a type, or all the items that belong to a user. Both of those could use this same type alias.

private func fetchAll(type: ItemType, completion: @escaping ItemHandler)
private func fetchAll(for user: User, compeltion: @escaping ItemHandler)

On top of that, the alias in this context makes it easier to make changes down the line. Maybe your backend folks want to change the returned result from an array of items to an object that contains some other information alongside the array. All you need to do is update the type alias and the compiler will then show you where you need to handle it.

typealias ItemResult = Result<ItemResponse, Error>

4. Combine Protocols

You can also use typealias to combine multiple protocols into one name. You may want to do this if you have multiple protocols that are commonly used together, but that define methods that aren't required to be handled by the same type. A good example of this from Foundation is Codable, which is really just a type alias for Decodable and Encodable. This way if your type can just be encodable or decodable if you only need the functionality of one or the other, or it can be both by adopting the one protocol.

Maybe in your code the UICollectionViewDelegate and UICollectionViewDataSource are always the same object. You could define a type alias to encompass both. Same for UICollectionViewDragDelegate and UICollectionViewDropDelegate.

typealias CollectionViewDataSourceDelegate = UICollectionViewDataSource & UICollectionViewDelegate

typealias CollectionViewDragDropDelegate = UICollectionViewDragDelegate & UICollectionViewDropDelegate

typealias CollectionViewSuperDelegate = CollectionViewDataSourceDelegate & CollectionViewDragDropDelegate

// Use the type alias that combines them all
class ViewController: CollectionViewSuperDelegate {
    override func viewDidLoad {
        super.viewDidLoad()

        // and then this type can be all four of these things
        collectionView.dataSource = self
        collectionView.delegate = self
        collectionView.dragDelegate = self
        collectionView.dropDelegate = self
    }
}

5. Better Auto-complete

Finally, if you're lazy like me and rely on auto-complete to do most of your typing for you, you're in luck. Type aliases will show up there and definitely speed things up when they are specifying a generic type. ItemResult will auto-complete as a whole unit, but Result<[Item], Error> would take more keystrokes because you would either have to auto-complete Result, Item and Error separately, or just type it all out yourself.

Bonus. Light-weight Type Replacement

With a type alias, you can name a tuple with labels and it will basically function as a struct without a lot of the bells and whistles. I would not recommend doing this in production. It can be helpful when you're prototyping, messing around with a script or maybe in a test suite. But in almost all cases you should turn your prototype into a real struct, or pick an existing type that fits the shape of your data, before pushing your code to production.

// this is valid Swift
// you can name this tuple
typealias Coordinate = (x: Int, y: Int)

// use it as a parameter in your functions
func manhattanDistance(from first: Coordinate, to second: Coordinate) -> Int {
    return abs(first.x - second.x) + abs(first.y - second.y)
}

// and pass literal tuples to that function
manhattanDistance(from: (1,2), to: (3,4)) // results in 4

// but there is already a common type in most contexts where you write Swift
// called CGPoint that you should probably use instead
func manhattanDistance(from first: CGPoint, to second: CGPoint) -> CGFloat {…}

Why You (Mostly) Shouldn't Use It

Type aliases are very useful and there are many good reasons to use them, but that doesn't mean you should rename every type in your code. So next time you're going to reach for it, be sure to weigh the cost against the benefits.

Type aliases add complexity to your code. Mental overhead. Any time a reader of your code (including future you) comes across an alias they will either have to option+click it in Xcode to see what it actually is, or they will have to switch it out for the real meaning in their head. If it is the first time they have encountered it, they may have to look up the actual definition several times before they internalize it. Sometimes this trade off is worth it, if you are reaping the benefits of one or more reasons listed above. But other times it is not.

You might find yourself in a situation where you want to rename something because of your preference, but you won't actually benefit from it, or the benefit is so small that it isn't worth the added complexity. I would advise against using a type alias in this case. Especially if you work on a codebase with a team larger than just you. It actually makes your code harder to read. And that is almost never a good thing.

// this alias actually reduces clarity _and_ brevity
typealias Number = Int

// this one adds brevity but reduces clarity
typealias TableController = UITableViewController

// these don't add much benefit and are kind of the opposite of dry
typealias StringArray = Array<String>
typealias IntArray = Array<Int>
typealias DoubleArray = Array<Double>

The cost gets even higher if you and/or your team spend a lot of time looking at your code outside of Xcode. If you have a regular code review process (you should) there is a good chance that significant amounts of time will be spent reading and reasoning about code for the first time from the GitHub/GitLab/Bitbucket/etc diff interface where you don't have the convenience of being able to option-click a type name to see its definition. There are times when the trade off is still worth it, but it is good to have a conversation with your team about what your collective line is, or to follow the established practice if it exists.

Wrap Up

Type aliases are just one of the many features of Swift that makes it really customizable and extensible while still being totally type-safe. We've covered some of the many good reasons to use them, including adding clarity, reducing line-length, reducing unnecessary repetition, combining protocols, and improving auto-complete. And we've talked about how type aliases always come at the cost of added complexity, so we should weigh the cost against the benefit before we use them.

What do you think? When do you use type aliases in your code? What makes the trade off worth it for you?

Writing Short Code Isn't The Point

Dillon McElhinney — Mon, 14 Mar 2022 00:45:53 +0000

I don't know about you, but I have spent a lot of time trying to write code in the shortest, most elegant way possible. I have put a lot of thought and time and effort into it over the years. And I see it a lot in other people's code as well. I have seen it from both junior and senior developers. I have seen it in new code bases and mature code bases, both large and small. I think to some extent it comes from the code challenge and technical interview culture where accomplishing the goal with fewer characters is seen as better. Maybe it comes from our desire to prove ourselves and line count is a metric that is simply easy to gather. Maybe we just like the challenge, or we see it as a status symbol.

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 this has been helpful buy me a coffee!

Fixing An Unfixable Bug

Dillon McElhinney — Mon, 07 Mar 2022 00:27:37 +0000

If you have been an iOS developer for any length of time, you have certainly come across bugs that are hard to understand and hard to track down. And if you have an app out in the world that real human beings use you have probably encountered a bug or crash that is happening for some subset of your users, but that you cannot for the life of you reproduce on your device. This is the story of one of those bugs. It was one where I went into it not having a clue what the problem was and where I fully expected to bang my head against the wall for a day without actually solving anything.

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?

If this has been helpful buy me a coffee!

On Imposter Syndrome

Dillon McElhinney — Sat, 21 Aug 2021 19:08:28 +0000

A friend of mine was recently hired as a "senior" engineer. He's a sharp guy. He went through a bootcamp. He had worked at a company for a couple years as a junior, gaining experience and learning along the way. And now a new company was offering him a job with a bump up in title (and presumably pay). He had accepted the job and as his first day approached, the feelings of imposter syndrome started to creep in. Would he be able to keep up with people around him? Would he be able to live up to the title? What if they "found him out" and called him what he felt like, an imposter?

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?

If this has been helpful buy me a coffee!

Header photo by Marten Bjork on Unsplash.

A Look At iOS Native Half Sheets

Dillon McElhinney — Sat, 19 Jun 2021 00:43:13 +0000

One of the things that stood out to me from WWDC this year was the ability to have native half sheets. This has been a request from the designers at every job I have ever had and until now we have always had to roll our own. So I thought I would play around with the code from this video and see how they work in practice. This code is all written in Xcode 13, beta 1 on macOS 11.3 (Big Sur) and run on iOS 15 simulators.

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.

If this has been helpful buy me a coffee!

Building Airbnb's UI From Scratch - Part 6

Dillon McElhinney — Sun, 06 Jun 2021 01:49:43 +0000

In this series of posts I am going to be building out the UI for Airbnb's "Explore" tab from scratch. This is an exercise in figuring out how to achieve the different layouts and effects you find in popular apps and I chose Airbnb because I thought it had several great examples. It is not intended to be used for anything other than for educational purposes and all my code will be available at this repo if you want to follow along and build it yourself. A few disclaimers:

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:

We need the content to be moving up. The user's finger needs to be moving the scrollview upwards.
We need for to be within the bounds of the content, not beyond it. (This is more important in the expanding logic.)
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.

We need the content to be moving down.
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.
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.

If this has been helpful buy me a coffee!

Building Airbnb's UI From Scratch - Part 5

Dillon McElhinney — Fri, 28 May 2021 19:28:56 +0000

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.

https://youtu.be/_olzmg8GU7M

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.

If this has been helpful buy me a coffee!

Building Airbnb's UI From Scratch - Part 4

Dillon McElhinney — Mon, 24 May 2021 01:03:23 +0000

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.

If this has been helpful buy me a coffee!