Not only Swift

Leo Dion 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.

Defining a custom theme for your app is a good way to set yourself apart from the competition. Alexander Weiß 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.

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)

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.

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")

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

In this short clip, Sid 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.