Those Who Swift

Those Who Swift - Issue 287

Wed, 07 Oct 2026 19:46:46 GMT

Weekly note ✏️

Every release process has a ritual that lives in exactly one person’s fingers- the archive dance, the signing shuffle, the “oh, you have to flip that switch first.”

Lately, developers have been pulling those rituals into the open and handing them to scripts, command lines, and AI agents that don’t skip steps.

Which ritual would fall apart if its keeper took a week off?

If an Agent Can't Read It, It Isn't a Tool Yet

with Divya Ravi — Technical Editor

Twelve out of twenty. Then nineteen out of twenty.

That’s the number I keep coming back to from Antoine van der Lee’s RocketTrace benchmark. An AI agent given raw Instruments data found 12 real performance problems. Give it the same recording as a short list of ranked findings, and it found 19, using about a sixth of the tokens.

Same model. Same app. Same bugs.

The difference was how the tool presented the output.

We’ve spent years building Apple’s developer tools to be looked at. Instruments is gorgeous. SF Symbols is gorgeous. Xcode’s build log is, to be kind, a very long document.

That’s fine when the reader is a person.

It matters a lot more when the reader is an agent, a CI runner, or the new hire who wasn’t there when someone showed you the trick.

The four pieces in this issue make the same move from different directions.

Artem Novichkov covers the SF Symbols 27 command-line tool: search, check against your deployment target, export, and let an agent confirm a symbol exists before it writes code using it.

Daniel Saidi runs Xcode’s output through xcsift, so Claude Code sees errors, warnings, and test results instead of eleven thousand lines of compiler chatter.

Jeroen Leenarts swaps a stack of third-party build tools for plain Swift scripts that run in Xcode and Xcode Cloud.

And RocketTrace turns a trace into findings.

Different tools, same idea:

Cut the output down to the part that matters.

I don’t think everything should become a CLI. A GUI is exactly right when you’re exploring. Nobody wants to see their first flame graph as JSON.

The point is narrower: once you understand a problem, the useful output should be something you can hand to a script, a pipeline, or a model without a person translating in the middle.

Exploring needs pixels. Repeating needs text.

There’s another reason this matters, and Apple made it pretty clear this week.

The Full Disk Access update points out the risk of giving autonomous agents broad access to a Mac. Jeff Johnson’s look at Meta Muse’s first-run experience makes the same point from the user’s side.

The more we give agents, the more it matters what a tool exposes versus what an agent can reach.

A narrow interface — check this symbol, summarize this trace, filter this build — saves tokens, but it also shrinks the blast radius.

So here’s the habit I’d steal: next time you’re walking a colleague or a model through a manual step, stop and ask what the smallest useful output is, and whether the tool can produce it itself.

If it can’t, you’ve probably found your next side project.

Which step in your release process exists only in somebody’s head? Hit reply and tell me.

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Revisiting "Split Isolation"

Matt Massicotte takes another look at a pattern he once named and warned against, where a non-Sendable type has some main-actor methods and some not. Still usually a problem, but defensible during migrations or for secondary functionality.

📍Level: Advanced

withTaskCancellationShield: Swift 6.4 new feature

Omar Elsayed explains Swift 6.4's withTaskCancellationShield, which lets code finish even when its task is cancelled, but only on OS 27 and later. His workaround for older OS versions is a neat lesson in how cancellation propagates.

📍Level: Advanced

Swift Server Has Another Google

Google Cloud ships a server-side Swift SDK covering 100+ services. Fatbobman's measured take: a real milestone for the ecosystem, aimed at containers and DevOps rather than iOS apps, but not a revolution.

📍Level: Intermediate

Coding 👨‍💻

Modifier Order Is Matrix Order

Mihaela shows that SwiftUI transform modifiers compose like matrix multiplication, opposite to how Core Graphics reads, and that .offset quietly snaps to the device pixel grid first. Confirmed with pixel-level measurement, not guesswork.

📍Level: Advanced

Toolbar overflow and visibility priority on iPhone Duo

Sarun Wongpatcharapakorn covers how to choose between toolbar and tab bar on the Duo's vertical bars, consolidate overflow, and set visibility priority so essential actions survive tight space.

📍Level: Intermediate

Configuring Bazel Module Extensions with tag_class

Adin Cebic shows how Bazel’s tag_class lets users configure module extensions from MODULE.bazel, with a worked binary-download extension. One for teams who’ve outgrown Xcode-project-only builds.

📍Level: Advanced

Apple 🍏

Prepare and submit your apps for iPhone Duo

iPhone Duo reaches customers October 23. Build with Xcode 27.1 now; from April 2027, newly submitted apps must include Duo screenshots.

Updates to Full Disk Access in macOS

Apple is adding controls so users must take explicit action before granting Full Disk Access, citing the growing risk from autonomous AI agents. Relevant if your Mac app or tool asks for it.

Showcase your apps with new assets on the App Store

New product-page header and search-result assets, an App Store Connect preview across devices and Dark Mode, and an Asset Library for scheduling seasonal creative.

AI & Tooling 🤖

My Thoughts on Generative AI: October 2026]

Daniel Kennett, tired of how polarized AI talk is, encrypts his actual opinion and promises to publish the key in a year so it can be judged in hindsight. A refreshingly different answer to the discourse.

📍Level: Beginner

Design🎨

Adapting SwiftUI layouts for large Dynamic Type sizes

Natascha Fadeeva pairs dynamicTypeSize.isAccessibilitySize with AnyLayout to flip a row from horizontal to vertical at accessibility sizes while preserving child view identity and state.

📍Level: Intermediate

Community 🤝

Meta Muse Mac first run experience

Jeff Johnson documents Muse’s first launch on macOS, showing it needs explicit Full Disk Access authorization before reading Messages, and rebuts a journalist’s claim of unauthorized access. A good companion to Apple’s Full Disk Access notice.

📍Level: Intermediate

Building An Indie App Business

Sebastian Röhl's weekly indie log: syncing HabitKit across iOS and Android, automatic iCloud backups, deleting legacy database code, and juggling several AI-assisted projects at once.

📍Level: Beginner

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: You Are Valuable, Act Like It.

Sun, 04 Oct 2026 20:18:34 GMT

Hello! 👋

We’re happy to welcome Manuel Cazalla Colmenero as our guest author.

Manuel is an iOS developer working with Swift, SwiftUI, and UIKit, with hands-on experience building and maintaining production applications.

Beyond his professional work, Manuel is also an indie developer who has taken two of his own apps all the way from idea to App Store. That journey has given him practical experience beyond coding, from architecture and persistence to testing, localization, monetization, App Store review, and actually shipping a product to users.

P.S. You can follow Manuel and his iOS development journey on ⁠LinkedIn and GitHub.

Hey! 👋

Some of you know me, but for those who don’t, I’m Jacob, a husband and father of 5 kids under 10 years old, whom we homeschool. One of our kids has a rare medical condition that consumes a lot of our time, and it’s unfortunately not uncommon for us to spend weeks or months in the hospital with him.

We live out in the sticks in Wisconsin, trying to farm a bit. We’re better with animals than plants so far. We’ve had sheep, goats, and currently lots of chickens. We rest on Saturdays, spend our days at church on Sundays, and I run a Bible study on Monday nights that usually lasts until midnight.

Aside from all that, I spend much of my time helping developers make more money: I’m working on the SDKs at RevenueCat full-time.

So… I’m what you might call a “busy” guy.

Regardless, this year I've shipped 2 iOS apps (Noah Weather & Whoya) and 1 SaaS tool (BnbPhotoFactory). All are good-quality apps, and one is grossing a few thousand dollars a month.

You may wonder how I have the time to build. As you could probably guess, I don’t have much time. I have to squeeze it in, usually when I’d rather be sleeping. And many times, it’s really easy to put off working on my own apps and just get some sleep… A lot of times I do.

AI has certainly helped with velocity, but it’s not a silver bullet. There are things that require my mind and my time. I don’t want to ship slop. I’m still a craftsman, and that means I need to make time.

So how do you do that? How do you make the time?

I’m going to answer that, maybe in a more roundabout way than is typical. To give you some breadcrumbs, I want you to take away 3 things from this article:

Know your value
Cut out the noise
Make it easy to commit to

The Battle of the Mind

As a parent, time seems to fly by. My oldest is halfway to adulthood, but it feels like a month ago I was rocking her to sleep on my shoulder and changing her diapers all the time. And now, having a child with a severe medical condition, I realize how precious life is. How precious my time is. Life is not like Prince of Persia or Click, where I could rewind and undo things. I can’t go backwards and change or relive anything. When I trade my time, it’s a permanent trade. That time is gone. Forever.

So… What am I willing to trade that time for? Not much, honestly.

We cut a lot out of our lives.

We don’t watch TV or play video games anymore. We’re not on most social media platforms. We intentionally avoid the fearmongering media outlets. We aren’t willingly being ignorant, we pick and choose how and where we consume our information. We don’t allow those kinds of distractions into our lives, because we don’t want to waste our time.

We also cut out consumer debt. We spent years paying off the loans and credit cards, and cut them up. The payments on the debt nagged at my thoughts. They were stealing my peace and made it harder to be flexible with our lives. So we cut that out too. We don’t even have the desire to spend the mental energy playing the game for points. I don’t care about a few hundred extra bucks a year. The cost, my mental energy, is not worth it.

We are trying to have free minds and therefore free lives.

To get there, we had to choose that our lives were more valuable than the TV and the games. That peace of mind was more valuable than having the newest things and a credit card statement.

You may not need to go to the same lengths as we did. But what you certainly need to do is make it easy to choose. You have to do the work up front to know how valuable your life is and what your values are. It becomes easy to choose how to trade your time when you know your value. But if you don’t know the value of your time, it’s easy to allow all sorts of things to fill it.

How I Choose

When you’re as busy as I am, you don’t have much time to trade on projects. At that point, it can be discouraging. You have all kinds of ideas! And with AI, it’s a lot easier to make them reality! But you still have to prioritize what is most important. And that means, at least for me, there’s not much time to build.

If I choose to work on an idea that has potential but I’m not that fired up about it, I have a hard time committing my time to it. I also struggle to balance more than one idea at once. This is especially true if I’m excited about all of the ideas I’m trying to work on simultaneously.

So what I do is focus on just one app at a time. If there’s one that’s clearly urgent, like there’s money on the table, that one wins. But other than that, it’s whatever I’m most excited about. Apps that I want to build for ME or my family. It’s not easy to trade sleep for some random money-making idea. But it is SO EASY to trade it for an app I’m passionate about, because money is just a nice bonus.

If you’re married (or dating), I would also choose an idea your other half is interested in. Showing off what you worked on to an unimpressed audience is a total momentum killer. But showing off an app you’re both excited about fuels the flames. It works with friends too, but it’s not the same.

I also generally like to build for me first. When an app idea is solid enough that I think others would want it, I test that theory. I get it polished a bit, push it to TestFlight, invite some people, and see if it’s worth pursuing. If there’s enough interest, I’ll commit to the v1 feature set and polish, and go from there.

Wrapping It Up

So, if you’re anything like me and you don’t have much time to spend on things, here’s my advice. Take stock of what you spend your time on and evaluate whether it matches your values. Does the way you spend your time show that you value your faith, yourself, and your family? Cut out anything that competes with your values. Do the hard work now, because it’s so much easier to walk and run when you don’t have weights around your ankles. Then build from a place of excitement and passion! It’s a fun way to be.

My Apps

In the introduction, I mentioned things I’ve shipped this year outside of work. They are:

Whoya - a phone number memorization game I made for my kids.
Noah Weather - my most recent app: an encouraging weather app for Christians.
BnbPhotoFactory’s - AI image editing pipeline SaaS tool.

Those Who Swift - Issue 286

Wed, 30 Sep 2026 20:30:56 GMT

Weekly note ✏️

The iPhone Duo simulator landed in Xcode 27.1 beta, and suddenly a lot of familiar SwiftUI layout assumptions are getting tested in the same week.

The interesting one? Centered doesn’t always mean centered anymore.

Have you opened the Duo simulator yet, or are you waiting to see whether this actually becomes a real device?

Your Centered Layout Was Never as Stable as You Thought

with Divya Ravi, Technical Editor

Four people picked up the same beta this week and came at it from completely different directions.

Blake Crosley looked at what actually shipped in Xcode 27.1, the two-display simulator, the new Duo APIs, and the things that still aren’t there. Antoine van der Lee put a real SwiftUI layout through the simulator. Mick MacCallum went deep on ArrangementView, including its split and overlay modes. And Xiangyu Sun wrote the piece that stuck with me most: centered layouts, the kind we’ve been shipping for years without thinking twice, stop being centered the moment the device folds.

That’s the interesting part. Not the device itself.

A foldable phone isn’t conceptually that far from an iPad in Split View. Content gets squeezed, resized, or divided into separate regions. We’ve been dealing with versions of this problem for years.

The difference with Duo is that the failure becomes painfully literal.

On an iPad, a bad assumption about available width might leave you with an ugly but usable layout. On Duo, a bad assumption about “the center of the screen” can put a button across a physical seam or leave a modal split between two panels.

That’s not a subtle bug. It’s the kind of thing a designer can spot walking past your desk before QA even files the ticket.

What I keep coming back to after reading all four pieces is that they’re really describing the same discipline from different angles.

Crosley’s piece is about reading a beta carefully, understanding what you can actually test instead of assuming feature parity because an API exists.

Van der Lee’s is about treating new platform APIs as an enhancement to resilient layout code, not a substitute for it.

MacCallum’s is about making split and overlay behavior explicit instead of hoping GeometryReader will somehow figure it out.

And Sun’s piece gets to the underlying problem: “reserved regions” is essentially Apple’s way of acknowledging that a single content plane was always a convenient simplification. Now there’s a name for the places where that simplification breaks down.

None of this is really about foldables.

“The screen” was never actually one thing. It’s just an abstraction we’ve gotten comfortable with.

iPad multitasking chipped away at it. Dynamic Island chipped away at it again. Stage Manager did the same. Duo just makes the boundary physical.

And every time a new form factor arrives, the same two kinds of codebases show up.

There are the ones built around constraints and adaptive containers, where supporting the new shape is mostly a matter of wiring things up.

Then there are the ones where the assumption of a fixed rectangle is buried so deeply that “support the new screen” turns into rewriting half the view hierarchy under a deadline.

You don’t need a Duo roadmap item this quarter to take something from this.

The more useful question is much smaller:

Where in your codebase do you assume there is exactly one visible region, one center point, one continuous canvas?

Not because Duo will necessarily expose it.

It might never.

But the assumption was already fragile. Every new form factor Apple ships is just another way of finding out where we’ve made that assumption.

Hit reply and tell me: have you actually opened the Duo simulator yet, or are you in the “let’s see if this becomes a real SKU first” camp?

I’m genuinely curious which way you’re leaning, especially this close to launch.

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Using Swift's 'some' keyword beyond SwiftUI

John Sundell looks past the SwiftUI use case to show how `some` simplifies function parameters, avoids type erasure, and builds cleaner genericAPIs, all while keeping compile-time type resolution.

📍Level: Intermediate

Deployment Target Conditional Compilation

A new Swift Evolution proposal, now in review, that lets code adapt directly to the minimum deployment target instead of relying on runtime #avialable checks alone, a cleaner path for apps supporting multiple OS versions.

📍Level: Advanced

Task Identity

A proposal for a stable `Task.ID` type, so concurrent tasks can be correlated across logs and tracing tools without the overhead of wrapping them just to get an identifier, currently in review, with real debate over misuse-as-a-side-channel concerns.

📍Level: Advanced

Coding 👨‍💻

Stop Sleeping: Deterministic Tests for Concurrent Swift Code

Michal Raška shows how to use a “test spy” to make unstructured concurrent Swift code deterministic without sprinkling sleep() through your tests. A practical solution to a very real Swift 6 testing problem.

📍Level: Advanced

What minimumScaleFactor trades away in SwiftUI

Mike Salari runs 500 measurements across 100 conditions to show how minimumScaleFactor can quietly undermine visual hierarchy when neighboring labels scale independently.

📍Level: Advanced

Real-World iOS Development

Avi Tsadok's new book (Apress/Springer) on the practices real teams actually use in production, architecture and design patterns, testing, CI/CD, navigation, data persistence, team workflows, and a closing chapter on adapting to the AI era.

📍Level: Intermediate

Apple 🍏

Build for iPhone Duo with new resources

Apple’s official Duo resources, covering the Xcode 27.1 beta, design kits, and optimization workshops, the primary source behind much of this week’s Duo coverage.

AI & Tooling 🤖

Making Xcode and agents share incremental builds

Serg Dort tackles a surprisingly annoying workflow problem: switching between Xcode and AI coding agents can throw away incremental build work. This shows how to get both workflows sharing the same build outputs.

📍Level: Advanced

This Week in Swift x AI

Natasha The Robot rounds up recent Swift and iOS AI developments, from SwiftFairy’s launch and JEV decision models to what “in-app computer use on iPhone Duo” could mean for developers

📍Level: Intermediate

Design 🎨

McKinley: The SF Symbols Editor Apple Never Built

Lou Plummer gives McKinley, a new Mac app for generating and previewing SF Symbols weights and scales, a hands-on test using Apple’s own rendering engine. The review covers both what works and where the app still falls short.

📍Level: Beginner

Tutorials📒

Swipe Actions Beyond Lists in SwiftUI

Gabriel Theodoropoulos walks through swipeActionsContainer, showing how to bring swipe actions to grid layouts rather than limiting them to lists. Clear, practical, and a welcome return after a long rest.

📍Level: Intermediate

SwiftUI Charts: Dynamic Masking

Anton Gubarenko builds a TradingView-style chart where the selected range stays at full opacity while the rest fades back, using layered Swift Charts masking instead of rebuilding the dataset.

📍Level: Intermediate

Video 🎥

This Filename Breaks iOS, And That's Boring Now

