Chris Eidhof

Alt Tech Talks

Fri, 03 Apr 2026 00:00:00 +0200

In 2013, I got rejected for Apple’s “Tech Talks”. At the time, with objc.io doing well, I assumed I would have been accepted.

I jumped on my bike, cycled to the nearest cinema, and walked in asking what it would cost to rent the place for a day.

They said €3,000.

I realised I could probably get sponsors, and even if not, I could afford to lose it. So I said yes.

I called Microsoft and asked them to sponsor my alternative conference. I started asking friends to speak. I couldn’t pay them, but tickets would be free. The line-up filled up quickly.

On the day itself, I got out of the subway. It was still dark, and I saw “Alt Tech Talks” on the cinema lightbox. That was the first moment it felt real—and slightly terrifying. People were flying in from all over Europe.

The room filled up. The talks were great, but more importantly, the atmosphere was different. People meeting, talking, forming connections and making friends. It felt like a real coming together of the community.

Looking back, I didn’t actually need a ticket for Apple’s event. I needed a way to meet the community. And it turns out you can just build one.

What I didn’t expect was that others would pick it up. People started organizing their own versions of Alt Tech Talks. Daniel ran one in London. At that point, it stopped being about my rejection and became something bigger than that.

Building Pancake

Fri, 20 Feb 2026 00:00:00 +0100

In January, Nathan and I built a Mac app over the course of a month. Last year, I set the goal to collaborate more with other people in 2026, and Nathan was the first person I thought of. We’ve been doing SwiftUI workshops together throughout last year, and I really enjoy working with him. This post is a short story of what we’ve built and how we did it.

Our goal was to build and ship an app in a month. This is slightly ambitious, and we both succeeded and failed at the same time. We decided last minute that we’d build a Mac app to build static sites. Many static site generators come with all kinds of dependencies that eventually fail to resolve, and installation can be messy. With Mac apps, everything comes bundled and you get the experience of “batteries included”.

We decided that we wanted to scope it down to just creating blogs (initially) and speed was a core consideration: it should be extremely fast to create a new website (creating a new file), to write something (integrated editor) and also to publish it (our own server). Because we use a native text editor, adding images is as easy as just dragging the image in. In the video below, you can see exactly this process with Pancake, our new app:

We decided beforehand that we wanted to release this at the end of the month. In our case, this meant sharing the download link with just a few close friends. While we both have other obligations this month and next, we haven’t found the time to polish this in a way that we feel comfortable putting this out as a “public” release. But if you are interested, just send one of us a message.

I’m proud of what we built in a month. I do think we made a few mistakes. First of all, I think we had too big of a scope given the constraints. Second, including a server component means a lot of responsibility (what if people upload malicious content? what if the server goes down?) that feels unrealistic to support as a side project.

We’re not sure yet how we’ll proceed from here. Is this a portfolio piece? Will we keep working on it? In any case, it has been a lot of fun. For me, the highlight was actually working together with Nathan, in person, in Paris.

Self-Forking Agents

Fri, 13 Feb 2026 00:00:00 +0100

Over the last weeks, I’ve been experimenting with building agents. An agent in itself is a simple concept. It’s a loop where you give it input, and then the LLM responds. Crucially, you can tell the LLM to use specific tools that you describe, and the LLM’s response can include calls to those tools.

There is an inner loop where, before accepting the next user input, you process all the tool calls and feed that information back into the LLM. And it turns out you can write an agent with very few tools. The PI agent uses just four: read, write, edit, and bash.

I built a few things on top of Pi. I made a Mac GUI using SwiftUI, which turned out to be relatively useless for now. Then I wanted to take a key concept from OpenClaw, which is self-improving code . Here’s the goal I had in mind: I wanted to talk to an agent (running on a server) through Telegram and tell it to improve its own code. To do so, I wanted it to fork itself using a git worktree, make the changes, verify them and then open a pull request. This way I can talk to my agent and have it improve itself over time.

It took me a few hours of prompting to get this up and running. First, I created a self-fork skill. A skill is just a text file that describes how to do something specific, and it took a few tries to get this right. One of the key insights was to have as little code in the text as possible. I moved almost all the code out into separate scripts. This makes the skill much more reliable. Given what I learned, I do think I can prompt my way to the same result much quicker now.

For me, this is the way I like to learn. I recreate things from the ground up so that I understand how it works. And I feel that I’ve now understood a key part of how to build something like OpenClaw. Of course, there is a lot more to it, but to me, this was one of the pieces I wanted to see for myself.

If you want to try this yourself, here’s the goal to aim for: build an agent that you can talk to through a chat app. You should be able to tell the agent to improve itself and get that improvement out as a GitHub pull request. The agent needs to run on a server so that you can always access it. Getting this loop closed felt really magical to me. Good luck!

Integrating Dependencies into LLM-Assisted Projects

Thu, 05 Feb 2026 00:00:00 +0100

The other week I met Orta again. When talking about LLM-assisted coding, we also discussed dependencies. He told me about an approach he’s been taking: he just integrates dependencies into his code by literally pasting in the files and then adjusting them as needed. He also recommends this way of integrating for one of his projects. To me, it almost feels like “melting” the dependency into the codebase. You start owning the code the moment you integrate.

This is very different from having a dependency manager where you depend on the code other people maintain. Over the years, even before LLMs, I’ve done the same with my own code. Rather than abstracting things out, I often would just paste in existing code and modify it for that project. With LLMs, it’s now become even easier to do that.

Even Donald Knuth was skeptical about reusable code:

I also must confess to a strong bias against the fashion for reusable code. To me, “re‐editable code” is much, much better than an untouchable black box or toolkit. […] (Source)

In any case, I’ve been moving towards fewer dependencies for years, maybe now even more? I’m curious about other changes that might happen as well.

Food Assistant

Tue, 03 Feb 2026 00:00:00 +0100

This month, I want to focus on using LLMs more, and AI in general, so I’m working on a bunch of projects. I’ve been using Claude (and more recently Codex) over the last year or so, but now I’m actually using them very intentionally with the goal of understanding how to work with them better and to understand what the possibilities are.

