Forem: Donny Wals

Forcing an app out of memory on iOS

Donny Wals — Thu, 23 Dec 2021 11:11:14 +0000

I’ve recently been working on a background uploading feature for an app. One of the key aspects to get right with a feature like that is to correctly handle scenarios where your app is suspended by the system due to RAM constraints or other, similar, reasons. Testing this is easily done by clearing the RAM memory on your device. Unfortunately, this isn’t straightforward. But it’s also not impossible.

Note that opening the task switcher and force closing your app from there is not quite the same as forcing your app to be suspended. Or rather, it’s not the same as forcing your app out of memory.

Luckily, there’s somewhat of a hidden trick to clear your iOS device’s RAM memory, resulting in your app getting suspended just like it would if the device ran out of memory due to something your user is doing.

To force-clear your iOS device’s RAM memory, go through the following steps:

If you’re using a device without a home button, enable Assistive Touch. If your device has a home button you can skip this step. You can enable Assistive Touch by going to Settings → Accessibility → Touch → Enable Assistive Touch. This will make a floating software button appear on your device that can be tapped to access several shortcuts, a virtual home button is one of these shortcuts.

In a (somewhat) fluid sequence press volume up, volume down, and then hold your device’s power button until a screen appears that allows you to power down your device.
Once that screen appears, tap the assistive touch button and then press and hold the virtual home button until you’re prompted to unlock your device. You’ve successfully wiped your device’s RAM memory.

Being able to simulate situations where your app goes out of memory is incredibly useful when you’re working on features that rely on your app being resumed in the background even when it’s out of memory. Background uploads and downloads are just some examples of when this trick is useful.

My favorite part of using this approach to debug my apps going out of memory is that I can do it completely detached from Xcode, and I can even ask other people like a Q&A department to test with this method to ensure everything works as expected.

Using Swift's async/await to build an image loader

Donny Wals — Tue, 07 Sep 2021 07:26:50 +0000

Async/await will be the defacto way of doing asynchronous programming on iOS 15 and above. I've already written quite a bit about the new Swift Concurrency features, and there's still plenty to write about. In this post, I'm going to take a look at building an asynchronous image loader that has support for caching.

SwiftUI on iOS 15 already has a component that allows us to load images from the network but it doesn't support caching (other than what’s already offered by URLSession), and it only works with a URL rather than also accepting a URLRequest. The component will be fine for most of our use cases, but as an exercise, I'd like to explore what it takes to implement such a component ourselves. More specifically I’d like to explore what it’s like to build an image loader with Swift Concurrency.

We'll start by building the image loader object itself. After that, I'll show how you can build a simple SwiftUI view that uses the image loader to load images from the network (or a local cache if possible). We'll make it so that the loader work with both URL and URLRequest to allow for maximum configurability.

Note that the point of this post is not to show you a perfect image caching solution. The point is to demonstrate how you'd build an ImageLoader object that will check whether an image is available locally and only uses the network if the requested image isn't available locally.

Designing the image loader API

The public API for our image loader will be pretty simple. It'll be just two methods:

public func fetch(_ url: URL) async throws -> UIImage
public func fetch(_ urlRequest: URLRequest) async throws -> UIImage

The image loader will keep track of in-flight requests and already loaded images. It'll reuse the image or the task that's loading the image whenever possible. For this reason, we'll want to make the image loader an actor. If you're not familiar with actors, take a look at this post I published to brush up on Swift Concurrency's actors.

While the public API is relatively simple, tracking in-progress fetches and loading images from disk when possible will require a little bit more effort.

Defining the ImageLoader actor

We'll work our way towards a fully featured loader one step at a time. Let's start by defining the skeleton for the ImageLoader actor and take it from there.

actor ImageLoader {
    private var images: [URLRequest: LoaderStatus] = [:]

    public func fetch(_ url: URL) async throws -> UIImage {
        let request = URLRequest(url: url)
                return try await fetch(request)
    }

    public func fetch(_ urlRequest: URLRequest) async throws -> UIImage {
        // fetch image by URLRequest
    }

        private enum LoaderStatus {
                case inProgress(Task<UIImage, Error>)
                case fetched(UIImage)
        }
}

In this code snippet I actually did a little bit more than just define a skeleton. For example, I've defined a private enum LoaderStatus. This enum will be used to keep track of which images we're loading from the network, and which images are available immediately from memory. I also went ahead and implemented the fetch(:) method that takes a URL. To keep things simple, it just constructs a URLRequest with no additional configuration and calls the overload for fetch(_:) that takes a URLRequest.

Now that we have a skeleton ready to go, we can start implementing the fetch(_:) method. There are essentially three different scenarios that we can run into. Interestingly enough, these three scenarios are quite similar to what I wrote in an earlier Swift Concurrency related post that covered refreshing authentication tokens.

The scenarios can be roughly defined as follows:

fetch(_:) has already been called for this URLRequest so will either return a task or the loaded image.
We can load the image from disk and store it in-memory
We need to load the image from the network and store it in-memory and on disk

I'll show you the implementation for fetch(_:) one step at a time. Note that the code won't compile until we've finished the implementation.

First, we'll want to check the images dictionary to see if we can reuse an existing task or grab the image directly from the dictionary:

public func fetch(_ urlRequest: URLRequest) async throws -> UIImage {
    if let status = images[urlRequest] {
        switch status {
        case .fetched(let image):
            return image
        case .inProgress(let task):
            return try await task.value
        }
    }

        // we'll need to implement a bit more before this code compiles
}

The code above shouldn't look too surprising. We can simply check the dictionary like we would normally. Since ImageLoader is an actor, it will ensure that accessing this dictionary is done in a thread safe way (don't forget to refer back to my post on actors if you're not familiar with them yet).

If we find an image, we return it. If we encounter an in-progress task, we await the task's value to obtain the requested image without creating a new (duplicate) task.

The next step is to check whether the image exist on disk to avoid having to go to the network if we don't have to:

public func fetch(_ urlRequest: URLRequest) async throws -> UIImage {
    // ... code from the previous snippet

    if let image = try self.imageFromFileSystem(for: urlRequest) {
        images[urlRequest] = .fetched(image)
        return image
    }

        // we'll need to implement a bit more before this code compiles
}

This code calls out to a private method called imageFromFileSystem. I haven't shown you this method yet, I'll show you the implementation soon. First, I want to briefly cover what this code snippet does. It attempts to fetch the requested image from the filesystem. This is done synchronously and when an image is found we store it in the images array so that the next called of fetch(_:) will receive the image from memory rather than the filesystem.

And again, this is all done in a thread safe manner because our ImageLoader is an actor.

As promised, here's what imageFromFileSystem looks like. It's fairly straightforward:

private func imageFromFileSystem(for urlRequest: URLRequest) throws -> UIImage? {
    guard let url = fileName(for: urlRequest) else {
        assertionFailure("Unable to generate a local path for \(urlRequest)")
        return nil
    }

    let data = try Data(contentsOf: url)
    return UIImage(data: data)
}

