In last week's post, I demonstrated how you can use a task group in Swift to concurrently run multiple tasks that produce the same output. This is useful when you're loading a bunch of images, or in any other case where you have a potentially undefined number of tasks to run, as long as you (somehow) make sure that every task in your group produces the same output. Unfortunately, this isn't always a reasonable thing to do. For example, you might already know that you only have a very limited, predetermined, number of tasks that you want to run. These...

With Apple's overhaul of how concurrency will work in Swift 5.5 and newer, we need to learn a lot of things from scratch. While we might have used DispatchQueue.async or other mechanisms to kick off multiple asynchronous tasks in the past, we shouldn't use these older concurrency tools in Swift's new concurrency model. Luckily, Swift Concurrency comes with many features already which means that for a lot of our old uses cases, a new paradigm exists. In this post, you will learn what Swift Concurrency's task groups are, and how you can use them to concurrently perform a lot of...

This post applies to the version of SwiftUI that shipped with iOS 15, also known as Swift 3. To learn how you can present a bottom sheet on iOS 16 and newer, take a look at this post. With iOS 15, Apple introduced the ability to easily implement a bottom sheet with UISheetPresentationController in UIKit. Unfortunately, Apple didn't extend this functionality to SwiftUI just yet (I'm hoping one of the iOS 15 betas adds this...) but luckily we can make use of UIHostingController and UIViewRepresentable to work around this limitation and use a bottom sheet on SwiftUI. In this post,...

We've seen bottom sheets in Apple's apps for a while now, and plenty of apps have followed this pattern. If you're not sure what I mean, it's the kind of sheet that takes up just a part of the screen and can be swiped upwards to take up the whole screen or downwards to be dismissed. Here's an example from Apple's Maps app: To implement a sheet like this, we used to require third party tools, or we needed to get creative and implement this pattern ourselves. With iOS 15, Apple introduced UISheetPresentationController which allows us to implement bottom sheets...

If you've been following along with Swift Concurrency in the past few weeks, you might have come across the term "task local values". Task local values are, like the name suggests, values that are scoped to a certain task. These values are only available within the context they're scoped to, and they are really only supposed to be used in a handful of use cases. In this post, I will explain what task local are, and more importantly I will explain how and when they are useful. For a full rundown of task local values and their design I'd like...

We all know that async / await was one of this year’s big announcements WWDC. It completely changes the way we interact with concurrent code. Instead of using completion handlers, we can await results in a non-blocking way. More importantly, with the new Swift Concurrency features, our Swift code is much safer and consistent than ever before. For example, the Swift team built an all-new threading model that ensures your program doesn’t spawn more threads than there are CPU cores to avoid thread explosion. This is a huge difference from GCD where every call to async would spawn a new...

Meet async / await, explore structured concurrency, protect mutable state with actors should be watched first. Threading model Compares GCD to Swift. It’s not built on top of GCD. It’s a whole new thread pool. GCD is very eager to bring up threads whenever we kick off work on queues. When a queue blocks its thread, a new thread will be spawned to handle work. This means that the system can overcommit with more threads than there are CPU cores. This is also called Thread explosion and can lead to memory and performance issues. There’s a lot of scheduling overhead...

Persistence everywhere Core Data takes care of many complexities to persist data. It converts in-memory graph to persisted data and takes care of all kinds of complex tasks like memory management. Core Data works on all platforms, and it’s great in Swift. Apple’s been working to make Core Data better with Swift over the years. Core Data has always cared about running code concurrently. Swift concurrency Sample app The sample app loads data from the background and persist it. Eventually it updates the view context. Insertion is done with bgctx.performAndWait() and a batch insert. performAndWait will block the calling thread...

When performing slow work, you might dispatch off of the main queue. Updating an observable object off of the main queue could result in this updating colliding with a “tick” of the run loop. This means that SwiftUI receive an objectWillChange, and attempt to redraw UI before the underlying value is updated. This will lead to SwiftUI thinking that your model is in one state, but it’s in the next. SwiftUI needs to have objectWillChange->stateChange->runloop tick in this exact order. Running your update on the main actor (or main queue pre async/await) will ensure that the state change is completed...

Map, filter, reduce, dropFirst all work in async sequences: for try await someThing in async.dropFirst() { } For example. AsyncSequence suspends on each element and receives values asynchronously from the iterator. AsyncSequences either complete with success or stop when an error is thrown. Implementing an AsyncSequence follows all the rules that a normal sequence follows. Its next() returns nil when it’s completed for example. An async iterator also consumes its underlying collection. Things like break and continue work in async sequences too. You can cancel an iteration by holding on to its Task.Handle when you wrap it in async: let...