This morning I built a small custom agent. I used the new Codex Mac app to build this agent from scratch, and of course I’ve been inspired by the work that Peter has been doing with OpenClaw. This agent is taking care of my food, so it has an idea of what I have in stock. It knows about my allergies, my dietary wishes, and it has recipes and a grocery list. It also has a list of dishes I enjoy making and eating. I managed to get it up and running in about half a day.

I started by creating a new TypeScript project and using the Agents SDK from OpenAI. The main interface is a Telegram bot because Telegram has strong support for bots, and that way I have both a text and a voice interface for free. If I send it a voice message, it uses ffmpeg to convert the audio, then I send it over to OpenAI to get it transcribed.

The agent operates on Markdown files; they all live in a Git repository, and every time I change something it gets committed automatically. Also, the agent pulls from Git automatically. I’ve used a GitHub deploy key to give the agent access to just the one repository. This gives me persistent memory, change tracking, and I can just host my agent on Fly.io. I’m really liking this pattern. I wonder if I could extract it out into something more reusable. I

One of the fun things is that the system prompt is in a Markdown file as well, so I can actually tell my agent to change its prompt and that will automatically get reloaded. This is a powerful concept. Of course, things like OpenClaw can completely rebuild and rewrite themselves, which is even more powerful. I did not want that for this project, but being able to talk and chat to my software in order to then rewrite itself is very powerful.

One interesting thing is that the agent initially wanted to add tools for “writing the shopping list”, “writing the recipe list”, etc. When I changed that to just read/write markdown file tools the results got dramatically better.

I finally added some support for images and meal planning as well, so I can be a little bit smarter about going shopping and reusing things and meal prepping certain ingredients. All in all, it was half a day of work, and it’s already very useful. It’s online all the time, I can talk to it, it has no access beyond the files it needs, and we’ll see how I will use this in the future.

Today, I used it to plan my next four meals and my shopping list. It updated my plan, gave me a few recipe ideas and made me a shopping list.

2025

Wed, 31 Dec 2025 00:00:00 +0100

This has been a very eventful year for me personally. While I don’t want to talk publicly about all the bad things that happened, there’s been enough for a year.

Yet, this is a hopeful post. I’m doing well given the circumstances. I learned a whole bunch of new things about myself. I found much more compassion for both myself and for others. I was able to show up in ways I couldn’t imagine before. There are new people in my life that already feel like they’ve been there for years.

Some of the things from 2025 will continue to drag on in the new year. There’s going to be a lot of adjustment, but there will also be many new opportunities.

I decided to take action on some things that bothered me and will collaborate much more in 2026. I’ll start in January by doing a project with Nathan and hope to collaborate much more with others during the rest of the year. I’m planning to be in Berlin more regularly as well, and hope to be more active in the social part of the tech scene.

This year, I’m most proud of how I was able to reframe some really bad situations. Instead of trying to control things that were out of my control, I was able to show up in the best way possible. I showed up full of compassion and understanding. For the first time in my life, it was really clear to me that I chose to act well even when other people did not. I optimized against regret. It’s not the first time in my life where a stressful situation actually made me get the best out of me.

My new year’s resolution for 2026 is to celebrate more. Specifically, I want to celebrate the achievements of the people around me as well as my own achievements. I want to celebrate friendships, collaborations and other good things. If you have something to celebrate, reach out and we’ll find a good way!

Task Identity

Thu, 13 Nov 2025 00:00:00 +0100

When you write SwiftUI views, one of the big advantages over UIKit is that SwiftUI performs automatic dependency tracking. Whenever your model invalidates or one of your view’s properties change, your view is re-rendered.

Consider the following view that loads an image. It runs the image loading code in a task. The task will run the first time the view appears, and it seems to work:

struct ImageLoader: View {
    var url: URL
    @State private var loaded: NSImage? = nil
    var body: some View {
        ZStack {
            if let loaded {
                Image(nsImage: loaded)
            } else {
                Text("Loading…")
            }
        }
        .task {
            guard let data = try? await URLSession.shared.data(from: url).0 else { return }
            loaded = NSImage(data: data)
        }
    }
}

When we use the view in our ContentView, everything seems fine:

struct ContentView: View {
    var body: some View {
        ImageLoader(url: URL(string: "https://picsum.photos/200/300")!)
    }
}

However, there is a subtle bug in the initial code that is really hard to spot. The problem is that task runs the code exactly once — when the view appears. When the url property changes, the view’s body will be re-rendered, but the task will not be re-run as the view has already appeared. If you use onAppear instead of task you’ll have exactly the same problem.

We can verify by changing our ContentView:

struct ContentView: View {
    @State private var height = 300
    var body: some View {
        ImageLoader(url: URL(string: "https://picsum.photos/200/\(height)")!)
            .onTapGesture {
                height = height == 300 ? 200 : 300
            }
    }
}

When we run the code above, we can see that the image never loads again (beyond the initial load) even when the URL changes. We can put a print statement or breakpoint in the ImageLoader’s body and verify that the body is actually rerun when the URL changes.

The problem is our task: it runs when the view appears. And only when the view appears.

Note Unfortunately, task and onAppear are currently the best way to run code when a view gets created in the attribute graph. However, the concept of “view appearance” is not clearly defined in SwiftUI. For example, the task will re-run when you put the image loader in a List and scroll it out of bounds and back into bounds. Likewise, when you put the image loader in a tab view, the task will also run again when switching tabs.

To fix our problem, we need to understand the core issue. Let’s look at the code again:

struct ImageLoader: View {
    var url: URL
    @State private var loaded: NSImage? = nil
    var body: some View {
        // ...
        .task {
            guard let data = try? await URLSession.shared.data(from: url).0 else { return }
            loaded = NSImage(data: data)
        }
    }
}

Inside our task we have a dependency on the url property . This is causing our problems: ideally, we want our task to re-run whenever the url changes. We can do so by making the url part of the identity of our task:

.task(id: url) {
    guard let data = try? await URLSession.shared.data(from: url).0 else { return }
    loaded = NSImage(data: data)
}

This now makes our code work correctly. The task will run initially, and when the identity changes, the previous task gets cancelled and a new task is created.

Adding More Properties

Let’s consider a slightly more complicated example. Here we have a task that depends on two properties, baseURL (from the environment) and path (a regular property):

struct ImageLoader: View {
    @Environment(\.baseURL) private var baseURL
    var path: String