private func fileName(for urlRequest: URLRequest) -> URL? {
    guard let fileName = urlRequest.url?.absoluteString.addingPercentEncoding(withAllowedCharacters: .urlPathAllowed),
          let applicationSupport = FileManager.default.urls(for: .applicationSupportDirectory, in: .userDomainMask).first else {
              return nil
          }

    return applicationSupport.appendingPathComponent(fileName)
}

The third and last situation we might encounter is one where the image needs to be retrieved from the network. Let's see what this looks like:

public func fetch(_ urlRequest: URLRequest) async throws -> UIImage {
    // ... code from the previous snippets

    let task: Task<UIImage, Error> = Task {
        let (imageData, _) = try await URLSession.shared.data(for: urlRequest)
        let image = UIImage(data: imageData)!
        try self.persistImage(image, for: urlRequest)
        return image
    }

    images[urlRequest] = .inProgress(task)

    let image = try await task.value

    images[urlRequest] = .fetched(image)

    return image
}

private func persistImage(_ image: UIImage, for urlRequest: URLRequest) throws {
    guard let url = fileName(for: urlRequest),
          let data = image.jpegData(compressionQuality: 0.8) else {
        assertionFailure("Unable to generate a local path for \(urlRequest)")
        return
    }

    try data.write(to: url)
}

This last addition to fetch(:) creates a new Task instance to fetch image data from the network. When the data is successfully retrieved, and it's converted to an instance of UIImage. This image is then persisted to disk using the persistImage(:for:) method that I included in this snippet.

After creating the task, I update the images dictionary so it contains the newly created task. This will allow other callers of fetch(_:) to reuse this task. Next, I await the task's value and I update the images dictionary so it contains the fetched image. Lastly, I return the image.

You might be wondering why I need to add the in progress task to the images dictionary before awaiting it.

The reason is that while fetch(:) is suspended to await the networking task's value, other callers to fetch(:) will get time to run. This means that while we're awaiting the task value, someone else might call the fetch(_:) method and read the images dictionary. If the in progress task isn't added to the dictionary at that time, we would kick off a second fetch. By updating the images dictionary first, we make sure that subsequent callers will reuse the in progress task.

At this point, we have a complete image loader done. Pretty sweet, right? I'm always delightfully surprised to see how simple actors make complicated flows that require careful synchronization to correctly handle concurrent access.

Here's what the final implementation for the fetch(_:) method looks like:

public func fetch(_ urlRequest: URLRequest) async throws -> UIImage {
    if let status = images[urlRequest] {
        switch status {
        case .fetched(let image):
            return image
        case .inProgress(let task):
            return try await task.value
        }
    }

    if let image = try self.imageFromFileSystem(for: urlRequest) {
        images[urlRequest] = .fetched(image)
        return image
    }

    let task: Task<UIImage, Error> = Task {
        let (imageData, _) = try await URLSession.shared.data(for: urlRequest)
        let image = UIImage(data: imageData)!
        try self.persistImage(image, for: urlRequest)
        return image
    }

    images[urlRequest] = .inProgress(task)

    let image = try await task.value

    images[urlRequest] = .fetched(image)

    return image
}

Next up, using it in a SwiftUI view to create our own version of AsyncImage.

Building our custom SwiftUI async image view

The custom SwiftUI view that we'll create in this section is mostly intended as a proof of concept. I've tested it in a few scenarios but not thoroughly enough to say with confidence that this would be a better async image than the built-in AsyncImage. However, I'm pretty sure that this is an implementation that should work fine in many situations.

To provide our custom image view with an instance of the ImageLoader, I'll use SwiftUI's environment. To do this, we'll need to add a custom value to the EnvironmentValues object:

struct ImageLoaderKey: EnvironmentKey {
    static let defaultValue = ImageLoader()
}

extension EnvironmentValues {
    var imageLoader: ImageLoader {
        get { self[ImageLoaderKey.self] }
        set { self[ImageLoaderKey.self ] = newValue}
    }
}

This code adds an instance of ImageLoader to the SwiftUI environment, allowing us to easily access it from within our custom view.

Our SwiftUI view will be initialized with a URL or a URLRequest. To keep things simple, we'll always use a URLRequest internally.

Here's what the SwiftUI view's implementation looks like:

struct RemoteImage: View {
    private let source: URLRequest
    @State private var image: UIImage?

    @Environment(\.imageLoader) private var imageLoader

    init(source: URL) {
        self.init(source: URLRequest(url: source))
    }

    init(source: URLRequest) {
        self.source = source
    }

    var body: some View {
        Group {
            if let image = image {
                Image(uiImage: image)
            } else {
                Rectangle()
                    .background(Color.red)
            }
        }
        .task {
            await loadImage(at: source)
        }
    }

    func loadImage(at source: URLRequest) async {
        do {
            image = try await imageLoader.fetch(source)
        } catch {
            print(error)
        }
    }
}

When we're instantiating the view, we provide it with a URL or a URLRequest. When the view is first rendered, image will be nil so we'll just render a placeholder rectangle. I didn't give it any size, that would be up to the user of RemoteImage to do.

The SwiftUI view has a task modifier applied. This modifier allows us to run asynchronous work when the view is first created. In this case, we'll use a task to ask the image loader for an image. When the image is loaded, we update the @State var image which will trigger a redraw of the view.

This SwiftUI view is pretty simple and it doesn't handle things like animations or updating the image later. Some nice additions could be to add the ability to use a placeholder image, or to make the source property non-private and use an onChange modifier to kick off a new task using the Task initializer to load a new image.

I'll leave these features to be implemented by you. The point of this simple view was merely to show you how this custom image loader can be used in a SwiftUI context; not to show you how to build a fantastic fully-featured SwiftUI image view replacement.

In Summary

In this post we covered a lot of ground. I mean, a lot. You saw how you can build an ImageLoader that gracefully handles concurrent calls by making it an actor. You saw how we can keep track of both in progress fetches as well as already fetched images using a dictionary. I showed you a very simple implementation of a file system cache as well. This allows us to cache images in memory, and load from the filesystem if needed. Lastly, you saw how we can implement logic to load our image from the network if needed.

You learned that while an asynchronous function that's defined on an actor is suspended, the actor's state can be read and written by others. This means that we needed to assign our image loading task to our dictionary before awaiting the tasks result so that subsequent callers would reuse our in progress task.

After that, I showed you how you can inject the custom image loader we've built into SwiftUI's environment, and how it can be used to build a very simple custom asynchronous image view.

All in all, you've learned a lot in this post. And the best part is, in my opinion, that while the underlying logic and thought process is quite complex, Swift Concurrency allows us to express this logic in a sensible and readable way which is really awesome.

What exactly is a Combine AnyCancellable?

Donny Wals — Tue, 24 Aug 2021 18:41:11 +0000

If you've worked with Combine at all in your applications you'll know what it means when I tell you that you should always retain your cancellables. Cancellables are an important part of working with Combine, similar to how disposables are an important part of working with RxSwift.

For example, you might have built a publisher that wraps CLLocationManagerDelegate and exposes the user's current location with a currentLocation publisher that's a CurrentValueSubject<CLLocation, Never>. If you subscribe to this publisher it might look a bit like this:

