Tagged “swiftui”

I added a ProjectSpire design note in 399f74d that pushes the card pipeline toward a two-pass model: keep the parser output source-faithful, then resolve localization and rendered text separately for the app.

I created that work with GPT-5.5 in plan mode, and it asked a few genuinely useful clarification questions before I let it draft anything substantial, which made the whole process feel a lot more controlled than a blind codegen pass. I also pushed back on several of its first suggestions and made a lot of the consequential decisions myself, especially around keeping canonical variable names intact and separating raw data from resolved display data. That feels like a strong pattern for future ProjectSpire work: use the AI models to widen the search space, but keep the architecture decisions and edits grounded in my own judgment.

I’ve been working on ProjectSpire’s iOS app (codename: Neow’s Cafe) in NicholasClooney/ProjectSpire as a 1:1 Slay the Spire 2 card library, and the useful part is not just the filtering UI and refactor cleanup, but the way I’m trying to work with AI.

I get better results when I lay down the foundations myself first, especially around quality, guard rails, and how the data is modeled, and then let AI work inside that framework instead of asking it to define the framework for me. It also helps a lot when I have AI propose higher-level API or contract changes before it starts making edits.

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’ve moved the SwiftUI card view forward by adding a real Card model, so even though the screen does not look dramatically different yet, the app is much closer to rendering cards from extracted data instead of hardcoded values. There is even a small visual regression in the golden text compared with the previous screenshot, but the important change is underneath: I can now refine the card parser and JSON output models, bring those records and required images directly into the app, and aim to emulate any card regardless of rarity, type, or data shape. The relevant work is in the ProjectSpire compare for the card view changes and the new card model.

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’m recreating the Slay the Spire 2 card view in SwiftUI with assets extracted from the game, and I’m very happy with how close the first pass feels. The current work is captured in ProjectSpire snapshot/2026-04-28, especially CardView.swift; most of it is still hardcoded, but the visual foundation is there. Next I want to generalize it so the view can take a card data object and dynamically reload the text, colors, and assets, which might eventually turn into a Slay the Spire wiki app for the phone.

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.