    @State private var loaded: NSImage? = nil

    var body: some View {
        // ...
        .task {
            let url = baseURL.appendingPathComponent(path)
            guard let data = try? await URLSession.shared.data(from: url).0 else { return }
            loaded = NSImage(data: data)
        }
    }
}

To make this work correctly, we now need to create a compound identity that combines both the path and baseURL, as the task depends on both. In addition, this value needs to conform to Equatable. An easy way to solve this is by taking all your dependencies and sticking them into an [AnyHashable], for example by saying [baseURL as AnyHashable, path as AnyHashable]. In this specific example, we could actually pull out the url property — as it already combines both values — and use that as the identity:

struct ImageLoader: View {
    // ...

    var body: some View {
        let url = baseURL.appendingPathComponent(path)
        // ...
        .task(id: url) {
            guard let data = try? await URLSession.shared.data(from: url).0 else { return }
            loaded = NSImage(data: data)
        }
    }
}

Here’s my advice: whenever you use task or onAppear in your code, be extremely careful about the dependencies. Make sure to review your code carefully, and ideally, have someone else review it as well.

Note When you use onAppear instead of task, you can replace the onAppear with an onChange(of:initial:_:). As the value, you’d use the compound identity.

Clearly, Apple can’t just change the implementation of task or onAppear to make this work automatically, as I’m sure there are many apps that depend on the current behavior. I wonder if it can even be done automatically without introducing cycles in the graph.

Update

Matt Ricketson (SwiftUI Engineering Manager) wrote a very thoughtful response on Mastodon. I’ll quote it here so that it’s persistent in the future as well:

It was intentional to not have automatic dependency tracking with this API, as originally designed — that can very easily become an unintended (and equally unintuitive) footgun in other ways when applied to imperative code with side effects (which View.body is not):

First, as you mention at the end, automatic dependency cycle detection is more problematic, and if cycles do occur they can be much more difficult for a developer to detect and debug on their own.

There are common kinds of view tasks that are intended to only be run once, relative to the view’s lifetime, such as continuous tasks that manually track other values (e.g. a for await on an AsyncSequence of some kind, and note that task() predates the existence of Observable).

There are many cases where a view task will read/write cached values that should not participate in dependency tracking, so you would still need a similar API but inverted, to be able to specify the values that should be ignored (similar to purpose of @ObservationIgnored).

Of course, none of that contradicts your blog post! The image loading example is a great example of a common type of “pure function” task where it would be convenient and intuitive for automatic dependency tracking to occur, and the point about compound dependencies is a legitimate ergonomic problem!

LLMs for "Real Projects"

Wed, 09 Jul 2025 00:00:00 +0200

When I have an LLM assistant write prototypes in a language that I don’t know, my prompts are high-level and focused on features, not implementation. For simple projects, often a one-shot approach works. For example, I’ll say:

take these notes from my therapist and help me build a simple react app that asks me those questions.

For the project I was building above, I didn’t really care about the code, I just wanted it to work.

When I write SwiftUI, I’d like to have a lot more control, because that’s the domain I know. I care about the code. My prompts become a lot more technical and implementation-specific. For example, I said:

When hovering over an anchor/socket, propagate that anchor’s bounds, including its unit point up using a preference. The preference should contain an array of all the anchors that are currently hovered over. I think we should do the bounds as an Anchor<CGRect>. Before we do this, we should extract the socket view out into its own view.

My prompts are typically smaller, but still: this prompt worked really well. I was already in the context of making edits to that node view that contained the sockets. The code it generated was very close to what I would’ve written myself.

One interesting note: somewhat confusingly, I have anchors in my code that represent the sockets a node has (I’m building a small drawing app). Claude Code did not confuse them with SwiftUI’s builtin Anchor values.

Agentic Coding

Tue, 08 Jul 2025 00:00:00 +0200

I teach SwiftUI for a living. Through our workshops, books, and videos we try to help people build a mental model of how SwiftUI works as well as show some of the details. I really, really enjoy doing that and have built a successful lifestyle business doing just that.

Note: this post was written by me, not by an LLM. I don’t feel comfortable at all letting it do that.

To me, the quality of the LLMs and their tooling (looking at you, Claude Code) feel like a threat to my business. Will people still need to learn SwiftUI? Do we need to teach in different ways? What will the LLMs be capable of in a year from now? Will there still be enough people to teach?

I’m in an ongoing process of figuring this out. I’ve experimented a whole bunch with LLMs, have read and watched many things (Essential Reading for Agentic Engineers is a really good start). In this post, I’ll try to share some of the stuff I learned. I’m by no means an expert, but I still hope that this is useful.

Easy Things You Can Do Today

If you are not using an LLM or have not had success using it (“it just didn’t work for me”) here are some quick ideas in which it can help you today. I’m mainly using Claude Code (and sometimes the Claude desktop app):

Using the Claude desktop app, you can very quickly build basic prototypes. This can be extremely helpful in understanding a problem and can be a big motivation to build it “properly”. If you need a quick web service prototype, you can use tools like val.town to host (and further refine) stuff.

If you are working with an existing code base and don’t want an LLM touching your precious code (this is often how I feel!), you can have an LLM build little debugging tools. For example, I had it visualize some internal state for me during debugging. Seeing the current state in my app was much quicker to parse than reading through the debug output. Once I found the problem I immediately deleted the debug code.

I found it helpful to get a quick grasp of existing code. I just took a bunch of code and asked the LLM to explain it. I absolutely do not feel confident about my understanding after reading the explanation. It just helps to get a first basic feeling so that I can explore further.

I’ll also ask an LLM about possible algorithms I could use to solve problems. I’ll tell it I know Swift, Haskell and Typescript. I’ll make it generate examples. I don’t trust the output, and will verify things myself.

I found it helpful to ask an LLM to give me options to implement stuff (while also telling it to explicitily not implement it). I’ll use it to help me think through problems.

If I feel stuck on something or somehow can’t get started, I can always prompt the LLM to start on something tiny. I can then carry that momentum forward myself.

If I need to generate mock data (e.g. for my workshops) I’m often too lazy myself to really put time into it. Even the builtin LLM to Xcode has been giving me way better results than doing it myself.