struct ViewModel {
    let locationProvider: LocationProvider
    var cancellables = Set<AnyCancellable>()

  init(locationProvider: LocationProvider) {
        self.locationProvider = locationProvider
        locationProvider.currentLocation.sink { newLocation in 
            // use newLocation
        }.store(in: &cancellables)
    }
}

For something that's so key to working with Combine, it kind of seems like cancellables are just something we deal with without really questioning it. Thats why in this post, I'd like to take a closer look at what a cancellable is, and more specifically, I'd like to look at what the enigmatic AnyCancellable that's returned by both sink and assign(to:on:) is exactly.

Understanding the purpose of cancellables in Combine

Cancellables in Combine fulfill an important part in Combine's subscription lifecycle. According to Apple, the Cancellable protocol is the following:

A protocol indicating that an activity or action supports cancellation.

Ok. That's not very useful per se. I mean, if supporting cancellation is all we want to do, why do we need to retain our cancellables?

If we look at the detailed description for Cancellable, you'll find that it says the following:

Calling cancel() frees up any allocated resources. It also stops side effects such as timers, network access, or disk I/O.

This still isn't great, but at least it's something. We know that an object that implements Cancellable has a cancel method that we can call to stop any in progress work. And more importantly, we know that we can expect any allocated resources to be freed up. That's really good to know.

What this doesn't really tell us is why we need to retain our cancellables in Combine. Based on the information that Apple provides there's nothing that even hints towards the need to retain cancellables.

Let's take a look at the documentation for AnyCancellable next. Maybe a Cancellable and AnyCancellable aren't quite the same even though we'd expect AnyCancellable to be nothing more than a type-erased Cancellable based on the way Apple chose to name it.

The short description explains the following:

A type-erasing cancellable object that executes a provided closure when canceled.

Ok. That's interesting. So rather it being "just" a type erased object that conforms to Cancellable, we can provide a closure to actually do something when we initialize an AnyCancellable. When we subscribe to a publisher we don't create our own AnyCancellable though, so we'll need to dig a little deeper.

There's once sentence in the AnyCancellable documentation that tells us exactly why we need to retain cancellables. It's the very last sentence in the discussion and it reads as follows:

An AnyCancellable instance automatically calls cancel() when deinitialized.

So what exactly does this tell us?

Whenever an AnyCancellable is deallocated, it will call cancel() on itself. This will run the provided closure that I mentioned earlier. It's save to assume that this closure will ensure that any resources associated with our subscription are torn down. After all, that's what the cancel() method is supposed to do according to the Cancellable protocol.

Based on this, we can deduce that the purpose of cancellables in Combine, or rather the purpose of AnyCancellable in Combine is to associate the lifecycle of a Combine subscription to something other than the subscription completing.

When we retain a cancellable in an instance of a view model, view controller, or any other object, the lifecycle of that subscription becomes connected to that of the owner (the retaining object) itself. Whenever the owner of the cancellable is deallocated, the subscription is torn down and all resources are freed up immediately.

Note that this might not be quite intuitive when you think of that original description I quoted from the Cancellable documentation:

A protocol indicating that an activity or action supports cancellation.

Cancelling a subscription by calling cancel() on an AnyCancellable is not a graceful operation. This is already hinted at because the documentation for Cancellable mentions that "any allocated resources" will be freed up. You need to interpret this broadly.

You won't just cancel an in flight network call and be notified about it in a receiveCompletion closure. Instead, the entire subscription is torn down immediately. You will not be informed of this, and you will not be able to react to this in your receiveCompletion closure.

So. To sum up the purpose of cancellables in Combine, they are used to tie the lifecycle of a subscription to the object that retains the cancellable that we receive when we subscribe to a publisher.

This description might lead to you thinking that an AnyCancellable is a wrapper for a subscription. Unfortunately, that's not quite accurate. It's also not flat out wrong, but there's a bit of a nuance here; Apple chose the name AnyCancellable instead of Subscription on purpose.

What's inside an AnyCancellable exactly?

If an AnyCancellable isn't a subscription, then what it is? What's inside of an AnyCancellable?

The answer is complicated.

When I was first learning Combine I was lucky enough to run into an Apple employee at a conference. We got talking about Combine, and I explained that I was working on a Combine book. I kind of started firing off a few questions to validate my understanding of Combine and I was very lucky to kind of get an answer or two.

One of my questions was "So is an AnyCancellable a subscription then?" and the answer was short and simple "No. It's an AnyCancellable".

You might think that's unhelpful, and I would fully understand. However, the answer is fully correct as I learned in our conversation.

Combine intentionally does not specify what's inside of a cancellable because we simply don't need to know exactly what is wrapped and how. All we need to know is that an AnyCancellable conforms to the Cancellable protocol, and when its cancel() method is called, all resources retained by whatever the Cancellable wrapper are released.

In practice, we know that an AnyCancellable will most likely wrap an object that conforms to Subscription and possibly also one that conforms to Subscriber. One of the two might even have a reference to a Publisher object.

We know this because we know that these three objects are always involved when you subscribe to a publisher. I've outlined this in more detail in this post as well as my Combine book.

This is really a long-winded way of me trying to tell you that we don't know what's inside an AnyCancellable, and it doesn't matter. You just need to remember that when an AnyCancellable is deallocated it will run its cancellation closure which will tear down anything it retains. This includes tearing down your subscription to a publisher.

In Summary

In this post you learned about a key aspect of Combine; the Cancellable. I explained what the Cancellable protocol is, and from there I moved on to explain what the AnyCancellable is.

You learned that subscribing to a publisher with sink or assign(to:on:) will return an AnyCancellable that will tear down your subscription whenever the AnyCancellable is deallocated. This makes sure that your subscription to a publisher is deallocated when the object that retains your AnyCancellable is deallocated. This prevents your subscriptions from being deallocated immediately when the scope where they're created exits.

Lastly, I explained that we don't know what exactly is inside of the AnyCancellable objects that we retain for our subscriptions. While we can be pretty certain that an AnyCancellable must somehow retain a subscription, we shouldn't refer to it as a wrapper for a subscription because that would be inaccurate.

Hopefully this post gave you some extra insights into something that everybody that works with Combine has to deal with even though there's not a ton of information out there on AnyCancellable specifically.

What does “atomic” mean in programming?

Donny Wals — Tue, 24 Aug 2021 07:44:56 +0000

When you're learning about databases or multithreaded programming, it's likely that you'll come across the term "atomic" at some point.

Usually you'll hear the term in the context of an operation. For example, an atomic read / write operation. Or atomic access to a property.

But what does this mean?

Generally, you can summarize atomic as "one at a time".

For example, when accessing or mutating a property is atomic, it means that only one read or write operation can be performed at a time. If you have a program that reads a property atomically, this means that the property cannot change during this read operation.

In Swift, operations on a dictionary are not atomic. This means that in a multithreaded application, a dictionary might be changed from one thread while another thread is reading from it. No thread or operation has exclusive access to your dictionary.