Bryce Bostwick digs into a real iOS rendering bug involving filenames such as “highjump.png” and Apple’s IBHashImageName function, then turns it into a broader question: what happens to deep technical writeups when an LLM can solve the bug for you?

📍Level: Intermediate

Community 🤝

Little Memory 2.0: Moving 15 years of memories off my servers

Ivan Tse rebuilt his decade-old journaling app around offline-first storage and iCloud sync, moving sensitive diary data off his own servers. A thoughtful indie-dev story about architecture, privacy, and what happens when you rethink an old product.

📍Level: Intermediate

Shipaton at Week Six: Buildhorn Has Officially Been Submitted to Apple

The latest entry in Darryl Bayliss’s Shipaton devlog follows Buildhorn through App Store submission, including a performance issue caused by AI-generated code in widget syncing.

📍Level: Beginner

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: Opening In-App Search from Siri with App Intents in iOS 27

Sun, 27 Sep 2026 20:01:22 GMT

Hello! 👋

Today, I’m happy to say we have Ildar Zalyalov as our guest author. He’s a Lead Software Engineer at H&M Group with more than 11 years of professional experience in iOS development.

His journey spans the evolution from Objective-C to Swift, SwiftUI, modern concurrency, and AI-assisted development. Beyond building products, Ildar actively supports the iOS community through teaching and mock interviews, helping developers strengthen both their technical knowledge and interview skills.

P.S. You can check out Ildar’s work on LinkedIn and YouTube.

A schema gives an intent meaning that the system already understands. Instead of exposing an arbitrary action that happens to accept a search string, for example, we can describe it as an actual search operation.

In this post, we’ll look at why system schemas are useful, and implement an in-app search intent that can open an app directly on its own search results.

Prefer a System Schema When One Fits

Suppose we’re building a recipe app and want to expose its search functionality to Siri.

We could start with a custom App Intent:

import AppIntents

struct SearchRecipesIntent: AppIntent {
    static let title: LocalizedStringResource = "Search Recipes"

    @Parameter(title: "Query")
    var query: String

    func perform() async throws -> some IntentResult {
        // Pass the query to the app.
        return .result()
    }
}

This is a valid intent. The system sees an action called Search Recipes with a string parameter.

But search isn’t really specific to our app. It’s an operation Siri already understands.

App Schemas describe common actions using structures known to the system. Apple provides schemas across domains such as messages, mail, photos, media, and system functionality.

When one accurately represents what our app does, it’s usually better to adopt that schema than to create another custom representation of the same operation.

For in-app search, we can use the system search schema:

import AppIntents

@available(iOS 27, *)
@AppIntent(schema: .system.searchInApp)
struct SearchRecipesIntent: ShowInAppSearchResultsIntent {
    static var supportedModes: IntentModes { .foreground }

    static var allowedExecutionTargets: IntentExecutionTargets {
        .main
    }

    static let searchScopes: [StringSearchScope] = [
        .general
    ]

    @Parameter
    var criteria: StringSearchCriteria

    func perform() async throws -> some IntentResult {
        let query = criteria.term

        // Open the app's search experience.
        return .result()
    }
}

The difference is more than syntax.

With the custom intent, query is simply a parameter we defined. With ShowInAppSearchResultsIntent, the intent adopts the system’s search contract. The system provides StringSearchCriteria, and its term property contains the string to search for.

Apple recommends StringSearchCriteria for ordinary text-based searches, together with the .general search scope for general app content.

StringSearchScope.general also tells the system that the app provides general search functionality. Apple notes that this may participate in system-wide universal search behavior, depending on the app and its content.

Running the Intent in the App

A search intent is unusual in one important way: performing the action isn’t enough. We want to show something in our interface.

ShowInAppSearchResultsIntent is specifically intended to display search results in the app. Apple also notes that this kind of intent needs to run from the app rather than an App Intents extension.

For that reason, I prefer making the execution requirements explicit:

static var supportedModes: IntentModes {
    .foreground
}

static var allowedExecutionTargets: IntentExecutionTargets {
    .main
}

ShowInAppSearchResultsIntent already provides a foreground-capable default, so declaring supportedModes isn’t strictly necessary in every implementation.

I still find it useful here because it documents an important property of the intent: its result is an app UI transition, not a background operation.

Restricting the execution target to .main is more significant when App Intents code lives in a shared framework or the application also has App Intents or Widget extensions. It makes sure this particular action executes in the main app process.

Don’t Assume the Term is Useful

StringSearchCriteria.term is a non-optional string, but that doesn’t necessarily mean it contains a useful search query.

A small validation step makes the intent more robust:

static func normalizedTerm(_ term: String) -> String? {
    let trimmed = term.trimmingCharacters(
        in: .whitespacesAndNewlines
    )

    return trimmed.isEmpty ? nil : trimmed
}

We can use it from perform():

@MainActor
func perform() async throws -> some IntentResult {
    guard let searchTerm = Self.normalizedTerm(criteria.term) else {
        throw $criteria.needsValueError(
            "What do you want to search for?"
        )
    }

    // Open search for `searchTerm`.

    return .result()
}

Throwing needsValueError is more useful than silently doing nothing. It tells the App Intents system that the parameter doesn’t contain enough information to continue and gives it a chance to ask the user for a value.

For a request such as: “Show me pasta recipes in RecipeBox.” the value we eventually care about is just:

"pasta"

The interesting part is what we do with it next.

Hand the Search Off to the App

A small demo could navigate directly from perform().

In a real application, that becomes fragile quickly.

The intent may run while the application is already visible, or it may cause a cold launch. In the second case, perform()can happen before the root view hierarchy is ready to navigate.

Instead of making the intent know about view controllers or SwiftUI navigation, we can hand the action over to application-level routing code.

Here’s a small version of that pattern:

import Observation

enum Destination: Hashable {
    case search(String)
}

@MainActor
@Observable
final class AppNavigation {
    var path: [Destination] = []

    private var pendingSearch: String?
    private var isUIReady = false

    func enqueueSearch(_ query: String) {
        pendingSearch = query
        replayPendingSearchIfPossible()
    }

    func markUIReady() {
        isUIReady = true
        replayPendingSearchIfPossible()
    }

    private func replayPendingSearchIfPossible() {
        guard
            isUIReady,
            let query = pendingSearch
        else {
            return
        }

        pendingSearch = nil
        path.append(.search(query))
    }
}

The distinction between enqueueSearch() and actually changing the navigation path is intentional.

If the UI already exists, the queued search is handled immediately.

If the app is still launching, the request remains pending until the UI reports that it’s ready.

The intent itself stays small:

import AppIntents

@available(iOS 27, *)
@AppIntent(schema: .system.searchInApp)
struct SearchRecipesIntent: ShowInAppSearchResultsIntent {
    static var supportedModes: IntentModes { .foreground }

    static var allowedExecutionTargets: IntentExecutionTargets {
        .main
    }

    static let searchScopes: [StringSearchScope] = [
        .general
    ]

    @Parameter
    var criteria: StringSearchCriteria

    @Dependency
    private var navigation: AppNavigation

    @MainActor
    func perform() async throws -> some IntentResult {
        guard let searchTerm = Self.normalizedTerm(criteria.term) else {
            throw $criteria.needsValueError(
                "What do you want to search for?"
            )
        }

        navigation.enqueueSearch(searchTerm)

        return .result()
    }

    static func normalizedTerm(_ term: String) -> String? {
        let trimmed = term.trimmingCharacters(
            in: .whitespacesAndNewlines
        )

        return trimmed.isEmpty ? nil : trimmed
    }
}

Notice what isn’t here.

The intent doesn’t push a view controller, mutate a tab bar, construct a SwiftUI destination, or perform the search itself.

It only translates a system intent into an application action.

Handling Warm and Cold Launches

We can register the same navigation object with App Intents and SwiftUI:

import AppIntents
import SwiftUI

@main
struct RecipeBoxApp: App {
    @State private var navigation: AppNavigation

    init() {
        let navigation = AppNavigation()

        _navigation = State(initialValue: navigation)

        AppDependencyManager.shared.add(
            dependency: navigation
        )
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(navigation)
        }
    }
}

And let the root UI announce when navigation is available:

import SwiftUI

struct ContentView: View {
    @Environment(AppNavigation.self)
    private var navigation

    var body: some View {
        @Bindable var navigation = navigation

        NavigationStack(path: $navigation.path) {
            List {
                Text("Spaghetti Carbonara")
                Text("Pasta Primavera")
                Text("Tomato Soup")
                Text("Margherita Pizza")
            }
            .navigationTitle("Recipes")
            .navigationDestination(for: Destination.self) { destination in
                switch destination {
                case .search(let query):
                    SearchResultsView(query: query)
                }
            }
        }
        .task {
            navigation.markUIReady()
        }
    }
}

For a warm launch, isUIReady is already true and enqueueSearch() immediately adds the search destination.

For a cold launch, the intent stores the query first. Once ContentView appears, markUIReady() replays the pending action.

This mirrors a useful pattern in larger applications, where intents, deep links, push notifications, widgets, and other external entry points all feed the same action or navigation coordinator.

If an app already has such an abstraction, the intent should use it rather than introducing a new routing system specifically for Siri.

Displaying the Results

Our result screen doesn’t need to know where the query came from:

import SwiftUI

struct SearchResultsView: View {
    @State private var query: String

    private let recipes = [
        "Spaghetti Carbonara",
        "Pasta Primavera",
        "Tomato Soup",
        "Margherita Pizza"
    ]

    init(query: String) {
        _query = State(initialValue: query)
    }

    private var results: [String] {
        recipes.filter {
            $0.localizedCaseInsensitiveContains(query)
        }
    }

    var body: some View {
        List(results, id: \.self) { recipe in
            Text(recipe)
        }
        .navigationTitle("Search")
        .searchable(
            text: $query,
            prompt: "Search recipes"
        )
    }
}

The same screen could have been opened from the app itself, from a deep link, or from Siri.

That’s a useful boundary.

Siri provides the meaning of the external request. The intent translates it into an app action. From that point on, the existing application architecture takes over.

In-app Search and App Entities Solve Different Problems

searchInApp doesn’t replace App Entities.

An AppEntity represents an identifiable object from our app. A recipe app could expose individual recipes as RecipeEntity values, allowing Siri and other system experiences to resolve or operate on a particular recipe.

In-app search serves a different purpose.

Instead of requiring the system to resolve one entity, ShowInAppSearchResultsIntent gives the search criteria back to the app and lets the app display its own results.

That works particularly well when the search experience includes server-side content, filters, ranking, recommendations, or presentation logic we already maintain ourselves.

Apple also notes that apps can use this search integration without requiring every searchable entity to be indexed first.

Keep System Intents Thin

The most useful part of the implementation isn’t the amount of Siri-specific code we added.

It’s how little we needed.

The final intent essentially does three things:

guard let term = Self.normalizedTerm(criteria.term) else {
    throw $criteria.needsValueError(
        "What do you want to search for?"
    )
}

navigation.enqueueSearch(term)

return .result()

The system schema describes what the action means. StringSearchCriteria carries the query. The application’s existing routing and search layers decide what happens next.

This is a good pattern beyond search as well. Before creating a custom App Intent, it’s worth checking whether an App Schema already describes the operation. If it does, we can use the system’s vocabulary and keep the intent itself as a small adapter into the application.

For in-app search, that adapter is enough to take a request from Siri all the way to a native search results screen.

References

Those Who Swift - Issue 285

Wed, 23 Sep 2026 21:06:47 GMT

Weekly note ✏️

Swift 6.4 shipped this week, but the release itself wasn’t what caught my attention.

Three completely unrelated posts showed up in my feed within a few days of each other. One was about Swift’s debug information, another about figuring out where all those extra MB in your app actually went, and another about tracking down mysterious SwiftUI performance problems.

Different problems. Same frustration:

Something is wrong, but you can’t see what’s happening.

So this week’s issue is about debuggability — and why it deserves more attention than it usually gets.

I’d love to hear from you, too: what’s the last bug that took way longer than it should have because you couldn’t see what was actually happening? Hit reply and tell me.

Debuggability Is a Feature, Not an Afterthought

with Divya Ravi — Technical Editor

Three things landed in my feed within about a week of each other, and the authors weren’t connected.

Swift 6.4 brought some quieter improvements to how debug information keeps track of where code actually came from. Jacob Bartlett built a browser-based tool that can open up an .ipa and show you where your app size is going. And Natalia Panferova found a useful Xcode launch argument for figuring out why certain ForEach patterns can hurt SwiftUI performance.

Different problems. Different tools.

But all three have the same basic idea:

You can’t fix what you can’t see.

That sounds obvious. In practice, it’s one of those things that gets pushed aside surprisingly easily.

Nobody puts “better debugging information” on the roadmap when there’s a feature to ship. Nobody gets excited about spending a sprint figuring out why a binary grew by 40 MB. And “let’s make this performance problem easier to diagnose” rarely beats a customer-facing feature in a planning meeting.

Usually, someone just gets annoyed enough to investigate it.

That’s what happened with these pieces. Someone got tired of guessing, found a way to make the problem visible, and then shared it.

I think about this a lot when working in an older codebase.

When you’re new to a system, the hardest part usually isn’t understanding the business logic. It’s figuring out why the system behaves the way it does.

Why is this build so slow?

Why did the binary suddenly get bigger?

Why is this view rendering again?

Which module did this code actually come from?

Why did changing something three layers away suddenly fix the problem?

The answers might all be there. The problem is that the system doesn’t always make them easy to see.

That’s why I think good debugging tools are a form of documentation.

Normal documentation tells you how the system is supposed to work.

Good debugging information tells you what the system is actually doing.

And unlike a wiki page, that information can stay pretty close to reality because it’s coming directly from the system.

There’s another reason this feels especially relevant right now.

We’re generating more code than ever with AI. Agents can write functions, refactor code, add tests, work across branches, and make surprisingly large changes very quickly.

But when something goes wrong, we still need to understand why.

Is the generated code slower?

Did it make the binary larger?

Did it introduce an unexpected rendering path?

Did an agent change something three layers down?

The more code we produce, the more important it becomes to have good ways of looking inside that code.

And none of the interesting examples this week needed an AI agent or a shiny new framework.

They started with a much simpler idea:

If you can’t see the problem, make it visible.

So here’s something I’m going to keep in mind when planning engineering work.

If there’s one thing that has made us guess over and over again — build performance, a recurring crash, view rendering, binary size, whatever it is — maybe “make this easier to understand” deserves to be an actual engineering task.

Not something we keep saying we’ll get to later.

Because sometimes the fastest way to fix the next problem is to make the current one easier to see.

And if you have a debugging mystery that has eaten way too much of your time, hit reply and tell me about it. I’m collecting stories for a future issue.

I have a feeling we’re all dealing with at least one.

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Connecting two iOS simulators over BLE

Two iOS Simulators talking to each other over Bluetooth LE.

Yes, really.

Kyle Browning shows how to connect two simulator instances so you can test things like pairing, proximity, and handoff without needing two physical devices sitting on your desk.

A clever trick for a problem that usually means reaching for another phone.

📍Level: Advanced

Coding 👨‍💻

From pbxproj to xcproj: Xcode Project Configuration Gets a JSON Format

The familiar .pbxproj file is getting a new counterpart: project.xcproj, a JSON-based project format.

The obvious benefit is fewer merge conflicts and easier parsing.

The more interesting question is what this means for tooling — especially now that AI agents are increasingly reading and modifying project configuration directly.

📍Level: Intermediate

Build Siri experiences across apps, Part 1: Onscreen Awareness

Siri understanding “this” or “that” sounds simple until you think about what the system actually needs to know.

Sarun walks through Siri’s onscreen awareness and how views can be connected to App Entities using NSUserActivity or view annotations.

This is the first part of a larger series, so there’s more to come.

📍Level: Intermediate

isPictureInPicturePossible was true and PiP still wouldn’t start

Here’s a familiar kind of iOS bug:

The API says everything is fine.

It still doesn’t work.

McMizzle walks through the Picture-in-Picture issue from the initial symptom to the actual cause, including the repro and fix.

These are some of my favorite debugging posts because the final answer is usually something you would never guess from the original symptom.

📍Level: Advanced

Backporting SwiftUI APIs

A new SwiftUI API looks great. Your deployment target says, “Not so fast.”

Majid Jabrayilov walks through two clean ways to backport newer SwiftUI APIs: a dedicated Backport namespace or availability-annotated methods that can eventually be removed when your minimum iOS version catches up.

The second approach has a particularly nice property: you can grep for the old code later and know exactly what can go.

📍Level: Intermediate

Apple 🍏

Hello Developer: September 2026

Apple’s September roundup is here, with the latest Apple Event recap, new App Store Connect analytics videos, the Apple Intelligence Group Lab from WWDC26, Cupertino developer events, and documentation updates across Core Spotlight, Safari, SwiftUI, and Metal.

A good monthly skim if you want to know what’s changed without digging through everything yourself.

AI & Tooling 🤖

Fun with AI

Sarah Reichelt writes about using Claude during a major web-development redesign — but the interesting part isn’t just what AI helped with.

It’s where she drew the line.

She was happy to use AI for parts of the technical work, while keeping her actual writing firmly human.

That feels increasingly relevant as AI gets better at touching more parts of our work. Not everything needs to be automated just because it can be.

📍Level: Beginner

My terminal-native setup for parallel coding agents

Running several coding agents at once sounds great.

Until you have three terminals open and no idea which agent changed what.

Igor Kulman shares the tmux + worktree setup he uses to run multiple agents without losing track of them.

It fits nicely with this week’s theme too: parallel agents are useful, but only if you can still see what’s going on.

📍Level: Intermediate

Design 🎨

How Klemens Strasser prioritized inclusivity with Art of Fauna

Klemens Strasser’s Apple Design Award-winning puzzle game Art of Fauna was built around vintage animal illustrations, but there’s more to the story than the visual design.

The game was designed with accessibility in mind and tested with Screen Curtain for blind and low-vision players.

Even better, 20% of the proceeds goes toward wildlife conservation.

