Not only Swift

Natalia has worked on the SwiftUI team at Apple, and now works as an independent developer and consultant, which gives her a unique perspective on SwiftUI.

In this talk, she shares 5 pitfalls you need to watch out for as a SwiftUI developer.

If you’d rather read than watch a video, check out her book on the same topic: The SwiftUI Way.

What’s the primary purpose of code reviews? Is it to find bugs or is it to steer the codebase? Martin Fowler argues that it’s the latter.

As an example, he cites a blog by a David Poll, a former Firebaser, who describes the Firebase API Council.

The Firebase API Council discusses and decides on API design and evolution. For every API change and every new API, you have to write an API proposal that will then get reviewed by a group of people who are experts on the language(s) used, the platform itself, and the product area.

The most valuable feedback from that council was never “you have a bug in this spec.” It was “this API implies a mental model that contradicts what you shipped last quarter” or “this deprecation strategy will cost more trust than the improvement is worth” or simply “a developer encountering this for the first time won’t understand what it does.”

I love reading about how people use tools to improve their workflows. Vova shares firsthand insight into his experience being the lead iOS engineer on Anytype, an open source productivity app.

One aspect that really stood out to me is this quote here.

The code that ships is the same quality it was before agents. In some areas better, because now I have way more mental energy and less resistance to fix a small bug or refactor something pesky.

From my own experience, I can say that the risk of wanting to do more in the same amount of time is pretty substantial when using agentic coding. I feel that you need to make a deliberate choice to not overload yourself with too much work.

It’s addictive though. Be careful.

I agree, on both counts.

Agentic coding not only changes how we make changes to our code base (by expressing intent rather than making granular changes), it also changes where and how we make those changes (in the agent window rather than the text editor of our IDE).

Addy argues that this moves IDEs out of the center of the developer workflow, but they’re still required - at least while agents don’t get it right 100% of the time.

What’s the right skill for my code base? And is there maybe a skill that is more powerful? Should you install skills for all the languages that you might be working on or ruthlessly eliminate the ones that are not required for the job at hand?

If these are some of the questions you are asking yourself, this article by Esther Lloyd is a must-read.

Esther discusses how she built a dynamic skills discovery agent that provides the right skills at the right time.

Local-first Mermaid editing with instant preview, saved history, presets, theme controls, and export-ready diagrams. Plus, no ads!

Portless does away with port collision on port 3000 or others by mapping ports to subdomains using a reverse proxy. Super useful for agentic workflows that use git worktrees to work in parallel.

One of the things I missed the most when I switched from Windows to macOS in 2007 was ALT-Tab window switching.

I only learned many years later that you can use command + backtick to switch between individual windows of the currently active app. But that’s not the same as ALT-Tab.

Sergio replicated ALT-Tab window switching purely in Swift.

Stitch by Google is a “vibe design” tool, allowing you to create UI designs using natural language prompts. Now there is a TypeScript SDK for it.

So now you can write code like this to generate UI designs:

import { stitch } from "@google/stitch-sdk";
 
// 1. Create a project
const project = await stitch.createProject("My First App");
 
// 2. Generate a screen
const screen = await project.generate("A simple login page");
 
// 3. Get your outputs
const htmlUrl = await screen.getHtml();
const imageUrl = await screen.getImage();
 
console.log(`HTML:  ${htmlUrl}`);
console.log(`Image: ${imageUrl}`);

I’m curious to see what people will build with this.

Here is your updated list of conferences for iOS, Swift, and AI.

The first substantial piece of software I wrote was a vocabulary trainer I named “Turbo Trainer” (fun side note: I wrote it using QuickBASIC and assembly (for the performance critical parts of the text-based windowing system), and not - like you might think TurboPascal or TurboBASIC).

At the time, I was 15 and needed something to help me learn my English, Latin, and French vocabulary. Scratching your own itch definitely helps to build something that works well.

It was the year 1989, and the internet as we know didn’t exist. We didn’t even have a dial-up modem. The only way to distribute software was mailing floppy disks to your customers, and advertising in computer magazines (which was prohibitively expensive). Or, find a shareware distributor who would do this for you.

This article explains what shareware is and how it worked.