If the operation was atomic, the first read operation would have to finish before the write can start.

Another way to think of an atomic operation is that no observer of an atomic operation can "see" the operation as in-progress. You can observe the operation as not yet started or as completed, but never in between.

I wrote a post about an @Atomic property wrapper that I've seen making the rounds. In that post, you can see why this property wrapper does not guarantee exclusive access properly for value types, resulting in strange results.

If you want to learn more about atomicity and see an example of atomicity in Swift, I highly recommend you give that post a look.

If you're just looking for a definition, think of atomic as exclusive or one at a time. When an operation is performed atomically, you know that no other operations will interfere with your atomic operation.

I hope this quick tip gave you a better idea of what atomic means in programming. If you have any questions about this posts or if you have suggestions to make it better, feel free to reach out on Twitter.

The iOS Developer's guide to WWDC 2021

Donny Wals — Thu, 03 Jun 2021 07:19:27 +0000

WWDC is always an exciting time for iOS engineers. It's the one week a year where we're all newcomers to a whole range of features and APIs that Apple has just unleashed upon the world through their latest Xcode, macOS, iOS, tvOS, iPadOS, and watchOS betas. The entire iOS community comes out of hiding and we all come together to share thoughts, experiences, opinions, and findings.

For a whole week, Apple releases dozens of sessions on different topics, and we all scramble to watch them as soon as possible to make sure we're all up to date with whatever the latest and greatest is. As a newcomer, or a person with a regular sleeping schedule, this can be quite intimidating.

So that's why I figured I'd put together a little guide to making the most out of WWDC without being completely overwhelmed and intimidated by the sheer volume of content that Apple is about to unleash on us all.

Let's jump right in, shall we.

Tip 1: Breathe

Once Apple opens up that firehose of new content and beta's it's a scramble. You immediately start up the Beta downloads once they're up. In the meantime, you scan the documentation for new things and you're looking at the Apple Developer app to try and figure out which sessions you're going to watch and when.

It's a lot to take in all at once.

When you blink twice, you'll see the first people Tweet about the cool things they're already doing with the new Xcode beta while you're still waiting for that .xip file to finally finish extracting. The FOMO becomes more real with the second.

Just breathe. Take a moment, and breathe.

The Xcode betas aren't going anywhere. You'll have plenty of time to mess around with new APIs if you want to. Because even though it looks like everybody is exploring all the new things in depth within seconds of the first betas becoming available, a lot of us are much, much slower. In fact, I'd say a majority of us are not on top of everything all the time, and you don't have to be either.

Sit back, breathe, and proceed at a comfortable pace.

You'll find that breathing, and taking it easy are a recurring theme in this guide. That's because it's important that you do.

Tip 2: Figure out what's relevant to you

When you keep an eye on Twitter throughout the week of WWDC you'll find that everybody is talking about the latest and greatest. For WWDC 2021 I'm sure everybody's going to be all over what's new in SwiftUI, Swift 5.5's async/await, and whatever other new and exciting frameworks and APIs Apple releases.

Personally, I love exploring the new things too. It's new, it's fresh, it's exciting. But let's be honest; it's completely irrelevant for most of us in the short term. Apple isn't going to officially release anything they announce until more than three months later, so while it's fun to explore new things, it's not likely that you'll need to be aware of everything.

Whenever I'm going through WWDC content I try to focus on two types of sessions:

The super interesting sessions on new technology (for fun)
Sessions that cover best practices or advances in technologies I'm already familiar with

That's right, I love watching sessions on stuff that's not new at all. Sometimes these sessions don't even involve any new features and instead cover (usually undocumented) tips, tricks, and best practices that I can incorporate into my work almost immediately. These sessions are most exciting to me because they are most relevant to me in the short term.

So when you're in doubt about which sessions to watch, I would recommend to focus on what's relevant to you at the time rather than a new technology that everybody on the internet seems to be all over.

Tip 3: Move at a comfortable pace

I can't stress it enough; that firehose of content that Apple unleashes during WWDC is intimidating. Apple will upload dozens of videos and each one will look more attractive than the other. You might feel the pressure to watch as many videos during the day as you can. Heck, you might even be so excited that it's excitement that drives you. And my advice to you is that you don't give in to that urge.

Watch videos in a pace that is comfortable to you. If you're going over more than a couple of topics in the timespan of a few hours there's a good chance the contents won't really stick, and you'll be too tired to explore the APIs you've just learned about.

Move at a pace that is comfortable to you. If that means watching two videos a day and spending a few hours exploring in code, then that's exactly what you should do. If you prefer watching more videos and not exploring until later,that's fine too! And if you want to skip the videos and just code all day long, guess what? All good!

The videos aren't going anywhere for a long time. Watch them as needed. Maybe even pick a few videos from last year's WWDC if they're referred to from one of this year's videos. It's your choice.

WWDC is not a race, so focus on having fun with it.

Tip 4: Don't skip the State of the Union

If you've ever attended an in-person WWDC you'll know that the main keynote that starts at 10AM PDT on the Monday of WWDC is the main event. People get in line for a good seat early in the morning; some even start queueing at 11PM the day before. It's where we see a first glimpse of all the goodness we'll get to learn more about in the week to come. However, as a developer this main event is probably not the most interesting first day presentation you can watch.

After the main Keynote event, at 2PM PDT, there's a presentation called State of the Union. This presentation is the one to look out for as a developer in my opinion. It's where Apple will dig deeper into the APIs and Frameworks that were introduced, and they'll show off new OS features in-depth.

I know that a lot of developers skip the State of the Union in favor of playing with new APIs and resting up, but I personally love watching the State of the Union. It usually gets me much more pumped up for all the good stuff than the main Keynote does.

Tip 5: Prepare for your lab sessions

WWDC is a unique chance for developers to ask questions to Apple engineers directly. Once WWDC is underway we have the opportunity to request appointments with Apple engineers, and we can show them our projects and ask for input on ways to improve our code, solve bugs, or even just clarify how certain things are supposed to work. Labs is arguably the most valuable part of WWDC, so when WWDC went online last year it was a relieve to see that labs were brought online too. And this year is no different.

When you book a lab appointment, try to make sure you come as prepared as possible. If you want to ask about (what you believe to be) a missing feature, or a bug, make sure you file feedback in Apple's feedback assistant ahead of time. This will make it so your lab session can be associated with the feedback which makes the Apple engineer's job a lot easier. It'll also allow the engineer to pull up your feedback ahead of time.

Possibly more important than filing feedback is that you make sure you have a demo project ready to show off. If your lab starts and you have to work your way through your full codebase, it will make it harder for you and the engineer to work through your question, and potentially fix your problem.

A bare-bones example of what you need will improve this a lot, and will help you make the most out of your lab appointment.

Tip 6: File feedback

This tip applies mostly to the period after WWDC. Once WWDC is over and we start spending actual time with new APIs, and we start testing our own apps on the latest Xcode version, bug will start showing themselves. Presented APIs might be missing features that you'd love to have, iOS 15 might do interesting things to your app, or maybe Xcode 13 crashes every time you do something specific.