It’s a nice example of accessibility being part of the product itself rather than something added at the end.

📍Level: Intermediate

Tutorials📒

Parameterized tests and test organization with Swift Testing

If your tests are starting to look like the same test copied five times with different inputs, parameterized tests are probably worth a look.

Natascha Fadeeva walks through @Test(arguments:), @Suite, and a cleaner way to organize related Swift Testing cases.

Simple idea. Much less test duplication.

📍Level: Intermediate

Compressing images and PDFs from the Finder context menu

A tiny automation, but a useful one.

Daniel Saidi shows how to add an Automator workflow to Finder so you can compress images and PDFs directly from the right-click menu.

Not everything needs to be a massive automation project. Sometimes the best ones are the little things you use every week.

📍Level: Beginner

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: Being a Good Developer Isn’t Enough to Build Your Own Product

Sun, 20 Sep 2026 20:30:41 GMT

Hello! 👋

In today’s issue, Aliaksandra Asichka is sharing her knowledge behind indie development.

She’s an AI Engineer and iOS Developer who combines artificial intelligence with mobile development to turn ideas into real products. Aliaksandra experiments with new technologies, builds her own projects, and shares practical discoveries from her journey with the developer community.

Is it enough to be a good dev to ship a product?

P.S. You can check out Aliaksandra’s work on LinkedIn.

As developers, we are used to thinking in terms of solutions.

There is a problem. We understand the technology. We design the architecture, choose the tools, write the code, fix the bugs, ship the feature.

So when a developer decides to build their own product, the natural assumption is that the hardest part will be building it.

I thought so too.

After working on my own iOS product, MirrorFit, I realised that writing the code was probably the most predictable part of the entire journey.

The much harder questions were:

Who actually needs this?
What do they need it for?
Will they come back?
How do I reach them?
And what should I change when the market doesn’t behave the way I expected?

These are questions engineering skills don’t necessarily prepare you for.

It Started With Technology — but Technology Wasn’t the Product

MirrorFit started with an idea between me and my co-founder.

The original idea was technically interesting: use the camera and face tracking to recognise facial movements and turn them into exercises.

I had been practising face fitness myself for a couple of years.

So I didn’t just see a piece of technology that could track a face. I could see how it could actually be used.

I started thinking about which exercises could realistically be tracked, how they could be performed in front of a camera, and how computer vision could turn something that was traditionally a set of instructions into an interactive experience.

That was the moment when the technology became a product idea.

And that experience taught me something I still consider important:

Technology is rarely the product by itself.

As technical people, we are naturally attracted to interesting technology. A new model, a difficult computer vision problem, an unusual architecture, a new framework — these things are fun to build.

But the fact that something is technically interesting doesn’t mean that people need it.

The first question shouldn’t always be:

What can I build with this technology?

Sometimes it should be:

Who has a problem that this technology can solve better?

The Technical Trap: Making the Product Better Instead of Getting It Into People’s Hands

Our next mistake was much more familiar.

We spent time improving the product before launch.

The design wasn’t quite right. The content wasn’t quite ready. There were things we wanted to polish. We wanted the product to feel complete.

Meanwhile, the market was moving.

Someone released a similar product before we did.

And, as if that wasn’t enough, the name we had chosen was taken by someone else for another fitness-related product.

That was an unpleasant lesson in timing.

While we were thinking about how to make our product better, someone else was already shipping.

Looking back, I would launch the MVP much earlier.

Not because the first version would have been better, but because it would have given us something much more valuable than another polished feature: real information.

A product sitting in development gives you assumptions.

A product in the hands of users gives you evidence.

The Audience Became More Important Than the Feature Set

Our first testers were friends, people from women’s communities, and readers from Threads.

Eventually, I collected around 100 people in TestFlight.

But I wasn’t just looking for people to click through the app.

Even while we were developing it, I was asking questions:

Do you know what face fitness is?
Which face fitness bloggers do you follow?
Have you taken any courses?
How much time would you realistically spend on a facial workout?
What would make you use an app like this regularly?

These conversations taught me more than I expected.

And surprisingly, the most useful research wasn’t a sophisticated framework or a spreadsheet.

It was talking to people.

Personal conversations helped me understand what people actually meant, rather than what I assumed they meant.

I also became a very active user of my own product. I tested it after practically every deployment.

At some point, I was completely immersed in it.

That was useful because I could immediately feel when something was inconvenient or didn’t make sense.

But it also created a danger.

When you build something yourself, it is very easy to confuse your own understanding of the product with the market’s understanding of the product.

Those are not the same thing.

The Android Request Was More Than an Android Request

One of the recurring pieces of feedback was surprisingly simple:

“When will you have Android?”

We had built an iOS application, and our audience kept reminding us that the market was bigger than the platform we had chosen.

Another recurring request was localisation.

These requests were uncomfortable because they were not really about features we could simply add to the backlog.

They exposed a bigger question:

Who are we actually building this for, and what prevents them from using it?

That is an important distinction.

User feedback doesn’t always mean that you should blindly implement whatever users request.

But every repeated request is a signal.

The job is to understand what is behind it.

The Painful Part: Accepting who the Product Was Actually For

One of the decisions that took the longest to accept was our target audience.

Initially, we wanted MirrorFit to work for both women and men.

It sounded reasonable.

Why make a face fitness product specifically for women?

Men can have the same interest in their appearance. Men can have wrinkles. Men can care about their skin and face.

And men actually helped us during testing. Around 5% of our testers were men, and their feedback was useful.

But testing also showed something else.

Trying the product and having a reason to keep using it are two different things.

The long-term motivation was much stronger among women.

The problem wasn’t that our competitors had somehow forgotten that men existed.

If almost every product in the category was positioning itself primarily toward women, perhaps there was a reason.

We had been looking at the market through the lens of what we wanted the product to be.

Eventually, we had to take off the rose-coloured glasses.

We didn’t fundamentally change the concept.

We changed our understanding of who was most likely to need it.

And that distinction matters.

Sometimes a pivot isn’t abandoning your original idea. Sometimes it is understanding your original idea more clearly.

Changing the Design Hurt more than Changing the Positioning

There was another part of the process that was surprisingly difficult for me: the design.

If you decide that you’re building a product primarily for women, the product needs to look and feel like something your audience actually wants to use.

That sounds obvious.

It wasn’t obvious while we were building it.

As a developer, I naturally wanted the functionality to be right first.

If the tracking worked, the exercises worked, the flow worked — that felt like progress.

But users don’t experience your app as a technical achievement.

They experience it as a product.

They see the visual language, the content, the onboarding, the tone, the exercises, the value proposition.

And then they decide whether they want to spend their time with it.

Changing the design meant letting go of something we had already spent time creating.

That was painful precisely because I liked the product we had.

But liking what you’ve built is not the same as knowing that the market likes it.

Then Came the App Store Reality Check

At some point, I caught myself thinking:

Why isn’t the App Store promoting us?

We had built the product. We had testers. We had launched.

Where was the growth?

The number that eventually stood out to me was 91 downloads.

On paper, 91 downloads is not an impressive App Store success story.

But I started looking at it differently.

Those 91 downloads didn’t appear because I wrote good Swift code.

They happened because I had built something, launched it, talked about it, created content, found people, explained the product, fixed it, shipped it again and kept trying.

And I realised:

91 downloads were actually my achievement.

That sounds small when you compare it with successful apps.

But when you build your first product, you quickly discover that every number has a story behind it.

One download means someone noticed you.

One tester means someone gave you their time.

One piece of feedback means someone cared enough to tell you what they thought.

And when the numbers are small, you don’t have the luxury of hiding behind dashboards.

You have to understand where every user came from.

Once It’s Your Product, You’re Not Just the Developer

This was probably the biggest mindset change for me.

When you work as a developer, you can specialise.

You can be responsible for iOS while someone else handles product.

Someone else researches users.

Someone else writes copy.

Someone else runs marketing.

Someone else looks at acquisition.

Someone else worries about positioning.

When it’s your own product, there is no “someone else”.

You are the developer.

But you’re also the product manager.

You’re the marketer.

You’re doing user research.

You’re looking at analytics.

You’re thinking about design.

You’re answering users.

You’re deciding what to build next.

And sometimes you’re staring at the App Store wondering why nobody is downloading the thing you spent months building.

What I Would Do Differently

If I started MirrorFit again, I would do three things differently.

1. Launch the MVP Earlier

Not when everything feels finished.

Earlier.

The market is a much better source of information than another month of internal polishing.

2. Start Marketing Earlier

I used to think marketing was something that came after the product.

Now I see it as part of product development.

You need to know whether you can reach the people you’re building for.

You need to understand what language makes them stop scrolling.

You need to know what they think the product is before you can know whether your positioning works.

3. Get Comfortable Changing Your Mind

This is probably the hardest one.

When you’ve built something yourself, you’re emotionally attached to it.

You’ve spent evenings on it.

You’ve solved technical problems.

You’ve made decisions.

You’ve imagined what it could become.

Then someone tells you they want something different.

Your first reaction is often:

But that’s not what we wanted to build.

Sometimes that’s exactly when you need to listen.

Should You Build Alone?

Building your own product also taught me something that has nothing to do with technology.

It is hard.

Really hard.

Not because there is always too much work, but because there are periods when nothing seems to happen.

You can have a period where everything moves forward and you feel that the product is finally taking off.

Then you can have a period where the numbers don’t move, marketing doesn’t work, and you start questioning whether any of it makes sense.

I don’t think building alone is impossible.

But I don’t think it’s for everyone either.

Having a co-founder or even a friend who genuinely supports you can make a huge difference.

The useful thing about having another person is not only dividing the workload.

Sometimes you simply need someone who is having a good day when you’re having a bad one.

If you’re building with someone, your periods of doubt may not happen at exactly the same time.

And that can be enough to keep moving.

The Lesson I Actually Took from Building a Product

I started this project because I wanted to experience both sides of the process: being a developer and being an entrepreneur.

I wanted to release my first application, understand what happens beyond writing code, and see what it actually takes to put a product on the App Store.

I got that experience.

But I also learned that there isn’t a perfect formula for what to do first.

You can’t only listen to yourself.

You can’t only listen to the market.

If you only listen to yourself, you can spend months building something technically impressive that nobody needs.

If you only listen to the market, you can end up changing your product every time somebody asks for a new feature.

The real skill is finding the balance.

Listen to yourself enough to have a vision.
Listen to the market enough to challenge your assumptions.

And if you’re thinking about building your own product, I would start with something much less exciting than opening your IDE.

Study your competitors.

If you can’t find any, don’t automatically assume you’ve discovered an untouched opportunity. Ask yourself whether you’re solving a problem people actually have.

If competitors do exist, don’t be discouraged by them. Ask yourself how you can create more value.

Find a co-founder, a friend, or someone who can support you through the inevitable ups and downs.

And most importantly:

Don’t be afraid to change the idea.

A pivot doesn’t necessarily mean that the original idea was bad.

Sometimes it means you’ve finally learned enough about the market to build the version that has a chance to matter.

Those Who Swift - Issue 284

Thu, 17 Sep 2026 06:08:23 GMT

Weekly note ✏️

Apple announced a foldable iPhone this week and gave developers about six weeks before it ships. This issue looks at what that means for iOS developers: what we can safely work on now, what’s still uncertain, and where it may make sense to wait.

Are you starting the refactor now, or waiting for Xcode 27.1?

Shipping for Hardware You Can't Fully Test Yet

with Divya Ravi — Technical Editor

Apple announced the foldable iPhone on September 9 and gave developers about six weeks before it reaches customers. The interesting part isn’t just learning the new APIs. It’s figuring out what’s safe to change while the platform is still evolving.

It’s easy to treat this as an API-learning exercise: learn the new size classes, reserved regions, ArrangementViews, and start updating layouts. But the harder part is that we still don’t know everything. Some APIs are still coming through the Xcode 27.1 beta, and developers haven’t had real hardware to validate how apps behave across different fold positions.

So the real question is: how much should you build now?

I’ve made both mistakes. Earlier in my career, I rebuilt a navigation layer around a beta API that changed significantly before GM. That meant weeks of rework. I’ve also waited too long on a new platform capability and ended up playing catch-up after launch.

For iPhone Duo, I’d split the work into two buckets.

The safe stuff: move away from orientation checks, use size classes properly, and look for hardcoded screen dimensions or aspect-ratio assumptions. None of this is really foldable-specific. It’s good iOS engineering that the new form factor makes more important.

The uncertain stuff: anything that depends on the exact behavior of the hinge, fold positions, or APIs that are still changing. That’s where I’d wait. Building against a stable API is a one-time cost. Building against something that changes every beta can mean repeated rework.

There’s a broader lesson here too. Platforms are never really finished; they just usually feel finished because we don’t see the seams. A new form factor makes those seams obvious.

For me, the approach is simple: make the changes that are clearly correct today, and keep the hardware-specific pieces flexible until we know more.

What are you doing—starting now, or waiting for Xcode 27.1?

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

What Apple's September 2026 Event Means for Developers

A broader look at Apple’s September announcements, including the A20 Pro, on-device AI, AirPods 5, and the new Watch hardware.

📍Level: Beginner

Native is now the future of mobile at Shopify

Shopify explains its move from React Native back to native Swift and Kotlin. The interesting part is the economics: AI coding tools have changed how the team thinks about maintaining native codebases.

Not directly related to iPhone Duo, but definitely worth reading if you’re thinking about where AI-assisted development is taking mobile engineering.

📍Level: Beginner

Coding 👨‍💻

When Intuition Lies: Lessons from a CSV Parser

A good reminder that performance problems aren’t always where we expect them. The example starts with a CSV parser that looks reasonable but spends most of its time on string allocation rather than file I/O.

Also interesting: the release build was dramatically faster than debug.

📍Level: Intermediate

Action Runner: An iOS Architecture for Isolating Business Logic

A different approach to keeping business logic away from controllers. The Action/RunnableAction pattern and shared RunContext are worth looking at if your architecture is starting to develop circular dependencies.

📍Level: Advanced

iOS 27: CrashReportExtension Framework

A look at Apple’s new crash-reporting extension in iOS 27. Instead of doing everything from a signal handler, the crash can be inspected from a separate system-managed process.

📍Level: Advanced

In-House Over-the-Air Localizations in a Modular iOS App

An interesting production example from Just Eat Takeaway: updating localized strings remotely without requiring a full App Store release.

📍Level: Advanced

Apple 🍏

Get ready for iPhone Duo

Apple’s main developer hub for iPhone Duo. It brings together the six Tech Talks, Group Labs, Q&A sessions, and the Xcode 27.1 beta.

App Store submissions now open for the latest OS releases

Xcode 27 RC is available, and App Store Connect is accepting submissions built against the latest OS releases. The new minimum-SDK requirements take effect across Apple platforms in April 2027.

AI & Tooling 🤖

LazyState 1.0: Now Available to Everyone

Point-Free’s LazyState macro is now at 1.0. It creates SwiftUI state lazily and keeps it tied to the view’s identity.

📍Level: Intermediate

Object Tracking Updates in visionOS 27 and iOS 27

A look at the new object-tracking capabilities in visionOS 27 and iOS 27, including an accessibility project that combines object tracking with Vision Pro and iPhone.

📍Level: Intermediate

Design🎨

Designing for iPhone Duo: The HIG Guide in 5 Minutes

A quick walkthrough of Apple’s HIG guidance for the new form factor, including adaptive layouts, safe areas, fold displacement, and the new arrangement containers.

📍Level: Intermediate

Tutorials📒

Moving from XCTest to Swift Testing

A practical guide to moving from XCTest to Swift Testing, including the new @Suite and @Test APIs and updated assertion syntax.

📍Level: Beginner

Video 🎥

Prepare your app for iPhone Duo

If you only watch one of Apple’s six iPhone Duo videos, I’d start here. It covers flexible layouts, size classes, asymmetric safe areas, and the reserved-regions API..

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: A Working App Is Only the Beginning

Sun, 13 Sep 2026 20:31:02 GMT

Happy Sunday! 👋

Today, Ekaterina Buyanova is sharing her secrets with us.

She’s an iOS developer with a strong interest in SwiftUI, creative coding, and building polished user experiences. Ekaterina also shares her experiments and practical discoveries with the iOS community through technical posts and open-source projects.

Where would the indie app development process go?

P.S. You can check out Ekaterina’s work on LinkedIn, and Git.

I’ve come across many technically impressive apps. Complex features are implemented exceptionally well, the problems they solve are genuinely meaningful, and some solutions clearly reflect serious engineering work. The developer understands the system inside out and can bring almost any idea to life.

To the person who built it, the interface feels obvious - they know its logic, understand the purpose of every element, and remember exactly where each action is. A new user arrives without any of that context. They open the app for the first time and see only what’s right in front of them.

At that point, the technical complexity behind the product takes a back seat. If users have to search for the primary action, figure out the navigation, or guess what they’re supposed to do next, there’s a good chance they’ll simply close the app.

Not because the product is bad or the feature isn’t useful, but because the cost of that first interaction was higher than the value they had a chance to see.

While working on my own product, I started looking at development more and more from this perspective. A working feature doesn’t automatically create a good user experience, and a technically finished app isn’t necessarily a finished product.

The First Few Seconds Matter

A user forms their first impression of an app before they have a chance to appreciate its functionality. First, they need to understand something much simpler: where they are, what they can do, and where to start.

And this is where developers face a problem - we know our own interfaces too well. After dozens of hours working on an app, the meaning of every icon and the location of every button feel obvious. But that knowledge exists in the developer’s head, not the user’s.

That’s why a working interface isn’t necessarily an understandable one. A button can trigger the right action, data can save correctly, and navigation can work without errors - while the user is still looking at the screen wondering, “What am I supposed to do next?”

One thing worth paying close attention to is visual hierarchy. If five elements on a screen all look equally important, we’re essentially asking the user to decide what matters most. The primary action should be easy to recognize, while secondary options should appear when they become relevant.