Personally, if I think of my app’s architecture, I’m much more willing to let an LLM generate “leaf nodes” that can easily be replaced rather than trusting it with “core” nodes that require much more consideration.

I did find that getting better at prompting really can improve the results you’re getting.

Weird Things

Things are changing so quickly. It’s hard to keep up with new things, what might have been true last month is not true anymore this month. My setup is pretty simple: I mainly use Claude Code and the Claude desktop app.

I often “feel bad” about deleting code that was just written. The AI will often just write the wrong thing. I take full responsibility for the result (I either need to improve my instructions or write it myself). It’s okay to delete the just-generated code, ignore the responses and start over. However, I do still anthropomorphize the LLM: it’d be hard to tell a human to throw away what they just did, and I still feel a bit bad about it when doing that to the LLM.

I’ll have the LLM do non-code stuff as well. For example, you can tell Claude Code to create a git commit, to set up parts of your dev environment, and so on.

What Doesn’t Work

I don’t really believe in “vibe coding” beyond basic prototypes. To build quality non-trivial software, I think you (still?) need to have a very good understanding of what’s happening. For example: I asked Claude Code to add an inspector to an app I’m working on. Rather than using the inspector API, it generated an HStack. When I specifically told it to use the inspector API, it did do so. I still needed to change things myself. In other words: writing code with AI is absolutely not a fully automated process for me. I don’t shy away from writing code.

I had some fun with a side project and it looked like things were going well. I was doing TDD and iterating quickly. I got lazy, did not review the code, but trusted my tests. Turns out, the agent had been adding special cases to the code just to make the tests pass.

Another “fun” thing is that these models are not lossless. For example, I wanted to move some code to a different file. While doing this, Claude Code just hallucinated some new code and changed some of the old code. This becomes hard to spot when the diff gets large (when the diff gets too large, I’ll just undo the change and do stuff myself).

I had people in my workshop that used an LLM to generate a whole bunch of code that wasn’t working and not using the suggested APIs. Instead of using SwiftUI’s animation system, they animated with a timer. They were solving the wrong problem in the wrong way. The goal of the workshop was understanding, and not getting through the exercises as quickly as possible.

You Still Need to Understand What’s Happening

I feel like I still need a very strong understanding about the APIs that exist, about how to structure the code and about the mental model behind SwiftUI. My iterations are pretty short. I want to understand exactly what is happening.

Peter seems to have a lot of success with a more hands-off approach, letting his agents run for a very long time.

Feedback Loops

The current thing I’m thinking about is how we can increase the feedback loop between the agent and me. This is the current loop:

I prompt the agent to make a change.
The agent starts working, this often takes a while (30s to a few minutes). The better my prompt is, the quicker the work often goes.
The agent verifies its own work (by running the tests, compiling the project, etc.)
I need to verify what happened. Because I do a lot of GUI stuff, this often involves running and clicking through the app (or opening different previews in Xcode).
At this point, I’ll have three choices: I commit when I’m happy, I iterate to refine the solution, or I start over.

I think the second step (agent building things) will get much quicker over time. I think the third step (agent verifying its own work) still has a lot of untapped potential. But by far, the slowest part of the loop is me verifying what happened.

Opportunities

It’s hard to keep up. A good reliable source of information could be helpful. (I’m considering turning what I’ve learned (and will learn) into a workshop).
We can build tools to help the agent work more effectively. Linters, type checkers, tests, but possibly also other methods of formal verification.
We can build tools to shorten the feedback loop (how can we verify the agents’ work more quickly?)
…

Conclusion

I don’t see a future without agentic coding. It feels like we’re just at the start. I think we still need a very strong understanding of what’s happening to be truly effective. It feels like things are changing very quickly, and none of the above might be true in a few days, weeks or months.

Presentation: Attribute Graph

Tue, 01 Jul 2025 00:00:00 +0200

I gave a talk about my understanding of the Attribute Graph. I created a presentation page that contains the video, an edited transcript and some references.

It was really fun creating the talk: I used my “record typing” tool to automate the typing and animate the graph, preview and other bits. The graphs are draw in SwiftUI, but the layout is done in GraphViz.

SwiftUI View Model Ownership

Tue, 06 May 2025 00:00:00 +0200

When we cover SwiftUI’s state system in our workshops, we often get asked: How can I set up my view model in a view? There’s a bit more to this question, so let’s try to spell out the requirements:

We want our view to create a view model and maintain ownership: when the view goes away, the object should go away.
We want our view model to be an object (not a struct) and the object should use the Observation framework.

Getting this right is trickier than expected.

Let’s consider a view model that counts the number of people in a room. Here’s the model definition:

@Observable class RoomVM {
    let roomName: String
    var count: Int = 0
    init(roomName: String) {
        self.roomName = roomName
    }
}

When we now want to create a RoomView we are faced with a choice: we need to think about ownership. When the lifetime of our view model is tied to the lifetime of the RoomView, we say that the RoomView is the owner of our object. That means we should use an @State property. When the view model is passed from the outside, we are not the owner, and we should not use an @State property.

In our requirements, we wanted the RoomView to be the owner. This means we should use an @State property. My personal rule of thumb is to always mark all @State properties as private and to always initialize them on the same line as the declaration. For example, for a simple Int property I’d write:

struct CounterView: View {
    @State private var value = 0
}

If you are unable to use those two rules (marking as private and setting the initial value), you should either reconsider using a @State property or you should make sure to pay extra attention to the code you’re writing. In our case, we want an API that looks like RoomView(name: "Main Room").

struct RoomView0: View {
    var name: String
    @State var viewModel: RoomVM = // ...
    var body: some View {
        LabeledContent(viewModel.roomName) {
            Stepper("\(viewModel.count)", value: $viewModel.count)
        }
    }
}

The init Trap

What do we write after the equals sign above? Ideally, we’d write RoomVM(roomName: name) but that doesn’t compile, because the name is not available yet. Luckily after a bit of searching, we’ll find a solution somewhere on a blog, forum post or in a video:

struct RoomView1: View {
    var name: String
    @State var viewModel: RoomVM
    init(name: String) {
        self.name = name
        self.viewModel = RoomVM(roomName: name)
    }

    var body: some View {
        LabeledContent(viewModel.roomName) {
            Stepper("\(viewModel.count)", value: $viewModel.count)
        }
    }
}