No matter what your feedback is, file it as soon as you can.

Don't expect that others will already have filed your feedback. Even if they have, the more duplicates Apple gets, the more likely it is that your feedback is eventually bumped to the top of the list. This means that it's more likely that your bugs get fixed, and that your feature requests get implemented when you file your feedback.

I know that Apple has a history of not always responding to feedback, and that it can be very time consuming to file feedback. But if there is a perfect time for you to do it, it's during the big beta cycle that starts with WWDC.

In Summary

WWDC is a hectic time for everybody. I think it's most important that you focus on taking it easy, not giving in to that fear of missing out, and not trying to learn everything in one week. Consume WWDC content at your own pace, and focus on what's relevant to you unless it's simply something you're super interested in even though it might not be something that you can apply in your work just yet.

I hope that these tips help you make the most of your WWDC experience, and that you'll be able to enjoy this WWDC as much as I've always enjoyed mine!

Formatting dates in the user's locale using DateFormatter in Swift

Donny Wals — Thu, 15 Oct 2020 12:20:29 +0000

Working with dates is hard, there is no doubt about that. And formatting dates properly for every user of your app is no easier (if you want to do everything manually). Luckily, the system can help us.

For example, in the US one would write "October 15" while in The Netherlands we write 15 oktober.

Note that the order of the date and the month is different, the spelling of the month is different and the capitalization is different too.

The DateFormatter in iOS will handle a lot of this for you. For example, if you'd use the following code on a device that uses nl as its locale you would see the output that I added to this snippet as a comment:

let now = Date()
let formatter = DateFormatter()
formatter.dateFormat = "dd MMMM"
formatter.string(from: now) // 15 oktober

The output of this code is spot on. Exactly what we need and it matches the specified date format perfectly. If you'd run the same code on a device that uses en_us as its locale the output would be 15 October.

The date formatter got the spelling and capitalization right but the date and month are in the wrong order.

You can fix this by using setLocalizedDateFormatFromTemplate on your date formatter instead of assigning its dateFormat directly. Let's look at an example that runs on a device with nl as its locale again:

let now = Date()
let formatter = DateFormatter()
formatter.setLocalizedDateFormatFromTemplate("dd MMMM")
formatter.string(from: now) // 15 oktober

That still works, perfect. If you'd run this code on an en_us device the output would be October 15. Exactly what we need.

If you want to play around with setLocalizedDateFormatFromTemplate in a Playground you can give it a go with the following code that uses a date formatter in different locales:

import Foundation

let now = Date()
let formatter = DateFormatter()
formatter.locale = Locale(identifier: "en_us")
formatter.setLocalizedDateFormatFromTemplate("dd MMMM")
formatter.string(from: now) // October 15

formatter.locale = Locale(identifier: "nl")
formatter.setLocalizedDateFormatFromTemplate("dd MMMM")
formatter.string(from: now) // 15 oktober

If you have questions about this Quick Tip, or if you want to reach out to me for other reasons then don't hesitate to send me a message on Twitter.

It's a good thing that Swift and Foundation can handle these kinds of

I wrote a book about Apple's Combine framework

Donny Wals — Fri, 27 Mar 2020 11:07:20 +0000

After writing a series of posts about Combine on my blog I figured a more complete, comprehensive resource that teaches Combine from a practical standpoint would be nice.

My book teaches Combine using real-world examples because I love learning by doing, and seeing how my new skills will fit into my existing workflow. I did my best to ensure that the book I wrote fits this style of learning.

Everything I show in my book is backed up by examples and anecdotes of how and when something is useful, and most imprtantly, why.

Learn more about my book on practicalcombine.com.

Reading and writing Property List files with Codable in Swift

Donny Wals — Wed, 04 Mar 2020 09:31:11 +0000

You have probably seen and used a property list file at some point in your iOS journey. I know you have because every iOS app has an Info.plist file. It's possible to create and store your own .plist files to hold on to certain data, like user preferences that you don't want to store in UserDefaults for any reason at all. In this week's Quick Tip you will learn how you can read and write data from and to property list files using Swift's Codable protocol.

Defining a model that can be stored in a property list

Because Swift has special PropertyListEncoder and PropertyListDecoder objects, it's possible to define the model that you want to store in a property list using Codable:

struct APIPreferences: Codable {
  var apiKey: String
  var baseURL: String
}

This model is trivial but you can create far more complex models if you want. Any model that conforms to Codable can be used with property lists. If you haven't worked with Codable before, check out this post from my Antoine van der Lee to get yourself up to speed. His post is about JSON parsing, but everything he writes about defining models applies to property lists as well.

Loading a model from a property list

We can load plist files from the filesystem using the FileManager object. Let's dive right in with some code; this is a Quick Tip after all.

class APIPreferencesLoader {
  static private var plistURL: URL {
    let documents = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first!
    return documents.appendingPathComponent("api_preferences.plist")
  }

  static func load() -> APIPreferences {
    let decoder = PropertyListDecoder()

    guard let data = try? Data.init(contentsOf: plistURL),
      let preferences = try? decoder.decode(APIPreferences.self, from: data)
      else { return APIPreferences(apiKey: "", baseURL: "") }

    return preferences
  }
}

I defined a simple class here because this allows me to use the APIPreferenceLoader in a brief example at the end of this post.

The plistURL describes the location of the property list file on the file system. Since it's a file that we want to create and manage at runtime, it needs to be stored in the documents directory. We could store an initial version of the plist file in the bundle but we'd always have to copy it over to the documents directory to update it later because the bundle is read-only. You might use the following code to perform this copy step:

extension APIPreferencesLoader {
  static func copyPreferencesFromBundle() {
    if let path = Bundle.main.path(forResource: "api_preferences", ofType: "plist"),
      let data = FileManager.default.contents(atPath: path),
      FileManager.default.fileExists(atPath: plistURL.path) == false {

      FileManager.default.createFile(atPath: plistURL.path, contents: data, attributes: nil)
    }
  }
}

This code extracts the default preferences from the bundle and checks whether a stored property list exists in the documents directory. If no file exists in the documents directory, the data that was extracted from the bundled property list is copied over to the path in the documents directory so it can be modified by the application later.

The load() method from the initial code sample uses a PropertyListDecoder to decode the data that's loaded from the property list in the bundle into the APIPreferences model. If you're familiar with decoding JSON in Swift, this code should look familiar to you because it's the exact same code! Convenient, isn't it?

If we couldn't load the property list in the documents directory, or if the decoding failed, load() returns an empty object by default.

Writing a model to a property list

If you have a model that conforms to Codable as I defined in the first section of this tip, you can use a PropertyListEncoder to encode your model into data, and you can use FileManager to write that data to a plist file:

extension APIPreferencesLoader {
  static func write(preferences: APIPreferences) {
    let encoder = PropertyListEncoder()

    if let data = try? encoder.encode(preferences) {
      if FileManager.default.fileExists(atPath: plistURL.path) {
        // Update an existing plist
        try? data.write(to: plistURL)
      } else {
        // Create a new plist
        FileManager.default.createFile(atPath: plistURL.path, contents: data, attributes: nil)
      }
    }
  }
}

