Not Only Swift

Comment

Last week was all abuzz with news about Apple delaying the “more personalized Siri” features, and what this means for Apple.

The general consensus seems to be that Apple might have announced their own AI features ahead of time due to ~~peer pressure~~ the entire industry being in an AI mania.

In last week's Hard Fork episode, Kevin and Casey talk about another possible reason for the delays (starting around the 12:10 timestamp): the potential for prompt injections (which was originally brought up by Simon Willison). Making sure a feature that is rolled out to millions and millions of users can't be used to unknowingly attack them would definitely be a top priority reason to spend more time.

On the bright side, this gives developers more time to implement App Intents and integrate their apps with Siri.

Swift

Implementing Sign in with Apple in the watchOS Simulator

Leo demonstrates an interesting solution for a problem many watchOS developers face - the watchOS Simulator doesn't support Sign in with Apple (yet?). His approach involves creating a custom file-based authentication flow that works within the simulator environment.

I had considered a similar approach to work around the fact that Sign in with Apple was broken on the iOS Simulator for almost two years. I never found the time for it, and thankfully this is now fixed. But should it ever break again, Leo's implementation might prove useful.

SwiftUI

Effortless SwiftUI Theming

Defining a custom theme for your app is a good way to set yourself apart from the competition. Alexander has set out to implement a theming library that is flexible, yet easy to use, and follows Apple's accessibility guidelines.

I mentioned Alexander's theming library last week in a link about using DocC for creating multi-platform documentation, and the documentation is indeed a great starting point to see how easy to use this is.

Understanding structural identity in SwiftUI

SwiftUI is a declarative UI framework, which means it takes care of much of the stuff you typically have to handle yourself - like when (or when not) to update the UI.

To enable SwiftUI to efficiently re-render the UI as often as necessary, but as less as possible, it needs to understand the view hierarchy, in particular the view identity.

Natascha explains what structural identity is and how it enables SwiftUI to optimise rendering your UI. This is a key aspect to understand for building efficient SwiftUI views. If you want to dive deeper, I recommend Apple's WWDC21 sessionm Demystify SwiftUI (video, write-up)

AI and ML

Generating Blender scenes using MCP

Last week, I wrote about MCP, the Model Context Protocol.

In this short clip, Siddharth Ahuja shows the power of MCP in action - in it, we see Claude using Blender to create a 3D scene just from a couple of prompts.

One thing that has always bothered me about image generation was that, while you can prompt amazing images, you only get pixels. With MCP and a set of MCP servers for apps like Blender, Figma, Photoshop, and others, you will be able to generate scenes, designs, images, and other digital works that you can actually modify after the model has generated them. This is huge.

Code

GitHub - Aeastr/RenderMeThis: A simple SwiftUI debugging tool

The idea behind this tool is great - highlight the SwiftUI views that will be re-rendered. However, I believe it (incorrectly) shows more view updates than actually happen.

This is due to how the tool works: it provides a wrapper view (RenderDebugView) that will flash a red overlay when the view(s) it wraps are re-created.

This sounds fine, but it misses a crucial point: the fact that SwiftUI re-creates a view doesn't necessarily mean that view will also be rendered. According to Demystify SwiftUI, views will only be re-rendered if its value has changed.

Even though this tool works slightly differently than it's supposed to, it might still be useful to understand which of your views get re-created.

The best way to profile your SwiftUI code is via Instruments.

GitHub - buzap/open-symbols: SF Symbols converted from popular open source icon sets

SF Symbols are great, and I think by making a curated and well-crafted set of icons available to developers, Apple has done more for good design than most people realise.

But if you want to stand out, you might want to use a different set of icons. In previous episodes, I've talked about how to create your own custom SF Symbols - either by using the SF Symbols app, or by using a design tool like Figma.

Open Symbols takes a different approach - it's a collection of SF Symbols converted from popular open source icon sets, such as Font Awesome, Lucide, RemixIcons, or Heroicons.

Making these icons sets available as SF Symbols makes it so much easier to use them:

// Example usage with SwiftUI
Image("android")
    .font(.largeTitle)
    .foregroundColor(.blue)

// Example usage with UIKit
UIImage(named: "android")

Issue 76 17th March 2025