Not only Swift

I’m currently working with one of our Google Summer of Code interns, Haibo Yang, on updating the iOS quickstart for Firebase AI Logic. We’re making some updates to achieve feature parity with the Android quickstart, and of course, we’re bringing that sweet Liquid Glass design to the app as well.

Watch this branch on the repository to follow along.

Max presents a unique approach to building customizable SwiftUI views - based on a macro. The macro, @ViewConfigurable, generates code for managing the state that holds the respective property, as well as the accessor (i.e., the view modifier) to set it.

I have to admit that, when I first started looking into building custom SwiftUI components, I used the same approach - until I discovered the SwiftUI Environment, which is how Apple implements most of their view modifiers.

Using the SwiftUI Environment allows you to define view configurations that apply to not just a single view, but an entire group of views. Check out my talk Why every SwiftUI developer should care about the Environment to learn more about this.

While it might be more canonical to use the SwiftUI Environment to make views configurable, Max has a point - the fact that view modifiers can be applied to any View makes them slightly less discoverable - you have to know they exist, or scroll a seemingly endless list of modifiers in Xcode’s code completion. I guess this particular problem is going away thanks to smarter code completion and agentic IDEs, but if you absolutely want to make sure your view modifiers only work on your views, you can do so by making them an extension on the particular view.

Filip Němeček’s article discusses the onGeometryChange modifier, which is a much cleaner alternative to GeometryReader for getting view dimensions.

This isn’t brand new, but it came in handy when I was working improving the ActionMenu component that I use in my Second Brain app. Thanks, Filip!

If you’ve been reading this newsletter for any amount of time, you probably know that I am a huge fan of the SwiftUI Environment. I would go as far and say it is one of the backbones of SwiftUI - it is what enables us to use view modifiers to customize individual SwiftUI views as well as entire groups of views.

You probably know that you can define custom environment keys to put your own values into the environment, and use them later. The most prominent example for this is @EnvironmentObject.

But you might also want to put actions in the environment. Magnus discusses how to do this safely using Swift’s callAsFunction feature, and demonstrates how to use this at the example of a situation that is common for many data-driven apps.

Definitely worth a read!

This is a fun episode of Decoder with Anysphere CEO Michael Truell. If you don’t know who Anysphere are, you’re in good company (no pun intended) - they are best known for Cursor, their agentic IDE.

They touch on many topics around vibe coding and the future of programming. For example, with coding agents now capable of generating entire apps, reviewing code becomes a real issue. Should you review every single line of code an agent produced? Or should you just approve it wholesale? Michael’s opinion is more nuanced - he thinks that in a professional setting, the truth is somewhere in the middle.

He then goes on to explain that coding agents raise the level of abstraction, allowing us to program on a higher level. Similar to how almost nobody uses assembly language to write apps these days (as compilers translate code from high-level programming languages into machine code for us), coding agents allow us to express what we want in natural language, and then translate that into code.

This is an idea I explored in my keynote at Bletchley Park a couple of weeks ago, and I am curious to see how the world of programming is going to evolve in the next coming months.

It has been … (checks notes) … about 35 years since I last wrote Assembly Language (I needed to improve the performance of a menu bar component I needed in a vocabulary training app I wrote to help me learn languages at school). And, boy, am I grateful I don’t routinely have to write any assembly language code any more.

Artur Gruchała’s article is a hands-on introduction for Swift developers (yes, everything happens inside Xcode), and walks you through the process of creating (or should I rather say, hand-crafting) a “Hello, Assembly” program (actually just 20 lines of code, not too bad).

“Why should I care”, you ask? Well, let’s be honest - you’re not going to write much Assembly code yourself. But you might end up reading some assembly when looking at some low-level crashes or even when stepping through your app’s code.

Christian Heilmann provides some excellent tips for presenting at larger conferences. While this mostly applies to conferences that record sessions, it’s useful to keep in mind for smaller conferences as well. I learned what a ‘ramp’ is, and Christian also confirmed a suspicion I had about how radio DJs manage to talk exactly as long until the lyrics of a song start.