This code checks whether our property list file exists in the documents directory using the plistURL that I defined in an earlier code snippet. If this file exists, we can simply write the encoded model's data to that file and we have successfully updated the property list in the documents directory. If the property list wasn't found in the documents directory, a new file is created with the encoded model.

Trying out the code from this post

If you've been following along, you can try the property list reading and writing quite easily with SwiftUI:

struct ContentView: View {
  @State private var preferences = APIPreferencesLoader.load()

  var body: some View {
    VStack {
      TextField("API Key", text: $preferences.apiKey)
      TextField("baseURL", text: $preferences.baseURL)
      Button("Update", action: {
        APIPreferencesLoader.write(preferences: self.preferences)
      })
    }
  }
}

If you enter some data in the text fields and press the update button, the data you entered will be persisted in a property list that's written to the document directory. When you run this example on your device or in the simulator you will find that your data is now persisted across launches.

In Summary

Because Swift contains a PropertyListEncoder and a PropertyListDecoder object, it's fairly simple to create models that can be written to a property list in Swift. This is especially true if you're already familiar with Codable and the FileManager utility. If you're not very experienced with these technologies, I hope that this Quick Tip provided you with some inspiration and ideas of what to look for, and what to explore.

If you have any feedback about this tip, or if you want to reach out to me don't hesitate to send me a tweet!

How to sort an Array based on a property of an element in Swift

Donny Wals — Tue, 25 Feb 2020 14:33:11 +0000

The easiest way to sort an Array in Swift is to use the sort method. This method is available for all Arrays that have Equatable elements and it sorts your array in place:

var words = ["hello", "world", "this", "is", "a", "list", "of", "strings"]
words.sort() // words is now ["a", "hello", "is", "list", "of", "strings", "this", "world"]

This modifies the input Array and sorts its elements using String conformance to Equatable.

But what if you want to sort the Array based on the length of each string? Or what if you want to sort an Array whose elements aren't Equatable? Or maybe you have a list of objects that have an id property and you want to sort by id, or maybe you want to sort blog posts by date?

You can achieve this using Array's sort(by:):

var words = ["hello", "world", "this", "is", "a", "list", "of", "strings"]
words.sort(by: { lhs, rhs in
  return lhs.count < rhs.count
}) // words is ["a", "is", "of", "this", "list", "hello", "world", "strings"]

You can use any kind of comparison logic in the closure that you pass to sort(by:). In this example, I used count which is a property of String to sort my Array by string length.

Note that sort() and sort(by:) both modify the source Array in-place. If you don't want to modify the source and create a new Array instead, you can use sorted() or sorted(by:).

let words = ["hello", "world", "this", "is", "a", "list", "of", "strings"]
let sorted = words.sorted(by: { lhs, rhs in
  return lhs.count < rhs.count
}) // sorted is ["a", "is", "of", "this", "list", "hello", "world", "strings"]

If you have any questions about this tip, or if you have feedback for me, don't hesitate to send me a Tweet!

Working with throwing functions in Swift

Donny Wals — Mon, 24 Feb 2020 08:25:09 +0000

This post was originally published on my blog. You can read it in its original form here.

In Swift 2.0, Apple introduced the throws keyword in Swift. This addition to Swift language added the ability for developers to write code that clearly communicates that an error might occur during the execution of a code path, and it forces the caller of that code to handle, or explicitly ignore the error in-place. In this post I will show you what the throws keyword is exactly, and how you can deal with errors in your codebase.

Working with code that throws errors

If you've worked with JSONDecoder in Swift, you have already experienced code that can throw an error. Let's look at a quick example to refresh your mind.

do {
  let data = "hello, world".data(using: .utf8)!
  let decoder = JSONDecoder()
  let string = try decoder.decode(String.self, from: data)
} catch { error in
  print("something went wrong!")
  print(error)
}

This code is a very basic example of how you can work with code that might throw an error. When you call a function that can throw an error, you must prefix this invocation with the try keyword. You can't just do this anywhere. Calling out to code that might throw an error must occur in a do {} catch {} block. The try prefixed code must be in the do portion of the block. You can have more than one try prefixed method call in a single do block. When any of those method calls throws an error, execution is immediately moved to the catch part.

The catch block receives a single argument, which is the Error that was thrown in your do block. In Swift, Error is a protocol that is used to represent errors. It's possible to specialize your catch block to make it catch only a specific kind of error. If you do this, you still need a general purpose catch that will catch all other Error types. Let's look at an example:

do {
  let data = "hello, world".data(using: .utf8)!
  let decoder = JSONDecoder()
  let string = try decoder.decode(String.self, from: data)
} catch is DecodingError {
  print("something went wrong while decoding!")
} catch { error
  print("something went wrong!")
  print(error)
}

You can use pattern matching to specialize catch clauses for an entire category of errors, or a specific error (catch is MyError.someCase). Doing this can be convenient if you have special handling paths for certain errors, but you do lose access to the original error. The final catch-all is invoked if none of the specialized catch blocks match the thrown error.

There are cases when you might make the decision that you don't want to handle any thrown errors. In these cases, you can use the try? prefix instead of try. When you call a throwing function with try?, the function's return type becomes an Optional that's nil when an error was thrown. Let's look at an example:

enum MyError: Error {
  case myErrorCase
}

func doSomething() throws {
  throw MyError.myErrorCase
}

print(try? doSomething())

This example is pretty worthless in a real codebase, but it illustrates my point nicely. The doSomething() function doesn't return anything. This means that it returns Void, which can also be written as an empty tuple (()). The printed result of this code is nil. If you comment out the throw line from doSomething(), the printed output is Optiona(()). In other words, an optional with Void as its value. If a function has a return value and you call it with try?, the result is also optional. Let's look at another example:

let data = "hello, world".data(using: .utf8)!
let decoder = JSONDecoder()
let string = try? decoder.decode(String.self, from: data)

print(string)

If you run this code in a Playground, you'll find that the printed value is nil. The provided data isn't valid JSON, so it fails to decode. But because we call decoder.decode(_:from:) with try?, the error is hidden and decode(_:from:) returns an optional value instead of its normal non-optional value.

If you call a throwing function that returns an optional with try?, you might expect a nested optional to be returned. After all, the function itself returns an optional and the return type of a throwing function is wrapped by an optional when you call it with try?. This means that a function that returns String returns String? when you call it with try?. However, if you call a function that returns String?, it doesn't return String??. Swift will automatically work around this nested optional, which is both a blessing and a curse. Consider the following code:

let string = try? returnsOptionalString()

if string == nil {
  // why is string nil? Is it due to an error? Or did the function execute successfully and we just got back nil without encountering any errors?
}

While the code above might be more convenient to write than a do {} catch {} block, you lose all error-related information. And in cases where code returns an optional, you don't whether you received nil because of an error. You should only use try? if you truly don't care about handling errors, or knowing whether an error occurred at all.