The same applies to familiar iOS patterns. It can be tempting to invent a more original interaction, but navigation bars, sheets, tab bars, and system controls already have one major advantage: users know how they work before they even open our app. If a standard pattern solves the problem well, there should be a good reason to replace it with something unfamiliar.

One of the most revealing tests requires almost no tools at all. Give the app to someone who has never seen it before, ask them to complete a specific task, and don’t explain anything.

The moment you feel the urge to say, “No, tap here first,” stop. You’ve probably just found a part of the interface that was obvious to the developer - but not to the user.

That’s why testing shouldn’t focus only on whether a user can complete an action, but also on whether they can figure out how to do it on their own.

Beyond the Happy Path

During development, it’s easy to focus on the ideal scenario: the user opens a screen, performs an action, and gets the expected result. But real users don’t follow our test scenarios.

They leave fields empty, interrupt actions halfway through, lose their connection, or return to the app after an update with existing data. Sometimes they simply use a feature in a way we never expected. This is where the difference between a working feature and a resilient product becomes much more visible.

The happy path is only the tip of the iceberg.

Below the surface are all the states that are easy to overlook when everything goes according to plan: empty states, denied permissions, invalid input, interrupted flows, errors and recovery, migrations, and unexpected combinations of existing data. So when testing a feature, it can be useful to reverse the usual question.

Instead of asking only:

“Does the main flow work?” ask: “What happens when the user goes beyond it?”

The happy path shows that a feature works.

What happens around it shows how well the product was actually designed.

More Than Working Code

When building your own app, it’s easy to focus on the question we, as developers, naturally ask: “Does it work?”

It’s an important question - but for an indie developer, it can’t be the last one.

There may be no separate designer, QA engineer, or product team to challenge our decisions from another perspective. We have to deliberately step outside the implementation and look at the experience we’ve created.

The code can work perfectly. But users don’t experience the implementation - they experience the product.

And that’s why a working app is only the beginning.

WaterMeApp 🌿

I recently released WaterMeApp, an iOS app designed to make everyday plant care simple and easy to keep track of.

I wanted the experience to feel calm and intuitive, with a thoughtfully designed interface and a soft, nature-inspired color palette. One of the features I especially wanted to include was shared plant care - you can share your plants with someone while you’re away and stay updated when they’re watered.

Building WaterMeApp gave me the opportunity to put many of the ideas from this article into practice - and reinforced the idea that making an app work is only one part of building a product.

Those Who Swift - Issue 283

Wed, 09 Sep 2026 20:05:48 GMT

Weekly note ✏️

Four pieces this week, and every one of them starts the same way: someone stops assuming and goes and checks.

What they find is the same shape of problem wearing different clothes — the screen isn’t the device, the toolbar doesn’t have infinite room, the view model doesn’t need every layer of the template, and the data isn’t shaped the way the schema assumed it was.

Hit reply and tell us: what’s an assumption baked into your codebase that you’ve never actually gone and verified?

The Space You Have Isn't the Space You Assumed with

with Divya Ravi — Technical Editor, iOS engineer

Every iOS developer has, at some point, written UIScreen.main.bounds and moved on with their day. It compiles. It runs. It’s been “fine” for years. It is also, this week’s reading reminded me, quietly wrong in an increasing number of situations — and the fix for that particular wrongness turns out to be a pretty good description of a habit worth having everywhere else in the codebase too.

Livsy’s piece on UIWindowScene.effectiveGeometry is the clearest version of the argument. UIScreen.main tells you about the physical display. It has never told you about the space your app actually occupies — and on modern iOS, with Stage Manager, external displays, split-screen multitasking, and resizable windows, “the space your app actually occupies” and “the physical display” can be wildly different numbers. The fix isn’t complicated once you know it exists: ask the window scene what space you’ve actually been given, respond to it when it changes, and stop treating a Screen API as a stand-in for a question it was never built to answer. The API name is almost a tell. It says Screen. It was never going to tell you about your window.

Natascha Fadeeva’s toolbar piece is the same idea at a smaller scale. A toolbar with five items looks perfect at design time, on your test device, in your test locale. Then someone rotates the device, or picks a language where your labels run long, or uses a Dynamic Type setting you didn’t test at, and “five items” stops fitting. The interesting part of her piece isn’t the overflow API itself — it’s the framing. Toolbar space was never a fixed quantity you could design against once. It’s a runtime value, same as any other piece of state, and it deserves the same respect you’d give any other thing that can change out from under you.

Antoine van der Lee’s MVVM piece pushes on a version of this that’s easier to miss because it isn’t visual. A lot of SwiftUI architecture advice assumes a ceiling of complexity that most individual screens never actually reach — every screen gets a view model, every view model gets injected dependencies, every dependency gets a protocol, whether the screen in question is a five-state settings toggle or a real, gnarly, stateful flow. The piece isn’t an argument against MVVM. It’s an argument for measuring the actual complexity of the actual screen before reaching for the full pattern — the same move as checking effectiveGeometry instead of assuming the device size, just applied to code shape instead of screen shape.

And then there’s Fatbobman’s piece on SwiftData modeling, which is the same lesson at the layer furthest from the screen. He makes the case that optimization problems in SwiftData are, more often than people expect, modeling problems wearing a performance costume — a slow fetch is frequently the result of a schema shaped around how the data was imagined rather than how it’s actually queried and related. You can spend a long time tuning predicates and indexes against a model that was wrong from the start. Model first, from what’s actually there. Optimize second.

Four different layers — the screen, the toolbar, the view model, the schema — and the same underlying move at each one: replace an assumption you inherited or guessed at with a value you actually checked. None of these are dramatic bugs. They’re the unglamorous kind of wrong that just sits there working “well enough” until a configuration shows up that your assumption didn’t cover, and by then it’s not a code review comment, it’s a support ticket.

I don’t think the lesson is “distrust everything.” Most of your assumptions are fine, most of the time, or nobody would ship anything. But it’s worth keeping a running list, somewhere in the back of your head, of the assumptions in your own codebase you’ve never actually gone and checked — the ones you inherited from a tutorial, a template, or your own past self on a smaller, simpler version of this project. This week’s four pieces are what it looks like when someone finally checks one.

Hit reply and tell me: what’s the assumption in your codebase you’d bet money is wrong, if you ever got around to checking it?

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

What's New in Swift: August 2026 Edition

Swift.org's monthly roundup of language, tooling, and ecosystem changes from across the Swift project — the fastest way to catch anything that shipped last month without combing through individual proposal threads.

📍Level: Intermediate

Codable Errors Are Finally Readable in Swift 6.3

Sarun Wongpatcharapakorn covers Swift 6.3's overhaul of DecodingError's printed output — turning a wall of nested enum cases into something you can actually read at a glance the next time a JSON payload doesn't match your model.

📍Level: Beginner

Coding 👨‍💻

Don't Modularize Your .xcdatamodeld Until You Read This

Lee young-jun documents a rough real-world attempt to split a Core Data model across feature modules — the crashes and codegen mismatches that showed up, and the manual model classes plus an xcrun momc build step that ended up being the actual fix. ⚠️ Published May 12, 2026 — outside our usual 2-3 week window; included as a flagged exception since Core Data modularization pain doesn't really go stale. See verification notes.

📍Level: Advanced

Apple 🍏

Upcoming Changes to Rosetta Support for Intel-Based macOS Apps

Apple laid out the endgame for Rosetta on Apple silicon: user-facing warnings starting in macOS 26.4, and macOS 27 as the last release that runs Intel-only apps at all. If you're still shipping an Intel-only build, the clock is now explicit.

Tax and Price Updates for Apps, In-App Purchases, and Subscriptions

New VAT and digital sales tax rules in Morocco, the Republic of the Congo, and Tanzania are triggering automatic App Store price and proceeds updates starting September 14 — worth a look if you sell in any of those storefronts.

AI & Tooling 🤖

Building AI Features Using Foundation Models: Multimodal Input

Majid Jabrayilov walks through feeding images alongside text into Apple's on-device Foundation Models framework — a concrete look at multimodal prompting without leaving the device or paying a cloud-API bill per request.

📍Level: Intermediate

Why Pi Is My AI Coding Harness

Igor Kulman explains why he standardized on Pi, a minimal coding agent, as a stable workflow layer — building his own extensions and reusable skills once so he can swap the underlying AI model without rebuilding his whole setup each time.

📍Level: Intermediate

Advanced Agentic Engineering

Jacob Bartlett shares practical techniques for running multiple AI coding agents at once — verification loops, automation, and guardrails that keep several agents productive in parallel instead of turning into several times the review burden.

📍Level: Advanced

AI-Accelerated Mobile Development: Lessons from My NSLondon Talk

Giordano Scalzo revisits his NSLondon talk on building iOS/macOS apps with AI coding agents — including the moment a missing sandbox entitlement broke his QR-code app's file saving, and what that taught him about the engineer's job shifting from writing code to directing it.

📍Level: Intermediate

Design🎨

Building a Sunburst Diagram in Swift Charts

Matthaus Woolard builds a hierarchical sunburst chart using Swift Charts' newer arc and sector marks — a solid reference the next time you need to visualize nested categories and Swift Charts' built-in chart types don't quite fit the shape of your data.

📍Level: Advanced

Community🤝

The End of Swift Talk

After a decade and more than 500 episodes, objc.io is ending Swift Talk, its long-running weekly Swift video series — auto-renewals are already off, and the full archive is set to go public by year's end. The end of one of the format's earliest and most consistent teaching resources.

📍Level: Beginner

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: Domain, Data, Presentation - What Clean Architecture Actually Buys You on iOS

Sun, 06 Sep 2026 19:31:02 GMT

It’s already the 5th issue, wow, time flies! Thank you for reading. 🥳

Today, Vadim Krutov is sharing his architectural planning vision.

He’s an iOS developer who has been building apps since 2017, with a strong interest in Swift, SwiftUI, architecture, and modern Apple development.

As the creator of Swiftloop, he shares practical lessons drawn from real-world iOS development, from debugging tricky issues to exploring APIs and architectural decisions.

Vadim also contributes to the Swift ecosystem through open-source packages and technical writing.

Let’s check out what CLEAN architecture will bring us.👇

P.S. You can check out Vadim’s work on LinkedIn, and website.

Most iOS codebases don’t start layered. They start as a SwiftUI view or a view model that fetches, decodes, maps, validates, and renders, all in one file, because that’s the fastest way to ship the first screen. It works right up until the second screen needs the same business rule, or the backend changes a field, or someone tries to unit test a network call without booting a simulator. At that point the tax comes due: business logic is welded to URLSession, UI state is welded to Core Data, and touching any one of them risks breaking all three.

Clean Architecture’s answer is to split the app into three layers — Domain, Data, Presentation — with one rule holding them together: dependencies point inward, toward Domain. Data and Presentation both know about Domain; Domain knows about neither. That single rule is where most of the payoff comes from, and most of the ways teams get it wrong come from quietly breaking it. Here’s what that looks like in practice, fifteen lessons in.

Why Bother Splitting into Three Layers at All

The immediate win is navigability. When every piece of code has exactly one of three possible homes — business rules in Domain, persistence and networking in Data, screens and state in Presentation — a developer who has never seen the codebase can still find their way around it. “Where’s the discount logic?” has one answer, not “check the view model, or maybe the API client, or possibly that extension file.”

The bigger win shows up when you make a large decision later. Decide to move from MVVM to TCA, or from Combine to async/await in your view layer? That only touches Presentation. Decide to replace Core Data with SwiftData, or REST with GraphQL? That only touches Data. Domain doesn’t move either time, because Domain never depended on how data was fetched or how the screen was built — only on the contracts. Layering doesn’t prevent big rewrites; it just makes sure a rewrite in one layer doesn’t force a rewrite in the other two.

Start With the Domain Layer, and Keep It Pure

If you’re building all three layers from scratch, start with Domain. Both Data and Presentation end up depending on it, so the contracts it defines — protocols, models, use cases — are the thing everything else is built against. Defining them early isn’t mandatory, but it saves you from designing a repository interface and a view model in parallel, guessing at what the other side needs.

The part that’s easy to get wrong isn’t the ordering, it’s the purity. Domain should stay clear of UIKit and SwiftUI — nothing in your business rules needs to know a screen or a view exists. Foundation basics like Date, UUID, and Data are a different case; they’re everyday vocabulary, not framework leakage, and most domain models end up depending on at least one of them. Combine is more of a team call than a hard line — if your Data layer is already built on it, Domain may end up depending on it too, since there’s often no realistic way around that. Beyond keeping UI frameworks out, how strictly you draw the line is ultimately a team agreement. Some teams knowingly let a specific framework into Domain because it clearly pays for itself in their context. That’s a fine trade-off to make deliberately; it’s just worth making it on purpose rather than by accident, since every exception is one more thing standing between Domain and being buildable and testable on its own.

struct Order: Identifiable, Equatable {

    let id: UUID

    let items: [OrderItem]

    let status: OrderStatus

}

protocol OrderRepository {

    func fetchOrders() async throws -> [Order]

    func place(_ order: Order) async throws

}

Nothing here says how orders are fetched or stored. That’s what makes the “develop independently” promise real: you can write and test every business rule against this protocol before a single Data or Presentation type exists, with no simulator and no mocked network layer, just a fake conforming to OrderRepository.

The Repository Is a Facade, Not a Pipe

Domain depends on repository contracts, never on individual data source contracts. Everything that can go wrong on the data side — a flaky network, a cache that needs merging with a fresh response, a backend field that got renamed — should be invisible past the repository boundary. That only works if you design the contract carefully up front, because loosening it later usually means touching every call site.

Two things tend to hide inside that facade: mapping and error translation. A DTO and a domain model often look identical, and that similarity makes people want to collapse them into one type. Don’t — the DTO is what absorbs an API change; the domain model is what the rest of the app is allowed to depend on.

Error translation has the same shape, and the same rule about which layer owns what: OrderError has to be defined in Domain, not Data, because Domain can never depend on Data — if the error type lived next to RemoteOrderRepository, nothing above it in Domain would be allowed to catch it.

// Domain

enum OrderError: Error {

    case unavailable(underlying: Error)

    case corruptedResponse

    case unknown(underlying: Error)

}

// Data

struct OrderDTO: Decodable {

    let id: String

    let items: [OrderItemDTO]

    let status_code: Int

}

struct RemoteOrderRepository: OrderRepository {

    private let client: APIClient

    private let cache: OrderCache

    func fetchOrders() async throws -> [Order] {

        do {

            let dtos = try await client.get(”/orders”, as: [OrderDTO].self)

            let orders = dtos.map(Order.init)

            await cache.save(orders)

            return orders

        } catch let error as URLError {

            if let cached = await cache.readAll() { return cached }

            throw OrderError.unavailable(underlying: error)

        } catch is DecodingError {

            throw OrderError.corruptedResponse

        } catch {

            throw OrderError.unknown(underlying: error)

        }

    }

}

That trailing catch { throw OrderError.unknown(underlying: error) } isn’t decoration — Swift requires a do-catch to be exhaustive, so without an unconditional catch at the end, this doesn’t compile. It also happens to be the right place to route anything you didn’t anticipate into the same domain vocabulary, rather than letting a raw URLError or some third one slip through uncaught.

Nothing in Order ever needs to know that status_code used to be a String and became an Int in some backend release, and nothing in a view model needs to catch a URLError — it catches OrderError.unavailable and shows a retry button. That’s the whole point of the facade: whatever happened on the way in, Domain only ever sees its own vocabulary, defined on its own side of the boundary.

Use Cases Have to Earn Their Keep

A use case that only forwards to a single repository method is dead weight with extra steps:

struct FetchOrdersUseCase {

    let repository: OrderRepository

    func execute() async throws -> [Order] {
        try await repository.fetchOrders()
    }

}

This shows up in a lot of codebases that adopted Clean Architecture by the checklist rather than by need, and it adds a maintenance cost — one more type, one more place to inject, one more file to open — without adding any behavior. Strictly speaking, this is what canonical Clean Architecture calls for: Presentation and Data both depend on Domain, and a use case is the shape that dependency is supposed to take, even when all it does is forward to one repository method. Following that to the letter is correct by the pattern; it’s also exactly where the maintenance burden shows up fastest. Plenty of teams bend the rule slightly and inject repositories directly into view models or reducers instead, skipping the pass-through use case entirely. That’s a small deviation from the canonical shape, not a different architecture — and whether to make that trade is a team decision, not something the pattern settles for you.

A use case earns its place when it’s actually doing something: coordinating more than one repository, enforcing a business rule, or sharing logic across several view models or reducers that would otherwise duplicate it.

struct PlaceOrderUseCase {

    let orders: OrderRepository

    let inventory: InventoryRepository

    func execute(_ order: Order) async throws {

        try await inventory.reserve(order.items)

        do {
            try await orders.place(order)
        } catch {
            try? await inventory.release(order.items)

            throw error
        }
    }
}

That’s worth a dedicated type. Depending on two repository protocols here is fine, and doesn’t bend the dependency rule — OrderRepository and InventoryRepository are both Domain contracts, so the use case is coordinating within Domain the entire time; it never reaches into Data or Presentation to do it. Whether your team draws the “worth a use case” line here is genuinely a team decision, not an architectural law — just be honest about which side of it a given use case is on.

Let Swift’s Own Capabilities Do Some of the Work

Keeping track of what the language itself gives you matters as much as the layering does. If you’re designing a new repository contract today, reach for async/await before Combine — it maps more directly onto what a repository call actually is, a single request with a single result, and it keeps Data-layer code out of publisher composition that Presentation didn’t ask for.

That same instinct — use the language, don’t route around it — is where a lot of Clean Architecture guidance for iOS shows its Android or Java roots most clearly, usually one level below the repository. A MyLocalDataSource: MyLocalDataSourceProtocol pair for something as small as a Keychain-backed token is often more type than the job needs on this platform:

@propertyWrapper
struct KeychainStored {

    let key: String

    var wrappedValue: Value? {
        get { KeychainHelper.read(key, as: Value.self) }
        set { KeychainHelper.write(key, newValue) }
    }

}

