iOS Resources
Hand-picked Articles and Videos

Before Swift Concurrency, it was possible to accidentally access mutable state from multiple threads at the same time. These bugs were notoriously difficult to reproduce because they depended on timing and thread scheduling. An application might work perfectly for months and then suddenly crash or corrupt data in production.

When a crash happens deep inside concurrent code, the first question is always: which task did this? Pthreads had names, Grand Central Dispatch had queue labels — they show up in stack traces, in Instruments lanes, in debugger output. Swift Concurrency had none of that until SE-0469, implemented in Swift 6.2.

While building and testing a macOS app locally, values stored in UserDefaults remain between launches. This includes data stored using the UserDefaults APIs directly or data persisted via the SwiftUI's @AppStorage property wrapper. But it's often useful to clear saved values to test onboarding, restore default settings, and reproduce a fresh app state.

A video enhancement feature usually starts with a product sentence: “Can we make playback look sharper?”The engineering answer should not start with “add a filter.” It should start with a boundary question: where in the playback pipeline are we allowed to touch the frame?

Recently, I was asked an interesting question. If the purpose of an actor is to protect mutable state, is a stateless actor pointless?

At first, I thought it was an easy answer. Actors exist to define a little, protective bubble around state. They "isolate" data away from any unsafe accesses. An actor that has nothing to isolate seems like a strange thing.

Can such an arrangement serve a purpose?

Swift makes it easy to write clean camera and video code. It also makes it easy to accidentally destroy performance with one innocent conversion.

The declarative expression of animation is one of SwiftUI’s core strengths. But in some scenarios the result isn’t always as smooth as we’d hope. A typical example: when the content height inside a List row changes dynamically — a subtitle going from empty to non-empty, or text changing its line count after an update — the system’s built-in layout engine often fails to produce a continuous transition. Instead we get visible height jumps, flicker, or even clipping anomalies. This article starts from that phenomenon, peels back the causes layer by layer, and gives a solution built entirely on SwiftUI’s native primitives. Along the way it revisits a few key constraints in SwiftUI’s layout machinery.