There is one more way to deal with code that can throw errors. You can use try! in cases where you're absolutely sure that your code shouldn't throw an error, and you want your app to crash if it does. This flavor of try should be used sparingly, and preferably not at all. Let's look at one last example:

enum MyError: Error {
  case myErrorCase
}

func doSomething() throws {
  throw MyError.myErrorCase
}

try! doSomething() //

This code would crash at runtime. doSomething() always throws an error, and by calling it with the try! prefix we tell Swift that we don't expect doSomething() to actually throw an error. And when it does, execution of the program should halt, and the app should crash. This is quite radical and, again, should be used sparingly.

Throwing errors in your own code

Sometimes, the code you write needs a way to express that something went wrong and execution of that code path needs to stop immediately with an error. If the error is recoverable, you might have a good candidate for a throwing function on your hands. When I say that an error is recoverable, I mean that the error didn't occur due to a programming error (like accessing an out of bounds index in an array for example) and that the program isn't in an unexpected or invalid state. It might simply mean that something went wrong.

For example, when you try to decode invalid JSON using a JSONDecoder, that's not considered an error that's severe enough to crash the app. Instead, an error is thrown to let you know that something went wrong. This is an important distinction, and trying to decode invalid JSON should never crash the application. At least not in the JSONDecoder. You're free to crash your app is a decoding error occurs if you want but I'd strongly advise you not to. Especially if you're loading JSON from a webserver.

When you're writing your own code, you might want to throw an error of your own. You already saw how to do this in the previous section in the doSomething function:

func doSomething() throws {
  throw MyError.myErrorCase
}

Functions that can throw an error must have the throws keyword appended to their signature, before the return type. Here's what a function signature for a throwing function with a return type looks like:

func returnsOptionalString() throws -> String? {
  // do work
}

When you're writing code in a so-called throwing function, you can call methods that throw errors without using a do {} catch {} block:

func decodeJSON(_ data: Data) throws -> String {
  let decoder = JSONDecoder()
  let decodedString = try decoder.decode(String.self, from: data)

  return decodedString
}

This code is okay because Swift knows that decodeJSON(_:) might encounter and throw an error. When the JSON decoding fails in this function, the thrown error is passed up to the called of decodeJSON because it's marked as throwing with the throws keyword. When this function is called from another function that's throwing, that function will also forward the error up to its caller. The error will be passed up all the way to a caller that's not part of a throwing function.

There is one more error throwing related keyword that I want to show you. It's called rethrows. The rethrows keyword is used for functions that don't directly throw an error. Instead, the functions take a closure argument where the closure might throw instead of the function itself. Let's look at an example of a function that takes a throwing closure without rethrows:

func execute(_ closure: (() throws -> Void)) throws {
  try closure()
}

do {
  try execute {
    print("hello!")
  }

  try execute { 
    throw MyError.myErrorCase
  }
} catch {
  print(error)
}

In the code above I have defined an execute function. This function takes a single closure argument, and all it does is execute the closure immediately. Nothing fancy. You'll see that both execute(_:) and the closure it receives are marked with throws. It's important to understand that marking a function as throwing does not mean that the function is guaranteed to throw an error. All we're saying is that it might. This is especially relevant for the closure argument. The closure that's passed might not even be capable of throwing an error, just like the first call to execute(_:) in this example. Even though we know that this closure never throws an error, and the compiler also knows it, we must mark the call to execute(_:) with try because that function itself might throw an error.

We can clean this code up a little bit by declaring execute(_:) as rethrowing rather than throwing:

func execute(_ closure: (() throws -> Void)) rethrows {
  try closure()
}

execute {
  print("hello!")
}

do {
  try execute {
    throw MyError.myErrorCase
  }
} catch {
  print(error)
}

Because execute(_:) is now rethrowing, the Swift compiler can verify whether a code path might throw an error, and it will allow you to call execute(_:) without try if it can prove that the closure you passed to execute(_:) doesn't throw an error. Quite neat right?

You'll find rethrows in several places in the Swift standard library. For example, map(_:) is marked with rethrows because the closure you supply to map(_:) is allowed to throw errors if needed:

let mapped: [Int] = try [1, 2, 3].map { int in
  if int > 3 {
    throw MyError.intLargerThanThree
  }

  return int * 2
}

This probably isn't how you commonly use map(_:) because typically the closure passed to this function doesn't throw. But now you know that you're allowed to throw errors while mapping, and you also know why you're not forced to mark every call to map(_:) with try.

Note that the execution of any throwing method or closure is halted immediately when an error is thrown:

func doSomething() throws {
  throw MyError.myErrorCase

  print("This is never printed")
}

Throwing an error is a strong signal that something's wrong, and there's no point in fully executing the current code path. The error is sent to the caller of the throwing function, and it must be handled or forwarded from there. If you throw an error in a function that should return something, the function will not actually return anything. Instead, your code switches to the catch part of the do {} catch {} block immediately where you can handle the error. The exception here is when the called of your throwing function calls it with try? or try! like I explained in the previous section.

In Summary

In this post, I've shown you how you can deal with functions that can throw errors in Swift. You saw how you can call functions that are marked as throwing, how you can tell Swift you're not interested in handling an error and how you can tell Swift that you're absolutely sure a certain call will never actually throw an error at runtime.

After that, I moved on to show you how you can throw errors from your own code, what the rethrows keyword is and when it's useful.

If you have any feedback for me about this post, or if you have any questions, don't hesitate to reach out to me on Twitter.

Testing push notifications in the Simulator with Xcode 11.4

Donny Wals — Thu, 13 Feb 2020 09:15:42 +0000

This post was originally published on my blog where I publish weekly articles and tips.

Xcode 11.4 is currently still in beta, keep in mind that you can't use this version of Xcode to ship apps to the store. Read my guide on installing multiple Xcode versions alongside each other if you want to play with the Xcode 11.4 beta while keeping your copy of 11.3.1 around as well.

For years we've had to resort to using physical devices when testing push notifications. With Xcode 11.4, Apple finally gives developers the tools needed to test push notifications on the iOS Simulator. I'm going to assume you already know how to add push notifications to your app. If you've never added push notifications to an app before, I have a post that describes how to set up and test push notifications without a third-party service. That post should get you all set up to follow along with this post.

Sending a test push from the command line

Xcode comes with several command-line tools that allow you to run your tests, builds and other tasks directly from the Terminal in macOS. If you have Xcode installed, it should automatically install the command line tools on its first launch. If you've followed my guide on having multiple Xcode versions installed, make sure to select Xcode 11.4 or newer by running xcversion select 11.4 and replace 11.4 with the version of Xcode you want to use. Doing this will make sure the Xcode command line tools point to the correct toolchain.

When you have an iOS 13.4 or newer simulator running, all you need to send a push notification is an apns notification payload. The payload should look similar to the following:

{
  "Simulator Target Bundle": "com.donnywals.SilentPushDemo",
  "aps": {
    "alert": {
      "title": "Push on the simulator",
      "subtitle": "So cool...",
      "body": "This notification is going to show up in the simulator!"
    }
  }
}