struct AuthRepository {
    @KeychainStored(key: “auth.token”) private var token: AuthToken?
}

Same behavior as a dedicated data source type, a fraction of the code to maintain. Not every data source deserves a full type — some deserve one line.

Make the Boundaries Real: Modules and Composition Roots

Folder structure and good intentions don’t stop someone from importing a Presentation type into Domain under deadline pressure — and once that happens once, “Domain is pure” becomes a claim nobody can actually verify by reading the code. Splitting Domain, Data, and Presentation into separate Swift Package targets turns that mistake into a compiler error instead of a code review miss, with faster incremental builds as a side effect:

// Package.swift

targets: [

    .target(name: “Domain”),

    .target(name: “Data”, dependencies: [”Domain”]),

    .target(name: “Presentation”, dependencies: [”Domain”]),

    .target(name: “App”, dependencies: [”Data”, “Presentation”])

]

Data and Presentation can both import Domain, but neither can import each other, and Domain can’t import either. That’s the dependency rule, enforced by the build system rather than by convention.

Somewhere, all of this still has to get wired together — a concrete RemoteOrderRepository handed to a PlaceOrderUseCase handed to a view model. Keep that assembly in one obvious place, whether that’s your app’s entry point, a set of factories, or a small DI container, rather than letting each screen construct its own dependency graph. A composition root is the one place in the app that’s allowed to know about all three layers at once; that’s a feature, not a violation of the rule.

Why this matters even more when an agent is writing the code

Clear layering used to be mostly a human-navigation aid. It’s now also a determinism aid. An agent generating a new feature against a codebase with well-defined layers produces far more predictable output than one working against a flat pile of SwiftUI views, because “where does this code go” has an answer before the agent has to invent one. And the same clarity that helps the agent generate code helps you review it afterward — you know a repository implementation belongs in Data, so when an agent’s diff puts networking code in a view model, that’s immediately visible as wrong, not something you have to reconstruct from context. Architecture that used to be a courtesy to the next developer is now also a courtesy to the next agent, and to whoever reviews what it wrote.

Gotchas

Don’t reach for three layers and three modules on a three-screen prototype. Clean Architecture’s cost is real and mostly fixed — it doesn’t scale down. Applied to something that will be thrown away in a sprint, it’s not rigor, it’s overhead with nothing to show for it.

A repository contract designed around one data source rarely survives a second one untouched. If OrderRepository was shaped entirely by what the REST client returns, adding a local cache or a second backend tends to expose assumptions baked into the contract, not just the implementation. The careful-design-up-front advice isn’t boilerplate — it’s where most contract rewrites originate.

Module boundaries pay for themselves at team and codebase size, not before. Three SPM targets on a solo two-week project is mostly extra Package.swift ceremony. The build-time enforcement earns its keep once more than one person is touching the code and a misplaced import would otherwise sit unnoticed until it’s expensive to unwind.

Summary

Everything above is really one rule wearing different clothes: dependencies point inward, and Domain doesn’t know Data or Presentation exist. Start there, keep it pure, make repositories the only seam between Domain and the outside world, and let use cases prove they’re doing real work before you write another one. The layering doesn’t make big decisions disappear — switching frameworks, backends, or architectures inside a layer is still work — it just makes sure that work stays inside the layer it started in, whether the one making the change is you, a teammate, or an agent.

Those Who Swift - Issue 282

Wed, 02 Sep 2026 21:05:28 GMT

Weekly note ✏️

“It just works” is doing a lot of quiet work in that sentence.

This week’s reads are about the rules hiding underneath four things that feel automatic: how SwiftUI decides a view needs to redraw, which property wrapper actually owns your object, what git really deletes when you force-push over two weeks of work, and what happens when you stop clicking through Xcode and start scripting it directly.

Hit reply and tell us: what’s the last “it just works” feature that turned out to have rules you had to learn the hard way?

Every “It Just Works” Has Rules You Haven’t Learned Yet.

with Divya Ravi — Technical Editor, iOS engineer

Every framework sells you a story. SwiftUI redraws the right views. Git deletes what you tell it to delete. Xcode is where you click things until the app runs. The story is convenient right up until the moment it’s wrong, and then you find out the story was never the whole mechanism — just the part someone decided you didn’t need to see.

Natalia Panferova’s piece on SwiftUI data dependencies is a good place to start, because “SwiftUI re-renders when state changes” is the kind of sentence that’s true enough to stop you from asking a better question. Which state? Tracked how? Through what boundary? Panferova walks through the actual dependency graph SwiftUI builds, and once you’ve seen it, the mysterious extra redraw — or worse, the redraw that never happens — stops being mysterious. It was never magic. It was a rule you hadn’t read yet.

Antoine van der Lee’s @StateObject-versus-@ObservedObject piece sits right next to that one, because ownership is exactly the kind of thing SwiftUI lets you get away with ignoring until you can’t. Both wrappers will compile. Both will often behave identically in a demo. The difference only shows up when the view holding an @ObservedObject gets recreated and your “persistent” state quietly resets — at which point you learn, expensively, that one of these wrappers was never supposed to be the source of truth.

Then there’s Daniel Saidi’s story, which is the most viscerally relatable thing I’ve read this month: an errant git reset and force-push erased two weeks of work on a real project. I felt that in my chest reading it. But the resolution is the actual lesson — git doesn’t delete commits when you delete a ref, it just stops pointing at them. The work was never gone. It was unreachable, which is a very different thing from destroyed, and knowing that difference is the kind of fact that turns a five-alarm panic into a five-minute recovery.

Artem Novichkov’s MCP-driven Xcode piece rounds this out from a different angle. Instead of learning a hidden rule the hard way, he’s exploiting one on purpose: Xcode and the simulator were never really “a GUI,” they’re a set of programmable interfaces that a GUI happens to sit in front of. Once you talk to that layer directly — prompt to build to simulator, no clicking — a lot of what felt like “the way Xcode works” turns out to have been “the way the GUI chose to expose Xcode.” Different thing entirely.

None of these are really stories about bugs. They’re stories about the gap between the interface you were handed and the system actually running underneath it — and about what happens once someone bothers to close that gap for you. The dependency graph, the ownership model, the ref/object split, the automatable toolchain: all of it was always there, documented or discoverable, just not part of the story anyone tells you on day one.

I don’t think the answer is to distrust every abstraction you use. Most of them earn the trust, most of the time. But it’s worth noticing which ones you’ve never actually verified — which “it just works” you’ve been repeating because it’s convenient, not because you checked. The rules are usually learnable in an afternoon. The bill for not knowing them tends to come due at a much worse time.

Hit reply and tell me: what’s an “it just works” in your stack that you’ve never actually gone and verified?

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Trailing Commas Beyond Arrays In Swift 6.1

Sarun Wongpatcharapakorn covers how Swift 6.1 extends trailing-comma support past arrays to parameter lists, tuples, and generics — a small change that quietly makes every future code review and diff cleaner.

📍Level: Beginner

Beta Preview: LazyState

Point-Free previews LazyState, a library that picks up where WWDC's new @State macro left off, letting SwiftUI view state be initialized lazily and dynamically from data the parent view passes in.

📍Level: Advanced

Coding 👨‍💻

Why Swift Is Introducing A Warning For Weak Captures Within Nested Closures

John Sundell explains a new Swift compiler warning that catches a specific, easy-to-miss closure-capture mistake — and why "just add [weak self]" turns out not to be automatically enough once closures start nesting.

📍Level: Intermediate

Building A Reusable HTTP Client In Swift With async/await

Mohammad Azam builds a typed, testable networking layer from scratch on async/await — a solid reference the next time you're tempted to reach for a third-party networking library instead.

📍Level: Intermediate

Dynamically Setting Accessibility Custom Content Pairs In SwiftUI

Bas Broek shows how to attach and dynamically update multiple accessibility custom content entries on a view, so VoiceOver users get more than one flattened description of what's on screen.

📍Level: Intermediate

Apple 🍏

Surprise And Shine

Apple announced a September 9, 2026 event, widely expected to headline the iPhone 18 Pro lineup. Nothing developer-facing has shipped yet, but it's the date to have on your radar.

Update: New Domain For Sign In With Apple

Apple reversed a planned domain change for Sign in with Apple and iCloud+ Hide My Email after developer and user pushback — the current domain stays in place.

AI & Tooling 🤖

Getting Into Flow With AI Coding

Natasha makes the case that AI-assisted coding can deepen flow state rather than break it — if you stay actively involved: breaking work into small commits, and doing the planning and reviewing yourself instead of handing that over too.

📍Level: Intermediate

Claude Code Rules, Hooks And Skills, And How I Set Mine Up

Roland Leth breaks down Claude Code's three configuration layers — rules, skills, and hooks — and how they differ: preferences you state versus procedures you define versus safeguards that get enforced whether the AI "remembers" them or not.

📍Level: Intermediate

Design🎨

Building An Accessible Calendar Chart With Swift Charts

Matthaus Woolard builds a calendar-style chart with Swift Charts that also works with VoiceOver — treating accessibility as part of the chart's design from the start rather than a pass added at the end.

📍Level: Intermediate

Tutorials 📒

Uploading To TestFlight From The Command Line

Kyle Browning walks through scripting a TestFlight upload without opening Xcode — a useful building block for anyone trying to get release day off a human's clipboard and onto CI.

📍Level: Intermediate

Fix Sluggish SwiftUI Previews Instantly With Static Mock Data

Sagar Unagar shows a quick technique for keeping Xcode previews fast: swap live or expensive data sources for static mocks so iterating on a view doesn't mean waiting on a network call every time.

📍Level: Beginner

Community🤝

SE-0541: Flexible Swift/C Interoperability For Packages

The Swift Evolution community accepted SE-0541, giving Swift packages more flexible ways to interoperate with C code — a small but real ecosystem win for anyone bridging C libraries into Swift.

📍Level: Advanced

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: From AI-Generated Code to AI-Assisted Engineering

Mon, 31 Aug 2026 18:00:40 GMT

Let’s call it some technical issues. 😅

Instead of Sunday, we’re publishing “Devs for Devs” on Monday.

This week, I’m happy to have Vinicius Serpa Pansan, an iOS developer with 4 years of experience building apps with a focus on performance and user experience. Based in São Paulo, Brazil, he works across the Apple ecosystem with technologies including Swift, SwiftUI, UIKit, and AppKit.

He shares his experience with AI-assisted app creation. Let’s check how to check, verify and adapt the AI-assisted code.

P.S. You can check out Vinicius’s work on LinkedIn, and Git.

A few months ago I started building Fio, a voice-first journaling app for iOS. The core idea is simple: speaking is faster than typing, so instead of asking someone to type out their day, you just talk, and the app transcribes and saves it. No decision required at the moment of capture, no folder to choose, no structure to commit to. Just speak, and it’s there.

I built it entirely in SwiftUI, and from day one, Claude Code and Codex were part of the actual development process, not a tool I reached for occasionally, but something I used in nearly every session.

My first instinct, like most people’s, was to use AI the obvious way: describe what I wanted, get a working implementation, accept it, move to the next screen. It’s the fastest path from idea to shipped feature, and for a while, it felt like exactly the right call. Screens came together quickly. Features that would have taken me a full evening to hand-write were done in twenty minutes.

Then, a few weeks in, I noticed something that bothered me more than it should have. I’d finish a session having built something that worked, and if you’d asked me to explain why it was built that particular way, instead of some other reasonable way, I sometimes couldn’t answer with confidence. I knew what the code did. I didn’t always know why it was the right shape for the problem.

That gap is easy to ignore when everything is working. It stops being easy to ignore the moment you have to defend a decision, in a code review, in an interview, or just to your future self six months later trying to remember why you did something a certain way.

This is the story of how I closed that gap, and the four-step loop I ended up building around it.

The Problem with Just Accepting the Output

The default AI workflow most developers fall into is straightforward: describe a problem, get a suggestion, skim it, it looks reasonable, accept it, move to the next task. It’s fast, and it feels productive, because things keep getting built. Velocity is visible. Understanding isn’t, so it’s easy to quietly deprioritize.

The moment this stopped being abstract for me was a decision that actually mattered for Fio: how to handle voice transcription. The app’s entire premise rests on a privacy promise, you speak, it’s transcribed, and nothing leaves the device unless you explicitly choose to back it up to your own iCloud. No audio ever touches a server. That’s not a minor implementation detail, it’s the reason the app exists in the shape it does.

If I had approached that the way I approached the first dozen smaller features, describe “add voice transcription,” accept the first working version, I likely would have ended up with something that technically transcribed audio just fine, but quietly assumed a server round-trip somewhere in the pipeline, because that’s the default shape most transcription examples and tutorials reach for online. It would have worked. It would have also violated the one promise the entire app is built around, and I might not have caught it until much later, possibly after the architecture around it was already hard to unwind.

Nothing about that outcome would have been the AI’s fault, to be clear. I was the one who hadn’t specified the constraint, hadn’t asked why a particular approach was chosen over another, hadn’t treated the output as something to interrogate rather than something to accept. The tool did exactly what I asked. I just hadn’t asked precisely enough, because I wasn’t in the habit of asking at all.

That’s the moment I stopped treating AI output as a finished answer and started treating it as a first draft that owed me an explanation

Here’s the difference in practice. The version I almost shipped would have looked something like this:

The version that actually matches Fio’s privacy promise sets one property explicitly:

One line. But it’s the line that turns “probably private” into “actually private,” and it’s exactly the kind of detail that’s easy to skip when you’re evaluating from a neutral position instead of comparing against something you wrote yourself first.

The Loop I Built Instead

I didn’t design this all at once. It came together step by step, each addition responding to a specific way the “just accept it” habit had already failed me.

Step 1: Write Your Own Approach Before Asking for One

Before I ask Claude Code or Codex to implement anything non-trivial, I write, in plain language, how I think it should work. Not code. A paragraph, sometimes just a few sentences. What matters isn’t the polish, it’s that I commit to an opinion before I see someone else’s, even an AI’s.

This sounds like a small thing, but it changes the psychology of the whole exchange. When you ask first and see the answer second, you’re evaluating from a neutral position, and neutral positions default to “looks fine” far more often than they should. When you write your own approach first, you have something to compare against, and comparison is a completely different cognitive act than approval. You’re no longer asking “does this look right?” You’re asking “where does this differ from what I expected, and why?”

More than once, my written approach turned out to be missing something the AI’s version accounted for, and I learned from the gap. Just as often, my approach was actually right, and the AI’s first suggestion took a shortcut I didn’t want, which I only caught because I had something concrete to compare it to.

Step 2: Let It Implement or Push Back, Not Replace

Once there’s a direction, the AI’s role is to build within it, and to flag problems it can see that I can’t, not to substitute its own direction for mine by default. This is a subtle distinction, but it changes how I write prompts. Instead of “build a sync mechanism for offline notes,” I’ll say something closer to “here’s how I want to structure the sync mechanism, tell me what breaks.”

That framing invites pushback instead of discouraging it. And when the pushback comes, it’s usually specific and useful, because it’s responding to a concrete proposal rather than generating one from scratch.

Step 3: Ask “Why This, Not the Alternative” on Every Non-Trivial Call

This is the step that actually catches the cases like the transcription example, the ones that are quietly wrong by default, not obviously wrong. If I can’t explain, in my own words, why a piece of implementation exists the way it does, I don’t move forward, regardless of whether the code compiles and the tests pass.

Sometimes the answer the AI gives is genuinely good, something I hadn’t considered, and I learn from it directly. Sometimes asking the question reveals that I framed the original request incorrectly, and the more useful fix is upstream of the code entirely. Either way, I come out of the exchange knowing something I didn’t know when I asked.

Step 4: Close Every Session by Summarizing What You Learned

Not what got built. What got understood? At the end of a session, I ask for a short summary of the concepts we touched, framed as though I had to explain them to someone else afterward, a teammate, an interviewer, my future self debugging this in six months.

This is the habit that turns a series of coding sessions into something that compounds instead of something that just accumulates. It’s also, practically speaking, what makes a project like this defensible later. When you can explain not just what a piece of code does but why it exists in that shape, you’re not reciting an AI’s explanation from memory, you’re demonstrating that the understanding is actually yours.

What Changed

Fio still isn’t public, so I’m not going to pretend this loop is the reason the app is good. What I can say with confidence is narrower and, I think, more useful: I know exactly why every non-trivial decision in it was made. That wasn’t true a few weeks earlier, when I was moving faster and understanding less, and it’s a different thing entirely from knowing that the code works.

That distinction matters more than it might seem to at first. Code that works is a snapshot. Understanding why it works, and why the alternative wasn’t chosen, is what lets you extend it, debug it under pressure, or explain it convincingly to someone else, none of which “it works” guarantees on its own.

I think this is the trade worth naming clearly, because it’s easy to miss in the current wave of AI-assisted development: speed was never actually the constraint holding most developers back. Understanding was, and it’s always been the harder, slower thing to build, which is exactly why it was the first thing to get cut whenever a faster path appeared. AI is, among other things, a very fast path. It removed a real excuse people used to have for skipping the “why”, there simply wasn’t time, someone had to just ship the thing. That excuse is mostly gone now. What’s left is a choice, made consciously or not, every time you accept a suggestion: build the loop that forces understanding, or don’t, and get code that works until, one day, it doesn’t, and you’re left debugging something you never actually understood in the first place.

The question worth asking isn’t “am I using AI?” anymore. At this point, most of us are, and the answer says less than it used to. The more useful question is narrower: after this session, do I know more than I did before it started, or am I just further along?

If you’re building something with AI as an active part of your process and want to compare notes on what’s working and what isn’t, feel free to reach out. I’m always happy to talk through it.

Those Who Swift - Issue 281

Wed, 26 Aug 2026 20:38:31 GMT

Weekly note ✏️

Ship day gets the screenshots, the release notes, and the celebratory post. Day two gets the bug reports.

