Tagged "swift"

I published A refresher on SwiftUI state management, async/await, and common patterns, turning a private set of interview-prep notes into a working refresher for the SwiftUI you actually meet in real codebases. It covers the pre-iOS 17 property wrappers next to their @Observable equivalents, async/await as the default for data loading, and the everyday shapes for networking, navigation, and error handling. The next entry in the Swift series, written for the version of me that has been away from SwiftUI long enough to want one page that catches him back up.

A working refresher on the SwiftUI you actually meet in real codebases in 2026: pre-iOS 17 state management, modern @Observable, async/await as the default, and the everyday patterns for networking, navigation, and error handling.

I shipped d60e0e1 in SwiftyBites with a new SwiftUIComponentsLibrary area for pickers, menus, search scopes and tokens, and width-showcase layouts.

The useful part is not just the snippets themselves, but that AI agents researched the best practices, produced the example code, organized the project, and left me with a runnable playground where I can compare equal-width stacks, GeometryReader, PreferenceKey, and some surprisingly similar results against my actual needs.

I published The Confident Lie: What AI Got Wrong About @ViewBuilder, a SwiftUI debugging note that came out of the ProjectSpire card view work. It captures a small but useful lesson: body gets @ViewBuilder from the View protocol, but a custom computed some View property needs the annotation explicitly if I want an if without an else. The compiler was right, the AI was overconfident, and now the mistake is written down somewhere I can find again.

A real SwiftUI debugging note about optional views, overconfident AI advice, and why @ViewBuilder is inherited by body but not by your own computed view properties.

I published Three ways to pass an @Observable object in SwiftUI, a short SwiftUI reference for choosing between environment injection, direct initializer passing, and @Binding. It keeps the distinction focused on ownership and coupling: whole-object reference sharing when the child is allowed to know the model, or a projected binding when the child should only see one value.

Environment injection, direct initializer passing, and @Binding all share SwiftUI state, but they carry different meanings around ownership, coupling, and interface scope.

I pushed 1263f2d to SwiftyBites as a Friday-night AsyncDebounceDemo for playing with Swift's async and sync edges. The demo compares a view-owned async .task flow with a synchronous button action that cancels and restarts a stored Task, which makes the debounce mechanics feel a lot more concrete than just reading the pattern.

I updated SwiftUI in the Wild: Memory, Concurrency, and the Gaps in the Docs with a clearer explanation of using .task(id:) for debounced work. The change moves that pattern into the debounce section, where SwiftUI's automatic cancellation model fits naturally, and keeps the button-action section focused on manual task ownership tradeoffs.

I published SwiftUI in the Wild: Memory, Concurrency, and the Gaps in the Docs, a field guide to the parts of modern SwiftUI + concurrency that look clean in isolation but get messy in real apps. The post covers @State + @Observable lifetime bugs, debouncing with async/await, task ownership in views and buttons, closure capture cycles, and why @Observable and actor pull in different architectural directions.

A collection of hard-won SwiftUI patterns for memory, async work, and Observation edge cases. Covers view model lifetime bugs, debouncing, async button actions, task ownership, reference cycles, and the tension between @Observable and actors.

Swift's Observation framework rethinks how model objects communicate changes to SwiftUI. This is the first post in my Swift series, walking through @Observable and @State with a concrete drag-coordination class as the running example.

I've been building a habit-logging iOS app called ProjectDawn. Not because the App Store needs another habit tracker, but because I wanted a personal project that was genuinely mine and open source, and a project that can answer this openly: what does it feel like to build a real, modular, native iOS app with AI as a primary collaborator?

This post is part personal log, part technical retrospective. It covers the tools I used, what surprised me, where the AI fell flat, and the biggest shifts in how I think about building things now.