The formatting of the push notification is the same as it would be when you send it from a server to a device. The only exception is the "Simulator Target Bundle" top-level key. This key should not be present in push notifications that you send from a production server. To send this push notification, you can run the following terminal command:

xcrun simctl push booted test_push.apns

This will send a test push notification to all booted simulators. The last argument passed to this command is the path to the file that contains the test push notification. In this case, it's a file called test_push.apns which exists in the directory as the one I'm running the command from.

The "Simulator Target Bundle" can be omitted from the file, but then the terminal command would be slightly different:

xcrun simctl push booted <your-bundle-identifier> test_push.apns

When you don't include your app's bundle identifier in the payload, you need to specify the bundle identifier of the receiving app in the command. Make sure you replace <your-bundle-identifier> with the receiving application's bundle identifier.

Sending a test push notification without the command line

If you're not comfortable using the command line to send a test push, you can also drag your test push notification directly to the simulator to have it delivered to that specific simulator immediately.

When doing this, make sure your file has .apns as its extension, and it must include the "Simulator Target Bundle" top-level key so the simulator knows which application should receive your test push.

In Summary

The ability to test push notifications in the simulator is a feature that iOS developers have wanted for a very long time, and I think that it's great that Apple has finally provided us with this ability. Especially because they managed to make the process so straightforward by keeping everything local to the machine you're developing on.

If you want to test with notifications that are actually generated and sent from your server, you still need to use a physical device because the simulator doesn't support true remote notifications just yet. However, I think this is a great step in the right direction and I'm sure I will use this feature regularly.

If you have any questions or feedback for me, make sure to reach out on Twitter.

Five ways to get better at receiving feedback

Donny Wals — Wed, 05 Feb 2020 09:09:45 +0000

This article was originally posted on my blog and can be read here.

When I just started my career as a developer there was a lot I didn't know yet. There also were a lot of things I didn't understand or had never done before. I have always been lucky enough to work in places where I was able to learn and grow as needed, and most importantly, I was allowed to make mistakes. One of the hardest things wasn't that I was constantly learning and figuring out. That actually was the fun part! The hard bit was often receiving feedback.

Whether it was feedback from clients, coworkers or teachers back in college. Something about getting feedback and learning about things I didn't get quite right, could have done better or differently always felt like it was some kind of an attack. You could argue that the feedback should have been delivered differently if that's the case, but the feedback usually was good and constructive. I just wasn't very good at receiving feedback.

Just like giving feedback, being able to receive it is a skill. It's something you learn to get better at over time. And in this week's quick tip I would like to leave you with a couple of lessons that I have learned over the years about receiving feedback in a productive, and positive manner.

1. Listen, don't defend

Something that I often found myself doing when I received feedback was coming up with counter-arguments or a defense against the feedback I was receiving. If somebody told me my code could have been better, I would tell them that my code was fine as it is. Or if somebody would point out that a specific animation wasn't quite right, I would immediately tell them that this was as good as it was going to get.

Not only does this make the feedback process very frustrating for both parties involved, but it also chips away from your credibility over time. When you tell somebody something can't be done, and a more senior developer helps you to it done anyway, that doesn't reflect too good on you as the receiver of feedback.

It's much better to listen carefully to the feedback you're receiving. Or if the feedback is delivered via an email, Jira ticket, code review or any other digital medium, read it carefully. Don't think about any counter-arguments just yet. Just soak up whatever feedback you're getting, no matter how wrong you think it is at the time of receiving it. Especially if the feedback is delivered to you carefully and properly, you can rest assured that the person giving you feedback has the best intentions and wants to ship a fantastic product, just like you.

2. Let the feedback sink in

After listening to the feedback, or reading it all, it's very tempting to begin formulating a response immediately. Try not to do this. When you receive feedback that requires you to make a bunch of changes, or if you need to fix something you don't quite understand, or even think is impossible, chances are that your initial response is quite emotional. You worked really hard and now somebody is telling you that you didn't do a perfect job, of course you're not thrilled about that. That's normal.

It's important to let feedback sink in for a moment, let your initial knee-jerk reaction subside before you respond. I distinctly remember sending a few too many emails back to coworkers and even clients with very well thought out responses explaining why I did what I did, and why I didn't their feedback was justified, only to regret it hours later. I knew they were right, for some reason I just felt the need to explain myself and justify my work to the person giving me feedback. If I had waited an hour or so before responding, I probably would have seen things very differently, and my responses would have been different too.

3. Don't take it personally

This tip has been a game-changer for me. For the longest time, I took feedback personally. If somebody pointed out that an animation wasn't smooth, or that a label is misaligned it felt as if they were critiquing me. All I would hear is that I didn't do a good enough job implementing a design, or that my coding isn't good enough. Detaching yourself from your work is really hard, but I found that it makes receiving feedback a lot easier.

If feedback is given well, it never is an attack on you. It does not even critique on you as a person. It's an objective look at the work that was delivered. In the end, the purpose of giving and receiving feedback is to create a better product. Designers do their best to create a beautiful design, and as a developer, you try to do justice to this design while writing good code. The whole teams wants this project to succeed. So when somebody points out a flaw in the product, they are doing just that. They are not pointing out a flaw you made. They are looking at the product and pointing out a flaw in the product.

In a professional environment, nobody should be out to get you. Remember that.

4. Ask for more information if needed

Sometimes, feedback isn't delivered very well. Key information is missing, or you don't understand what somebody means. It's easy to bounce this kind of feedback off and ignore it. It's one less thing on your todo list. Unfortunately, this almost never works. The person providing feedback to you obviously cared enough to give this feedback to you. If it's not clear, ask for more information. Ask the person that gave you feedback to explain themselves.

This also applies in scenarios where you don't understand why somebody gave you certain feedback. If you're asked to refactor something in a code review but you don't understand why, you'll probably comply reluctantly. Instead, try asking this person for more information. Why do they want you to refactor? What do you gain from it? When you understand the why, implementing the feedback suddenly isn't so bad.

5. Ask for help

In my career, I have often ignored this advice. When receiving feedback, I would often explain why I did what I did, and why changing my work to address the feedback was either impossible or would take a tremendous amount of time. Being a junior developer with just a year or two experience, that's a bold statement to make. When you get feedback from a more senior developer, or designer asking you to improve something, chances are that they know that it can be done.

If this happens to you, don't jump into defense mode immediately. Instead, ask for help. Walk up to a coworker, your team lead or even the person giving you feedback and explain that you want to address their feedback but aren't quite sure how. You did a ton of research but couldn't figure out how to achieve the desired result. Doing this is good. There is no shame in admitting that you don't know how to do something and asking for help. It's much better to be honest when you're not sure about something and asking for help than it is to make a bold claim saying that something can't be done, only to be proven wrong later. That's not good for your self-esteem, and it also harms your credibility.

In summary

Receiving feedback can be hard. Especially if you're not very experienced yet. I hope that this post has given you some good tips to help you get better at receiving feedback. These tips are all derived from my own experiences as a developer over the past years and they really helped me grow as a developer.

If you have any questions about this post for me, or if you want to share your experiences with receiving feedback, don't hesitate to reach out on Twitter.