This week’s reads are about that much longer stretch of software life: a 14-year-old app replacing its database, an open-source maintainer asking others to take ownership, a developer measuring what iOS background scheduling actually does in the wild, and an engineering lead making decisions before certainty arrives.

Hit reply and tell us: what’s the oldest piece of software you’re still responsible for keeping alive?

Shipping Is the Easy Part. Sustaining It Is the Job.

with Divya Ravi — Technical Editor, iOS engineer

Ship day gets all the ceremony. The build goes green, App Review says yes, and for a few hours the project feels finished.

Then somebody finds the edge case.

Maybe it is an old device you no longer own. Maybe it is data created six versions ago. Maybe it is not even your bug, but it is happening inside your app, so the distinction is not especially useful to the person staring at a broken screen.

That is the part of shipping we rarely celebrate: the years after the release, when the job becomes less about adding something new and more about keeping a promise you already made.

Daniel Saidi’s Wally is a good example. The app is 14 years old, and version 7 replaces Realm with SwiftData. Saidi describes a much cleaner architecture, less storage code, better integration with modern Apple frameworks, and private iCloud sync. It is tempting to summarize that as a straightforward modernization. It probably did not feel straightforward while changing the foundation of an app that has been accumulating users and data since 2012.

There is a point in every long-lived codebase when leaving the old system alone stops being the conservative choice. The workaround has a workaround. A dependency no longer fits the direction of the platform. The code still runs, but every new feature pays rent to an architectural decision made years ago. Replacing it is risky. Keeping it is risky too.

Matt Massicotte’s post sits nearby, although the debt is human rather than technical. He lists the open-source projects he can no longer maintain properly and asks people to take them over. I appreciated how direct the post is. Open source has plenty of launch energy and very little succession planning. We talk about adoption, stars, and contributors; we talk much less about what happens when the person whose name is on the repository no longer has the time to be its unpaid support team.

Asking for maintainers is not abandoning a project. Done early enough, it may be the most responsible maintenance decision available.

Irving Popovetsky’s post on iOS background tasks is the kind of article that only gets written after the happy path has stopped being useful. He instrumented BGTaskScheduler on his own device and watched what happened over time: refreshes arrived hours later than requested, resubmitting could accidentally push a pending task further into the future, and background launches became less frequent when the app went unopened.

The useful part is not a magic configuration that makes iOS behave like cron—there isn’t one. It is the record of all the small decisions required to make an unreliable system reliable enough: keeping refresh work short, handling expiration races, anchoring the next request to the last run, and being honest with users about what the operating system controls. This is maintenance in its purest form. The API call is easy; learning how it behaves after weeks of real use is the job.

And sometimes the maintenance problem is outside your repository. Jeff Johnson’s latest App Store post looks at suspicious gaps between ratings and written reviews, along with developers submitting apps at remarkable volume. You can improve your architecture, tests, and release process and still depend on a distribution system whose failures you cannot patch.

So I kept coming back to Mohammad Faani’s decision framework, especially his 70% rule: when one option looks roughly 70% right, choose it and adjust as you learn. That is useful advice for leads, but it is also a fair description of maintenance work. Most choices arrive with incomplete information. Wait for certainty and the backlog continues making decisions for you.

Working on SDKs has changed what I count as a successful release. A launch can be exciting, but the work that builds trust happens afterward: integrations continue working, old assumptions are tested against new platform behavior, and users do not need to know how much changed underneath them. “Nothing broke” is not much of a headline. It is still an outcome worth being proud of.

There is no tidy lesson here. Sometimes the right call is a migration. Sometimes it is one more compatibility fix. Sometimes it is admitting that a project needs a new maintainer. The hard part is noticing when the decision has changed—and making it before neglect makes it for you.

Hit reply and tell me: what are you still sustaining years after you shipped it, and would you make the same choices again?

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

What Is a Swift Package Registry?

Dave Verwer explains the difference between SwiftPM, a package index, and a package registry—and why verified, immutable source archives can be faster and safer than fetching every dependency through Git.

📍Level: Intermediate

Coding 👨‍💻

Protecting SwiftUI Views With Authentication

A reusable RequiresAuthentication container for gating SwiftUI screens behind login, including inline and sheet-based flows, dismissal handling, and a view-modifier alternative. One important caveat is included too: hiding a screen does not replace server-side authorization.

📍Level: Intermediate

Empty States in SwiftUI with ContentUnavailableView

Kyle Browning walks through the ContentUnavailableView initializers and builds a reusable approach for search results, errors, offline screens, and other empty states.

📍Level: Intermediate

The Curious Case of the Missing SwiftUI Clicks

Buttons inside a bidirectional ScrollView stop responding after a few taps. Switching to vertical-only scrolling fixes the problem, although the reason remains unexplained. One to remember for the next impossible-looking SwiftUI bug.

📍Level: Intermediate

Preventing Transitive Swift Imports with Bazel

Swift permits a module to import dependencies it never declared directly. Adin Ćebić shows how the rules_swift layering check makes those accidental imports fail at build time, before they become part of the architecture.

📍Level: Advanced

iOS 27: StateReporter

Anton Gubarenko explores StateReporting, a new iOS 27 framework that attaches app-state context to MetricKit and Instruments. Instead of seeing only that a hang occurred, you can see what the app was doing when it happened.

📍Level: Intermediate

NSTextTable in Swift

iOS 27 brings NSTextTable, NSTextTableBlock, and related TextKit APIs to UIKit, making real tables possible inside NSAttributedString. It is meant for rich text—documents, invoices, reports—not as a replacement for UITableView.

📍Level: Intermediate

Apple 🍏

Changes for Apps in the European Union

Apple announced new EU business terms taking effect October 1. The update replaces the per-install Core Technology Fee with a 5% commission on digital transactions in apps distributed outside the App Store, revises other commission rates, expands alternative-distribution eligibility, and adds child-safety rules for alternative payments.

Embedded Swift Improvements Coming in Swift 6.4

Swift.org previews broader language support for Embedded Swift, including generalized existential types, untyped throws, and metatypes, plus floating-point parsing and error handling for concurrent operations on constrained targets.

AI & Tooling 🤖

Apple Foundation Models: Hybrid AI with Dynamic Profiles

Peter Friese builds a router that keeps smaller prompts on Apple’s on-device model and sends larger ones to Gemini. Dynamic Profiles hold the model choice, token-budget check, and model-specific instructions so the call site stays clean.

📍Level: Advanced

Translation Sub-Agents Go Brrrrrrrr

Amy Delves shares a localization workflow built around LocalizedStringResource, a strings catalog for each view, detailed translator comments, and Xcode 27’s translation skill. It is a useful example of shaping a codebase so both people and coding agents have the context they need.

📍Level: Intermediate

AI Wanted to Give Up. The Human Didn’t.

Fatbobman reflects on Linus Torvalds’s “debug session from hell”: 24 debugging patches and 18 kernel boots to find a one-line fix. AI helped with the repetitive work, but human judgment supplied the persistence. A timely reminder that faster tools do not remove the hardest part of debugging—knowing when the evidence still does not add up..

📍Level: Intermediate

Tutorials 📒

Presenting Alerts and Confirmation Dialogs from Identifiable Data in SwiftUI

Natascha Fadeeva demonstrates the new iOS 27 item-based APIs for presenting alerts and confirmation dialogs. Binding presentation directly to an optional Identifiable value removes the separate Boolean state—and the synchronization bugs that can come with it.

📍Level: Intermediate

Video🎥

AI-Assisted TDD in Practice (Swift + AI)

Quality Coding demonstrates how test-driven development can put useful boundaries around AI-generated Swift code. The tests define the expected behavior, while the coding assistant works toward small, verifiable changes instead of producing an entire implementation at once.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: Short Eye Long Eye

Sun, 23 Aug 2026 20:51:09 GMT

Hello! 👋

Another Sunday, another “Devs for Devs” issue!

Meet Faiq Khan , an experienced iOS engineer with a strong background in building and shipping mobile products.

Today, he answers a simple question many indie devs face: what should an indie dev keep in mind while developing?

With his years of hands-on development experience and practical knowledge from working across different projects and teams, he shares his tips on how to keep moving forward.

P.S. You can check out and follow Faiq’s work on LinkedIn and website.

A Strategy for Indie Developers

As indie developers, we lack the safeguarding structure that full-sized product teams enjoy. We don’t have a dedicated PM, a scrum master, or the formal structure of a sprint or squad environment, systems designed to handle heavy planning, detailed estimation, and peer discussion.

You are often completely on your own making those decisions.

While traditional agile processes can work, as indie devs we need to relentlessly streamline how much energy we assign to planning overhead in order to deliver features in a reasonable time.

It’s easy to get caught up thinking about the distant product we want to build:

The big vision.

The polished UI.

The features we haven’t even started yet.

The version that exists somewhere months down the road.

Having that long-term vision is important. It gives you direction and something to work towards.

But there’s a danger in staring at the destination for too long: you can lose sight of what actually needs to happen today.

I’ve found it much more useful to think in two layers:

Long Eye: Where am I ultimately trying to take this product?

Short Eye: What specifically needs to happen today to move me one step closer?

And that short-term vision should get really short.

Not “build the new creation system this week.”

Instead:

“Today, get the item selection working.”

Tomorrow might be:

“Connect the selected item to the inventory system.”

Small, achievable steps.

There’s another benefit to working this way: small steps make it harder to fall down rabbit holes.

We’ve all been there. You start working on one feature, notice something that could be improved, start refactoring it, discover another problem, research a new approach… and suddenly three hours have disappeared and you’re nowhere near what you originally set out to do.

Daily Goals

A clearly defined daily goal gives you something to anchor yourself to.

You can still explore. You can still experiment. But you always have a destination for the day.

For me, a good daily goal should be (MASS):

Meaningful: it should move the product forward, even if only slightly.
Achievable: something I genuinely have time to complete.

Simple: clear enough that I don’t spend half the day deciding what to do.

Small: scoped to fit within the day.

And there’s one task I always want to finish the day with:

Review tomorrow’s agenda.

Before closing the laptop, decide what tomorrow’s small win looks like.

That way, when you sit down the next morning, you’re not asking:

“Where do I start?”

You already know.

The Long Eye tells you where you’re going.

The Short Eye tells you what to do next.

Keep the steps small, stay out of the rabbit holes, and keep moving forward.

Think big. Plan small. Ship every day.

Those Who Swift - Issue 280

Wed, 19 Aug 2026 20:31:22 GMT

Weekly note ✏️

This week’s articles share a common thread: frameworks can change significantly beneath APIs that look exactly the same.

SwiftUI’s compiler performance is improving, @State has a new underlying implementation, and developers are still debating whether the framework’s long-standing limitations are acceptable. Together, these pieces show why understanding the mechanism—not just the API—often leads to faster debugging and better engineering decisions.

Have you ever had to investigate a SwiftUI or UIKit behavior that the documentation couldn’t explain? Hit reply—I’d love to hear what you found.

Under SwiftUI's Hood, Nothing Is As Simple As It Looks

with Divya Ravi — Technical Editor, iOS engineer

Seven years after its introduction, SwiftUI still asks developers to trust a considerable amount of hidden machinery. This week’s reading made a strong case for looking beneath that abstraction.

Start with ContentBuilder. Apple introduced it at WWDC26 as a way to improve SwiftUI type-checking performance. But as Fatbobman explains, the improvement does not come from adding another builder type. It comes from restructuring the shared builder APIs used by containers such as Group and ForEach.

By relying on TupleContent and deferred conditional conformance, SwiftUI gives the type checker less work to perform. The code developers write remains largely unchanged, while the compiler does substantially less work behind the scenes.

That distinction matters. When build performance improves without an obvious source change, it is easy to treat it as compiler magic. Understanding the implementation gives us something more useful: a clearer mental model for why certain view structures are expensive and why newer APIs may compile faster.

A similar change is happening with @State.

Stewart Lynch found that in Xcode 27, @State is implemented as a macro rather than a property wrapper. The syntax remains familiar, but the initialization behavior changes in an important way.

Previously, the initializer expression could be evaluated during every view recreation, even when SwiftUI ultimately preserved the existing state value. With the macro implementation, that expression is evaluated lazily.

For a simple integer or Boolean, the difference is unlikely to matter. For state initialized through a database lookup, file operation, or expensive computation, it can eliminate work that developers may not have realized was happening.

These two changes approach the same problem from different directions. ContentBuilder improves compiler behavior beneath a stable API, while the new @State implementation changes the underlying mechanism without changing how the declaration looks. Both improvements are nearly invisible unless someone profiles the behavior, examines the generated code, or asks why the result changed.

That brings us to Yakov Manshin’s “SwiftUI After 7 Years: A Story of Mediocrity,” a deliberately sharp retrospective that generated more than 300 comments on Hacker News.

His central argument is difficult to dismiss completely: after seven years, “it is still a young framework” becomes a less convincing explanation for persistent problems. Focus management, drag-and-drop, platform inconsistencies, and difficult edge cases have survived several release cycles.

I do not agree with every conclusion in the article, but the larger tension is real. SwiftUI’s internals continue to improve, while some visible limitations remain stubbornly familiar.

Those are separate measures of maturity. Compiler performance can improve dramatically while developers still struggle with basic interactions. A framework can gain powerful new APIs without resolving gaps in older ones. When we say SwiftUI has come a long way, it is worth being precise about which part of SwiftUI we mean.

Chang-Jui Lin’s article on building an EPUB reader with CoreText offers a practical counterpoint. Instead of adapting a WebView or relying on a higher-level text component, Lin built directly on CoreText to support reflowable content, fixed layouts, media overlays, and bidirectional text.

It is a much lower level of abstraction—and a much larger engineering commitment. But it also provides the control required for a problem that higher-level frameworks do not solve cleanly.

That is not an argument for rebuilding every framework primitive. Most abstractions are valuable precisely because they prevent us from owning that complexity. But when an abstraction becomes the constraint, understanding the layer below it can reveal options that are otherwise easy to miss.

The broader lesson from this week is not that SwiftUI is good or bad. It is that no framework should remain a complete black box.

The engineers who diagnose difficult problems fastest are often the ones willing to inspect the generated code, profile the rebuild, trace the macro expansion, or move down the stack when the current abstraction stops being useful.

Frameworks will continue to improve while retaining frustrating gaps—sometimes within the same release. The durable skill is learning how to investigate what the framework is actually doing. That understanding makes debugging faster, design decisions clearer, and point-release surprises far less surprising.

What is the last SwiftUI, UIKit, or Swift behavior you had to reverse-engineer because the documentation did not explain enough?

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay

Researchers document a WebKit issue that can expose a user’s real IP address and DNS queries while using proxy-based browsers or iCloud Private Relay. Important context for teams making privacy guarantees around WebKit-based experiences.

📍Level: Intermediate

Coding 👨‍💻

How to stream SSE with URLSession in Swift

A practical implementation of Server-Sent Events using URLSession.bytes(for:), along with a small test server. Particularly useful for apps consuming AI responses or other incrementally delivered data.

📍Level: Intermediate

Type-safe JSON and JSONB in StructuredQueries

StructuredQueries 0.35 introduces schema-checked support for JSON and JSONB data in SQLite. The article shows how to retain type safety while working with semi-structured local data.

📍Level: Advanced

Using Top Functions Mode in Instruments to Quickly Find the Slowest Code

A concise guide to the Top Functions view in Xcode 26.4’s profiling instruments. Sorting by self-weight and inspecting flame graphs can make it much easier to identify where execution time is actually being spent.

📍Level: Intermediate

Installing simulator runtimes from the command line

Command-line steps for installing simulator runtimes when Xcode 27 beta remains stuck on “fetching download information.” A useful workaround to keep nearby when the graphical installer fails.

📍Level: Intermediate

Sendable and @Sendable closures explained with code examples

A clear explanation of Sendable types and @Sendable closures, with examples showing how values move safely across concurrency boundaries. A solid reference when working through Swift 6 strict-concurrency warnings.

📍Level: Intermediate

Taking control of toolbar items in SwiftUI

Explores SwiftUI toolbar placement, customization, and platform-specific behavior. Helpful for interfaces where the default toolbar layout does not provide enough control or consistency.

📍Level: Intermediate

Apple 🍏

Get ready for new creative assets on the App Store

Apple previews new creative and marketing asset options for App Store product pages. Worth reviewing before planning your next product-page update or launch campaign.

TestFlight Update

The latest TestFlight release notes, covering recent changes to Apple’s beta-distribution workflow. A quick check before your next external-testing cycle may save some surprises.

AI & Tooling 🤖

Using Cursor in Xcode 27

A hands-on guide to connecting Cursor to Xcode 27 through Agent Client Protocol support. It offers an early look at how external coding agents can participate directly in an Xcode-based workflow.

📍Level: Intermediate

Build a Local Codex Token Usage Ledger Without Replay Errors

A practical fix for tracking token usage across Codex/Claude coding-agent sessions without hitting replay errors — useful if AI agents are part of your build pipeline, even outside the Swift/iOS-specific tooling this newsletter usually covers.

📍Level: Intermediate

Tutorials 📒

Recording VoiceOver on iOS & macOS

A practical guide to capturing VoiceOver audio for accessibility testing, bug reports, and demos. iOS supports the workflow through screen recording, while macOS requires a virtual-audio device.

📍Level: Intermediate

Community🤝

SwiftUI should become Open-Source

Makes the case that open-sourcing SwiftUI could help developers diagnose and address long-standing issues such as keyboard focus and drag-and-drop. Even if the proposal feels unlikely, the argument raises useful questions about framework transparency and community participation.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: From XCUITest to Promo Video

Sun, 16 Aug 2026 19:30:07 GMT

Another Sunday, another gem from top developers for you!

This week, our guest author is Noam Efergan, a Senior Mobile Engineer at Yazio specializing in iOS development.

A self-taught developer based in the UK, he’s also a technical writer with a particular interest in CI/CD, automation, and modern mobile development practices.

Beyond his engineering work, Noam is a core member of the SwiftLeeds team and an active contributor to the iOS community, sharing his experience through articles, conference talks, and open discussions about mobile engineering.

