iOS Resources
Hand-picked Articles and Videos

Two keywords that turn actor isolation from a wall into a precision tool. nonisolated opts a member out of isolation (useful for computed properties that read only constants, and for fixing delegate crashes from CLLocationManager and similar). isolated on a function parameter makes the function run directly on whatever actor you pass in. transaction closure pattern with isolated parameter lets you group multiple operations without multiple suspension points. #isolation captures caller isolation automatically. nonisolated(unsafe) is a migration escape hatch for legacy globals. isolated deinit in Swift 6.2. And the shift from nonisolated async always hopping away to nonisolated(nonsending) vs @concurrent.

A honest look at building a native macOS app entirely in SwiftUI. The author ported Shopie (an iOS wishlist app) to macOS and ran into real platform specific issues. The term "Mac-assed app" means following Mac conventions: keyboard shortcuts, proper selection states in inactive windows, context menus that highlight the target item without changing selection, and drag and drop that you can track. The article covers specific problems. Selection in inactive windows works fine. Selected but unfocused items require manually passing isEmphasized through the environment. Context menus are impossible to detect, so you cannot highlight the target item unless you use List (which is hard to customize). Drag and drop went through three API versions but still gives no way to know if a drag completed successfully outside the window. Keyboard navigation with arrow keys stops working when a TextField has focus (Spotlight style behavior is not possible). Toolbar placements are semantic and platform dependent, making precise layout difficult.

The article explains how Swift's reference counting has evolved. It starts with the early design where objects stored strong and weak counts inline, creating "zombie objects" that remained allocated until all weak references were accessed. It then covers why this changed (memory overhead, concurrency concerns) and the modern side table design where weak references trigger allocation of an external structure. The article explains inline counts, the transition to side tables, how weak and unowned work today (including why unowned crashes), unowned(unsafe), and performance trade-offs between strong, weak, and unowned.

The article explains three strategies for breaking down monolithic SwiftUI views. First, extracting small reusable components by moving chunks of code into dedicated structs with parameters, which improves readability and enables separate previews. Second, using view modifiers (ViewModifier protocol) to encapsulate styling logic, with extensions for clean dot syntax. Third, creating generic containers with @ViewBuilder that can host any content type without knowing it in advance. The article also warns against using computed properties as a shortcut because they hide complexity without decoupling.

The article explains how to configure background app refresh in a SwiftUI app. It covers enabling background capabilities in Xcode, registering task identifiers in Info.plist, scheduling a background task with BGAppRefreshTaskRequest and setting earliestBeginDate, registering a handler using the backgroundTask(.appRefresh) scene modifier, and testing the background fetch in Xcode using a private debug command to simulate a launch.

The article explains what GeometryReader is and how it provides access to a parent container's size and position through GeometryProxy. It covers basic usage (reading width and height), creating responsive grids that adapt column count based on available width, coordinate spaces with global frame conversion, a practical circular progress view example, and caveats about GeometryReader taking all available space by default and potential performance impacts.

The article explains how tasks inherit MainActor isolation from the surrounding context, which creates an unexpected suspension point. A task created on the MainActor must wait for the main thread to become available before it even starts executing, even if its first real operation switches to a different isolation domain. This can cause performance issues, especially when many such tasks are created rapidly. The solution is to start the task on a different isolation domain immediately using Task { @concurrent in } and then jump back to MainActor only when UI updates are needed.

The article explains the motivation and mental model behind Swift Concurrency, starting from the 2017 Concurrency Manifesto. It covers isolation domains (MainActor, custom actors, nonisolated), how isolation propagates through calls and closures, Sendable for safe data crossing, and common problem areas like mixed isolation, detached tasks, MainActor.run, and unstructured concurrency. It also explains actors under the hood (executors, job queues, thread independence), global actors, and the recent shift toward approachable concurrency where async code stays in the caller's isolation domain by default.

The article explains why recursive enums need the indirect keyword. It covers the problem (value types need a known size at compile time, but recursive cases create infinite size), the solution (indirect stores the case via heap reference), case level versus enum level indirect, practical examples like expression trees and file systems, and trade offs including heap allocation and indirection cost.