The code above is broken, and it is not obvious. For example, if you run the following snippet, it works exactly as intended. We can navigate to a room, change the value, and when we navigate away the view model is destroyed.

struct ContentView: View {
    var rooms = ["Main Room", "Breakout", "Hallway"]
    var body: some View {
        NavigationView {
            List {
                ForEach(rooms, id: \.self) { room in
                    NavigationLink(room) {
                        RoomView1(name: room)
                    }
                }
            }
        }
    }
}

Let’s now consider a different way of using our RoomView1:

struct ContentView: View {
    var rooms = ["Main Room", "Breakout", "Hallway"]
    @State var selectedRoom: String = "Main Room"
    var body: some View {
        VStack {
            RoomView1(name: selectedRoom)
            Picker("Select a room", selection: $selectedRoom) {
                ForEach(rooms, id: \.self) { room in
                    Text(room)
                }
            }
        }
    }
}

When we change the counter for a room, then select a different picker value, we never see the RoomView update: it always will show the initial room (“Main Room”). Why does this happen?

In our RoomView1‘s initializer, we’re not actually changing the value of the state property. When we assign to a state property outside of the view’s body, we are changing the initial value that’s used when that view is created in the attribute graph. You can only modify the state’s value inside the body of a view.

This is why I have that personal rule of always making the state property as private (so no one can assign from the outside) and initializing it straight away (so I’m not allowed to initialize it in the view’s init). And yet: we cannot do this for our example above.

Towards a Fix

There’s no one perfect way to solve this, but here’s one approach. Because we have a dependency on name in our view model expression, we also need to add an onChange(of:). Each time the name changes, we create a new view model.

struct RoomView2: View {
    var name: String
    @State var viewModel: RoomVM
    init(name: String) {
        self.name = name
        self.viewModel = RoomVM(roomName: name)
    }

    var body: some View {
        LabeledContent(viewModel.roomName) {
            Stepper("\(viewModel.count)", value: $viewModel.count)
        }
        .onChange(of: name) {
            self.viewModel = RoomVM(roomName: name)
        }
    }
}

Another way to think about this is that the name uniquely determines the identity of our RoomView2. When that name changes, the identity changes and we should recreate our view model. The code above works as expected in all scenarios. It is not quite there yet, though. After I published this article, Kyle asked the following question:

@chris In the fixed example, is it correct to say that an instance of the view model object will be needlessly created each time the view’s initializer is called by the parent? As in: when you change the selected room in the parent, the child’s initializer is run, name is set to the new name, the view model object is created and then not used (because of the attribute graph as you mentioned), and then the “original” view model is replaced by a third inside of onChanged?

Source

Kyle is absolutely right. The example above does have the correct behavior, but unnecessarily creates and discards new objects everytime the initializer runs.

A Final Solution?

Here’s a variant that creates the RoomVM once when the view appears, and only recreates when the name property changes:

struct RoomView3: View {
    var name: String
    @State private var viewModel: RoomVM?

    var body: some View {
        ZStack {
            if let viewModel {
                RoomView3Helper(viewModel: viewModel)
            }
        }
        .onChange(of: name, initial: true) {
            self.viewModel = RoomVM(roomName: name)
        }
    }
}

struct RoomView3Helper: View {
    @Bindable var viewModel: RoomVM

    var body: some View {
        LabeledContent(viewModel.roomName) {
            Stepper("\(viewModel.count)", value: $viewModel.count)
        }
    }
}

The code is way less clean than what we started with, but at least it’s correct and efficient. I wonder if there’s an cleaner way to write the code above, or if this is really what we need to resort to.

Conclusion

One of the hardest parts about this problem is that, initially, our code seemed to work correctly. It seemed to just do the right thing. It’s hard to catch this problem during testing, but as long as you stick to the private/initial value rules, you’ll never have that problem. If you do need to break the rule, pay extra attention and add on onChange(of:) for every property that your view model depends on.

Updates