Let’s see how a coding task can lead to a marketing video matching the latest updates.

P.S. You can check out Noam’s work on LinkedIn, X, and website.

Treating Marketing Assets Like Build Artifacts

Every time I made a meaningful change to Dee’s interface, I created a second task for myself: remake the marketing.

A label moved, a timer changed, or a new state appeared. Suddenly an App Store screenshot was stale, a clip no longer matched the product, or a translated screen had to be recorded again. Recreating the right state by hand was often slower than the UI change itself. Timers kept moving, animations settled at different moments, and sample data was never quite identical.

That is a familiar indie developer problem. The person building the product is also producing the screenshots, launch posts, and promo videos. Repeating fragile setup work is a poor use of that person’s time.

I eventually stopped treating marketing assets as files I created manually. I started treating them as build artifacts that should be reproducible from the real app.

The raw source is the real SwiftUI workout screen, launched with controlled data and time

Start with an Exact SwiftUI State

Dee is a Muay Thai training app with time-based workout screens. That makes manual capture especially awkward. By the time I navigate to the correct round, dismiss the right controls, and start recording, the timer has already changed.

The solution begins inside the app. In debug builds, a launch argument selects a named marketing state. Each state creates the same typed models used by the product, but with controlled input. A frozen clock stops the timer from drifting while XCTest waits for the interface.

#if DEBUG
enum MarketingScreenshotSeed {
    static let launchArgument = “-AppStoreScreenshotMode”

    enum Mode: String, CaseIterable, Sendable {
        case roundTimer = “round-timer”
        case restNext = “rest-next”
        case liveActivity = “live-activity”
    }

    static func makeClock() -> TestClock {
        TestClock(now: Date(timeIntervalSince1970: 1_800_000_000))
    }
}
#endif

The important part is not the particular launch argument. It is the boundary. Marketing fixtures control dependencies and data, but they do not replace the production view with a separate mock screen. If I change the actual workout layout, the next capture contains that change.

Keeping the fixtures debug-only also prevents this tooling from becoming a hidden route through the release app.

Let XCUITest Operate the Camera

Once the app can launch directly into a stable state, XCUITest becomes a reliable camera operator. The test starts the requested mode and locale, waits for the real screen, and stores the screenshot as a named attachment.

private func captureMarketingLocale(_ locale: String) {
    for (name, mode) in marketingScreens {
        let app = launchWorkout(locale: locale, mode: mode)
        settle(seconds: 1.5)

        let attachment = XCTAttachment(screenshot: app.screenshot())
        attachment.name = “\(locale)_\(name)”
        attachment.lifetime = .keepAlways
        add(attachment)

        app.terminate()
    }
}

I currently run the capture flow across six locales. Locale is just another launch input, so translated screens follow the same path as English instead of becoming a separate manual checklist.

Animations introduced another source of flakiness. A view can be accessible before the simulator has produced a complete frame. For the more animated screens, the test samples screenshots until it receives the same PNG twice. If the compositor never settles, the test fails rather than quietly exporting a broken image.

That failure is useful. When a UI change invalidates a fixture or makes a screen unstable, I find out during capture. I do not discover it weeks later while assembling launch material from an old folder.

Move from XCTest to Remotion

The XCTest attachments are extracted from the result bundle and copied into a small marketing workspace. From there, Remotion turns the real app captures into code-driven vertical video.


  
    
      
    
    
    
      
    
  

  {deeCueAudioPath ? (
    
      
    
  ) : null}

The composition controls timing, transitions, captions, framing, and audio. The current example renders at 1080 by 1920, 30 frames per second, and 12 seconds. It uses Dee’s captured screens, and the composition can include a cue copied from the app’s shipped resources rather than recreating the interface or sound for the advertisement.

The product produces the evidence. The marketing layer selects, composes, and validates it.

I also added a capture manifest and hashes around the process. The manifest binds the exact screenshots, audio, and composition properties used by a render. Preflight checks dimensions, captions, asset provenance, and whether inputs changed after capture. Human review remains the final step.

This is more machinery than a single promo clip needs. It becomes valuable because the output is recurring. One source capture can support App Store screenshots, social video, carousels, and localized variants without pretending that a design mock is the shipping product.

What was Worth Automating

Coding agents helped me move faster through repetitive plumbing, test cases, and review. They were useful for tracing asset paths and checking consistency across the Swift and TypeScript sides. They did not decide what the product should claim, which screen represented it honestly, or whether the final creative was ready to publish. Those decisions stayed with me.

The pipeline still has a maintenance cost. Fixtures must evolve with the app. UI tests need care around animations and simulator behaviour. Remotion adds another toolchain. If I needed one screenshot for one launch, I would take it manually.

I would consider this approach when an app has dynamic screens, several locales, frequent UI changes, or an ongoing need for product content. Start with one painful state, not a complete marketing platform. Add a launch argument, freeze its dependencies, capture it in a UI test, and only automate the next stage when repetition justifies it.

The larger lesson for me is that testability has uses beyond tests. When an app can reproduce an exact state on demand, it becomes easier to debug, demonstrate, localize, and market. The best part of this workflow is not that it produces a video. It is that the video remains connected to the product that users will actually open.

Those Who Swift - Issue 279

Wed, 12 Aug 2026 20:30:39 GMT

Weekly note ✏️

Swift concurrency stopped being the scary new thing a while ago — it’s just how we write Swift now. But “we adopted it” and “we understand it” are different claims, and this week’s picks live in the gap between them. The theme: concurrency that’s grown past the tutorials and into the parts of real apps where the edges actually are.

Wrestling with an isolation error that makes no sense? Reply — those are the best ones to dig into together.

The Delegate Is Dead. Long Live the Actor.

with Divya Ravi — Technical Editor, iOS engineer

Every Apple framework of a certain age carries the fingerprints of the era it was born in. Open CoreBluetooth, or CoreLocation, or any of the old guard, and you’re not just reading an API — you’re reading 2011. The delegate pattern everywhere. State machines you assemble by hand across six callbacks that fire in an order the compiler knows nothing about. A “did” method for every possible thing that could happen, and a strong-reference dance you have to get exactly right or the whole thing quietly deallocates out from under you.

For a decade, that was just the cost of doing business on Apple platforms. We learned it, we internalized it, and we mostly stopped noticing how strange it was. You want to read one value off a Bluetooth sensor? Sixty lines, seven delegate methods, and a comment somewhere that says // now what? for the disconnect case nobody fully handled.

What’s happening in Swift right now is the slow, deliberate dismantling of that world — and I don’t think we talk about it plainly enough. Structured concurrency didn’t just give us a nicer way to write async code. It changed what the shape of correct code looks like. The delegate era scattered your logic across callbacks because callbacks were the only tool for “tell me when this happens later.” Async/await collapsed that back into something you can read top to bottom: wait for the radio, find the device, connect, stream the readings. The program finally looks like the sentence you’d use to describe it.

But here’s the part I actually want to make the case for, because it’s subtler than “async is nicer.” The real shift isn’t syntax. It’s who enforces correctness. In the delegate world, thread-safety was a promise you made to yourself in a comment — “these callbacks arrive on this queue, so be careful.” Nobody checked. You just had to be right, every time, forever, including the time six months from now when a tired version of you touches that file at 4pm on a Friday. Swift 6’s isolation model takes that promise and hands it to the compiler. The actor doesn’t ask you to be careful about which context your state is touched from. It makes touching it from the wrong context not compile.

That is a genuinely different relationship with your own code. And it’s why the isolation errors everyone complains about are, I’d argue, mostly a good thing wearing an annoying costume. When the compiler rejects your code with some knotty message about a non-Sendable type crossing an actor boundary, it is usually not being pedantic. It’s telling you about a data race that, in the old world, would have shipped — and surfaced three weeks later as a one-in-ten-thousand crash you could never reproduce. The friction moved earlier. That’s the whole trade. You pay at compile time instead of paying at 2am when the pager goes off.

The catch — and there’s always a catch — is that the model is subtle exactly where it matters most. Protocols and global actors interact in ways that surprise even people who’ve been doing this for years. The difference between isolating a protocol, a conformance, and a requirement is real, and getting it wrong produces errors that feel arbitrary until the mental model clicks. That’s the actual work of this era: not memorizing which keyword goes where, but building an intuition for what the compiler is protecting you from, so the errors read as help instead of harassment.

So if you’ve been treating Swift concurrency as a box you check — “yes, we migrated, yes, it compiles” — I’d gently push on that. The migration is the easy part. The understanding is the part that pays off, because it’s the difference between fighting the compiler and letting it do the thing it’s uniquely good at: proving, before your code ever runs, that an entire category of bug simply cannot happen.

The delegate taught us to be careful. The actor lets us stop having to be. That’s not a small upgrade. That’s the ground moving.

What concurrency concept finally clicked for you — and what’s still fighting you? Hit reply. The best answers make next week’s issue.

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

What's New in Swift: July 2026 Edition

The official Swift.org digest rounds up the month across the project — releases, evolution proposals, community talks, and the news that Swift now runs in a broader range of IDEs including Cursor, VSCodium, Kiro, and Antigravity via the Open VSX Registry.

📍Level: Beginner

Coding 👨‍💻

Managing Focus in SwiftUI with FocusState

Natascha Fadeeva on driving focus properly in SwiftUI — FocusState, programmatic focus changes, and the keyboard-management details that make forms feel right.

📍Level: Intermediate

SwiftUI Document APIs in the 2027 Releases: Everything You Need to Know

Sagar Unagar on the new Document protocol — snapshot-based updates, efficient disk access, and how it layers on top of the existing FileDocument world without breaking it.

📍Level: Advanced

Using SwiftUI's ContentBuilder with Non-View Types

Artem Novichkov digs into ContentBuilder — the unified builder replacing per-container overloads — and how to use it with non-view types, plus what it means for compile times.

📍Level: Advanced

iOS 27: Working with the Media Intelligence Framework

Anton Gubarenko digs into iOS 27’s new Media Intelligence framework — what it exposes, what it’s actually good for, and where it fits alongside the existing media APIs.

📍Level: Intermediate

Apple 🍏

Hello, Developer: August 2026

Apple's monthly developer digest for August — a guided tour of the biggest WWDC26 updates, a walkthrough of building App Store assets for iOS 27, and a profile of the team behind the hit game "Is This Seat Taken?"

Design 🎨

Concentric Buttons with OS 27's SwiftUI APIs

Alexander Weiss on the new concentric-shape APIs in OS 27 — building nested, concentric button shapes that stay aligned the way the new design language expects.

📍Level: Intermediate

Adaptive SwiftUI Toolbars in iOS 27

Natalia Panferova on the new adaptive toolbar behavior in iOS 27 — how toolbars reflow across size classes and what you get for free versus what you still configure.

📍Level: Intermediate

AI & Tooling 🤖

Using AI Without Losing Your Critical Thinking

Bruno Rocha on staying sharp while leaning on AI tools — a thoughtful, non-hype take on where agents genuinely help and where offloading judgment quietly costs you.

📍Level: Beginner

How to Use Git Worktree — and How AI Agents Use It

Mohammad Faani on git worktrees — the underused feature that lets you check out multiple branches at once, and why it's suddenly relevant as AI agents work across branches in parallel.

📍Level: Intermediate

Video 🎥

Previewing SF Symbols with Apple's Own Renderer

Amy Worrall wires up Apple's own SF Symbols renderer to preview symbols exactly as the system draws them — a neat bit of tooling for anyone who's been squinting at approximations.

📍Level: Advanced

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Devs for Devs: Preparing Your Apps for iOS 27

Sun, 09 Aug 2026 20:30:33 GMT

Hey, the Those Who Swift team is here! 👋

Not on Wednesday as usual, from now on we’ll see each other twice a week. Welcome to our new newsletter segment, “Devs for Devs”

We used to run a whole separate newsletter for this called “Indie App Devs” Now, every Sunday, we’ll feature a new segment from world-class, well-known devs here.

We’re starting with Natalia Panferova. I’m sure she doesn’t need to be introduced to you. She’s a software engineer, author, and former member of Apple’s core SwiftUI team, where she helped design and build SwiftUI APIs.

She has worked with startups and large companies across Europe and New Zealand, building web and mobile applications.

And without further ado, let’s jump into today’s topic and prepare our apps for iOS 27.

P.S. You can check out Natalia’s work on LinkedIn, X, and her website.

Since WWDC, I’ve been spending a lot of time exploring the changes coming in iOS 27 and working through what they mean for the apps I maintain, from rebuilding them with Xcode 27 and testing layouts at different sizes to reviewing SwiftUI changes that may affect existing code.

There are plenty of new APIs to explore, and it’s always tempting to start adding them straight away. But for an existing app, I think it’s more useful to begin by checking how well it works with the new SDK and system behavior. Much of this preparation isn’t about adopting new APIs at all. It’s about making sure existing layouts work when the app is resized, reviewing the visual changes that come from rebuilding with Xcode 27, and addressing new compiler errors and warnings in existing SwiftUI code.

The amount of work will be different for every app, but these are the main areas I’d recommend reviewing.

Supporting Resizable iPhone Apps

One of the most significant changes in iOS 27 is that iPhone apps can now appear at more flexible sizes. This makes it increasingly difficult to assume that an iPhone app will always run in a narrow portrait window or at one of a small set of familiar screen dimensions.

Until recently, our walking app Strolly only supported portrait orientation on iPhone. It makes heavy use of non-modal sheets placed over a map, allowing users to adjust their route preferences while continuing to interact with the content underneath. When we added landscape support in preparation for iOS 27, we found that the system sheet didn’t preserve its non-modal presentation after rotation. It became a full-screen sheet and covered most of the map.

We ended up building an adaptive panel that appears along the bottom in a narrow layout and moves to the trailing edge when enough width becomes available. The layout decision is based on the actual scene width rather than the device type or horizontal size class. This lets the same presentation adapt to iPhone rotation, iPad multitasking, and window resizing.

Not every app will need a custom presentation, but it’s worth checking for similar assumptions throughout the interface. Fixed frames, hard-coded screen dimensions, and layouts that switch only on device idiom can all become problematic when the available space changes.

Xcode 27 includes resize handles in SwiftUI previews and a resizable iOS simulator, which make it easier to test a range of widths without relying only on predefined devices. I’d pay particular attention to toolbars, sheets, overlays, forms, keyboards, and any screen that places several controls side by side.

It’s also important to check that state remains stable while the available size changes. Controls shouldn’t disappear or become difficult to reach, and resizing shouldn’t unexpectedly reset navigation, scroll position, selections, or data owned by the view hierarchy.

Reviewing the Liquid Glass Appearance

Apps built with Xcode 27 automatically receive the latest refinements to the Liquid Glass design. Many of these changes come through standard SwiftUI and UIKit components, so rebuilding the app and inspecting the result should come before adding custom glass effects.

Navigation bars, tab bars, sheets, menus, toolbars, and standard controls may all look slightly different. Custom interfaces can also produce unexpected results when they place translucent controls over photographs, maps, gradients, or similarly colored content.

I’d test these screens with accessibility settings such as Increased Contrast and Reduce Transparency. Users have more control over the appearance of Liquid Glass in iOS 27, so the interface should remain clear across those variations rather than depending on one specific level of transparency.

Toolbars need some extra attention now that apps can appear at more sizes. Xcode 27 adds SwiftUI APIs for controlling which toolbar items remain visible and which move into the overflow menu. We can assign a visibility priority to important groups, deliberately place less frequently used actions in a ToolbarOverflowMenu, and use the topBarPinnedTrailing placement for an action that should always remain available.

Before adopting these APIs, I’d resize the existing toolbar and see what the system does by default. Standard behavior may already be sufficient. Where it’s not, the new controls let us express which actions are most important without replacing the system toolbar with a custom implementation.

Building the Existing App with Xcode 27

I like to begin a new SDK migration by building the existing project before introducing any new features. This keeps compiler errors and warnings caused by the new SDK separate from issues introduced while adopting new APIs.

Building with Xcode 27 brings a few SwiftUI changes worth checking. One of the most notable is that @State is now a macro rather than a property wrapper. This fixes a long-standing performance issue when an @Observable class is used as the default value of a state property. The initial expression is now evaluated lazily, so the observable model is created only when SwiftUI sets up the state storage rather than every time the view value is recreated.

We should still avoid assigning an observable model to @State inside a view initializer. This creates a new model whenever the initializer runs, even though SwiftUI preserves only the first value in its state storage. If the model depends on changing input from the parent, it can also retain stale data because later assignments are ignored.

Custom environment values are another area to check. Xcode 27 now warns when an @Entry declaration creates a new class instance directly in its default expression. Every fallback environment lookup would otherwise return a different reference, which can make SwiftUI treat the value as changed and reevaluate dependent views unnecessarily.

Some existing view expressions can produce new ambiguity errors because SwiftUI’s result builders are now unified under ContentBuilder. For example, expressions passed directly to overloaded APIs such as overlay and background may need to use their trailing-closure variants so the compiler can select the intended overload.

Adopting New SwiftUI APIs

Once the app builds and works correctly, we can start looking for places where the new APIs solve an existing problem or let us remove custom code.

Swipe actions are no longer limited to rows inside a List. In iOS 27, applying swipeActionsContainer() to a ScrollView enables coordinated swipe actions for rows in a LazyVStack, LazyVGrid, or custom layout.

SwiftUI also has new native reordering APIs for stacks, grids, and other containers. We apply reorderable() to the dynamic content and reorderContainer(for:) to the enclosing container. SwiftUI manages the drag preview, insertion placeholder, and animation, while the app receives a ReorderDifference to apply to its model.

AsyncImage has gained new initializers that accept a URLRequest, giving us control over request headers, cache policy, and timeout without requiring a separate image-loading implementation. A new asyncImageURLSession() modifier can provide a custom session to asynchronous images in part of the view hierarchy.

These are all useful improvements, but an app doesn’t need to adopt them simply because they are new. I’d start with areas where the current implementation is limiting the interface, requires significant custom coordination, or has been difficult to maintain.