May 7 : Added a version that doesn’t recreate the model every single time the `init runs.

SwiftUI Alignment Guide Bug

Mon, 05 May 2025 00:00:00 +0200

For the last few years SwiftUI’s alignment guides have been broken in combination with if-statements. Here’s a small example:

struct ContentView: View {
    var value = true
    var body: some View {
        Color.green
            .frame(width: 100, height: 100)
            .overlay(alignment: .topLeading) {
                if true {
                    Circle()
                        .alignmentGuide(.leading) { $0.width/2 }
                }
            }
    }
}

I expected the horizontal center of the circle to be aligned with the leading edge of the green color. Instead, both views are centered on top of each other. When you remove the if it works as expected. If you replace the if with an if/else it’s still broken, but if you replace the if with a switch it does work as expected.

Depending on your use case you can also replace the if statement with an opacity modifier or something similar.

(FB13676056 for Apple folks. Last tested on Xcode 16.3).

Bindings

Fri, 21 Mar 2025 00:00:00 +0100

In SwiftUI, there are two kinds of bindings. There are bindings created using keypaths, and then there are bindings created using Binding(get:set:). These are not the same at all.

For example, consider the following (contrived) view:

struct ContentView: View {
    @State var value1 = false
    @State var value2 = false
    var body: some View {
        VStack {
            Toggle("Test", isOn: $value1)
            Nested(value2: $value2)
        }
    }
}

When we change either value1 or value2, the body of ContentView will re-render. This is expected. However, we only want Nested to re-render its body when value2 changes, not when value1 changes.

Under the hood, SwiftUI looks at the Nested value in the attribute graph and compares it against the new value of Nested that we’re constructing above. If these are “the same”, it will not re-render the body of Nested. It is not documented how this comparison works, but Javier found out some things and there are some old tweets by SwiftUI team members. SwiftUI compares the old and new view on a field-by-field basis, and only if all fields are the same, it stops re-rendering.

In the example above, SwiftUI can do this comparison, and indeed, the body of Nested will not be re-rendered unless the actual value of value2 changed.

Manual Binding Problems

Instead of writing $value2, we could have also constructed a manual binding using Binding(get: { value2 }, set: { value2 = $0 }). This has a different behavior: every time ContentView re-renders its body, Nested will re-render its body as well. Even when only value1 changes. While we don’t have access to the SwiftUI source code, I think the problem is that these manual bindings store closures instead of a “pointer” to the state value. Every time the body of ContentView executes, a new closure is constructed. Swift cannot compare closures and thus SwiftUI needs to re-render the body of Nested.

While the above is a contrived example (no one would write Binding(get:set:) instead of $value2) the distinction between binding types becomes important when creating member bindings. For example, in SwiftUI Binding Tricks we look at creating a binding of Bool from a state property of type Set. While it might be easier to write this using a Binding(get:set:) we do create a potential efficiency trap. When you write something like $selection[contains: element] a binding with a keypath is constructed, and SwiftUI can compare these kinds of bindings effectively. At least one of the companies we’ve worked with has documentation and warnings in place because using Binding(get:set:) caused way too many view body redraws.

Conclusion

I think we should avoid Binding(get:set:) in production code. In most cases, you will probably not see a big difference in performance, but it can come back to bite you. With some practice, bindings using key paths rather than Binding(get:set:) are just as easy to write and often simplify testing.

References

Jacob Van Order wrote an article where he measures the different approaches using the SwiftUI Instruments templates.

Why I Avoid Group

Wed, 19 Mar 2025 00:00:00 +0100

In our SwiftUI workshops, we often see people reaching for the Group view. There’s a lot of code out there that does this, and yet, I noticed myself avoiding Group, even though it can be pretty handy. In investigating, I realized that it’s not even Group that is the problem. It seems to be the meeting point of SwiftUI and UIKit.

In my understanding, Group is just a way to get view builder syntax, but doesn’t really add any “structure” or “container” node.

In SwiftUI, when you have an if/else statement and want to apply a modifier to that, it won’t compile:

if let image {
    Image(image)
} else {
    Text("Loading…")
}
.onAppear {  } /* does not compile */

You can fix this by wrapping everything in a Group:

Group {
    if let image {
        Image(image)
    } else {
        Text("Loading…")
    }
}
.onAppear {  } /* works */

So far, so good. And yet, every time I see this it makes me uneasy, because Group has such strange, unpredictable behavior. For some reason, it always seems to come back and bite me. However, I couldn’t really put my finger on it. In this post, I’ve boiled down the problem, so that in the future, I have an explanation that I can link to.

Group Variadics

You can also use Group to apply some modifiers to each of the subviews rather than to the group as a whole. For example, you can apply padding and a background to each of the elements in a Group:

Group {
    Text("One")
    Text("Two")
}
.padding()
.background(.blue)

If you create a new Xcode project and add this as the body of your ContentView, it will look like this in the previews:

However, if you then run that very same app in the Simulator, it looks very different:

The complete difference in behavior above is the reason why I avoid Group. From my interpretation, the Group documentation page makes it clear that the preview behavior is correct, and the Simulator behavior is a bug.

Some modifiers do seem to work differently. In the official documentation, it says:

The modifier applies to all members of the group — and not to the group itself. For example, if you apply onAppear(perform:) to the above group, it applies to all of the views produced by the if isLoggedIn conditional, and it executes every time isLoggedIn changes.

In my testing, I saw a different behavior, it only called onAppear once. If I understand the document correctly, the code below would print twice (and yet it doesn’t):

Group {
    Text("One")
    Text("Two")
}
.onAppear {
    print("Appear")
}

It seems that the behavior not only differs between simulator and previews, but also between different modifiers.

Aside: View Lists

Before we look at the problem, let’s consider some theory. If we look at the definition of (say) HStack, we’ll see that it’s generic over a single Content parameter that conforms to View. Looking at the type, we could say that an HStack has a single subview. But clearly we know that an HStack has multiple subviews!

The HStack receives a single type that conforms to the View protocol, but it can flatten that into a list of subviews. For example, the two texts in the group above turn into a TupleView<(Text, Text)>. The HStack can flatten the tuple view to get a list of the two subviews. A few years ago I wrote more about how SwiftUI Views are Lists.

When a flattened view list turns out to be a single item it’s called a unary view , and if it’s zero or more items, it’s a multiview . You can also read about this in Robb’s post or my own post on variadic views.

Investigating the Problem

At first, I thought the problem was with Group. But it seems to be a problem with the “root view” that renders a SwiftUI view. I believe (but haven’t verified) that ultimately, at the very root of our app, there is still some UIKit that renders our root view. If that root view is not a unary view , the behavior can be unexpected.

For example, with the code below, the root view is not unary but actually returns two views:

Group {
    Text("One")
    Text("Two")
}
.padding()
.background(.blue)

We can see the exact same behavior difference between previews and the Simulator when we replace the Group with an explicit view builder:

struct ContentView: View {
    var body: some View {
        helper
            .padding()
            .background(.blue)
    }

    @ViewBuilder var helper: some View {
        Text("One")
        Text("Two")
    }
}

To fix the differences in behavior, we can just wrap our body in a VStack. This way, the VStack is the new, stable, unary root view and SwiftUI will have no problems rendering this as expected:

VStack {
    helper
        .padding()
        .background(.blue)
}

Wrapping in a VStack works with both the view builder variant as well as the Group, which seems to confirm that Group is really just a way to get view builder syntax, nothing more.

Note: The onAppear problem still exists: if you replace the padding and background with an onAppear, it’ll still only get called once for the entire group. At least this behavior is consistent between the Simulator and previews, and between Group and view builders.

Conclusion

I think the behavior of Group (or to be more precise: applying modifiers to lists of views) is just too unreliable to use in production. Why does it differ between the Simulator and previews? Why does onAppear on a list get called once, but the background gets applied to each item?

For me, I’m avoiding Group where possible, and always choose for “stable containers” such as a stack (VStack and ZStack are my favorite, for some strange reason, HStack feels wrong). Going back to the initial example, I would write it like this:

VStack {
    if let image {
        Image(image)
    } else {
        Text("Loading…")
    }
}
.onAppear {  } /* works */

Note: all of this is tested with iOS 18.2, hopefully some of this will be fixed in the future.

SwiftUI Phase Animation "Bug"

Mon, 03 Mar 2025 00:00:00 +0100

I noticed that phase animators weren’t behaving as expected, and I initially assumed I’d found a bug in SwiftUI. It took me way too long to realize the problem here, that’s why I am writing this up. Spoiler alert: there is no bug .

I am preparing a workshop on SwiftUI Animations (this is a follow-up to our regular SwiftUI Workshop). As I went through the exercises, I created a very minimal shake animation to demo how phase animators work.

A phase animator lets you animate between multiple phases (in the example below, the initial phase is 0, the second phase is 20 and the third phase -20). It starts by displaying the view at its initial phase. When we change the trigger value, it animates to the second phase. When that animation completes, it animates to the third phase. Finally, it animates back to the initial phase. This is essentially a really nice way to run nested animations in completion handlers. In the animation closure, you get the target phase in and can choose which animation curve you want to animate towards that value.

Here’s my attempt at trying to create a shake animation with a custom timing curve for the first part of the animation. I exaggerated the curve so that it’s really clear that this doesn’t work:

struct ContentView: View {
    @State var trigger = 0
    var body: some View {
        Button("Hello") {
            trigger += 1
        }.phaseAnimator([0, 20, -20], trigger: trigger) {
            $0.offset(x: $1) // somehow always animates with the default animation
        } animation: { phase in
            switch phase {
            case 20: .linear(duration: 5)
            default: .default
            }
        }
    }
}

If you run the example above, you can even set a breakpoint and see that the linear animation gets used. What’s more, you can add a transaction { print($0.animation) } to the content closure, and you’ll see the correct animation printed out. Yet it does not animate slowly.

The problem has two causes:

SwiftUI buttons have an implicit animation going on. This happens even with a custom ButtonStyle. I haven’t verified this, but I think it animates when you depress a button (when isPressed changes back to false).
Layout modifiers such as offset are applied at the leaf nodes in the view tree (in this case, the actual button). In other words, the offset itself does not animate, but instead, the x position of the button animates.

As far as I’m aware, the button animation behavior is not documented. The layout behavior is underdocumented and could be much clearer. There are a number of solutions: the easiest is to apply a geometryGroup before the offset. This causes the offset to apply to the group as a whole, rather than being applied at the leaf views. Interestingly, the documentation of geometryGroup actually explains that position and size are set at the leaf views.

struct ContentView: View {
    @State var trigger = 0
    var body: some View {
        Button("Hello") {
            trigger += 1
        }.phaseAnimator([0, 20, -20], trigger: trigger) {
            $0
                .geometryGroup() // this now animates as a whole rather than at the leaf views
                .offset(x: $1)
        } animation: { phase in
            switch phase {
            case 20: .linear(duration: 5)
            default: .default
            }
        }
    }
}

The geometry group above now animates its frame and uses the animation it receives from the current transaction (the five second linear animation). Internally, the button animates its pressed state but that doesn’t influence the position anymore.

Alternatively, for my purposes (demoing phase animators) I could use an onTapGesture instead of a button, as I don’t need all the extra stuff that button provides (highlighting, styling and accessibility). Or use a different modifier than offset, such as rotation or scale (these don’t apply at the leaf nodes).

This is not the first time I’ve been bitten by the default button animations, and probably not the last. Hopefully writing this post will help me remember in the future.

Weeknotes № 52

Mon, 30 Dec 2024 00:00:00 +0100

Just to be consistent I’ll add the notes for this week as well. Mostly had family time and managed to put in a few longer but very cold bike rides.

We took the train to The Netherlands, the bike rides here are cold as well. I rented a gravel bike which is really nice (even though the brakes don’t really work all that well, so I’ll bring my own bike next time).

I’ve spent a bit of time on preparing upcoming workshops, we recorded another Swift Talk episode and I played around a bit with Helix. For Helix, I installed Marksman to get nice Markdown autocompletion. It supports wiki-like syntax so that I can edit my Zettelkasten notes as well (although I prefer the more integrated workflow of The Archive).

2024 in Review

Tue, 24 Dec 2024 00:00:00 +0100

This was a fun and busy year that flew by. At a personal level, a lot has happened (the oldest started school, we went on a bicycle holiday, and I started therapy again.)

Work-wise, the biggest thing is that I started a new company in addition to objc.io. This is the new home for our workshops as well as new projects.

The first project under the new company is the SwiftUI Field Guide. This is a website that tries to show how the SwiftUI layout system works by providing interactive examples. A lot of work went into it, and I’m very proud of how it turned out. I essentially reimplemented (a small part of) SwiftUI in TypeScript. It’s what I wished SwiftUI documentation would be like: way more visual and interactive. I went into all kinds of rabbit holes in order to build this. For example, just trying to implement gradients (which are used in one or two places) sent me off deep into color space land where I learned about OKlab and other things.

I gave presentations in Hamburg, Prague, Cupertino, Paris and Bologna. They focused on the SwiftUI Layout system as well as animations. For the newer presentations, I used a new tool that lets me record me typing (during preparation) and play it back smoothly (during the actual presentation) while making sure previews are directly visible. This has been a lot of fun to work on. I used that same tool in my recent videos on Bluesky and Mastodon to give one-minute overviews of SwiftUI topics.

I held workshops at companies like DKB, Rossmann, Dexcom, Etsy, Wallapop, Sketch, Atlassian, Amex and StarFinanz. The learning has been tremendous from all sides – obviously the goal of a workshop is that the attendees learn, yet I learn a lot as well. It’s been really great doing more in-person workshops this year.

Except for Cupertino I traveled everywhere by train: London, Paris, Bologna and within Germany. It felt good to do that and I was able to use a lot of that time productively (I find that much harder when traveling by car or plane).

I moved to jujutsu over the last months as my main way of interacting with Git, although I still love Retcon. Both of these make rewriting history a lot simpler. With jujutsu, even the mental model is greatly simplified compared to regular git, which really helps me. Beyond that, I haven’t used a lot of new technology: I did write a lot of TypeScript in VSCode which was okay but I still strongly prefer Swift and Xcode. As an experiment, I’m using the helix editor to write this post, I do feel it has the potential to be a vim replacement for me. One new workflow I’ve gotten used to is using the Zettelkasten note taking strategy (using The Archive).

At objc.io, we recorded weekly Swift Talk episodes and moved our office from Berlin to Fürstenberg. Our Berlin studio had water damage that the landlord wasn’t interested in fixing, and after half a year we had enough of that. For me, it also means I can actually cycle to and work from an office, which feels nice (I’ve worked from home for almost all of the last twenty years).

Out of all the code I wrote this year, maybe the Dynamic Type package has been the simplest and most useful. I’m using this package in my presentations, in our Workshop app and for a number of internal tools. It’s been pretty incredible to just have iOS-like dynamic type (including things like ScaledMetric) everywhere. During a presentation, I can increase or decrease the font size. When I’m demoing the workshop app in a conference room at a client, I can just scale things up and down where needed.

Ever since getting back from our cycling holiday I’ve had a foot injury, I think because I walked on flip-flops too much. While I am now mostly pain-free, I still have issues when running. Somewhere towards the end of summer, I switched to cycling, mostly gravel but some road cycling as well. Running has been a massive part of my identity for the last twenty years, but it’s been surprisingly easy and fun to replace it with cycling. I’m not quite sure what 2025 will look like exercise-wise. If I can keep up the cycling, I do want to do a longer bikepacking trip.

Here’s to a fun and productive 2025!

Weeknotes № 51

Mon, 23 Dec 2024 00:00:00 +0100

Last week I finished almost all preparation for the first workshop of next year. There was a weird crash in the Workshop app. This app has evolved a lot over the last few years, and I didn’t quite understand the reason it was crashing (duplicate symbols?). I did remove the last remaining static framework by changing it into a Swift package and that finally got rid of the crash.

We researched more attribute graph stuff for Swift Talk. There are six episodes already and we could easily do ten more, but not sure yet where we’ll draw the line. It’d definitely be fun to do state management, the environment, preferences, etc.

I thought more about some patterns that I’ve used over the years: defunctionalization, explicit witnesses and incremental programming systems. I also have some more ideas written down about the incremental static site generator I’d like to build. I experimented a bit with some of those topics, hopefully I’ll be able to at least write about some of that.

I created four more one-minute videos:

I’ve been thinking a bit about how to build a workflow system in Swift. This is a system that would have long-running tasks (think days or months) with discrete steps that also include user-input. For example: an email arrives, triggers a new workflow instance, some automated stuff happens but before a reply gets sent I get to review and edit it. I’d like to come up with a simple core model for describing these workflows, but it turns out to not be all that easy. I think I’ll ultimately have to go for a graph structure as I’d want forks and joins in the workflows. In writing about it just now, I realized I should start with a simpler (non-persistent) implementation to test out what the API would feel like.

I started reading “Stories Sell” by Matthew Dicks. So far it seems quite interesting.

I went for two longer gravel rides on the weekend: one was 53km and the other one 86km. It’s definitely more challenging in low temperatures, on the longer one I even got rained on quite a bit. I did bring an extra jacket and a thermos flask of tea, next time I’ll bring a spare pair of dry gloves as well. I rode some beautiful new (to me) trails.

Weeknotes № 50

Mon, 16 Dec 2024 00:00:00 +0100

Last week I again tried to not focus too much on work, and instead went to Berlin to meet friends and get my passport renewed. I also played my first theatre role in almost thirty years. The previous role was at the closing play of primary school, this time it was at the youngest’s day care.

I put out new videos last week with a focus on alignment:

I am still going strong on the Zettelkasten note taking method. My note with attribute graph questions is getting quite long, hopefully at some point I’ll be able to ask someone about it.

I read a bit about deliberate performance. In short, you can increase performance by:

Experimenting . Form hypotheses and these these out.
Estimating . How long will this take me? How big / expensive will this thing take me?
Extrapolition . How can you apply the learned things to other areas? How does this concept generalize?
Explanation Writing, teaching, etc.

It’s fun to see how we apply these in our workshops as well. We give a quick intro, let the attendees solve a solution, have them explain their solution and then try to discuss the theory or what it means in the abstract.

I read more about defunctionalization. We also wrote about this in 2019. It’s been a pattern I keep seeing everywhere: in the Elm Architecture, in TCA and while thinking about building virtual machines (you can start with a naive functional implementation of whatever it is you want to build and then use CPS + defunctionalization to build a very efficient iterative implementation).

I’ve been thinking about using the stuff I learned about the attribute graph implementation to take yet another stab at an incremental static site generator (just for fun). Not sure when I’ll have time for that.

Weeknotes № 49

Mon, 09 Dec 2024 00:00:00 +0100

Last week was more personal stuff and less work. I spent a morning teaching a zine workshop to primary school kids, which was really fun. One of our kids was sick and I had to take care of her for a day, which only left three short days of work time. I spent an evening rehearsing a short play with other parents for the day care. I think the last time I was in a play was almost thirty years ago.

Because of weather and responsibilities, I cycled indoors quite a bit (instead of in the forest). This is definitely better than running on the treadmill (which I used to do a few years ago). A lot more comfortable and not as loud.

I recorded short videos and posted them on Bluesky and Mastodon (hope to keep doing that for the rest of December):

I spent more time figuring out how the attribute graph works. At the same time, I tried porting some of GraphViz’s layout algorithm to SwiftUI.

I had a call with Nathan from Retcon. We talked about a bunch of stuff, but one quote really stuck with me: “when designing puzzles in games, the designers want people to try the wrong solution first”. I always feel anytime we make a mistake and later do it right, learning is much better. Maybe I could use this as inspiration for my teaching.

Chris Eidhof

Alt Tech Talks

Building Pancake

Self-Forking Agents

Integrating Dependencies into LLM-Assisted Projects

Food Assistant

2025

Task Identity

Adding More Properties

Update

LLMs for "Real Projects"

Agentic Coding

Easy Things You Can Do Today

Weird Things

What Doesn’t Work

You Still Need to Understand What’s Happening

Feedback Loops

Opportunities

Conclusion

Presentation: Attribute Graph

SwiftUI View Model Ownership

The init Trap

Towards a Fix

A Final Solution?

Conclusion

Updates

SwiftUI Alignment Guide Bug

Bindings

Manual Binding Problems

Conclusion

References

Why I Avoid Group

Group Variadics

Aside: View Lists

Investigating the Problem

Other Possible Problems

Conclusion

SwiftUI Phase Animation "Bug"

Weeknotes № 52

2024 in Review

Weeknotes № 51

Weeknotes № 50

Weeknotes № 49