If the app continues supporting older versions of iOS, new APIs will also need an availability strategy. In some cases, the new behavior can be an enhancement on iOS 27 while the existing implementation remains as the fallback. In others, it may be better to wait until the deployment target can move forward rather than maintain two complicated code paths.

Testing Before the Public Release

An app prepared for iOS 27 still needs to work correctly on every version it supports. I’d test the main flows on both iOS 27 and the oldest supported system, paying particular attention to code guarded by availability checks.

Accessibility and localization can expose layout issues that don’t appear with default settings. I’d check the main screens with large Dynamic Type sizes, VoiceOver, Increased Contrast, Reduce Motion, and longer localized strings. These tests become especially useful alongside resizing because the most difficult layouts often combine a narrow width with larger content.

For performance-sensitive apps, Instruments 27 adds Run Comparisons for measuring changes between profiling sessions and expands the Swift executors instrument for investigating work running on the main actor and other executors. iOS 27 also introduces a new Swift-first MetricKit API. It continues to deliver app-health metrics and crash and hang diagnostics, while adding memory exception diagnostics and the ability to break metrics down by app-defined states.

Finally, I’d avoid leaving all of this work until the last beta. APIs and behavior can still change throughout the beta period, but testing early gives us more time to report issues through Feedback Assistant and adjust the app without rushing just before the public release.

SwiftUI Books with 20% off! 📚

New SDK releases are exciting, but they also remind me how important it is to understand the behavior behind the APIs we use. Many of the issues Xcode 27 now helps us identify are related to the same fundamental topics we deal with every year: view identity, state ownership, data dependencies, layout, and performance.

I cover these foundations in SwiftUI Fundamentals, which explains SwiftUI’s core principles and underlying mechanisms in depth. My newer book, The SwiftUI Way, builds on that foundation with practical guidance for structuring production apps, managing data flow, minimizing unnecessary view updates, and avoiding subtle anti-patterns as projects grow.

Both books include free lifetime updates. I recently released a substantial update to “The SwiftUI Way” with expanded guidance on data flow, view performance, stable custom bindings, environment values, and the changes to @State in Xcode 27.

Readers of this newsletter can use the coupon code ThoseWhoSwift" to get 20% off any of my books or book bundles until the end of August. You can find all the available options on the Nil Coalescing books website.

Those Who Swift - Issue 278

Wed, 05 Aug 2026 20:00:46 GMT

Weekly note ✏️

iOS 27 shipped, and now the real work starts — not adopting the shiny new features, but finding where they rub against the app you’ve already built. Liquid Glass is the most visible example: stunning in the keynote, strange in a UIKit view that predates it by a decade. But it’s the same story across the cycle — the gap between what demos cleanly and what survives contact with a real, aging codebase. This week is about that gap, and the field notes people are writing as they hit it.

Hit an iOS 27 surprise in your own app? Reply and tell me — I’m collecting the good war stories.

When the Glass Meets the Girder

with Divya Ravi — Technical Editor, iOS engineer

There’s a particular moment in every major design transition that nobody puts in the keynote. It’s the moment you build your project against the new SDK, launch the app you’ve shipped for years, and watch something you didn’t touch look subtly, unmistakably wrong. A button with the wrong corner. A bar that doesn’t blur where it used to. A control that was crisp yesterday and is now floating in a way you never asked for. Welcome to Liquid Glass in production.

I want to talk about that moment honestly, because the discourse around a new design language tends to split into two unhelpful camps. One says it’s gorgeous and you should adopt it everywhere immediately. The other says it’s a regression and you should fight it. Both miss the actual engineering reality, which is more interesting and more useful: a system-wide design language is not a coat of paint you apply. It’s a set of assumptions the framework now makes about your views — and the friction you feel is the distance between those new assumptions and the ones your codebase was built on.

Here’s the thing about Liquid Glass specifically. It’s a material, and materials are contextual by nature. A glass button assumes it sits on top of something worth seeing through. A minimizing bar assumes there’s content behind it that benefits from the effect. These are reasonable assumptions — until they meet a ten-year-old UIKit view hierarchy that was architected when every surface was opaque and every layer was flat. The framework does its best to adapt your old views to the new material, and most of the time it succeeds. The pitfalls live in the cases where it can’t, and those cases are exactly the ones a keynote demo will never show you, because keynote demos are built fresh, in the new world, with none of the accumulated assumptions of a real app.

This is why “just adopt it” is bad advice and “just fight it” is worse. The right posture is the one experienced engineers take toward any system-level change: understand what the framework now assumes, audit where your app violates those assumptions, and decide — deliberately, view by view — where to adapt and where to opt out. Liquid Glass gives you compatibility escape hatches for a reason. They’re not admissions of failure. They’re the framework acknowledging that your app has history, and history has weight.

The deeper lesson here isn’t about glass at all. It’s about what a design language actually is, underneath the marketing. It’s a contract about how surfaces relate to each other — depth, translucency, hierarchy, motion. When Apple changes that contract, every view you own is silently re-signed under the new terms, whether you read them or not. The apps that transition well aren’t the ones that adopt fastest or resist hardest. They’re the ones that treat the new contract as something to actually read — to understand where their existing UI agrees with it, where it conflicts, and where a five-minute opt-out saves a week of chasing a visual bug that was never a bug, just a disagreement about assumptions.

And Liquid Glass is only the most visible instance of a pattern that runs through this whole release. The same gap shows up everywhere real apps meet iOS 27: in the rendering model, in the architecture decisions that determine how easily you adapt, in the long-standing rough edges the framework quietly smoothed while you weren’t looking. The friction isn’t a bug in the release. It’s the tax every mature codebase pays when the platform moves — and the apps that pay it cheaply are the ones built to bend.

So if you’re staring at a control that looks wrong this week and you didn’t change it, you’re not losing your mind. The framework changed the terms. Go read them — the field guides are already being written, and the good ones map the pitfalls before you fall in. That’s the whole job this cycle: not adopting blindly, not resisting reflexively, but understanding precisely where the new platform meets the girder of everything you already built.

What’s the strangest Liquid Glass behavior you’ve encountered in a real app? Hit reply—the best examples may appear in next week’s issue.

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Swift Protocols and the Main Actor

John Sundell on how actor isolation actually works with protocols — one of those foundational topics that quietly trips up even experienced developers as concurrency tightens.

📍Level: Advanced

Stop Using @unchecked Sendable

Soumya Mahunt makes the case against reaching for @unchecked Sendable as an escape hatch — what it really costs you, and the safer patterns that get you the same result.

📍Level: Advanced

Introducing ListKit: An Open-Source Library for SwiftUI Lists

Daniel Saidi open-sources ListKit — reusable view components and extensions for the list problems everyone re-solves from scratch, from sectioning to selection to reordering.

📍Level: Intermediate

Coding 👨‍💻

Demystifying Thread Hopping with Swift 6.2 Approachable Concurrency

Nikita Vasilev breaks down what actually happens when your code hops threads under Swift 6.2's approachable concurrency — and how to reason about it instead of guessing.

📍Level: Intermediate

New in SQLiteData: Sectioned Queries

Point-Free adds sectioned queries to SQLiteData — a clean way to drive sectioned SwiftUI lists straight from your database without hand-rolling the grouping.

📍Level: Intermediate

Apple 🍏

Hello Developer: July 2026

Apple's monthly developer digest rounds up the latest across the 27 platform releases — new documentation, sample code, and release notes, plus design resources and WWDC26 follow-ups worth a scan.

Design 🎨

Keeping Canvas Interactions Responsive with Frame Reprojection

Matthaus Woolard on maintaining responsive canvas interactions under the new rendering model using frame reprojection — a look under the hood of how modern SwiftUI stays smooth under load.

📍Level: Advanced

AI & Tooling 🤖

The iOS Testing Strategy Agent Skill

Artem Mirzabekian shares an agent skill built around a practical iOS testing strategy.
It’s a useful example of turning team conventions—what to test, how to structure tests, and which edge cases matter—into repeatable instructions an AI coding agent can follow.

📍Level: Intermediate

A Sol's Work: Shipping with GPT-5.6 Sol

Rudrank Riyam gives a coding agent a real engineering task, step away fro several hours, and the checks whether the final report matches what actually happened.
An honest account of where long-running agent work succeeds- and where human verification is still essential.

📍Level: Intermediate

Tutorials 📒

Building a Custom In-App Keyboard in SwiftUI

Lee young-jun needed an in-app numeric keyboard and discovered SwiftUI's TextField gives you no clean hook for it — so he went spelunking through the UIKit view hierarchy to find the underlying UITextField and swap its inputView. A genuinely instructive walk through the messy reality of bridging SwiftUI and UIKit, dead ends included, ending with a sharp note on why banking and OTP apps ship custom keyboards in the first place.

📍Level: Advanced

Shipping a SwiftData App with iCloud Sync

Thorsten Stark walks through taking a SwiftData app from local persistence to multi-device CloudKit sync, including model constraints, container setup, and duplicate- record problems caused by concurrent device updates.

📍Level: Intermediate

Video 🎥

SwiftUI Image Caching Explained: Faster Lists and Better Performance

Stewart Lynch explains image caching in SwiftUI end to end — why uncached liimage loading hurts scrolling performance, how a caching layer helps, and how to build one clearly.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Those Who Swift - Issue 277

Wed, 29 Jul 2026 20:01:55 GMT

Weekly note ✏️

Last week the iOS 27 beta landed and everyone braced for what breaks. This week is the other side of that coin — the quiet, genuinely useful APIs Apple slipped into iOS 27 that make code you already write simpler. The stuff that never gets a keynote slide, but shows up in your codebase for years.

Got a favorite iOS 27 API nobody’s talking about? Hit reply — I’m collecting them.

The AI Agent for Your RevenueCat Data

Meet Rico! 👋

RevenueCat’s embedded AI app growth advisor for subscription apps. Ask questions about churn, trials, pricing, paywalls, or retention and get answers using your app’s real subscription data directly inside RevenueCat and Slack.

Built to help iOS developers make smarter monetization decisions faster.

Try Rico today!

The Quiet Half of iOS 27

with Divya Ravi — Technical Editor, iOS engineer, creator of FoundationModelsKit

Every WWDC has two halves. There’s the loud half — the keynote feature, the framework everyone live-tweets, the thing that lands on every “what’s new in iOS 27” listicle by Tuesday afternoon. And then there’s the quiet half: the small API refinements that never trend, never get a session to themselves, and turn out to matter far more to your day-to-day code than the headline act ever will.

I want to make the case for the quiet half — because this year it’s unusually good, and because the quiet changes are the ones that actually change how you write things.

Here’s the pattern I keep noticing in iOS 27. For years, a whole category of ordinary UI work lived in an awkward middle ground: not hard exactly, but not supported either. Swipe actions only worked inside List. Reordering only worked inside List. Adaptive panels meant hand-rolling a detent system and hoping it behaved in landscape. Toolbar customization meant quietly fighting the framework’s defaults. You could do all of it — you just did it by working around the framework instead of with it. Every iOS codebase of a certain age has a folder full of these workarounds, and everyone who’s touched one knows the specific dread of opening it.

What iOS 27 quietly does is close a lot of those gaps at once. Swipe actions work outside List now. Reordering has real APIs instead of a custom drop-delegate dance. Size classes gave way to a more honest model of available space — which suddenly matters, now that iPhone apps resize. None of these got a dramatic reveal. All of them delete code you currently maintain.

And that’s the real point, the one I’d underline twice. The loud features add capability — new things your app can do. The quiet features remove liability — workarounds you no longer have to own. Those two are not equally valuable, and we consistently act like they are. A new capability is something you adopt when you have the time and the reason. A removed workaround is tech debt that stops being your problem the moment you migrate — no adoption required, no feature to design, just deletion. And deletion compounds. Every custom reordering implementation you delete is code you no longer test, no longer debug, no longer explain to the engineer who inherits that file in eighteen months.

There’s a reason this half gets ignored, and it isn’t laziness. It’s that the quiet changes don’t announce themselves. Nobody writes a breathless thread titled “swipe actions now work in a ScrollView.” It doesn’t demo well. It doesn’t screenshot. But six months from now, the teams that went looking for these changes will have measurably simpler codebases than the teams that only adopted the headline features — not because they’re better engineers, but because they read past the first screen of the release notes.

So here’s my actual advice for this cycle, and it’s almost aggressively practical: before you build anything custom in iOS 27, check whether Apple already built it. The odds this year are genuinely good that they did. The framework spent this release catching up to a pile of things we’ve been hand-rolling for half a decade, and the catch-up is sitting in the quiet half, waiting for someone to notice.

Read the release notes to the end. That’s the whole tip. The loud half will find you on its own — it always does. The quiet half you have to go looking for, and this year, it more than pays for the trip.

This Week in Those Who Swift 🗞️

The latest across Swift, Apple, AI, and the community.

Swift Around the Web 🌐

Understanding Code Signing and Provisioning in iOS

Natascha Fadeeva demystifies the whole signing chain — certificates, provisioning profiles, entitlements — as a practical mental model instead of a black box you fight at build time.

📍Level: Intermediate

Keeping SwiftData Behind a Boundary

Natascha Fadeeva on wrapping SwiftData behind a protocol boundary so your app isn't married to the framework — cleaner tests, easier migration, fewer surprises down the line.

📍Level: Intermediate

Swipe Actions Outside of List in SwiftUI

Majid Jabrayilov on one of iOS 27’s most overdue additions: swipeActions now works in a ScrollView and custom layouts, not just List.

📍Level: Intermediate

Coding 👨‍💻

Test iOS Apps in Different Time Zones

Antoine van der Lee on catching an entire class of date bugs before your users do — how to actually run your app under a different time zone on a physical device.

📍Level: Intermediate

Apple 🍏

New Business Terms for Link-Out Purchases

Apps that communicate or promote offers for digital goods outside the App Store will be subject to new terms — an initial acquisition fee, a store services fee, and, for the EU External Purchase Link Entitlement, the Core Technology Commission.

On-Demand Resources Are Deprecated in iOS 27

Apple's App Store Connect docs now list On-Demand Resources (and the NSBundleResourceRequest API) as deprecated across iOS 27, iPadOS 27, tvOS 27, and watchOS 27, with support to be removed in a future release. Apple recommends migrating to Background Assets.

Design 🎨

Blend Modes in SwiftUI

Natalia Panferova walks every SwiftUI blend mode through focused visuals and real use cases — and shows how to control exactly which views participate in each operation.

📍Level: Intermediate

AI & Tooling 🤖

User Diagnostics Reports: Solving Bugs Faster with AI Agents

Antoine van der Lee on turning real user diagnostic reports into fixes — feeding crash context to an AI agent and getting back a reviewed pull request instead of a raw stack trace.

📍Level: Intermediate

Tutorials 📒

Bridging Gemini Video with Foundation Models and CustomSegment

Rudrank Riyam routes video through a LanguageModelSession to Gemini — Apple's on-device model takes images but not video, so he bridges the gap with a custom Transcript.CustomSegment and a LanguageModelExecutor, verifying each layer along the way.

📍Level: Advanced

Video 🎥

iOS 27 SwiftUI Updates in Action

A hands-on tour of this cycle's SwiftUI changes in a real project — reorderable views, swipe actions outside List, and the new navigation and presentation APIs, shown in code.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇

Subscribe now

Those Who Swift

Those Who Swift - Issue 287

Weekly note ✏️

If an Agent Can't Read It, It Isn't a Tool Yet

Related reading on this week's theme 📚

This Week in Those Who Swift 🗞️

Swift Around the Web 🌐

Coding 👨‍💻

Apple 🍏

AI & Tooling 🤖

Design🎨

Community 🤝

Devs for Devs: You Are Valuable, Act Like It.

The Battle of the Mind

How I Choose

Wrapping It Up

My Apps

Those Who Swift - Issue 286

Weekly note ✏️

Your Centered Layout Was Never as Stable as You Thought

Related reading on this week's theme 📚

This Week in Those Who Swift 🗞️

Swift Around the Web 🌐

Coding 👨‍💻

Apple 🍏

AI & Tooling 🤖

Design 🎨

Tutorials📒

Video 🎥

Community 🤝

Devs for Devs: Opening In-App Search from Siri with App Intents in iOS 27

Prefer a System Schema When One Fits

Running the Intent in the App

Don’t Assume the Term is Useful

Hand the Search Off to the App

Handling Warm and Cold Launches

Displaying the Results

In-app Search and App Entities Solve Different Problems

Keep System Intents Thin

References

Those Who Swift - Issue 285

Weekly note ✏️

Debuggability Is a Feature, Not an Afterthought

Related reading on this week's theme 📚

This Week in Those Who Swift 🗞️

Swift Around the Web 🌐

Coding 👨‍💻

Apple 🍏

AI & Tooling 🤖

Design 🎨

Tutorials📒

Devs for Devs: Being a Good Developer Isn’t Enough to Build Your Own Product

It Started With Technology — but Technology Wasn’t the Product

The Technical Trap: Making the Product Better Instead of Getting It Into People’s Hands

The Audience Became More Important Than the Feature Set

The Android Request Was More Than an Android Request

The Painful Part: Accepting who the Product Was Actually For

Changing the Design Hurt more than Changing the Positioning

Then Came the App Store Reality Check

Once It’s Your Product, You’re Not Just the Developer

What I Would Do Differently

1. Launch the MVP Earlier

2. Start Marketing Earlier

3. Get Comfortable Changing Your Mind

Should You Build Alone?

The Lesson I Actually Took from Building a Product

Those Who Swift - Issue 284

Weekly note ✏️

Shipping for Hardware You Can't Fully Test Yet

Related reading on this week's theme 📚

This Week in Those Who Swift 🗞️

Swift Around the Web 🌐

Coding 👨‍💻

Apple 🍏

AI & Tooling 🤖

Design🎨

Tutorials📒

Video 🎥

Devs for Devs: A Working App Is Only the Beginning

The First Few Seconds Matter