The struggle between spending more time fixing it or rebuilding the whole view using plain UIKit kept growing. Before taking the final step into the controlled world of UITextField, there was one controversial option left: using introspection to access the underlying field from SwiftUI.

For that, I used one of my favorite libraries — Introspect. But that’s where the story behind this post begins. SPM decided to cause some trouble as well…

Swift Package Manager itself may be fine. Your package URL may be fine. Your repo may even clone normally in Terminal. And still, Xcode’s Add Package Dependency sheet can sit there forever, spinning without validating anything.

That is what makes this bug so annoying: it looks like a networking or SPM problem, but the workaround that helps most often points somewhere else entirely — Xcode’s own remembered package-entry state.

The Symptom

The original report is very specific: Xcode’s Swift Package sheet loads indefinitely whether a URL is entered or not, and clearing DerivedData plus SwiftPM caches does not help. The issue also affects multiple projects, not just one workspace.

That combination is a useful clue.

If the problem survives:

• multiple projects

• empty or filled package URLs

• DerivedData cleanup

• SwiftPM cache cleanup

then the bug is probably not inside your package manifest or repository alone. It starts looking more like Xcode UI state or package-assistant state.

The First Workaround: Clear Package History

1. Open the stuck Add Package screen

2. Right Click on Recently Used

   

3. Clear Recently Used…

4. Try adding the package again

That is already pretty revealing. If clearing history fixes the infinite loader, the issue is not just “SPM cannot resolve packages.” It suggests the Add Package assistant may be choking on recently used package metadata or state associated with that UI.

This is also why the bug feels so strange: the visible failure is “loading forever,” but the successful fix is effectively “wipe the remembered package list.”

The 2nd Workaround: Delete the Preference Key Manually

Here is a more direct workaround:

plutil -remove IDESwiftPackageAdditionAssistantRecentlyUsedPackages ~/Library/Preferences/com.apple.dt.Xcode.plist

I recommend to fully quit the Xcode first, running the command in Terminal, then reopening Xcode and trying again.

The key name is fairly descriptive on its own. It strongly suggests that Xcode stores recently used package references for the package-addition assistant in its preferences plist. Since removing that key can restore the Add Package UI, a reasonable inference is that corrupted or problematic remembered package state can block the sheet before actual validation completes. That is an inference from the key name plus the observed workaround, not an official Apple explanation.

Why Deleting DerivedData Often Does Nothing

This is the important distinction.

DerivedData and SwiftPM caches are usually where developers look first, and for good reason. They help with build artifacts, resolved package state, and repository caches. But, removing both ~/Library/Developer/Xcode/DerivedData and ~/Library/Caches/org.swift.swiftpm/ did not fix the problem.

That lines up with the workaround above. If the issue is in the Add Package assistant’s preferences state, clearing build caches is simply attacking the wrong layer.

In other words:

• DerivedData fixes build and indexing weirdness

• SwiftPM caches fix package cache weirdness

• this bug may live in Xcode’s package-addition UI memory instead

That separation is the whole story.

In IT, you collect new topics and terms throughout your entire career. For me, last month’s discovery was ADR.

I was reading the wonderful book “AI Driven Swift Architecture” by Walid Sassi and Dave Poirier — highly recommended. You can find it on Amazon or directly on the Packt website.

One chapter explained how to make LLM output more deterministic, and one of the approaches mentioned there was ADR. Sharing the details with you.

Useful links:

• What is ADR?

• What is Architecture Decision Record (ADR)? Do I need it?

• ADR Examples
  

But just like Xcode, the Simulator, or any other development tool/service, AI tools need to be tuned and adapted. Even cars have seat, steering wheel, and mirror adjustments.

Pasting a Figma screenshot or exported image is not the same as letting Claude (for example) traverse the structure itself, inspect groups, understand paddings, and consume tokens for actual context. It’s like drawing from a photo versus drawing from a live object. Yes, AI can estimate corner radii or pick colors from an image. But fonts, spacing, hierarchy? That gets complicated.

And I’m only talking about Figma right now. There’s also Notion, Slack, Google Docs, Linear… the list is huge.

Give your CLI a pair of glasses — or a few extra hands — to make its understanding more precise.

Useful links:

• What is MPC?

• Connect MCP in Claude

• Connect Figma MCP

• Connect Notion MCP

• Connect Slack MCP
  

Useful links:

• UIScreen.main

• UITraitCollection.current

• UIWindowScene

• SwiftUI: displayScale
  

scenePhase is SwiftUI’s built-in way to observe scene lifecycle. Apple documents ScenePhase as the operational state of a scene, with values such as .active, .inactive, and .background. Apple also notes that the meaning of the scenePhase environment value depends on where you read it.

That detail matters more than it first appears. Especially, when you have set the architecture once and just adding View by View.

In a pure SwiftUI app lifecycle, @Environment(\.scenePhase) is the natural tool. But once a SwiftUI view is embedded inside a UIKit app through UIHostingController, the lifecycle owner is no longer fully SwiftUI-driven. In that setup, scenePhase can be unreliable or simply not behave the way you expect from a SwiftUI App + Scene structure. Apple’s migration guidance frames scene monitoring as part of moving to the SwiftUI life cycle, which is a strong hint that this API is most at home there.

So the short version is: scenePhase is native to SwiftUI scenes. If your SwiftUI view is hosted inside UIKit, lifecycle tracking is usually more reliable through UIKit notifications.

What is scenePhase in SwiftUI?

In SwiftUI, scenePhase tells you whether the current scene is active, inactive, or in the background. Apple’s docs define ScenePhase around scene state, not generic app state. That distinction is important because scenes and apps are related, but not identical, especially on platforms and configurations that support multiple scenes.

A standard SwiftUI example looks like this:

import SwiftUI

struct ContentView: View {
    @Environment(\.scenePhase) private var scenePhase

    var body: some View {
        Text("Hello")
            .onChange(of: scenePhase) { _, newPhase in
                switch newPhase {
                case .active:
                    print("active")
                case .inactive:
                    print("inactive")
                case .background:
                    print("background")
                @unknown default:
                    break
                }
            }
    }
}

That works well when the app is using SwiftUI’s own lifecycle model.

Why It Can Fail Inside UIHostingController?

A hosted SwiftUI view still renders like SwiftUI, but it does not automatically mean it participates in the same scene lifecycle model as a SwiftUI app root.

That is the real trap. No jokes, from Star Wars.

If the app is UIKit-first, with lifecycle driven by UIApplicationDelegate, UISceneDelegate, and UIKit-managed windows, then the hosted SwiftUI subtree may not receive scenePhase updates in the same way a real SwiftUI scene does. Apple’s documentation does not say that every hosted SwiftUI view will always get full scene lifecycle semantics; instead, it consistently describes scenePhase in terms of scenes and the SwiftUI lifecycle.

That is why this bug feels confusing. The code compiles, the environment value exists, and the same view may behave differently when moved into a pure SwiftUI app.

What Actually Works Instead?

For a UIKit-hosted SwiftUI screen, the practical answer is to observe UIKit lifecycle directly from the view.

There are two good approaches:

• app-wide notifications from UIApplication

• scene-level notifications from UIScene

Apple documents UIApplication.didBecomeActiveNotification as a notification posted when the app becomes active, and UIApplication.willEnterForegroundNotification as one posted shortly before the app leaves background on the way to active. Apple also documents UIScene.didActivateNotification and related scene notifications for scene lifecycle transitions.

So UIApplication notifications are not the only solution. They are just the broadest one.

1. App-wide lifecycle with UIApplication notifications

If you only care whether the whole app became active or inactive, observing UIApplication notifications directly inside the SwiftUI view is often enough. Apple documents didBecomeActiveNotification and willResignActiveNotification specifically for those app state transitions.

import SwiftUI
import UIKit

struct HostedSwiftUIView: View {
    @State private var isAppActive = true

    var body: some View {
        //Strange way to change Text, but still
        Text(isAppActive ? "App Active" : "App Inactive")
            .onReceive(NotificationCenter.default.publisher(
                for: UIApplication.didBecomeActiveNotification
            )) { _ in
                isAppActive = true
                print("App became active")
            }
            .onReceive(NotificationCenter.default.publisher(
                for: UIApplication.willResignActiveNotification
            )) { _ in
                isAppActive = false
                print("App resigned active")
            }
    }
}

2. Scene-level lifecycle with UIScene notifications

If your app uses scenes and you want behavior closer to what scenePhase is meant to represent, UIScene notifications are a better match than UIApplication notifications.

Apple documents scene notifications including:

• UIScene.didActivateNotification

• UIScene.willDeactivateNotification

• UIScene.didEnterBackgroundNotification

• UIScene.willEnterForegroundNotification

That makes this pattern more scene-accurate:

import SwiftUI
import UIKit

struct HostedSwiftUIView: View {
    @State private var phase: ScenePhase = .active

    var body: some View {
        Text(String(describing: phase))
            .onReceive(NotificationCenter.default.publisher(
                for: UIScene.didActivateNotification
            )) { _ in
                phase = .active
                print("Scene active")
            }
            .onReceive(NotificationCenter.default.publisher(
                for: UIScene.willDeactivateNotification
            )) { _ in
                phase = .inactive
                print("Scene inactive")
            }
            .onReceive(NotificationCenter.default.publisher(
                for: UIScene.didEnterBackgroundNotification
            )) { _ in
                phase = .background
                print("Scene background")
            }
            .onReceive(NotificationCenter.default.publisher(
                for: UIScene.willEnterForegroundNotification
            )) { _ in
                phase = .inactive
                print("Scene foreground")
            }
    }
}

For many UIKit-hosted SwiftUI screens, this is the closest practical replacement for scenePhase.

Is There Any Other Solution?

There are a couple of alternatives, but they are not really better for this case.

One option is to inspect windowScene.activationState from UIKit and derive a current value manually. That can work for one-time reads, but by itself it does not provide observation. Another option is to move the feature into a real SwiftUI App / Scene lifecycle, where scenePhase is naturally supported. Apple’s migration docs make clear that lifecycle monitoring is part of the SwiftUI lifecycle model, so that route is valid, but it is usually a much larger architectural move than teams want for one hosted screen.

So for a UIKit-heavy app, the practical answer remains: bridge lifecycle from UIKit.

Recommended Rule of Thumb

A clean rule is:

• Use @Environment(\.scenePhase) in a real SwiftUI App / Scene

• Use UIApplication notifications in hosted SwiftUI when app-wide state is enough

• Use UIScene notifications in hosted SwiftUI when you need scene-level behavior

That is more precise than saying only UIApplication notifications work.

They work, but they are not always the best fit.

Why This Matters?

The bug is subtle because nothing looks obviously broken. A hosted SwiftUI view still feels like SwiftUI, so it is natural to expect scenePhase to behave the same everywhere.

But lifecycle ownership is one of those invisible boundaries that changes behavior dramatically. scenePhase belongs to SwiftUI scenes. UIHostingController belongs to UIKit hosting. When those two worlds meet, UIKit lifecycle APIs are often the more dependable source of truth.

References

• Apple Developer Documentation: ScenePhase.

• Apple Developer Documentation: EnvironmentValues.scenePhase.

• Apple Developer Documentation: Migrating to the SwiftUI life cycle.

• Apple Developer Documentation: UIApplication.didBecomeActiveNotification.

• Apple Developer Documentation: UIApplication.willResignActiveNotification.

• Apple Developer Documentation: UIScene.didActivateNotification.

• Apple Developer Documentation: UIScene.willDeactivateNotification.

• Apple Developer Documentation: UIScene.didEnterBackgroundNotification.

• Apple Developer Documentation: UIScene.willEnterForegroundNotification.

Examining, checking, validating, and testing are essential parts of a developer’s life. Whether we’re verifying business logic, complex client-side computations, or trying to isolate a bug — tests are our helpers.

I’m not just talking about unit or UI tests. When we check an input and know the expected output, isn’t that a test? Maybe not as formal as Red–Green–Refactor or TDD (yes, I’m reading the book everyone’s been talking about lately), but it can still be seen as part of that approach.

For those who still use XCTest (like me 😅), as part of Swift Bits, I’m sharing some migration tips with you.

Useful links:

• Apple Swift Testing Notes

• Apple Developer: Swift Testing

• WWDC24: Meet Swift Testing

• Apple Guide: Migration from XCTest

• UseYourLoaf: Migration to Swift Testing

• Swift Testing: Writing a Modern Unit Test
  

The flow looks like this:

• Log in with your Apple Developer Forum account

• Submit a question for moderation (yes, moderation again!)

• Pass moderation

• Get upvotes to increase your chances of being answered

I took a chance and asked about task cancellation best practices — a topic many others were also interested in.

And, as usual, all questions were later removed. Thankfully, the answers were captured during the live session. To help you, I prepared a transcript for those who prefer not to watch, and added timestamps for those who prefer not to read 🙂

Enjoy!

Is

Task { @MainActor in
   ...
 } 

preferred over

Task { 
   // code to run in background
   await MainActor.run { 
     ...
   }
}

The difference between those two approaches is that Task with MainActor runs the entire task body on the MainActor. Of course, some operations inside that Task might be isolated to something else, and the task can switch between different isolation domains depending on what the code calls. But, for example, if you have synchronous code inside the Task and you want all of it to happen on the MainActor, then I would write the MainActor annotation directly on the Task closure signature. If you only have a specific operation, maybe just a couple of lines of code inside the Task, that you want to run on the MainActor, but everything else should continue running in the same context where the Task was created, then that is a case where you can use MainActor.run. Another option is to factor that code out into a MainActor-isolated function and call that function from within the task.

⏱️Time code

What’s the difference between nonisolated and nonisolated(nonsending), and why was the latter introduced?

Nonisolated means that a declaration has no preference for isolation. It does not have a fixed isolation, so it can be used in multiple isolation contexts. Nonisolated non-sending is about asynchronous functions. There was a behavior originally implemented for asynchronous functions in Swift concurrency where asynchronous functions would move to the concurrent thread pool, the shared executor, by default. We found that this was not the right trade-off as people adopted Swift concurrency and we learned more. So nonisolated non-sending, which is now the default behavior if you opt in using the approachable concurrency settings, is the new behavior where your asynchronous task or asynchronous function will not leave the isolation it was called from right away, unless there is an explicit reason to.

⏱️Time code

When marking a ViewModel with @MainActor how should we handle a method inside it that performs heavy I/O processing? How do process outside of MainActor/Main Thread?

Yes, if you have a particular operation on any MainActor-isolated type and you want only that operation to be offloaded, you can annotate just that method with a different isolation. For example, if you want to offload it to the concurrent thread pool, you can now use the @concurrent attribute. That is the right explicit spelling for it. The compiler will prevent you from directly accessing any MainActor mutable state on that view model, or whatever your MainActor-isolated type is, to make sure you are not accessing that state at the same time as another operation on that type is accessing the same mutable state from the MainActor. So take a look at @concurrent. There are also a lot of references from last year’s WWDC, where many uses of @concurrent were covered as well.

⏱️Time code

When a Task is created from @MainActor, will that block the main thread and cause UI hitches?

A task being created from MainActor is something you probably encounter often when working on a UI framework. I think that when a task is created on MainActor, there is still a suspension point that the compiler creates, so while that work is being performed, the main thread can still continue working on UI updates and avoid causing hitches. In general, the task machinery tries to schedule your work on the concurrent thread pool so that it does not block excessively. That is one of the nice behaviors that tasks provide. I think it depends on what the task does. If you create a task that is isolated to MainActor and that task starts running on MainActor, and you are doing some very expensive work that takes a long time, then it might block MainActor, and you might notice that. In that case, you may want to profile that code in Instruments and then decide whether to insert some suspension points or offload parts of that expensive task from MainActor. I really recommend that you do not worry about proactively offloading everything you can from MainActor. There are some things that are totally fine to run on MainActor. But if you notice hangs in your app and identify that piece of code through Instruments or your profiling tool of choice, that is when you should make targeted changes to move the expensive work off.

⏱️Time code

What is the best practice to cancel a task?

I think the practice I have been using is storing a task on the type and then calling cancel on it when needed. That is a good approach if you are trying to granularly manage the lifetime of that task. Any task that you want to be able to cancel needs to be tracked in some way, so you need to hold on to the handle.

⏱️Time code

When should I reach for at concurrent instead of nonisolated async? Is there a one sentence rule?

@concurrent is guaranteed to run on the shared thread pool in the background. For nonisolated async, it depends on your upcoming feature settings. As described earlier, the one-sentence explanation is that you should use @concurrent when you want your async function to be offloaded to the concurrent thread pool. It is an explicit spelling for behavior that used to be implicit for async functions, but that behavior is changing because it was not the best trade-off and not the best default for async functions. So you should use @concurrent now when you want that behavior. With nonisolated async, it depends on whether you have the approachable concurrency upcoming features enabled in your Xcode project, which is the default for new Xcode projects. If you do not have it enabled, I recommend enabling those settings because it gives you a set of defaults that are a bit easier to use with the data safety diagnostics.

⏱️Time code

Is it possible to have too many actors? Is there an intrinsic limit?

There is probably an intrinsic limit depending on how much memory you have, but I would definitely think about limiting how many different actors you have in your program. Generally speaking, you want to have just a few isolation domains in a program to reason about. Concurrent programming is hard, as we said earlier, and most of your code should be synchronous unless you have a reason to introduce concurrency and a reason to introduce different isolation domains. Every actor is a different isolation domain, and if actors need to work together, that creates complexity in your program. So you really want to think carefully when you factor something out into an actor, and decide whether it is really appropriate to add the complexity of needing to access that code asynchronously from other parts of your program. I think a very common question is: when do you actually use an actor? The answer is specifically when you can define that something will always need its own isolated domain, and the entirety of its functionality requires you to maintain that isolation. On the slide, I had a couple of examples like network caching or accessing a database. Those are common things where you often already know the work is going to be in an isolated domain anyway.

⏱️Time code

Could a Task started by .task modifier in SwiftUI view be cancelled if the view is refreshed by state change?

The task modifier in SwiftUI cancels your task when the view disappears, and state changes usually do not cause your view to be fully destroyed by SwiftUI. State works in a way where, when the state changes, SwiftUI reevaluates the view’s body, but it does not actually destroy the view. One case where you may see this behavior is if you have an ifstatement in your view’s body, and one branch becomes true while the other branch previously contained a view with a task. Once the condition flips, SwiftUI would cancel the task because the view in the other branch of the if statement is destroyed. You can also think about it like onDisappear: task is a modifier, and the task modifier manages cancellation with the same timeline as the onDisappear modifier, if you have used that before.

⏱️Time code

Intuitively what does the nonisolated keyword mean? Especially after the recent changes.

What has not really changed necessarily, but is now defaulted in some cases, is that nonisolated is a statement of your intent to not require any particular isolation for a type or function. When you annotate a type as @MainActor, you are stating that you only want it to be used from MainActor. nonisolated is removing that restriction. You can use it from any isolation domain, and that is really flexible and powerful. It is often the right choice for code in libraries, where you do not know where the app will want to use your library types. It can also be appropriate in your app for low-level models that do not have any inherent need to be isolated to MainActor or some other isolation domain. That is part of what motivated the behavior change for nonisolated with async functions. When something is marked as nonisolated, you can use it from anywhere. If you have a method that is not isolated and you call it from somewhere, it is going to run in the isolation domain it was called from. That used to not be the behavior for async functions, but now it is. So now there is a consistent meaning: when you see nonisolated, it means you can use it from anywhere, and when you call those methods, they are going to run wherever you call them from.

⏱️Time code

Are there plans to introduce tasks with timeouts (like GCD group timeout) or something to run after certain period of time (like DispatchQueue.main.asyncAfter)?

There is actually a proposal under review right now that adds this exact API to Task. I think the naming is still under debate. Right now, it is called withDeadline, and it is meant to provide exactly that behavior: you run a task, and if it exceeds a certain amount of time, the task will be canceled. That behavior has also been getting a lot of feedback during review. If you are interested in checking it out, you can head over to the Swift Forums and look at the Swift Evolution proposal. If you have any feedback about the proposed behavior, you can comment on the review thread there. Whoever asked that question should definitely go to the forums, ask questions, or provide feedback.

⏱️Time code

For a new app target, should I adopt MainActor default isolation? Does your answer change for libraries?

In Xcode 26, all new app targets use MainActor isolation by default. As someone from the SwiftUI team, I think that is an absolutely amazing choice for app targets because, in our UI framework, views are already on MainActor. If you have written a SwiftUI view and also have a model type, you may have noticed that it is often convenient to put that model on MainActor as well. With MainActor by default turned on, you do not have to do that manually. It makes UI code much easier to write and reason about, and you do not have to think as much about synchronizing your state because everything is on MainActor. But when it comes to libraries, my answer would change, depending on what the library does. If you are trying to be performant, concurrency can help you optimize behavior in your code by parallelizing operations, and libraries can make use of that in some cases. If you find that an operation is taking too long and you want to split it up, then it can make sense to introduce more concurrency, especially in library code. The same applies to app targets as well: you start on MainActor, and once you see potential for a performance optimization, or you profile the app and see the main thread being blocked by an expensive operation in your model, then you can consider adding concurrency annotations and moving things off MainActor. I also think many general-purpose library APIs are not specific to any particular isolation domain. Most of Foundation is not isolated, and clients of Foundation can choose where they want to use those APIs. For example, with Foundation, most APIs are not specific to any isolation, so most of them are nonisolated. There are a few APIs that are specific, such as UndoManager, which is heavily UI-focused and annotated with MainActor. For Foundation, it makes sense to keep most things nonisolated by default and add MainActor isolation for UI-related APIs. But when you are working on an app, it is almost the inverse: most of your things are on MainActor, and you may want to selectively offload work from there.

⏱️Time code

If a class launches a long-running Task and calls task.cancel() in deinit, does the task actually stop executing? And is its memory released immediately after cancellation? Also, are tasks automatically cancelled when their owning scope is deallocated?

Cancellation in Swift concurrency is cooperative. Depending on what the task is doing, that operation needs to check for cancellation. Usually, for a library method or similar API to support cancellation, the course of action is to throw a cancellation error. If you are running long synchronous code and someone cancels the task handle, that synchronous code is not going to be interrupted at any moment. That is actually an important behavior, because the work might need to perform some cleanup operation that must happen atomically without being interrupted by something like task cancellation. So no, the task does not necessarily stop running immediately because of cancellation. But as soon as you hit a piece of code that handles cancellation and maybe throws a cancellation error, that is when it will usually return by throwing such an error. There was another question about whether tasks get cancelled when their owning scope is deallocated. If a class has a task handle, like we discussed earlier, and you want to track a task to cancel it, you need to store it as a property. But no, it is not automatically cancelled just because the owning scope is deallocated. That is one of the gotchas when you opt into managing your task’s lifetime: you always have to remember to cancel it. That is also good in the sense that you are being explicit about the task’s lifetime. There was also a question about tasks swallowing errors. A Task does not require handling of thrown errors, which can lead to silently ignored failures. There is now an accepted proposal that addresses that exact pain point. In Swift 6.4, there will be a new diagnostic for exactly that case, where you have a task and have not handled errors within it. There are different ways to handle errors within a task. You can handle any thrown errors inside the task body, or if the task itself can throw and you want to keep a handle to the task, you can wait until you get the task’s value and handle any potential errors that were thrown. Those are two different ways to handle task errors. So yes, with the acceptance of that proposal, you will now get diagnostics for this. If you are interested, you can check the Swift Forums or Swift.org Swift Evolution for the accepted proposed behavior.

⏱️Time code

What’s the best practice for asynchronous requests in response to a button tap? Kicking off a one-off task? Exposing a synchronous method from your model that kicks off a task internally?

The general recommendation, although you can structure your code in both ways, is that I would prefer moving that asynchronous code to your model. Then the model can respond back with synchronous output to your view, so the view stays responsive and the model handles all of that asynchronous work. The benefit of this approach is that you can also test the asynchronous work outside of your view, which brings greater benefits to your entire codebase.

⏱️Time code

How do you handle legacy NSObject types which are non-scendable to work with at sendable closures?

I do not have a specific recommendation for NSObject types in general. It depends a lot on the situation in your code. If you have a class that inherits from NSObject, and your class does not add any state, and neither does NSObject itself, then it is possible that the type does not have any state. If it does not have any state, or it protects its mutable state, then you can mark it as @unchecked Sendable because you are managing that state yourself. If you really do have mutable state in that class, I do not recommend capturing it inside a @Sendable closure. With region-based isolation, which was introduced with the Swift 6 compiler, there are other tools you can use when you need to pass a closure over an isolation domain, but you do not necessarily need to call that closure multiple times, potentially in parallel. You can use the sending modifier, which allows you to pass a closure to another isolation domain. This is what the Task initializer and task creation methods use, because that closure goes to a different isolation domain depending on where you want to run the task, but it is only called once and only sent over an isolation domain one time. That allows you to capture non-Sendable state, like classes with mutable state or classes that inherit from NSObject, as long as you do not use them again from the original isolation domain where you formed the closure. Depending on the pattern of your code, there may be different solutions. There is not one general piece of advice for all classes that inherit from NSObject, but there are a variety of tools you can use depending on the exact concurrency guarantees of your code. Another tool we have used in Foundation is to avoid sharing the entire NSObject when you only need pieces of it. Often, an NSObject may have properties like a string or integer, which are Sendabletypes. So while you may not be able to share the whole NSObject between isolation domains, you can pull out the pieces that you need to share, as long as you do not need to worry about mutations. That has helped us avoid making everything Sendable. Instead, we can pick out the pieces that really need to be shared, make those Sendable, and let the legacy code that encapsulates everything remain non-Sendable. Also, when dealing with @Sendable closures and captured state, it is often helpful to use the closure’s capture list to capture only the Sendable pieces of your state, instead of trying to send over the entire containing type, which may not be Sendable. Hopefully, that provides some insight, but it is also worth checking the documentation and Swift Forums, where there are often many different tactics and suggestions discussed.

⏱️Time code

What is the best practice to write a unit test for async await code?

You can use Swift Testing and make your test method async, then test it there. If you need that method to run with a particular isolation, you can mark the test itself or the entire test case type with MainActor, or with whatever isolation you need that test to run on. Swift Testing is definitely worth checking out if you have not already.

⏱️Time code

What is best use case of Task.detached?

I have seen a lot of questions recently about when to use Task.detached versus when to use Task { @concurrent in }, because now those two things have very similar behaviors. The main difference is that the plain Task initializer, even when you specify some isolation, still inherits certain things from the surrounding context. Obviously, if you have explicitly specified an isolation, it does not inherit isolation, but it does inherit priority from the surrounding context. Task.detached, on the other hand, is completely detached. Nothing from the surrounding context is inherited by that task. So if you want something that is completely detached from the surrounding context, use Task.detached. If you just want to control the isolation, but you still want those other things to be inherited, use Task { @concurrent in }.

⏱️Time code

What’s the recommended pattern when processing many (thousands) of files, not just “spawn a task for every item”?

Profile first, because you never really want to just theorize about what might improve your performance the most. Experiment, profile, and see what is actually working. I could imagine that spawning a task for every file might not be the right design. Maybe you want to have some kind of batching logic instead. But you could try the most straightforward approach first and see how it works out before doing something more complicated.

⏱️Time code

Async Task from a SwiftUI view that calls a shared @Observable service. If the user dismisses the view before the task finishes, what’s the way to cancel it so the URLSession request is actually dropped (not just abandoned) and no UI state mutation happens post-dismiss?

In SwiftUI’s task modifier, SwiftUI does not currently expose a way to give you the task handle so you can cancel the task owned by SwiftUI. But since task is effectively similar to onAppear starting a task, you could structure your code so that you own that task yourself. Then, within onAppear of your SwiftUI view, you can start it, keep the task handle, and cancel it yourself when needed. If the condition is that the user dismisses the view before the task is finished, then you may also be able to use the task modifier directly, because SwiftUI cancels the task spawned there when the view is dismissed. So it depends on what your expectation is. But there is always a way to use your own Task instance that is not owned by SwiftUI if you need more granular control.

⏱️Time code

What are Apple’s recommended best practices for exposing data from actors in SwiftUI? Creating a “proxy” data broker between the actors and UI adds a lot of boilerplate, requires my own notification mechanism when actor data changes (I believe).

Exposing data from actors in SwiftUI depends on how that proxy object looks. But as we discussed earlier, introducing actors into your code adds extra synchronization points, where you have to await certain pieces. To access actor state from SwiftUI’s MainActor isolation, you need to introduce a layer that handles that synchronization. So it is almost inevitable that some kind of layer has to be introduced to synchronize that state. It would be helpful to hear more about the specifics, especially what boilerplate is involved here, what the notification mechanism looks like, and how the architecture is set up. This is probably a good case to continue the conversation on the Swift Forums, or file feedback with a sample project that has a similar architecture. That would make it easier to look more closely at the setup and see whether there is room for improvement to make this easier.

⏱️Time code

Any plans to support defers in async contexts?

There is another accepted proposal for Swift 6.4 that lifts the limitation on async code in defer blocks. There is no special syntax in a defer block. You can just call async methods, and it works. So yes, this is another recently accepted proposal. These questions are pointing directly to Swift Evolution. There is a dashboard on swift.org where you can filter by implemented proposals for Swift 6.4, if you are curious and want to see the full list of proposals coming in Swift 6.4.

⏱️Time code

If we are currently using Swift 5, have approachable concurrency set to no, default actor isolation is nonisolated and strict concurrency checking is minimal. What is the best first steps for us to move to Swift 6 concurrency?

The first step I would recommend is enabling the approachable concurrency features. There is migration tooling you can use from the command line, and the Swift Migration Guide covers how to do this, especially in cases where you rely on the old behavior for async functions. If you are using that behavior extensively in your project, there is a straightforward way to maintain it: write @concurrent on those async functions. So there are mechanical ways to migrate to those upcoming features without changing the behavior of your code. The approachable concurrency features are meant to make it so there are some data safety errors you do not have to deal with. Part of their purpose is to make the defaults reduce concurrency unless you have explicitly introduced it yourself. After that, you can either change strict concurrency checking from minimal to complete, or you can go feature by feature. In Xcode build settings, there is a section with specific upcoming features where you can enable specific categories of data-race safety diagnostics. For example, static variables are generally unsafe if they are not isolated and are mutable from anywhere. You can enable just those diagnostics, deal with all your static variables, and then move on to the next category. If you prefer working that way, you can deal entirely with the same kind of problem, find the few solutions that apply, fix those cases, enable that category, and then move on. Another approach is to turn everything on first, but that can produce a lot of diagnostics and feel overwhelming. In Foundation, for example, adoption has happened target by target. Some simpler targets could enable more features earlier because there were fewer issues to work through. In other targets, specific upcoming feature flags were enabled either in the Xcode project or Swift package manifest. That makes it possible to enable diagnostics the team understands and has already decided how to handle, while leaving other areas turned off until there is a clearer approach. SwiftUI adoption followed a similar pattern. When you see a large number of warnings, it helps to look for patterns. Once you identify a recurring issue, you can think about a more general solution and apply it in multiple places. For example, marking something with MainActor or adding a missing Sendable annotation can make many warnings disappear because all the call sites of that code become concurrency-safe. A common misconception is that you have to refactor everything into a perfect concurrency model immediately. In reality, looking at the diagnostics feature by feature lets you work iteratively and focus on specific patterns that usually have only one or two real fixes. Once your current app architecture works with native Swift concurrency, you can start thinking more deeply about how to express that architecture: where to introduce isolation domains, how to break down models, and which properties or components have different concurrency stories.

⏱️Time code

Does MainActor guarantee main thread? If not, when does it use another thread?

On our systems, MainActor is the main thread for sure. You could imagine an environment that Swift compiles for where MainActor might technically be some other thread. There are programs that are not apps where that might make sense, but for most intents and purposes, MainActor means the main thread. There are also some cases where you can have something annotated as MainActor, but it is still possible to call it from off MainActor in a context where the call site does not have strict concurrency checking enabled. I think the case where people see this most frequently is when interoperating with C, Objective-C, or C++. Those languages do not have static data safety, so it is possible to get a data race if you call something that is MainActor-isolated from one of those contexts. Swift also has tools to insert dynamic checking if you want to catch cases like that at runtime.

⏱️Time code

What’s the best practice to handle async shutdown functions during app termination? OS Lifecycle methods (such as applicationWillTerminate) are synchronous and they expect you to wrap up work there. Is it safe to use a semaphore in that scenario or are there better alternatives?

Generally speaking, you do not want to use semaphores to bridge asynchronous code to synchronous code, because it is likely to result in deadlock. If you block on an asynchronous method using a semaphore, and the concurrent pool blocks on that, it is quite likely that you can use up all the resources, and suddenly nothing can make forward progress. So I do not recommend that. The situation you are describing is tough. You are in a situation where you have been given a synchronous callback, and it is the only interface you have. Trying to refactor as much code as possible that you need to handle in that context so that it is synchronous itself is probably the best approach. Obviously, that can be really difficult in some situations, but I would not recommend using a semaphore to solve that problem.

⏱️Time code

What is an executor? Is that exposed to us in Swift?

You can make use of them, but you do not have to. Actors have default executors. The default executor manages scheduling for tasks, or more precisely, the synchronous pieces of a task, which are called jobs. Actors effectively have a priority queue of jobs that need to run on the actor from various tasks, and the executor handles scheduling and running those jobs. By default, that happens on the concurrent thread pool. You can also implement your own custom executors by conforming to a protocol and implementing whatever scheduling you need for your actor. Then you can provide a method on the actor that creates an instance of your custom executor type if you want to control that behavior. But the defaults are there so that you only need to drop down into that behavior if you need very fine-grained control over how those tasks are scheduled or run, or if you want to manage your own custom thread pool. That is something people sometimes do in services. So yes, those tools are available, but there are sensible defaults when you do not need that kind of control.

⏱️Time code

What does a healthy migration path from GCD and OperationQueue to Swift concurrency look like in a large existing app?

On Foundation, we have experienced a lot of these migrations, moving from things that use GCD, OperationQueue, run loops, and other mechanisms. I think a healthy migration is first and foremost an incremental migration. As mentioned earlier, trying to change the architecture of your app at the same time as you adopt these features is not necessarily easy, and it may also be difficult for other members of your team to review. An incremental migration means looking at the architecture your app has today and starting with the parts that are already easy to express using the compiler tools we have now. For example, when looking at how Foundation could adopt concurrency attributes, the first step was to identify types or functionality where the implementation was known and where it was trivial to add a few annotations to express things to the compiler. Once that base layer is done, you can start working on the harder parts. That helps you work piece by piece, instead of trying to fix a simple missing Sendable annotation while also figuring out how to rearchitect something else. In some cases, it was simple enough to add annotations. For example, UndoManager is heavily UI-related, so it made sense to make it MainActor-bound. Other types simply received a Sendable annotation because they were simple Swift value types. But there are also things where you may need to think about a different approach. For example, NotificationCenter was not, strictly speaking, easy to use with async APIs, so we reimagined how NotificationCenter could work with new APIs. The goal was to structure it so that you can use new async APIs while still integrating with older legacy APIs, sometimes using unsafe escape hatches to cross the boundary between them. Working incrementally lets you start with the easy things, enable the warnings you can fully resolve early so you do not accidentally backpedal, and then look at your architecture to decide how more complex concepts should map into Swift concurrency. It takes time. Foundation is still in the process of adopting some of these features as new compiler features appear and people propose new suggestions on the Swift Forums. But over time, piece by piece, you can get to a place where complex interactions that were previously expressed through threads, queues, or run loops become much easier to understand because they are now expressed directly in Swift code, rather than hidden in documentation comments or notes. There is some upfront burden when deciding how to rethink something that was heavily OperationQueue-based or GCD-based in the Swift concurrency world. But once you have APIs and architecture that integrate nicely with Swift concurrency, it becomes much easier to build on top of them. Having a base layer that works with Swift concurrency also makes it easier for apps using Foundation to integrate with new SwiftUI features or other APIs that take advantage of Swift concurrency. As the ecosystem moves further into a world where these ideas can be expressed clearly in code, those APIs start to fit more naturally with async/await and other Swift concurrency APIs from Apple SDKs and third-party packages. One additional recommendation is to prioritize areas where you are writing new code. If some part of your codebase is in maintenance mode, has been around for a long time, and only receives occasional bug fixes, it is okay not to dive in and rewrite it wholesale just to modernize it. The most important goal is to reach a point where you can write new code using Swift concurrency features and express that new code with static data-safety guarantees. Legacy code can be revisited over time when you have a specific motivation to do that work.

⏱️Time code

Does it make sense to use I have a generic capture in Tasks?

It really depends on what you are trying to do. It is definitely popular to use weak self in this kind of situation. People often want to optimize for the case where they are worried about capturing a reference to self and keeping it alive for too long. If that is your concern, you might use weak self to make sure the task is not what keeps self alive for too long. But you really need to understand what you are trying to accomplish in that task. It might be appropriate for the task to keep self alive until it finishes, because you want to complete that work regardless of whether everything else in the system has released its references to self. It depends on the kind of work. For example, with a task kicked off in a view, you may not want the view to be held onto by the task for too long after it disappears. That might be a good place to use weak self. As with most things, it depends. One case to be especially careful with is infinitely running tasks. If there is no end to the task, then the task may be what keeps self around. That is also the case where you can inadvertently get into reference cycles, especially if you are also storing a handle to that task on self. But as long as you do not have that kind of situation, it may be appropriate not to use weak self and let the task keep self alive until the work finishes.

⏱️Time code

I have a generic function that takes a Codable object: T as a parameter, makes a network call to retrieve an array of those objects and then returns an array of T. This will generate an error in Swift 6 about conformance must be on main thread.
Whats the best way to avoid this?

I suspect that isolated conformance might be coming into play here. Depending on the features of the target you are building, if you have MainActor isolation by default enabled, it might require that the Decodable conformance you pass is on the main thread, or that the conformance might be MainActor-isolated, but you are passing it to something that does not require that. I would check the documentation. The SendableMetatype protocol might be a good annotation to add to this API, depending on whether the conformance is the problem or whether the values being returned are the problem. That could mean using SendableMetatype on the type you are passing in, or perhaps using the sending keyword on the values you are returning, if you are just fetching them from the network, handing them off to the caller, and never touching them again. I suspect some of those keywords might help express the fact that you are taking a conformance to Codable and perhaps sending it to a different isolation to perform the network request, or taking the values created from that background isolation and sending them back to the calling isolation. In one of those directions, one of those keywords is likely to help resolve it. The context here is really valuable, so providing a sample through Feedback Assistant, checking the forums, and looking at the documentation would help narrow down the exact recommendation.

⏱️Time code

🏆 Acknowledgments

A huge thank-you to everyone who joined and shared thoughtful, insightful, and engaging questions throughout the session. Your curiosity and input made the discussion truly rich and collaborative.

Finally, a heartfelt thank-you to the Apple employees for leading the session, sharing expert guidance, and offering clear explanations of app optimization techniques. Your contributions made this an outstanding learning experience for everyone involved.

One More thing…

Through years of mentoring, I’ve built a small bookshelf of titles that are worth reading — or at least being aware of. The Grokking series from Manning Publishing is one of them. The style, the language, and the illustrations all combine to explain complex topics in an easy and engaging way.

You’ll find yourself wanting to learn more about things that once felt intimidating or difficult to understand. One of the latest additions is Grokking Data Structures by Marcello La Rocca.

Sharing the link with you.

Pull-to-refresh became a standard interaction in iOS apps long ago, so .refreshable feels like one of the most natural SwiftUI APIs. You attach the modifier, await some async work, and SwiftUI handles the native refresh behavior for you.

Apple introduced .refreshable during the WWDC21 SwiftUI updates, in the same release cycle as Swift concurrency and the task modifier. In that session, Apple presented it as the modern way to support pull-to-refresh on iOS and iPadOS, while task was described as async work tied to a view’s lifetime and automatically cancelled when that view disappears.

And that lifecycle detail is exactly where things start to get interesting. But let’s get back to declarations.

What is.refreshable?

At its core, .refreshable gives a view an async refresh action:

List(items) { item in
    Text(item.title)
}
.refreshable {
    await reload()
}

The system then connects that action to pull-to-refresh behavior where supported. Apple also notes that the action is propagated through the environment as a RefreshAction, which is why the feature integrates naturally with SwiftUI’s declarative model.

It feels like a callback, but it is more than that. It is SwiftUI-owned async work.

Full article here.

Pull-to-refresh became a standard interaction in iOS apps long ago, so .refreshable feels like one of the most natural SwiftUI APIs. You attach the modifier, await some async work, and SwiftUI handles the native refresh behavior for you.

Apple introduced .refreshable during the WWDC21 SwiftUI updates, in the same release cycle as Swift concurrency and the task modifier. In that session, Apple presented it as the modern way to support pull-to-refresh on iOS and iPadOS, while task was described as async work tied to a view’s lifetime and automatically cancelled when that view disappears.

And that lifecycle detail is exactly where things start to get interesting. But let’s get back to declarations.

What is.refreshable?

At its core, .refreshable gives a view an async refresh action:

List(items) { item in
    Text(item.title)
}
.refreshable {
    await reload()
}

The system then connects that action to pull-to-refresh behavior where supported. Apple also notes that the action is propagated through the environment as a RefreshAction, which is why the feature integrates naturally with SwiftUI’s declarative model.

It feels like a callback, but it is more than that. It is SwiftUI-owned async work.

A Simple Example

Let’s show ScrollView with random items added with delay:

import SwiftUI

struct LoadedItem: Identifiable {
    let id: Int
    let value: Int
}

struct RefreshCancellView: View {

    @State private var items: [LoadedItem] = []

    var body: some View {
        NavigationStack {
            ScrollView(.vertical, showsIndicators: false) {
                LazyVStack(spacing: 16) {
                    ForEach(items) { item in
                        Text(item.value, format: .number)
                    }
                }
            }
            .padding(16)
            .refreshable {
                await loadItems(fromRefresh: true)
            }
            .task {
                //Loading the initial list
                await loadItems()
            }
            .navigationTitle("Refreshable Example")
            .navigationBarTitleDisplayMode(.inline)
        }
    }

    func loadItems(fromRefresh: Bool = false) async {
        await MainActor.run { items.removeAll() }

        let count = Int.random(in: 20...40)

        for i in 0..<count {
            try? await Task.sleep(for: .milliseconds(Int.random(in: 50...150)))

            //Checking cancelaltion
            if Task.isCancelled {
                print("Cancelled fromRefresh: \(fromRefresh)")
                return
            }

            let value = Int.random(in: 0...10_000)
            let newItem = LoadedItem(id: i, value: value)

            await MainActor.run {
                items.append(newItem)
            }
        }
    }
}

On the surface, this looks reasonable. Clear the old values, load the new ones, append them as they arrive, and check for cancellation between steps.

But this code is actually a very good demonstration of the problem.

The Problem

The key trigger is this line:

await MainActor.run { items.removeAll() }

That mutation happens immediately inside the .refreshable task.

Since items is @State, SwiftUI redraws the body right away. And because the refresh work is owned by SwiftUI, that redraw can invalidate the task context that is currently running the refresh closure. The Stack Overflow discussion describes exactly this: clearing the data causes the body to redraw, .refreshable is redrawn too, and the previous task gets cancelled.

And this could throw you into debugging session for a long of time…

Then the example makes the situation even more fragile here:

await MainActor.run {
    items.append(newItem)
}

Every append is another state mutation, which means another redraw opportunity while the refresh task is still active.

So this sample now has both failure multipliers:

• one immediate redraw from removeAll()

• repeated redraws from every append

That is why it reproduces the issue so clearly.

Why This Happens

The simplest mental model is this:

.refreshable runs your closure as structured work owned by SwiftUI.

Apple’s WWDC explanation of the related task modifier is useful here: SwiftUI can attach async work to a view lifetime and cancel it when the view is removed. While Apple’s .refreshable docs are brief, the observed behavior lines up with that same lifecycle-driven model.

So when your refresh code changes the very state that drives the current body, SwiftUI may rebuild enough of the hierarchy to cancel the refresh-owned task before it completes. The Stack Overflow thread phrases it quite directly: clearing the observable collection redraws the body, .refreshable redraws too, and the previous task is cancelled.

This is also why the issue feels so strange. The code is not “wrong” in the usual sense. It is just colliding with the ownership model of SwiftUI concurrency.

A Common Symptom

You pull to refresh, the spinner appears, work starts, and then one of these happens:

• the task stops halfway through

• only part of the list loads

• a network request suddenly throws cancellation (Code -999 for the those who are trying to Google it)

That half-finished feeling is often the first clue that the problem is not your API layer, but the view lifecycle interacting with structured concurrency.

Fix 1: Avoid intermediate UI changes until the final update

The cleanest fix is to avoid publishing intermediate mutations while the refresh is running.

Instead of clearing and appending directly into @State, collect results locally and assign once at the end:

func loadItems(fromRefresh: Bool = false) async {
    let count = Int.random(in: 20...40)
    var loaded: [LoadedItem] = []

    for i in 0..<count {
        try? await Task.sleep(for: .milliseconds(Int.random(in: 50...150)))

        if Task.isCancelled {
            print("Cancelled fromRefresh: \(fromRefresh)")
            return
        }

        let value = Int.random(in: 0...10_000)
        loaded.append(.init(id: i, value: value))
    }

    await MainActor.run {
        items = loaded
    }
}

This works better because SwiftUI sees only one final state change instead of dozens of redraw-triggering mutations.

The tradeoff is that you lose progressive updates during refresh. But in most real pull-to-refresh flows, that is completely acceptable. The user usually cares more about a stable completion than about watching rows arrive one by one.

Fix 2: Move the Work Into an Unstructured Task

The other workaround is to let .refreshable create a separate task and await that task’s value:

.refreshable {
    await Task {
        await loadItems(fromRefresh: true)
    }.value
}

This pattern appears directly in one of the Stack Overflow answers: wrapping the logic in Task { ... }.value allows the refresh spinner to remain visible while the new task continues even if the original refresh-owned task is cancelled.

That makes it a practical fix when redraw-driven cancellation is getting in the way.

There is also a looser variation:

.refreshable {
    Task {
        await loadItems(fromRefresh: true)
    }
}

That decouples the work even more, but it also changes the semantics more aggressively because the refresh action no longer truly owns the work. The safer version is usually await Task { ... }.value, since it still lets the refresh indicator track completion.

Which Fix is Better?

In most cases, the first fix is the better design.

Use the single final update approach when:

• you can build the refreshed data off to the side

• progressive rendering is not important

• you want to stay inside structured concurrency as much as possible

Use the unstructured task wrapper when:

• redraw-driven cancellation is hard to avoid

• intermediate observable changes are required

• you need a practical workaround more than a pure structured model

The Stack Overflow thread includes both ideas in different forms: avoid redraw-triggering updates until later, or wrap the refresh body in a new task so it survives the redraw.

Final Thoughts

This is one of those SwiftUI behaviors that feels confusing until you frame it correctly.

If your .refreshable code updates the source of truth too early, the refresh task may cancel itself through the very redraw it caused. That is why the safest approach is often to keep all temporary work local and publish one final result when loading finishes.

And if you truly need incremental changes during refresh, then an unstructured task wrapper may be the most practical escape hatch.

That is a subtle detail, but it is the difference between a refresh flow that feels flaky and one that behaves predictably.

References

• Apple Developer Documentation: refreshable(action:)

• Apple Developer Documentation: RefreshAction

• Apple WWDC21 session “What’s new in SwiftUI,” including refreshable and lifecycle-bound async tasks.

One More thing…

Through years of mentoring, I’ve built a small bookshelf of titles that are worth reading — or at least being aware of. The Grokking series from Manning Publishing is one of them. The style, the language, and the illustrations all combine to explain complex topics in an easy and engaging way.

You’ll find yourself wanting to learn more about things that once felt intimidating or difficult to understand. One of the latest additions is Grokking Data Structures by Marcello La Rocca.

Sharing the link with you.

Not the actual screen size.

Not the simulator device size.

That old fallback size.

And yes, this behavior has been around for years. It still shows up in practice when launch-screen configuration is missing or broken, and developers keep rediscovering it because the symptom looks unrelated at first glance: your app launches, but the window, bounds, or rendered content behave like the device is tiny.

The strange part

You remove the launch screen, or the app no longer points to the correct launch storyboard, and suddenly the app starts acting like it lives in a much older world.

A common symptom is that values like screen bounds appear as 320 × 480, regardless of the actual device.

This is what makes the issue so confusing:

• the code that reads screen size may look correct

• the simulator may be a modern iPhone

• the UI may still compile and run

• but the app behaves like it launched in a legacy compatibility path

Why does this happen?

The launch screen is not only a visual placeholder while the app starts. It is also part of how iOS understands that your app supports modern screen sizes and adapts correctly to the current device family and display characteristics.

Historically, when iOS could not determine that an app supported newer display formats, it could fall back to older sizing behavior. That is why 320 × 480 keeps surfacing: it is the classic original iPhone/iPod logical size, and the system can still expose behavior that resembles that legacy compatibility mode when launch-screen support is absent or invalid.

It is not really about “splash screens”

That is also why calling it “just a splash screen” is misleading.

On iOS, the launch screen does more than show a placeholder image. It is part of the app’s launch configuration, and missing it can affect how the app is treated at startup.

So the issue is not really visual.

It is architectural.

How to check if this is your problem

If your app behaves suspiciously small, clipped, letterboxed, or reports old dimensions, check these first:

• does the target have a valid Launch Screen configured?

• does Info.plist contain the correct UILaunchStoryboardName or equivalent launch-screen configuration?

• does the referenced storyboard actually exist?

• did the launch-screen file get renamed without updating the target settings?

In practice, the fix is often simply restoring a valid LaunchScreen.storyboard and making sure the target points to it correctly.

The simplest fix

In most native iOS projects, the practical fix is:

1. Create or restore LaunchScreen.storyboard

2. Set it as the app’s launch screen in target settings

3. Ensure the app bundle includes it

4. Clean and rebuild the app

Typical config:

<key>UILaunchStoryboardName</key>
<string>LaunchScreen</string>

If you are using SwiftUI, plist-based launch-screen configuration is also possible in newer setups, but the core point stays the same: the app needs a valid launch-screen definition. Even the empty ones fixing it.

For Storyboard, you can check:

And it’s fine again!

Why this is still surprising in 2026

Because it feels like the kind of issue that should have disappeared with older iPhone screen transitions.

But launch behavior sits in a compatibility-sensitive part of the platform, and when that configuration is missing, iOS can still fall back in ways that expose very old assumptions. That is why this bug feels so strange: it does not look like a missing resource problem. It looks like the whole app forgot what year it is.

References

• Apple Developer Documentation: UILaunchStoryboardName

• Apple Developer Documentation: Specifying your app’s launch screen

• Apple Human Interface Guidelines: Launching

• Apple Developer Documentation: UILaunchScreen

• Apple Technote: Debugging your app’s launch screen

One More thing…

Through years of mentoring, I’ve built a small bookshelf of titles that are worth reading — or at least being aware of. The Grokking series from Manning Publishing is one of them. The style, the language, and the illustrations all combine to explain complex topics in an easy and engaging way.

You’ll find yourself wanting to learn more about things that once felt intimidating or difficult to understand. One of the latest additions is Grokking Data Structures by Marcello La Rocca.

Sharing the link with you.

AI-assisted coding became fast much earlier than it became predictable. That is exactly why spec-driven development is getting more attention now: instead of keeping requirements scattered across chat history, you turn them into artifacts the human and the assistant can both follow. OpenSpec is one of the tools built around that idea. It adds a lightweight workflow where you agree on the change first, generate planning artifacts, and then implement against them.

What is Spec-Driven Development?

Spec-driven development, or SDD, is a workflow where the specification becomes the source of truth before implementation starts. In OpenSpec’s wording, it helps you and your AI coding assistant agree on what to build before any code is written. Rather than relying on one long prompt, you break work into artifacts such as a proposal, specs, design, and tasks.

That matters even more in AI-heavy workflows. A good assistant can generate a lot of code quickly, but if the requirements are vague, the result is usually inconsistent, incomplete, or hard to evolve. SDD adds structure without forcing a huge process. The idea is simple: describe the change, refine the behavior, plan the work, then implement it against an agreed spec.

One of the nice ideas behind OpenSpec is that the workflow is not treated as rigid phase gates. Its docs explicitly frame the model as actions rather than locked phases, so you can create, implement, update, and archive as needed. That makes it fit better with real development, where requirements often change while implementation is already in progress.

SDD birthplace is NASA at 1960s as a mix of formal developments and multiple specifications. So we all can feel like a Space Explorers while using it )

What is OpenSpec, anyway?

OpenSpec is an open-source tool for spec-driven development aimed at AI coding assistants. The project describes itself as a lightweight spec layer that helps teams agree on what to build before code is written, keeps each change organized in its own folder, and works with more than 20 AI assistants through generated slash commands and skills.

The primary goal of OpenSpec is to solve the problem of unpredictability and inconsistency that can arise when using Al tools for coding. Since Al tools are non-deterministic, they can struggle to consistently follow complex requirements. OpenSpec provides a structured approach that allows teams and Al assistants to agree on specifications before coding begins. This leads to more efficient development, fewer errors, and improved code quality

After initialization, OpenSpec generates instructions that compatible assistants can auto-detect. In its docs, that means skills in locations like .claude/skills/, plus a project config file at openspec/config.yaml if you choose to create one. The default schema is spec-driven, and the standard artifact set includes proposal, specs, design, and tasks.

A particularly useful concept in OpenSpec is the idea of delta specs. Instead of rewriting the whole product spec every time, you describe what is changing. The docs present this with sections such as ADDED Requirements and MODIFIED Requirements, which makes OpenSpec more practical for brownfield projects where the codebase already exists. We will get back to this in the next chapters.

Full article here.

AI-assisted coding became fast much earlier than it became predictable. That is exactly why spec-driven development is getting more attention now: instead of keeping requirements scattered across chat history, you turn them into artifacts the human and the assistant can both follow. OpenSpec is one of the tools built around that idea. It adds a lightweight workflow where you agree on the change first, generate planning artifacts, and then implement against them.

What is Spec-Driven Development?

Spec-driven development, or SDD, is a workflow where the specification becomes the source of truth before implementation starts. In OpenSpec’s wording, it helps you and your AI coding assistant agree on what to build before any code is written. Rather than relying on one long prompt, you break work into artifacts such as a proposal, specs, design, and tasks.

That matters even more in AI-heavy workflows. A good assistant can generate a lot of code quickly, but if the requirements are vague, the result is usually inconsistent, incomplete, or hard to evolve. SDD adds structure without forcing a huge process. The idea is simple: describe the change, refine the behavior, plan the work, then implement it against an agreed spec.

One of the nice ideas behind OpenSpec is that the workflow is not treated as rigid phase gates. Its docs explicitly frame the model as actions rather than locked phases, so you can create, implement, update, and archive as needed. That makes it fit better with real development, where requirements often change while implementation is already in progress.

SDD birthplace is NASA at 1960s as a mix of formal developments and multiple specifications. So we all can feel like a Space Explorers while using it )

What is OpenSpec?

OpenSpec is an open-source tool for spec-driven development aimed at AI coding assistants. The project describes itself as a lightweight spec layer that helps teams agree on what to build before code is written, keeps each change organized in its own folder, and works with more than 20 AI assistants through generated slash commands and skills.

The primary goal of OpenSpec is to solve the problem of unpredictability and inconsistency that can arise when using Al tools for coding. Since Al tools are non-deterministic, they can struggle to consistently follow complex requirements. OpenSpec provides a structured approach that allows teams and Al assistants to agree on specifications before coding begins. This leads to more efficient development, fewer errors, and improved code quality

After initialization, OpenSpec generates instructions that compatible assistants can auto-detect. In its docs, that means skills in locations like .claude/skills/, plus a project config file at openspec/config.yaml if you choose to create one. The default schema is spec-driven, and the standard artifact set includes proposal, specs, design, and tasks.

A particularly useful concept in OpenSpec is the idea of delta specs. Instead of rewriting the whole product spec every time, you describe what is changing. The docs present this with sections such as ADDED Requirements and MODIFIED Requirements, which makes OpenSpec more practical for brownfield projects where the codebase already exists. We will get back to this in the next chapters.

How to install OpenSpec

OpenSpec requires Node.js 20.19.0 or higher. The main README and installation docs show the global package install via npm, plus alternatives for pnpm, yarn, bun, and nix.

node --version
npm install -g @fission-ai/openspec@latest

If you use another package manager, the official docs also list these options:

pnpm add -g @fission-ai/openspec@latest
yarn global add @fission-ai/openspec@latest
bun add -g @fission-ai/openspec@latest

How to use OpenSpec

The quick-start flow is straightforward. Install the CLI, move into your project, run openspec init, and then start the workflow from your AI assistant with /opsx:propose <what-you-want-to-build>. The default quick path in the docs is propose → apply → archive.

cd your-project
openspec init

This command will create the following directory structure in your project:

openspec/
├── specs/ # Source of truth (your system's behavior)
│ └── <domain>/
│ └── spec.md
├── changes/ # Proposed updates (one folder per change)
│ └── <change-name>/
│ ├── proposal.md
│ ├── design.md
│ ├── tasks.md
│ └── specs/ # Delta specs (what's changing)
│ └── <domain>/
│ └── spec.md
└── config.yaml # Project configuration (optional)

Two key directories:

• specs/ - Source of Truth. These specifications describe the current behavior of your stem. They are organized by domain (e.g., specs/auth/, specs/payments/).

• changes/ - Proposed Changes. Each change gets its own folder with all related artifacts. When a change is completed, its specifications are merged into the main

OpenSpec Artifacts

Each change folder contains artifacts that guide the work:

Artifacts build on each other:

Then in your AI assistant (Claude, in example):

/opsx:propose Add dark theme support to the iOS app

If you want a more expanded workflow, OpenSpec also supports commands such as /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:sync, /opsx:bulk-archive, and /opsx:onboard. The docs say these are enabled by selecting a workflow profile with openspec config profile and then applying it with openspec update.

openspec config profile
openspec update

OpenSpec can also inject project context and rules through openspec/config.yaml. The official docs show fields like schema, context, and per-artifact rules, which is useful when you want the AI to consistently follow your stack, style, testing, or architecture expectations.

Example config:

schema: spec-driven

context: |
  Platform: iOS
  Language: Swift 6
  UI: SwiftUI
  Architecture: MVVM
  Testing: XCTest
  Style: Keep features modular and accessibility-friendly

rules:
  proposal:
    - Mention user-visible impact
    - Mention rollback strategy if theme breaks visual contrast
  specs:
    - Use Given/When/Then scenarios
  design:
    - Note persistence approach and affected views
  tasks:
    - Keep tasks small and implementation-ready

What is Delta and why is it needed?

One of the most useful OpenSpec ideas is the delta. In simple terms, a delta is the change itself, not the entire product spec rewritten from scratch. OpenSpec’s concepts docs define delta specs as specifications for what is being added, modified, or removed.

That matters because most real work happens in an existing codebase. You are usually not writing a greenfield product spec from zero. You are adding dark theme, changing onboarding, refining analytics, or replacing a legacy flow. Rewriting the full spec every time would add noise and make reviews harder. Delta specs keep the focus on what changed.

This is also why delta works well with AI assistants. Instead of telling the model to reinterpret the whole product, you give it a precise target: implement this difference. That makes output easier to review, easier to evolve, and less likely to drift away from the original intent. This last point is an inference from OpenSpec’s artifact model and workflow design, rather than a direct quote from the docs.

A simple way to think about it:

• full spec = what the product is

• delta spec = what this feature changes

A typical delta can contain sections like:

## ADDED Requirements
### Requirement: Manual Theme Override

## MODIFIED Requirements
### Requirement: Accessible Theme Colors

## REMOVED Requirements
### Requirement: Legacy Fixed Light Theme

So if your app already exists and you want to add dark mode, the delta does not describe the whole app. It describes only the new or changed behavior related to theme support. That is what makes spec updates manageable over time.

Example: iOS spec to add Dark Theme

Here is the kind of change request OpenSpec fits well. Imagine an existing SwiftUI app that currently supports only a light theme, and now you want to add dark mode properly rather than as a quick visual patch.

A strong OpenSpec workflow would usually begin with a proposal, then move into specs, design notes, and tasks. OpenSpec’s docs position these as the standard artifacts in the default schema, and their examples recommend small, structured tasks and Given/When/Then-style scenarios for requirements.

1. Proposal

# Proposal: Add Dark Theme Support

## Summary
Add full dark theme support to the iOS app so users can use the interface comfortably in low-light environments and align the app with modern iOS expectations.

## Motivation
The app currently uses a light-only visual style. This creates poor visual comfort at night, makes the product feel less native on iOS, and limits accessibility for users who prefer darker interfaces.

## Goals
- Support system light/dark appearance
- Allow optional manual theme override in Settings
- Persist user preference between launches
- Update key screens and reusable components

## Non-Goals
- Rebuild the design system from scratch
- Add seasonal or branded themes
- Change unrelated layout or navigation behavior

## Risks
- Some screens may still use hard-coded colors
- Charts, overlays, and custom backgrounds may need separate tuning
- Contrast issues may appear on older screens

## Success Criteria
- Main user flows look correct in light and dark mode
- Theme switches without broken contrast
- Manual selection persists after relaunch

2. Specs

# Delta for Theme

## ADDED Requirements

### Requirement: System Theme Support
The application MUST support both light and dark appearance modes.

#### Scenario: Follow system appearance
- GIVEN the user has not selected a manual theme override
- WHEN the iOS system appearance changes between light and dark
- THEN the application updates its appearance automatically

### Requirement: Manual Theme Override
The application MUST allow the user to choose Light, Dark, or System in Settings.

#### Scenario: Select dark theme manually
- GIVEN the user opens Settings
- WHEN the user selects Dark theme
- THEN the application immediately applies dark appearance
- AND the selection persists across app launches

#### Scenario: Revert to system theme
- GIVEN the user previously selected a manual theme
- WHEN the user selects System
- THEN the application follows the current iOS appearance again

### Requirement: Accessible Theme Colors
The application MUST use theme-aware colors that preserve readable contrast in both appearances.

#### Scenario: Readability in dark mode
- GIVEN the app is displayed in dark mode
- WHEN the user opens any primary screen
- THEN text, icons, separators, and controls remain clearly readable

3. Design

# Design: Dark Theme Support

## Overview
Implement a centralized theme layer for SwiftUI that supports:
- system appearance
- manual override
- persistent storage
- theme-aware semantic colors

## Architecture
- Add `AppTheme` enum with cases: `system`, `light`, `dark`
- Add `ThemeStore` as an observable state holder
- Persist selected theme using `@AppStorage`
- Inject `ThemeStore` at the app root
- Map theme selection to `preferredColorScheme`

## UI Impact
Affected areas:
- app root scene
- settings screen
- reusable buttons
- cards and list rows
- onboarding screens
- charts and branded surfaces

## Edge Cases
- legacy UIKit-hosted screens may ignore SwiftUI preference
- hard-coded `Color.white` and `Color.black` usages must be replaced
- image assets may require dark variants

4. Tasks

# Tasks

## 1. Theme Infrastructure
- [ ] 1.1 Create `AppTheme` enum with `system`, `light`, `dark`
- [ ] 1.2 Create `ThemeStore` observable object
- [ ] 1.3 Persist selected theme with `@AppStorage`
- [ ] 1.4 Inject theme store into the app entry point

## 2. App Integration
- [ ] 2.1 Apply `preferredColorScheme` at root level
- [ ] 2.2 Add theme selector to Settings
- [ ] 2.3 Ensure changes update UI immediately

## 3. UI Migration
- [ ] 3.1 Replace hard-coded colors with semantic colors
- [ ] 3.2 Audit reusable components
- [ ] 3.3 Update custom backgrounds and overlays
- [ ] 3.4 Test charts and illustrations in dark mode

## 4. Validation
- [ ] 4.1 Test launch persistence
- [ ] 4.2 Test system appearance switching
- [ ] 4.3 Check accessibility contrast on key screens

[img: iOS dark theme concept illustration. iPhone screens transitioning from light mode to dark mode, with a settings panel and palette tokens floating around. Elegant product art, square, no text.]

Example Implementation Prompt

Once the planning artifacts are in place, you can move to implementation. In OpenSpec’s workflow, that is the role of /opsx:apply, which implements tasks while allowing artifacts to be updated as needed.

/opsx:apply Implement the dark theme change for the SwiftUI iOS app.
Respect the existing architecture.
Use semantic colors where possible.
Add manual theme selection in Settings.
Persist the selected option.
Flag any screens that still depend on hard-coded colors.

Further edit: refining the spec after first implementation

This is where OpenSpec becomes more useful than a single big prompt. After the first pass, you often discover missing details. Maybe the theme works, but charts still look wrong, onboarding illustrations are too bright, or a UIKit bridge ignores the chosen mode. OpenSpec’s docs explicitly support updating artifacts during work, and its delta-spec model is built for describing those changes rather than rewriting everything.

For example, after reviewing the first implementation, you might extend the spec like this:

## MODIFIED Requirements

### Requirement: Accessible Theme Colors
The application MUST use theme-aware colors that preserve readable contrast in both appearances, including charts, onboarding graphics, and empty states.

#### Scenario: Charts in dark mode
- GIVEN the app is displayed in dark mode
- WHEN the user opens an analytics or chart-based screen
- THEN chart axes, grid lines, labels, and highlighted values remain readable
- AND color choices preserve sufficient contrast against the background

And you could add follow-up tasks:

## 5. Dark Mode Polish
- [ ] 5.1 Tune chart palette for dark backgrounds
- [ ] 5.2 Add dark-compatible illustration assets where needed
- [ ] 5.3 Audit UIKit-hosted views for color-scheme mismatch
- [ ] 5.4 Re-test Settings, onboarding, and analytics screens

That iterative loop is probably the strongest part of the OpenSpec approach. You do not just tell the assistant “fix dark mode.” You update the source of truth, then implement again from a better artifact set.

Why OpenSpec is interesting for iOS work

For iOS development, OpenSpec feels especially useful in feature work that is bigger than a one-file change but smaller than a full RFC process. Dark theme, onboarding redesigns, analytics instrumentation, subscription flows, paywall experiments, or widget updates all benefit from a shared definition of behavior before the assistant starts touching code.

It also fits the reality of app development better than prompt-only coding. Mobile work usually includes UI states, accessibility, persistence, migration concerns, asset variants, platform conventions, and sometimes legacy UIKit or extension targets. A structured spec makes those details much easier to preserve across multiple AI-assisted implementation steps.

Competitors

Honestly, there is a Kiro. It positions itself as an AI development environment built around spec-driven development, custom agents, and structured workflows instead of prompt-only coding. The most interesting part is the emphasis on moving from fast prototypes to production work with executable specs, steering, and IDE plus CLI support. But it has a credits system.

Final thoughts

Spec-driven development is really a response to a new problem: code generation got fast, but reliable intent transfer did not. OpenSpec addresses that gap with a lightweight workflow built around proposals, specs, design, and tasks, plus a set of assistant-friendly commands and project configuration. It is not about replacing coding. It is about making AI-generated coding more intentional, reviewable, and repeatable.

For an iOS team or even a solo developer, that can be enough process to improve predictability without turning every feature into a documentation project.

References

• Fission-AI OpenSpec GitHub repository and README

• OpenSpec Getting Started docs

• OpenSpec opsx workflow docs

• OpenSpec concepts docs, including delta specs and task guidance

• OpenSpec installation docs

One More thing…

Through years of mentoring, I’ve built a small bookshelf of titles that are worth reading — or at least being aware of. The Grokking series from Manning Publishing is one of them. The style, the language, and the illustrations all combine to explain complex topics in an easy and engaging way.

You’ll find yourself wanting to learn more about things that once felt intimidating or difficult to understand. One of the latest additions is Grokking Data Structures by Marcello La Rocca.

Sharing the link with you.

Here is where chartXScale(range:type:) becomes interesting. Apple describes it as the modifier that configures “the range of x positions that correspond to the scale domain.” By default, that range is determined by the size of the plot area.

The same applies to chartYScale(range:type:). No extra diff spotted.

In other words, this modifier is not about changing your data. It is about changing how the x-axis uses the available horizontal space.

Why Would You Use It?

Most charts look fine with the default x-scale behavior. But sometimes the chart feels just a little off:

• the first bar is too close to the leading edge

• the last point looks glued to the trailing border

• the whole plot feels cramped even though the data itself is correct

That is usually not a domain problem. It is a range problem.

A useful mental model is this:

• domain = what values exist on the axis

• range = where those values are drawn in the plot area

Apple’s chart scale docs make exactly that separation: domain is about possible data values, while range is about the axis positions used to render them.

Basic Chart

Let’s start with a simple bar chart:

import SwiftUI
import Charts

struct SalesPoint: Identifiable {
    let id = UUID()
    let month: String
    let value: Int
}

struct ChartRangeDemoView: View {
    let data: [SalesPoint] = [
        .init(month: "Jan", value: 12),
        .init(month: "Feb", value: 19),
        .init(month: "Mar", value: 7),
        .init(month: "Apr", value: 15),
        .init(month: "May", value: 23)
    ]

    var body: some View {
        Chart(data) { item in
            BarMark(
                x: .value("Month", item.month),
                y: .value("Sales", item.value)
            )
        }
        .frame(height: 220)
        .padding()
    }
}

With no explicit range configuration, Swift Charts uses the plot area dimension automatically. That is the default behavior Apple documents for chartXScale(range:type:).

The Most Practical Use of plotDimension

The easiest and most useful version is applying padding to the plotting dimension.

Apple documents plotDimension(padding:) as “a scale range that fills the plot area with the given padding value at start and end.”

Chart(data) { item in
    BarMark(
        x: .value("Month", item.month),
        y: .value("Sales", item.value)
    )
}
.chartXScale(
    range: .plotDimension(padding: 20)
)
.frame(height: 220)
.padding()

This is the version I’d reach for first. It is simple, visual, and immediately improves charts that feel too tight near the edges.

Different Padding at the Start and End

Sometimes equal padding is not enough. You may want the chart to start tighter on the left, but leave a bit more breathing room on the right for a label, annotation, or simply for better visual balance.

Apple also provides a PositionScaleRange option that fills the plot area with different padding values at the start and end.

Chart(data) { item in
    BarMark(
        x: .value("Month", item.month),
        y: .value("Sales", item.value)
    )
}
.chartXScale(
    range: .plotDimension(startPadding: 0, endPadding: 28)
)
.frame(height: 220)
.padding()

This is where the modifier starts feeling less like “some axis API” and more like a visual tuning tool.

Example with an Actual Range

The interesting part is that chartXScale(range:type:) is not only for categorical data like month names. It also applies when your x-axis contains real continuous values such as dates or numbers.

Here is a date-based line chart:

import SwiftUI
import Charts

struct TemperaturePoint: Identifiable {
    let id = UUID()
    let day: String
    let temperature: Double
}

struct TemperatureChartView: View {
    let data: [TemperaturePoint] = [
        .init(day: "Mon", temperature: 18),
        .init(day: "Tue", temperature: 21),
        .init(day: "Wed", temperature: 19),
        .init(day: "Thu", temperature: 24),
        .init(day: "Fri", temperature: 22)
    ]

    var body: some View {
        Chart(data) { item in
            LineMark(
                x: .value("Day", item.day),
                y: .value("Temperature", item.temperature)
            )

            PointMark(
                x: .value("Day", item.day),
                y: .value("Temperature", item.temperature)
            )
        }
        .chartXScale(
            range: .plotDimension(startPadding: 12, endPadding: 12),
            type: .category
        )
        .frame(height: 220)
        .padding()
    }
}

Even though the x-axis is now based on Date, the job of range is still the same: define how the domain maps into the horizontal plot area. Apple’s documentation for the modifier does not limit it to categorical charts; it defines the range generally as the x positions that correspond to the scale domain.

What is Type?

This is the part that often feels vague at first.

Apple’s ScaleType documentation describes it as “the ways you can scale the domain or range of a plot.”

That means the type parameter tells Swift Charts how to interpret the scale, while range tells it how much horizontal plotting space to use and how to distribute it.

A typical explicit example looks like this:

.chartXScale(
    range: .plotDimension(startPadding: 12, endPadding: 12),
    type: .category
)

If your x-axis values are strings like weekdays, month labels, product names, or enum-backed display values, .category makes the intent very clear. Apple exposes category as one of the available scale types.

Why Might Type be Needed?

In many charts, you do not have to set type manually because Swift Charts can infer the right behavior from the values you pass in. But there are still good reasons to use it.

1. It makes the axis behavior explicit

If you are using strings as x-axis values, they are typically meant to be treated as categories, not as a continuous scale. Writing type: .category makes that obvious in code. That follows directly from Apple’s scale model and the presence of .category in ScaleType.

2. It can make chart code easier to reason about

Even if inference works, explicit scale configuration can make the chart easier to read and maintain. This is not a direct Apple quote, but it is a practical consequence of how the API separates the idea of scale type from the scale range itself.

3. It helps you think in the correct model

When you pass categorical values, you are working with discrete positions. When you pass dates or numbers, you are usually working with a continuous axis. type reinforces that distinction.

Category Example with Explicit Type

Here’s a complete example that makes the scale type explicit.

import SwiftUI
import Charts

struct TemperaturePoint: Identifiable {
    let id = UUID()
    let day: String
    let temperature: Double
}

struct TemperatureChartView: View {
    let data: [TemperaturePoint] = [
        .init(day: "Mon", temperature: 18),
        .init(day: "Tue", temperature: 21),
        .init(day: "Wed", temperature: 19),
        .init(day: "Thu", temperature: 24),
        .init(day: "Fri", temperature: 22)
    ]

    var body: some View {
        Chart(data) { item in
            LineMark(
                x: .value("Day", item.day),
                y: .value("Temperature", item.temperature)
            )

            PointMark(
                x: .value("Day", item.day),
                y: .value("Temperature", item.temperature)
            )
        }
        .chartXScale(
            range: .plotDimension(startPadding: 12, endPadding: 12),
            type: .category
        )
        .frame(height: 220)
        .padding()
    }
}

This is a good example of where range and type work together:

• range adds breathing room inside the plot

• type: .category makes the discrete x-axis behavior explicit

How This Differs From Domain?

This is the distinction that matters most.

If you write:

.chartXScale(domain: [”Jan”, “Feb”, “Mar”, “Apr”, “May”])

you are configuring which values belong to the x-axis domain.

If you write:

.chartXScale(range: .plotDimension(padding: 20))

you are configuring where those values are drawn horizontally.

And if you write:

.chartXScale(
    range: .plotDimension(padding: 20),
    type: .category
)

you are also telling Swift Charts how that scale should behave.

Apple’s chart scale documentation separates these concerns clearly: domain is about possible axis values, range is about axis positions, and ScaleType describes how the domain or range of a plot is scaled.

A Practical Rule of Thumb

Here’s the version I’d keep in mind while building charts:

• use domain when you want to control what values are visible

• use range when you want to control spacing and plotting space

• use type when you want to make the scale behavior explicit

That makes chartXScale(range:type:) much easier to understand.

Final Thoughts

chartXScale(range:type:) is one of those modifiers that does not look exciting at first glance, but it becomes very useful the moment you start polishing a chart. The biggest win is usually visual: better edge spacing, more balanced composition, and a cleaner plot without changing any data at all.

And the nice part is that it scales from simple to advanced quite naturally:

• start with .plotDimension(padding:)

• move to startPadding and endPadding when you need more control

• add Type when you want the axis model to be explicit

Once you think of it that way, the modifier stops feeling obscure. It is really just a small but important piece of chart layout.

References

• chartXScale(range:type:)

• chartXScale(domain:range:type:)

• PositionScaleRange

• ScaleType

• ScaleType.category

• Swift Charts

Problem Begins

After happily updating to Version 1.2026.048 (1771630681)

the main view welcomed me with this:

Chats were not loading and new ones were blocked from being created. Not very appealing, so I went to check the web version at ChatGPT.com, where there was a list of my chats: pinned and unpinned. After checking the latest ones, everything seemed fine. Now it was time to check the pinned ones. And it was the correct guess! One of them was not loading, and I got a toast at the top of the screen:

Could not load conversation <uuid>!

The Safari console looked like this:

Applied Fixes

Googling and prompting led to a couple of suggestions. First of all, report it to OpenAI via the help form or chat in the app

This may trigger a possible fix from the server side.

At the moment of publication, no fixes have been made.

Form client-side:

• Refresh/Restart: Hard refresh your browser or restart the app

• Log Out/In: Sign out and back into your account to refresh the session.

• Clear Data: Clear your browser’s cache and cookies for chat.openai.com.

• Check Extensions: Disable browser extensions (especially ad blockers) that might interfere with page loading.

• Try Incognito/New Browser: Use an incognito/private window or a different browser to rule out extension issues.

• Switch Network: Toggle your VPN off or switch to a different network.

Would I wrote a post if any of this worked?)

Tracing the Problem

As a developer, I can see how the loading of chats might be implemented. For a conversation ID, the app should load the list of chats and retrieve the pinned ones. If any of them fail → show a warning sign with a popup on tap containing details and a “Reload” button. Yeah, right.

Instead, if any chat fails → the macOS app shows none of them. That is because they are not calling each conversation with a GET Conversation ID request. That brings speed, but the batch request fails. What can we do about it? Exclude the problematic chat. Pin/Unpin will not work. The only option is to archive it. This will prevent it from loading and move it further into Settings:

Later you can find it here:

And that’s it! The chat is prevented from loading on the initial start.

Quite interesting that in API chats are called conversations. And even browser has a https://chatgpt.com/c/ prefix.

In the survey after the session, I mentioned that splitting it into separate sections would be better, in my opinion. Finding that much time during either the night or regular working hours is not always possible. Let’s hope they are actually reading the feedback.

• Apple Video source

• YouTube version

As usual, questions are splitted into more or less common section. Grammar and punctuation are kept too.

🔐 Security & Memory Safety

What strategies can we use to evaluate third-party libraries for security vulnerabilities?

Hi! Evaluating third-party libraries can be tricky and require a lot of domain expertise as there are a wide variety of issues to look for. This is especially true if you only have access to the libraries in a binary form. Certain features—like EMTE—serve as mitigations and can be applied (in some cases) without a recompile, which can help in cases where you cannot easily audit the source. When auditing the source, some good hints for finding security relevant bugs are: 1. Memory unsafe code (C/C++, Swift could which uses unsafe, etc.), especially decoders and deserialization routines (e.g. bespoke file/request format parsing). 2. File path construction and archive expansion (zip files, etc.) are a common source of problems due to path traversal 3. Whether or not the code is memory safe, take special care to understand where it comes from and whether you trust it.

What are the potential security vulnerabilities associated with storing data in UserDefaults and plist files, and what best practices should be followed to protect against tampering or exposure?

In terms of pure data security, both approaches are fairly similar. The data is being stored in the file system and is protected the same way any other file does. However, using your own plist file does mean you can directly set the file’s protection level, which is another reason to avoid storing sensitive data in UserDefaults. Similarly, both are using the same on-disk format and data parser. Theoretically, that’s an attack vector just like any file parser. However, this particular parser is relatively simple compared to other formats (for example, SQL) and so widely used throughout the entire system that I’d consider it quite safe.

For a standalone iOS app with no backend, what’s Apple’s recommended baseline for protecting sensitive user-entered data at rest? Is ‘Complete Protection’ (NSFileProtectionComplete) plus Keychain for secrets the correct default?

The baseline for most data should be NSFileProtectionCompleteUntilFirstUserAuthentication (for files) and kSecAttrAccessibleAfterFirstUnlock (keychain). The issue with storing data at higher security levels is that data stored at “Complete” can really only be safely accessed while your app is in the foreground. More specifically, the data will only be accessible if the device is unlocked, but that state changes independently from background execution, meaning data can suddenly become inaccessible anytime your app is running in the background. You can and should use “Complete” whenever you can, but it’s a choice that needs to be made as part of your app’s overall design, not as an automatic default.

Is it safe to use the Data type’s withUnsafeBytes method? I find myself using it a lot when parsing values from Bluetooth devices.

Methods with “unsafe” in the name can be used safely, but it requires more care and attention to do so. You won’t always be able to avoid using such methods, but you can carefully isolate such code and of course make sure to devote more effort to reviewing and verifying any code that uses unsafe methods or types.

I’m confused of the purpose of blast door, given the validation of the image was ultimately down to messages… surely blast door would protect and / or sanitise the object/data recieved? Or have I missed the point?

Properly validating images can itself be a perilous task and so it’s one best not performed inside a (relatively) privileged process like Messages. BlastDoor validates and unpacks attachments in a highly restricted environment and then passes a much safer, simpler version of it to Messages. So, for example, Messages may give BlastDoor a JPG and BlastDoor will ultimately hand back a simple bitmap representation of it. This indemnifies Messages against memory corruption bugs in the JPG parser.

Apple on messages for example never denies uploads of different file types, but then how does it protect against file-based vulnerabilities?

Messages allows sending (mostly) arbitrary files but—notably—it does not parse/preview/unpack arbitrary files. Messages and BlastDoor work together to ensure that attachments which are processed are processed in a way that’s safe. It is generally safe to accept arbitrary files so long as they are not processed.

Memory safe languages like Swift or Rust have sometimes to bypass security checks (e.g. to access the kernel). Which protections and tools can be used in that case?

On Apple platforms, EMTE is a great way to mitigate issues caused by this gap. Even kernel accesses to user memory are tag checked, and so out-of-bounds/use-after-free accesses to user memory will still be reported according to the process’ enforcement mode. Other techniques such as fuzzing with libfuzzer and either ASan or EMTE on can also serve as strategies to gain confidence that unsafe code has the desired memory safety properties.

This question may be covered today, but I’m curious what resources and guidance exists for maximizing security in apps when we build across platforms. SwiftUI is write once, tweak, deploy. How about security? Sandboxing is different as an example on Mac vs iPhone.

Hi! Thanks for joining. The event today covers many topics about security and memory safety. Most of the guidance is platform agnostic, and some are programming language agnostic. For additional resources specific to your app and project environments, please refer to Apple Platform Security: https://support.apple.com/guide/security/welcome/web

What techniques help verify if a third-party app has adopted security enhancements, hardware memory tagging, security extensions?

If you have the application bundle available to you, you can use the codesign tool to view an application’s entitlements: codesign -d --entitlements - /path/to/application/binary As EMTE is controlled by entitlement, you can use this technique to see if EMTE is enabled for a given executable in the app.

What additional features (settings) required for fully Swift apps? is Enhanced Memory safety required (new Capability + config)? How much of security guarantees Swift provides? anything in the talk required to be enabled or is enabled by default?

Enabling enhanced security features like PAC, EMTE, and typed allocations is still useful in Swift apps. In certain language modes, Swift apps which do not use unsafe can still have memory corruption issues due to data races (concurrently modifying a reference can cause reference counting errors). Similarly, although your application may be fully safe Swift, it may interact with libraries (provided by Apple or third parties) which are not fully memory safe, and so turning on enhanced security features will help protect you against issues not caused by your code.

🛡️ Enhanced Security & Capabilities

For the Pointer Authentication feature, supporting arm64e is required. I understand this applies to third party SDKs, but how about an app that is completely modularized (with all modules in the same workspace), do we need to configure this per module or only the main app target?

arm64e is indeed required, and every target that contributes binary code that’s linked or dynamically loaded into an app does need to have arm64e added as an architecture. When enabling the Enhanced Security capability, Xcode adds the ENABLE_POINTER_AUTHENTICATION build setting (that adds arm64e) as needed, but you may need to add that separately as well.

Is there a cSettings SPM construct to enable PAC, MTE (and other features that do not require the final top-level signing/capabilities entitlement) in a Swift package that has C/C++ targets, so that compiled libraries can be included in an Xcode project using these enhanced security capabilities?

Any clang compiler option can be included in cSettings. Caveat: Prior to Swift 6.2, only some clang options were allowed, but starting with Swift 6.2, you can put any option.

Does PAC specifically (enhanced security include PAC and more) work for iOS 14+ deployment targets? You can enable each part of enhanced security individually, so like we know that typed memory allocator compiles nicely for iOS16 or 17+, but we can get PAC compiled for iOS 14+?

PAC is tied to the arm64e architecture. arm64e is first supported in iOS 17.4, and generally supported starting with iOS 26 and macOS 26. Universal binaries can be built for arm64e + arm64, and arm64 will be used when arm64e isn’t supported. When building the universal binary, both architectures can be compiled for an older deployment target, but keep in mind that arm64e will only be used on newer iOS.

Do these features require Xcode 26.4 to debug, run and test with? I’ve noticed the change in entitlements mentioned in the Xcode 26.4 beta release notes, does that mean that you need to test and run on Apple 26.4 OSes to try out Enhanced Security capabilities now?

Most of the capabilities of Enhanced Security are supported on and can be tested on Apple OS versions starting from 26.0. The “hard mode” of MTE (under which tag-check violations result in an immediate crash) is only supported beginning in 26.4, so to test with that capability on hardware with MTE support you’ll need to test with 26.4 or later OS versions. (described in 26.4 release notes [1]) The new enhanced-security-version-string and platform-restrictions-string string version entitlements you noted described in the Xcode 26.4 release notes [2] are set automatically by Xcode 26.4, but can be set manually in your entitlements plists using a text editor if you need to stay on an earlier Xcode version.
[1] https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_4-release-notes [2] https://developer.apple.com/documentation/xcode-release-notes/xcode-26_4-release-notes

I’m having trouble finding the advanced security… is it under signing in capabilities or is it under the settings of Xcode? Also. Can you build an outlet already contained like I was building a journal app I don’t want it to be connected to any network services by default or any services

Hi Elijah, please refer to the documentation below for steps to enable the Enhanced Security capability: https://developer.apple.com/documentation/xcode/enabling-enhanced-security-for-your-app

I’ve noticed that when enabling MTE, my app keeps crashing on launch with reports pointing to 3rd party SDKs. Whenever I take out one SDK, it just crashes in the next. It seems the reported tag is always 0, which makes me believe it’s not just violations but maybe a configuration problem on my end?

Additionally, arm64 binaries produced by older versions of clang may have issues where the tag is incorrectly stripped from the pointer. Recompiling the binary with a recent compiler should remediate the issue.

Will enabling enhanced security extension from code signing help to find bugs for debug builds on simulators as well?

Yes, starting in the 26.4 OS versions, applications that enable MTE (checked-allocations) as part of Enhanced Security will run with MTE enabled in the simulator when running on macOS hardware that supports MTE.

Is enabling standard library hardening recommended for all build types not just for debug? Will it cause any latency issues when enabled for prod configuration? Does $(__LIBRARY_HARDENING_DEFAULT_VALUE) mean no hardening set for project?

Yes, we recommend enabling at least the fast hardening mode, even in production builds. It has been designed to have minimal performance impact, but if you have very performance sensitive workloads, as always: benchmark before and after. For configurations with optimization disabled (level set to 0 — normally Debug configs), __LIBRARY_HARDENING_DEFAULT_VALUE defaults to “debug” (the more extensive checks). For optimized configurations (e.g. Release), __LIBRARY_HARDENING_DEFAULT_VALUE defaults to “fast” if Enhanced Security is enabled, “none” otherwise.

🔍 Hardware Support & Compatibility

Which of the devices announced this week support memory integrity enforcement?

Memory Integrity Enforcement is supported on A19, A19 Pro, M5, M5 Pro, and M5 Max, which power iPhone 17e, the new MacBook Air (M5), and the new MacBook Pro (M5 Pro or M5 Max).

Is the memory tag exposed in memgraphs or Instruments in any way?

When running under the Allocations template in Instruments, the memory tags do show up in object addresses. In memgraphs and the CLI tools like heap, these tags aren’t currently exposed, with the addresses correlating directly to their containing VM regions. If you’re interested to see which regions have tagging enabled, this is available with vmmap --attributes

Does Memory Integrity Enforcement support pre-Swift 6.0?

Yes, Memory Integrity Enforcement can be used with any Swift version.

🔄 C/C++ Interoperability

In some C/C++ functions the Swift interop uses unsafe pointers to bytes. Is there something like a Span API over the bytes of a Swift var to ensure a memory-safe and bounds-enforced buffer pointer to pass through to C/C++ code instead of using unsafe methods such as withUnsafeMutableBytes()?

Great question! Automatically generated wrapper functions that safely unwrap Span types and pass along the pointer to C/C++ is a feature available since Xcode 26 when the experimental feature SafeInteropWrappers is enabled. This requires annotating std::span parameters with __noescape, or pointer parameters with both __noescape and __counted_by/__sized_by, directly in the header or using API notes. Note that this is only safe if Swift can accurately track the lifetime of the unwrapped pointer, which is why the Span wrapper is not generated without the __noescape annotation. More resources are available at https://developer.apple.com/videos/play/wwdc2025/311/ and https://www.swift.org/documentation/cxx-interop/safe-interop/. Since this is an experimental feature with ongoing development, questions and feedback on https://forums.swift.org are extra welcome to help us shape and stabilize this feature!

💉 Pointer Authentication

How does PAC work with ObjC method swizzling at runtime?

When you use the functions provided by the ObjC runtime, they ensure that any necessary pointer signing is correctly handled.

How does pointer authentication different from other memory defense ways mentioned as part of whole app protection?

Pointer authentication makes it more difficult to create a pointer (from an integer) or to modify an existing pointer. This complements technologies such as MTE (which can catch many bound and lifetime errors) and typed allocation (which mitigates the effects of memory re-use).

Why is Pointer Authentication a compile-time, opt-in feature, and not a platform-enforced, runtime-enabled feature? I imagine something like that should be possible if something as magical as Rosetta is also possible 🙂

Additionally, PAC is a compile time change as it requires different instructions throughout the program.

Where are the cryptographic tags used for pointer authentication stored on Apple devices? Are they kept in the Secure Enclave or in another hardware component?

The signatures are, however, stored in the upper bits of the pointer itself.

📦 Allocators & Memory Management

Are type and alignment independent for typed allocators?

Mostly, yes, but not entirely. The typed allocators segregate and isolate allocations by size class and, within each size class, by type space partition. Let’s call the (size class, type space partition) combination the “type bucket” that serves a particular allocation. Requesting aligned allocations (e.g. via aligned_alloc()) can change the effective size class of an allocation because of implementation details of the allocators, and so can change the type bucket that the allocation is served from.

What is best approach to use system allocator for third party SDK e.g. Braze if enabled enhanced security extension for app and memory corruption is noticed?

Third-party SDKs linked in to your app/program will generally be using the system allocator automatically and benefit from Memory Integrity Enforcement automatically. If there are memory corruption bugs in those SDKs that Memory Integrity Enforcement features like MTE detect and turn into crashes, you would want to work with the developers of those SDKs to have them fix the underlying bugs. You could use MTE soft mode [1] to avoid having those memory corruptions crash your app while you wait for fixes from the developers, at the cost of the relative reduction in security that that entails. https://developer.apple.com/documentation/BundleResources/Entitlements/com.apple.security.hardened-process.checked-allocations.soft-mode

📏 Bounds Safety

How do bounds safety checks prevent out-of-bounds (OOB) accesses in practice? Is this implemented as a built-in feature in Clang? When developers add annotations, what mechanisms are applied internally to enforce or adjust the bounds checks?

Yes, this is built into Clang. With -fbounds-safety enabled Clang will emit bounds checks wherever pointers are dereferenced or reassigned (exception: assigning to __bidi_indexable does not trigger a bounds check, since __bidi_indexable can track the fact that the pointer is out of bounds and defer the bounds check). If the bounds check fails the program will jump to an instruction that traps the process. Clang uses a combination of static analysis and runtime checks to enforce that pointer bounds are respected.

Why is CoreFoundation missing all bounds-checking annotations? Do I have to use __unsafe_forge_single for all initializers?

Yes, that is the recommended approach when interoperating with libraries that do not have bounds annotations, when you want to be explicit about the fact that you’re interacting with unsafe code. This makes it easy to grep for “unsafe” in your code base when doing a security audit. If you are confident that the API adheres to a bounds safe interface but simply lacks the annotations, you can redeclare the signature in your local header with added bounds annotations, like this:

//--- system_header.h bar_t * /* 
implicitly __unsafe_indexable */ foo(); 
//--- project_header.h 
#include #include bar_t * __single foo();

📱 App Store & Privacy

Are there common App Store review pitfalls for apps that store sensitive contact data locally (even if it’s not medical)? Anything you recommend we avoid to prevent rejection or privacy concerns?

Hi Gloria! Please see the following pages on user privacy and data use:

- https://developer.apple.com/app-store/user-privacy-and-data-use
- https://developer.apple.com/app-store/app-privacy-details/
- https://developer.apple.com/documentation/uikit/protecting-the-user-s-privacy/
- https://developer.apple.com/documentation/uikit/requesting-access-to-protected-resources
- https://developer.apple.com/documentation/uikit/encrypting-your-app-s-files

🏆 Acknowledgments

A huge thank-you to everyone who joined in and shared thoughtful, insightful, and engaging questions throughout the session — your curiosity and input made the discussion truly rich and collaborative.

Special thanks to:

Larry Wang, Chandrachud Patil, Christopher Sheats, Gloria Glazebrook, Patrick Hoekstra, Chris CL, Eric Dorphy, AAron Wangugi, Quinten Johnson, Nicholas Levin, Kim Ahlberg, Jason Brooks, Patrick Cousot, Alex Infanti, Ilia, nikolay dubina, Danylo, Pablo Butron, Elijah Cody Bain Black, Paul Floyd, Kim Kyoungsu, Zaid Al-Timimi, Rupinder, Tanner Bennett, Sanket P, Steven Joubanian and Gordon Leete.

Finally, a heartfelt thank-you to the Apple team and moderators for leading session, sharing expert guidance, and offering such clear explanations of the apps optimization techniques. Your contributions made this session an outstanding learning experience for everyone involved.

This time it was SwiftUI: from basics to state behavior. If the last session about “Coding Agents in Xcode“ went for 16 mins and had 3 question - this one is totally different. It took more than 3 hours (!) and more than a 150 question.

But! Questions were not always linked to the session topic. You can find info about Concurrency or SwiftData also.

Even formatting and session questions gathering took hours for me. So, this is truly unique content. There even was a question regarding where can I found the Q&A session transcript later. The answer is: nowhere except here)

This huge amount with a threads (this also were not so common previously) is taking out-of-email size. Follow the link below for the full list of answers:
SwiftUI Foundations: Build Great Apps with SwiftUI Q&A

This time it was SwiftUI foundations: Build great apps with SwiftUI. If the previous session about “Coding Agents in Xcode” lasted 16 minutes and had only 3 questions, this one was completely different. It ran for more than 3 hours (!) and included over 100 questions.

But! The questions were not always tied strictly to the session topic. You’ll also find discussions about Concurrency and SwiftData.

Even formatting and gathering the session questions took hours for me, so this is truly unique content. Grammar and punctuation were slightly adjusted, but the authors’ formatting was kept as is.

And without further ado — here’s the session Q&A.

💾 SwiftData & Backend

Do you think it would be possible to write a ModelContainer targeting a backend other than iCloud, such as Firebase, and still be compatible with SwiftData framework annotations?

This is such an awesome question, the answer personally is I do not know, but would love to try to see if can be done, I think it is possible to write a ModelContainer targeting a backend other than SwiftData, however Firebase is a 3rd party framework so we can’t provide compatibility with SwiftData framework. SwiftData provides a way to abstract the backend and focus on defining models and relationships.

Start by defining your SwiftData models with the necessary annotations to specify relationships and attributes. Configure the ModelContainer to use your chosen backend.

It sounds like you can try to make it work In your application, configure the ModelContainer to use Firebase as the persistent store but then will not be store in SwiftData. You can now perform CRUD operations on your models using SwiftData, leveraging the backend of your choice, but I do not work if that can work. I would love to see that working, personally.

Implement synchronization and conflict resolution mechanisms between SwiftData and your backend sounds like a hard project. This may require additional configuration or logic tailored to your use case. While challenging, I believe the customization and migration could way too complex. Migration is the key word and being able to work in the future versions.

Does SwiftData support data virtualization for large row counts to avoid loading all items

SwiftData Query doesn’t currently support partial fetching. When rendering a large SwiftData dataset, consider using FetchDescriptor with appropriate predicates to paginate the data so you only load the data of the current page.

Can the sorting option in Swift Data queries take a user sort preference from @AppStorage?

Yes, SortDescriptor is codable, and so you can definitely persist a sort descriptor to AppStorage, or other kind of storage, and then retrieve it from the storage when needed, and use it with a SwiftData query.

What if I want to store the sort property per trip, so each different trip’s sort setting is preserved

In that case, If your trips grow unbounded you might want to consider persisting the sort options in your data model using SwiftData.

SwiftData and SwiftUI....I’ve found using @Model and @Query a reliable and easy to use approach for simple CRUD operations for a view. Is this the first go-to recommendation for implementing SwiftData in SwiftUI apps, when basics only are needed?

That’s correct. You can start with @Model and @Query. If you have questions when going deeper, consider asking in the Developer Forums.

🪟 SwiftUI Views & Layout

Is List backed by UICollectionView? What is the most “CollectionView”- like View for SwiftUI?

List is the most “CollectionView”-like View for SwiftUI.

Given a list of cards that are mixed media (list of text rows, images, charts). Should you use Collection, List, ScrollView, or something else?

It’s possible you would need all of them! for direct answers that are relevant to your project, I would make a post on the developer forums and link your code.

What happens with a ViewThatFits when no option actually fits? Does it render neither?

Are you talking about https://developer.apple.com/documentation/swiftui/viewthatfits ?

If a ViewThatFits option in SwiftUI does not find any view that fits within the specified size constraints, it typically renders nothing. This behavior is designed to conserve space by not displaying any content if no suitable view can be accommodated. The ViewThatFits view automatically adjusts its layout based on the available space, but when no view fits, it simply does not render. Check the link I sent you as the documentation is pretty good at how ViewThatFits works.

And check the sample code in the doc https://developer.apple.com/documentation/swiftui/viewthatfits

What might cause Text to sometimes be truncated? Using .fixedSize(horizontal: false, vertical: true) seems to always fix this issue. Is it due to ambiguous layout?

It might not have a frame large enough to contain the content until you give it one. You can share the code and project on the forums to get input from engineers around the world. See here https://developer.apple.com/forums/

Silly question, for adaptive views why cannot I use ZStack over .overlay() or .background()?

I don’t know what you mean, can you provide an example? Oh sorry use the forums to provide the example as will be a better answer if we can see what you are trying to accomplish as using ZStack over .overlay() or .background() for adaptive views isn’t necessary because both ZStack and these modifiers are part of SwiftUI’s declarative layout system and can work seamlessly together to manage stacking and overlaying of views.

Please provide your sample at the apple forums https://developer.apple.com/forums/

What is the best way to make a view inside a ScrollView at least the content size of the ScrollView itself and then it’s scrollable if larger than that. (Ex. I want to centre some empty/error state text).

To achieve this effect, you’ll want to ensure that the view inside the has a minimum height equal to the height of the itself and grows if the content exceeds this size. With GeometryReader once outside the to capture the device’s screen height available for scrolling, and once inside to measure the content height. This setup will ensure the text is centered and the view is scrollable if the content exceeds the default screen/scrollable area height.

I can’t write code in chat very well, but something like that?

GeometryReader { geometry in
    ScrollView {
        VStack {
            Spacer() Text("test test.")
                .multilineTextAlignment(.center).padding()
            Spacer() }
    }
}

🔷 Observable & State Management

Question about project from webinar

Why is Trip and Activity a class? I would have made them structs and only decorate DataSource with @Observable.

You can only place @Observable with a class (not struct). This is because the @Observable macro is designed specifically for reference types (class) to enable observation of property changes. For value types like struct, you should use @State in your view to manage data changes, as structs are designed to be copied rather than shared.

To rephrase my question from earlier. I understand, that only classes can be annotated with @Observable. My question was more pointing towards why you chose class also for Trip and Activity in the sense of that DataSource is already observable, so all its properties are. Or am I getting it wrong?

For the sample code, this allowed to pass the objects to views as references instead of copies, so that they could be mutated in place (when editing a Trip, adding activities to a trip, or marking an activity as completed). This made it so we wouldn’t need to mutate the whole model when a change was made.

Will @StateObject be updated to work with @Observable class without needing to conform the class to Combine’s ObservableObject protocol? We can’t use @State because it leaks heap memory, i.e. it inits a new initial object on every View init. And using optional State that’s init .onAppear is a painful

If the object is created in View init and set to a @State property via State(initialValue:), the new object instance is expected to be immediately freed if the view’s identity didn’t change, so leaking heap memory is not expected, and the leak might have been caused by other reasons like retain cycles. If there are concerns to create the @Observable object many times, an alternative would be to create the object higher up and pass it down to this view via a parameter in the init or via the environment.

@Environment causes all views that contain it to update? So it is hard to make the views that use it stable? Any and every change causes all views to update ... Correct?

@Environment in SwiftUI causes views containing it to re-evaluate their state when the associated value changes.

If the environment value changes frequently or across the app, consider using or directly within the relevant view hierarchy to encapsulate logic and data handling. Use conditional rendering to avoid unnecessary re-renders.

Yes they cause to update but while provides a powerful mechanism for data sharing, manage its usage carefully to maintain UI stability and responsiveness. By leveraging SwiftUI’s declarative nature and state management capabilities, minimize unnecessary re-renders and ensure a smooth user experience.

Main benefit it to be used to share state objects accessed by multiple views.

Can you subclass an @Observable object so that parent and child would have the macro? Example:

@Observable
class Trip {}

@Observable class ExtendedTrip: Trip {}

Are you talking about the sample or in general on SwiftUI? You can subclass an in Swift to create a custom observable object that can be used across the view hierarchy. This allows you to encapsulate your data and logic in a way that can be observed by any views that depend on it.

This pattern allows you to encapsulate your data and logic in a reusable observable object that can be shared across different views in your SwiftUI app. Like this?

@ObservedObject var observableObject: CustomObservableObject

In SwiftUI lists, should item model be value types (struct) and rely on parent ViewModel updates, or reference types (Observable/ObservableObject) so each row can update independently? What’s the recommended trade-off for performance and architecture?

This question is being answered in the current session. Please tune into the live Data Flow session to learn more.

The answer is… it depends! Use structs when your data is of a value type, and use class when your data contains reference types. When using a class, you typically make it Observable, so a change on the data can update related SwiftUI views.

I want to ask a quite basic question. If we are creating a model we should always be using class instead of struct? And there is no such thing as “View Model” then?

You normally use struct when your data is of a value type, and use class when your data contains reference types. When using a class, you typically make it Observable so a change on the data can trigger relevant SwiftUI updates.

I have an ObservedObject with Published Properties associated with a View. This is extended into 3 ObservedObjects conforming to a common Protocol. But the properties of the protocol would actually be Published Properties, which is not possible? Can we define a Protocol with such properties?

Swift doesn’t allow adding a stored property to a protocol extension, so if you tend to add published properties to a protocol extension so the types conforming the protocol automatically gain the properties, you can’t do so. You might consider using an Observable class instead. For more information, see mentioned in the following doc.

Could you explain the difference and why using let and var inside Views. It looks like with let the whole View is redrawn when the value change in the caller View.

When developing SwiftUI views, understanding the differences between and is crucial for efficient view updates and correct behavior. Let: Creates a constant value that cannot be modified after initialization. Var: Allows properties to change over time, triggering view updates.

Use let for stable values that do not change during view updates, ensuring predictable view behavior. Dynamic data in SwiftUI can be managed using var with @State for interactive or changing data, enabling reactive UI updates.

Mastering let and var in SwiftUI views is crucial for efficient, responsive user interfaces. Use let for immutable data and var with @State for mutable state

I would recommend to post this question into the forums as the basics of let and var in the views is probably not enough for you.

Visit Apple Developer Forums here: https://developer.apple.com/forums/

🚏 Navigation

How did you migrate from UIKit to SwiftUI specifically in navigation? Did you have a coordinator patter?

It depends on what exactly you’re trying to achieve here. The coordinator patter works as one way to handle navigation but it’s not required. The best thing to note, is that if you’re in UIKit UINavigationController you will want to use the standard push/present calls and present a UIHostingController. And inside a SwiftUI context you will want to use SwiftUI presentation. Mixing the navigation stacks can have unintended consequences. If a coordinator patter helps manage that, that works perfectly but you can also just call the views directly depending on the complexity of the UI and what fits best.

Migrating from UIKit to SwiftUI has two major difficulties, and they are not on View, it’s navigation and database. Do you have a presentation or a study case for this? How to move from segue navigation to SwiftUI? How to move from Core Data context to Swift Data?

A great video for that and resource I like is: https://developer.apple.com/videos/play/wwdc2023/10189/

Migrating from UIKit’s segue-based navigation to SwiftUI’s navigation system involves understanding the differences between the two approaches and adapting your navigation logic accordingly.

To migrate to SwiftUI, you’ll need to create a SwiftUI view that represents the same flow. Instead of using a navigation controller, you’ll use SwiftUI’s navigation views.

Also this is my go to https://developer.apple.com/documentation/swiftui/building-a-document-based-app-using-swiftdata

Bring core data to swiftUI https://developer.apple.com/videos/play/wwdc2021/10017/

And remember to model your data https://developer.apple.com/videos/play/wwdc2023/10195/

I am not an expert in SwiftData so I would recommend to ask that question and be specific of what you want migrate in another question for our expert to pick up.

How can we best provide async navigation links? This seems to be a fundamental requirement. I built a custom built AsyncNavigationLink that overlays a button on a NavigationLink, triggers an async call, overlays a ProgressView(). The async call triggers the NavigationLink. Is this the best way?

NavigationLinks themselves can’t be responsible for asynchronous handling. The destination view can have a ProgressView and react to asynchronous changes to your model. But, since NavigationLink is a view itself, it needs to be processed on the main actor. If you want to present the ProgressView before moving to the new view, you can make a Button that triggers the asynchronous callback, and then update your navigation path (that you can set with NavigationStack(path: $path)) when it is finished. This will use the .navigationDestination(for:) modifiers to decide the views to move to. Not sure if this entirely answers your question (

Navigation in Swift is one of the topics I’ve struggled with for a while. Whether using NavigationDestination or building your own Router to navigate. What is your recommendation for doing such, especially when you have multiple views that you want to push? Any suggestions?

The developer website has tons of documentation on recommended navigation styles: See https://developer.apple.com/documentation/swiftui/bringing-robust-navigation-structure-to-your-swiftui-app and https://developer.apple.com/documentation/swiftui/navigation

🛠️ UIKit & SwiftUI Integration

HostingConfiguration or HostingController ? On TableView and CollectionView , what’s best way to wrap SwiftUI code in cells? Is there difference between hosting config and hosting controller?

For wrapping a SwiftUI hierarchy in UICollectionViewCell or UITableViewCell objects, UIHostingConfiguration is the intended class. Please see the documentation for details: https://developer.apple.com/documentation/swiftui/uihostingconfiguration/ UIHostingController is intended to be used more broadly for SwiftUI views in general.

What is the best way to integrate SwiftUI into an existing UIKit App, keeping the performance of SwiftUI Previews high? I can use Swift Package Manager to integrate packages that contain SwiftUI components into the project. Is this the best way or are there simpler paths to go for best speed?

To use SwiftUI views in your UIKit app. See UIKit integration https://developer.apple.com/documentation/swiftui/uikit-integration

I’d like to re-ask the question by Joshua Arnold about resizing with UIViewRepresentable, as the link provided does not give an answer as to how to animate the size change

The reference is at the bottom of the linked page, see Adding UIKit to SwiftUI View Hierarchies https://developer.apple.com/documentation/swiftui/uiviewrepresentable#Adding-UIKit-views-to-SwiftUI-view-hierarchies

You can also post your code, images and more on the forums to receive direct help https://developer.apple.com/forums/

When using UIViewRepresentable, is it possible for the UIView to internally resize itself, and have SwiftUI animate the change in size? If I call invalidateIntrinsicContentSize() on the view, SwiftUI resizes the view immediately without an animation.

You must communicate size changes back to SwiftUI state for animations to work. For info how see Adding UIKit views to SwiftUI view hierarchies https://developer.apple.com/documentation/swiftui/uiviewrepresentable

What is Apple’s recommended approach for detecting when a UIHostingConfiguration / ContentView changes size internally? If I update the a UIHostingConfiguration with a larger view, the view will just truncate / clip instead of bubbling up to UIKit to resize itself.

When working with a hybrid UIKit and SwiftUI environment, SwiftUI views may change size internally without automatically updating their containing UIKit views. This is because SwiftUI views are declarative and may not notify UIKit of size changes beyond their initial setup. To address this, you can use SwiftUI view modifiers and UIKit mechanisms to propagate size changes.

GeometryReader to read the current size of a SwiftUI view and communicate changes back to UIKit.

I would personally wrap a SwiftUI view in a UIViewRepresentable and use a coordinator to listen for size preference changes and update the UIKit view size accordingly.

in a UIKit view controller or view to adjust the layout so observe notifications if possible

Visit Apple Developer Forums here: https://developer.apple.com/forums/

🔷 ScrollView & Visibility

Is there any further documentation or reliable ways to know if something is actually visible on screen? Based our experiences, onAppear in VStack in ScrollView, List, and LazyVStack all have different onAppear behaviors for their elements.

Please check out the .onScrollVisibilityChange modifier.

Is there a suggested way to determine the difference between .onAppear being called in a ‘forward’ transition vs a ‘return’ transition? i.e. list displayed vs returning to list from details view.

Yes, it is possible to differentiate between when .onAppear is called during a forward transition versus a return transition in SwiftUI, though it requires some manual state management since SwiftUI itself does not provide built-in distinction for these cases directly within .onAppear. I got some sample code so you can provide a more detailed information about your question.:

.onAppear { 
    if appearedOnce {
            print(”Main View reappeared (back navigation)”) 
    } else { 
        print(”Main View appeared (forward navigation)”)
        appearedOnce = true 
    } 
}

If I have a database with 100k+ rows, how do I manage paging/infinite scroll in SwiftUIs “List”, to manage memory appropriately. Similar to UITableViews prefetch handler.

Similar the the VStack and HStack shown on stage, there is a LazyVStack and LazyHStack which automatically allocate and deallocates views as they are needed on screen. For more info see “Creating performant scrollable stacks“: https://developer.apple.com/documentation/swiftui/creating-performant-scrollable-stacks

🦋 Animation & Effects

For the symbolEffect(_:options:value:) method for SF symbols, the animation only runs when the value changes. Is there a way to implement this behavior (only run something once for each unique value) idiomatically in SwiftUI?

Depending on the use case, this might not require explicit treatment to run an animation (e.g. the animation(value:) modifier might be all you need). But if you do need to perform side effects based on value changes, onChange(of:...) might be right to reach for.

I’ve added an animation to a Button but when it’s placed inside a NavigationStack’s ToolbarItem, the animation doesn’t run. When the Button is used elsewhere, the animation works as expected. Can you share how to use this animating Button inside a .toolbar?

This is a good question for the forums. Given a Button inside a .toolbar { } modifier, we’d need to see a fuller code sample to know things like where the animation is declared.

How can I start an animation after another animation? (without using hard coded durations)

A KeyframeAnimator or PhaseAnimator can be used for more complex animations! In KeyframeAnimator, for example, you can have separate steps in a KeyframeTrack, and separate tracks in a KeyframeTimeline. Helpful docs: https://developer.apple.com/documentation/swiftui/controlling-the-timing-and-movements-of-your-animations https://developer.apple.com/documentation/swiftui/keyframetimeline

⛏️ Modifiers & Customization

Is it possible to write modifier functions that can configure a custom view property even if it is contained in other container views? This would be similar to how .font works, in that it can be applied to a view and any contained Text will be reconfigured?

One possible way to achieve this is to use a type such as Group that can create a collection of views, such that its modifiers apply to all of its member views: https://developer.apple.com/documentation/swiftui/group

UIKit is inheritance-driven, so it is possible to subclass an UIButton, for example. The same is not possible with SwiftUI. What is the recommended alternative for a similar approach (mainly to customize appearance)? Style, viewModifiers, custom view, something else?

Custom view modifiers are one way in which you can reuse multiple view modifiers across different views. You can even extend the View protocol with a function that applies your custom modifiers. Check out “Reducing view modifier maintenance” for how to do that.
https://developer.apple.com/documentation/swiftui/reducing-view-modifier-maintenance

Is it possible to add a view modifier for the text width and set it to expanded as well as making it italic? The following code does not work, and italic is only applied if the width is .standard:

.font(.caption2.width(.expanded).italic())
   .fontWeight(.bold)
   .frame(maxWidth: width, alignment: .leading)
   .italic(italic)

Something like that too: .font(.caption2)

it is possible to combine text width and italic styling in SwiftUI using a custom view modifier. The issue with your current code is that the modifier in SwiftUI does not support applying both and modifiers directly in a combined way like you’re attempting. Instead, you can create a custom view modifier to achieve this behavior

If I put it together should be something like:

content .font(.caption2) .fontWeight(.bold).frame(maxWidth: width, alignment: .leading) .italic(italic)

Disclamer I didn’t test it, but I think is the idea.

Allows you to flexibly adjust the text’s width and apply italic styling independently within a single view modifier.

What’s the best approach to building modifiers in SwiftUI? I am specifically interested in how to handle the inert state. Is it better to apply the modifier conditionally depending whether it’s inert state or not. Or is it better to deal with the sate inside the modifier implementation.

Generally, try to avoid conditionally applying modifiers (specifically when the condition can change at runtime). It is better to handle an “inert” state from within the modifier. If you have a specific question about building a modifier that handles some state, feel free to send a question for that as well!

🔎 Performance & Debugging

I’m trying to debug a log about “Attribute Graph Cycle”. I’ve tried instruments, but it’s hard to identify the source. In my case, I think it has to do with frames/geometry negotiating sizes. I don’t notice a major slowdown - Is this even a problem?

Check if you have a custom layout or onGeometryChange that could be affecting your View’s sizing. Instruments can help show the catalyst of an update (through the Cause-and-Effect graph). Hitting a cycle may lead to unexpected behavior (aside from just performance issues/hangs), so it is still important to identify if you can. If you don’t see anything in your program that could be causing a loop, consider filing a bug report on Feedback Assistant!

Is there a way to see SwiftUI’s dependency graph for a view, so we can figure out whats causing excessive updates etc? Is instruments the best way to do this?

Instruments is the best way to figure out what is causing excessive updates and other issues with performance. Check out “Optimize SwiftUI performance with Instruments” for a lot of great information about SwiftUI and how to use Instruments to profile and optimize your app.

Can we see the view’s dependency graph in Xcode? Via debugging?

If you profile using SwiftUI template in Instruments, it shows you information such as long view body updates, cause-and-effect graph, update groups etc. please review the Understanding and improving SwiftUI performance article to learn how to use instruments to understand and debug your SwiftUI Views.

When is it better to extract a view into a separate ViewBuilder function/computed property versus creating a separate struct View? What are the performance implications of each approach?

Extracting your views into a separate view structs is a good way to, reduce dependencies to only those that matter to the view. This makes your code easier to read, and your dependencies become apparent at its use site. Ultimately you want to use your best judgement here because not every dependency deserves to be scoped to a separate view struct.

When views are scoped to separate view struct, try reducing view values to only the data they actually depend on. This could mean fewer updates and that implies better performance when data changes in your app.

During SwiftUI view reordering or layout updates, what typically causes temporary disappearance of views, and how can state consistency be preserved during rapid UI changes?

Having views temporarily disappear isn’t typical. Check out the tips in “Optimize SwiftUI performance with Instruments” to determine if there are some performance issues or tuning that you can do to improve the view. If that doesn’t help, please post your specific issue on the Developer Forums for more assistance.

One of the great things I find in working with SwiftUI is that you can build most of your app staying in Xcode with Preview. I loved the last section about using print in view, but it is only at runtime. Is there a library that let you use a debug overlay modifier to display debug data in a view?

You can output into a Label? And there are many views where output is allowed. But the NSLOG is a way to go to the console. You can add a GeometryReader within a view’s .overlay()

SwiftUI provides a convenient way to display debug data

There is a video that may help you: WWDC23: Debug with structured logging

I would recommend this doc as well https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/DebuggingTricksandTips.html

Are there tools for diagnosing layout issues? On macOS, my app behaves very strangely, growing the window arbitrarily even though subviews’ sizes aren’t changing.

Hi, you might find the following guide helpful: “Diagnosing issues in the appearance of a running app”.

🏡 Dismissal & Environment

What would be the difference in using the @Enviroment(.dismiss) or making it a binding when dismissing a sheet? Is there performance benefit?

Both and make sheet dismissal in SwiftUI, but they differ in functionality and performance. It is a property wrapper that exposes the modifier applied to a view. It’s often used to dismiss views or sheets from outside their hierarchy, like from a parent view or navigation stack. It is efficient as it doesn’t create additional state or UI components. It simply exposes an existing closure in the view hierarchy, involves defining a closure for dismissal and wrapping it in a . This is useful for more control or integrating with custom views that require explicit dismissal but creating a binding has some overhead, but it’s usually negligible. The impact is minimal compared to other UI operations.

In summary, and are efficient is straightforward for dismissing views from outside their hierarchy, while binding provides more control and flexibility for custom dismissal logic. Performance differences are minimal I think, and the choice depends on your application’s requirements.

🏛️ Architecture & Patterns

Is MVVM organization recommended for a SwiftUI project?

Different apps need different architectures. An app with heavily server-driven content should make architectural decisions specific to that design. An app focused more on displaying data locally (and might not be updating its content as frequently) should use an architecture that makes that use case easier to build for. SwiftUI is architecture agnostic to allow deliberate architectures that work for your app.

When passing in an action into a view is it better to use closure or function/method reference? Example:

SomeView(saveAction: { viewModel.performSave() }) 
vs
SomeView(saveAction: viewModel.performSave)

Great question and thanks for providing the code. What I think is whether to use a closure or a function/method reference when passing an action into a view depends on your specific use case and personal preference. Both approaches have their advantages, and the choice might be influenced by factors like readability, performance, and Swift features. You can capture specific variables from the surrounding context using a capture list if needed, providing more flexibility. It allows for quick inline modifications or additional logic without needing to create a new method elsewhere. Cleaner syntax, especially for simple method calls, improving readability. Potentially more performant since it directly references the function without additional closure overhead?

🐞 iOS Issues & Bug Reporting

Since iOS26, dismissing the keyboard stopped working as expected. If I have a TextField focused in a navigationDestination view or in the content view of a fullScreenCover, and then dismiss the view, the keyboard would sometimes leave a white bar at the bottom in the safeArea. Is this a known issue?

If you come across any visual issues while using SwiftUI, please feel free to file a bug report via Feedback Assistant. Thanks for letting us know about this! https://developer.apple.com/bug-reporting/

🎓 Learning Resources & Miscellaneous

What’s the best way to learn how to use Metal, particularly for visual effects rather than graphics?

This is just my approach, I like to take apart and study sample code. For Metal, there is an entire database of sample code here https://developer.apple.com/metal/sample-code/

Also, please check out the segment on Metal in this talk from WWDC24, “Create custom visual effects with SwiftUI”.

Love to learn more about SwiftUI and Metal - for video rendering would the performance be faster using a custom shader with [[stitchable]] and SwiftUI vs NSView or MkitView?

It depends on the purpose! [[stitchable]] Metal shaders can be used to apply an effect to an existing SwiftUI view via the colorEffect(_:isEnabled:), distortionEffect(_:,maxSampleOffset:isEnabled), and layerEffect(_:maxSampleOffset:isEnabled:) modifiers. If you’re looking for a more flexible view that displays Metal objects (i.e. drawing your own shapes with vertex and fragment shaders), you should probably lean on MTKView. MTKView is provided by MetalKit and can be placed in an NSViewRepresentable or UIViewRepresentable. One is not strictly faster than the other, and you should choose whichever method matches your vision! MTKView: https://developer.apple.com/documentation/metalkit/mtkview SwiftUI Shader: https://developer.apple.com/documentation/swiftui/shader

What do your designers (in Apple) use to design for passing on to developers? Whenever I’ve had designs from Figma, Sketch, Azure, Miro, whatever, they aren’t true to platform and don’t correctly confine the designer to use native components.

This is a good question! It can be hard for design tools to match the fidelity of the look and feel of Apple platforms. Apple provides design resources for Sketch and Figma at https://developer.apple.com/design/resources/ and the materials are adjusted to resemble iOS as closely as possible.

In your partnership with developers, check in with the engineers and ensure that the designs are well understood before they are implemented. It also helps when everyone communicates using the same language, so we recommend that both developers and designers (and even other members of the team) familiarize themselves with the Human Interface Guidelines for the platform your app supports. The Human Interface Guidelines are available at https://developer.apple.com/design/human-interface-guidelines/

I had some trouble finding the entry point of sessions like “Code-along: Start building with Swift and SwiftUI” on the developer website. Is there an entry point where I can navigate thru all the sessions like “code along” and today’s or previous sessions?

Thanks for the question. I recommend to start with this video: https://developer.apple.com/videos/play/wwdc2021/10062, then a code along is always good like: https://developer.apple.com/videos/play/meet-with-apple/237/ and do not forget the what’s new to avoid using the older API https://developer.apple.com/videos/play/wwdc2024/10136/

As an absolute beginner, what would be the first go-to step to go for training? or documentation? on Apple.

A great place to learn how to develop for Apple is through Pathways (https://developer.apple.com/pathways/?cid=ht-pathways), your first step to creating for Apple platforms! For documentation, here is the top-level page: https://developer.apple.com/documentation/

Do you have any advice for someone with Flutter/Dart experience starting SwiftUI?

Thanks for the question. I think we got something similar from someone else, but welcome to Swift coming from Flutter! To start I would recommend to start with this video: https://developer.apple.com/videos/play/wwdc2021/10062/ then a code along is always good like: https://developer.apple.com/videos/play/meet-with-apple/237/ and do not forget the what’s new to avoid using the older API https://developer.apple.com/videos/play/wwdc2024/10136/ But welcome to Xcode! You are going to love it.

Any recommendations for resources (books, WWDC sessions, sample repos, or articles) on doing test-driven development with Swift/SwiftUI—especially patterns for testing view models/presenters and keeping UI code thin?

There’s several WWDC sessions that may be beneficial to you, https://developer.apple.com/videos/play/wwdc2024/10195 and https://developer.apple.com/videos/play/wwdc2019/413

There are tons of modifiers, how we suppose to memorize all of them or even know that they are exists? 😊

The Developer Documentation is always a great place to start! https://developer.apple.com/documentation/swiftui You can also look into bundling your commonly-used modifiers into custom view modifiers- check out “Reducing view modifier maintenance”.

🔷 Wishlist App Specific (App from the webinar)

Where can I download the wishlist app xcode project?

Thank you for your question and attending the event. The sample code for “SwiftUI foundations: Build great apps with SwiftUI” will be made available on the Apple developer website sometime after the event concludes. Stay tuned!

Will the code for Wishlist app be made available?

Thank you for your question and attending the event. The sample code for “SwiftUI foundations: Build great apps with SwiftUI” will be made available on the Apple developer website sometime after the event concludes. Stay tuned!

Why cardsize is provided for TripCard in example of Wishlist struct presented in motion presentation ?

TripCard could either be represented in different sizes, either as a compact or expanded card with a larger width.

I noticed the Wishlist sample app has a customized font in the NavigationBar’s title. Curious how this was accomplished?

For a navigation bar title with styling, you can create a custom view containing a Text with styling modifiers, then wrap it in ToolbarItem(placement: .largeTitle) or ToolbarItem(placement: .title) on the .toolbar.

Is the Wishlist app MultiPlatform for iPhone, Watch, TV, Mac, etc?

Thanks for the question. The app is currently an iOS / iPadOS app. You can run it on macOS and visionOS in Designed for iPad mode.

💬 Text & Fonts

Any recommendations to have a more readable or idiomatic alternative to .frame(maxWidth: .infinity, alignment: .leading)?

Certainly! If you’re looking for a more readable or idiomatic alternative to , it depends on the context and the layout you’re working with. If you’re using Auto Layout, you can define constraints programmatically. This might be more readable if you’re comfortable with constraints, use that. If you have a container view that naturally supports full-width content, you might use a container view to manage the layout. If you need more control over the frame, you might define a custom frame Choose the method that best fits your design system and the constraints of your project. Auto Layout is often preferred for its flexibility and control, especially in UIKit. But I personally like adding a Spacer() into the view!.

I would like to follow up on the question on how to add a different font in the navigationTitle. While it is true, that you can add a styled text to the modifier. The result will will compile but not change its appearance and show an error: “Only unstyled text can be used with navigationTitle(_:)”.

You can create a ToolbarItem(placement: .title/.largeTitle) that is a Text styled with AttributedString.

📐 Geometry & Sizing

What if a subview prefers a bigger HxW than what is offered by the parent view? How are the conflicts handled?

I’d recommend testing this out, then adding other modifiers to build intuition for SwiftUI’s layout system!

struct BiggerChild: View { 
  var body: some View {
     VStack {
       Color.orange .frame(width: 200, height: 200) .opacity(0.3) 
      }
      .frame(width: 100, height: 100).background(.purple) 
    } 
}

You’ll find that the parent won’t clip the child, and the child will extend beyond the parent. From there, check out the clipShape() modifier.

Is there a canonical way to set .frame sizes that are dynamic to device sizes? For example, .frame(height: oneThirdOfDeviceHeight)? UIScreen? Geometry reader? Is there a preferred approach?

To set dynamic frame sizes in Swift for different devices, you can calculate dimensions based on screen width and a predefined ratio to maintain aspect ratios. The GeometryReader approach is modern and powerful, defining views in terms of available space. For complex layouts, Auto Layout provides flexible constraints that adapt to device sizes. For simplicity and direct access, using or similar methods works well for basic dynamic sizing. For more complex layouts and better responsiveness, Auto Layout is more powerful. Constants and computed properties help keep code organized and maintainable.

I think I understand your question with the frames utilization but please feel free to ask the question again with more details.

I have the following:

LazyVGrid { 
  ForEach { 
    VStack { 
      Image() 
      Text() 
    } 
   } 
}

Now, because the text of each view differs (sometimes it takes 2 lines, sometimes 1 line and sometimes 3 lines) the views are no longer aligned on a base-line. How can I get the views aligned again at a common base-line.

It could be the way your LazyVStack is deallocating views. I think this would be a great question for the Developer Forums. I encourage you to post this question there so we can more easily share code and others with the same issue can find help for the same issue. Visit Apple Developer Forums here: https://developer.apple.com/forums/

If I have a view thats 50px x 50px, and I want to display many of them in a HStack, evenly spaced so they are edge to edge. Whats the most performant way to achieve this? I’ve been using a “Spacer()” inbetween each, but wondering if thats causing overhead

Best way to see the best perform control is to debug and use instruments to check your UI as has SwiftUI instruments as well. Using between views in an is a common approach, but if you’re concerned about performance due to a large number of views, you might consider a more direct calculation to distribute space evenly. Lately I have been a huge fan of GeometryReader as It is used to get the available width of the parent view. Calculate the total width occupied by the views and subtract it from the available width to get the total spacing needed. Divide this by the number of gaps (which is one less than the number of views).

But Space is really good, I would really recommend you to make Instruments your best friend.

Visit Apple Developer Forums here: https://developer.apple.com/forums/

Any performant alternatives to geometry reader? I have to put a vertically centered textfield, with a helper text below it, but also add pull to refresh, so I have added a scrollview.refreshable, one alternative is to create a manual drag gesture, but can we achieve this using scrollview?

This depends on what you’re trying to achieve. For example, if you’re trying to respond to scroll view changes you should checkout the onScrollGeometryChange, onScrollTargetVisibilityChange, onScrollVisibilityChange
and onScrollPhaseChange API.

📼 Images & Media

I’d like to have a zoomable and draggable image within a scrollview, like you would see in the photos app. Can this be done with SwiftUI?

We can provide information how Apple apps controls work, you can achieve a zoomable and draggable image within a in SwiftUI using the modifiers and the and views.

.gesture( DragGesture() .onChanged { value in 
  print(”Dragging at: (value.location)”) 
}.onEnded { value in 
  print(”Drag ended at: (value.location)”)
})

Other this are ScrollView, creates a horizontal ScrollView without showing the scroll indicator bar.

If I present a series of Image views in a LazyVStack -- Image views that need to be resized. How can I make sure all images get resized to the same width/hight (a common denominator) and don’t end-up looking different?

To ensure consistent sizing of views in a series, explicitly set modifiers on each view to define a specific width and height for all images. Decide if you want to maintain the aspect ratio by using modifiers to control how images fit within their frames. This makes images scalable, sets a fixed size for each image, and clips images that exceed frame bounds for neatness.

Great question for sure! Make sure when displaying a series of views in a and ensuring they all have the same dimensions so you do not need to set constraints.

Visit Apple Developer Forums here: https://developer.apple.com/forums/

🎨 Colors & Themes

How do create themes in a SwiftUI app. A theme that can hold typography, colors, spacing. How do we handle a case with multiple themes. And a case where the theme is fetched from the backend.

You can create a file with all your application constants, and use conditional logic in the View to select which constant you need on a view by view basis, or pick up on environments such as light mode, dark mode or orientations.

If you need help, make a post on the forums!

If you use a non-semantic color how do you make sure it works in dark mode?

I’d consider checking the colorScheme environment and using an appropriate color based on the current dark/light mode. See the following doc for more details.

For designing is there a best practice for example the title in the trip detail is white but what if the photo is having a white color where the text is going to render, or there is a way to make it adaptable depending on the background to create the right contrast

If the title sits on top of scrollable content, for example a toolbar or safe area bar, the color automatically adapts to the content beneath it.

Maho mentioned a neon color. Since it is not part of the system colors, how do we create it? Do we have to provide the light, dark and increased contrast versions?

How to add a color literal to an Xcode project is discussed here: After adding a color to your asset catalogs, you can set up the color variants, and also set the hex value of the color. The Wishlist sample will be made available on the Apple developer website sometime after the event concludes. You can download it and look into the details of the color.

What impact does use of Color have on battery life? How can we override dark mode?

Have you use the Instruments from Xcode3? I think like colors with higher saturation tend to require more brightness to be perceived clearly, which can drain a battery faster? But you can use the battery impact into the Instruments app to give you clear answers but using color and avoiding color. Remember that while overriding dark mode can help with visibility and comfort in bright environments, it may increase battery consumption but Instruments here are your best friend.

Visit Apple Developer Forums here: https://developer.apple.com/forums/

📊 Charts & Performance

Following up on my Chart question. The chart is showing live data showing over time. I tested with instruments and tracked it down to the chart that is causing it. My current plan is to use Canvas instead for better performance but wanted to confirm I’m not missing something with Swift Charts

If you have spotted out that Swift Charts is the performance bottleneck, yeah, drawing with Canvas with your own code may help, because that way you can only draw the content specific to your needs. But again, we will be interested in looking into more details about your use case. I suggest that you ask this question in our Developer Forums with your code snippets and analysis so SwiftUI folks can follow up from there. Thanks.

I have been trying to test Swift Charts with some sample tests. My use case requires updating the chart continually (at least a few times a second). For 200 data points I’m seeing around 40% CPU usage which is a lot for my use case where I might have multiple charts displaying at the same time.

For a performance issue, I’d typically start with using Instruments to profile the app and figure out the performance bottleneck, and then see how it can be improved. The following doc may be worth reading: - Understanding and improving SwiftUI performance In your case, you might also consider if “at least a few times a second” is really needed and brings a lot of value. Refreshing a chart that frequently does consume resources.

🚟 Platform Specific

I have a SwiftUI view which displays a List, with a few labels and an image. The list row height should be consistent for each item. When the list items grows large, the same code performs just fine on iOS, but starts lagging on macOS (26.2). What explains this?

It is difficult to say for a specific app what would cause the difference. In general, first use Instruments to profile the app and optimize its performance. Check out “Optimize SwiftUI performance with Instruments” for detailed information and tips. If you’re still having issues, please post on the Developer Forums for more assistance.

When building a native Mac app using SwiftUI how do I debug the title bar looking different on my machine (built via Xcode or exported) vs a testers machine even when on the same macOS version (26.2)? Ex: The title bar being transparent as expected in some places or just greyed at the top instead.

Hello, you can troubleshoot visual inconsistencies across different devices by making sure all of your Appearance settings are the same between them, e.g. Dark Mode, Liquid Glass, Accessibility display settings, etc. Also make sure that the content underneath the titlebar is consistent. If you are still experiencing issues despite this (or the appearance is not what you would expect), please file a bug report via Feedback Assistant: https://developer.apple.com/bug-reporting/

What is the best way to make an app that works for all the devices (iPhone, iPad, Mac, TV, Watch, Vision Pro)? Making a single “empty” project in Xcode then adding each platform target, or a separate Xcode project per platform?

Create a new Multiplatform app. Then in the target list in Xcode, add a new target; Add a Watch app that is a companion to the existing app target. In the Watch app target properties, check or uncheck the box for “Supports Running without iOS App Installation” depending on your app’s requirements.

In macOS, SwiftUI provides some default menus. How can I specify keyboard equivalents for default menu items without having to replace the implementation, specifically for Edit->Delete? Even if I provide an implementation, it seems I’m forced to replace all of the pasteboard commands, not just Delete.

You can find a full guide on configuring the Mac menu bar here: https://developer.apple.com/documentation/swiftui/building-and-customizing-the-menu-bar-with-swiftui

Is SwiftUI ideal for extensions?

Hello, if you’re interested in building app extensions with SwiftUI, it’s a snap when paired with WidgetKit!
https://developer.apple.com/documentation/swiftui/app-extensions

Can SwiftUI be used to develop a 2D game? If not what is the suitable apple framework to use? (SwiftUI or SpriteKit or ARKit or something else?)

SpriteKit is a framework you could use to add characters to your game. For setting up the game and its logic, I would start with GameKit! See this documentation to get started: https://developer.apple.com/documentation/GameKit/creating-real-time-games

And ARKit is if you want to make an immersive 3D app using the device camera.

Will the custom shape overlay MKMultiPolygon from UIKit MapKit be included in SwiftUI MapKit? It’s a major polygon type overlay for map engineering and developers currently have access to only Polygon,Circle,Polyline etc… any graceful suggestions in the mean time?

Depending on how you’re currently using MKMultiPolygon, you could use a ZStack with multiple Polygons in your Map, and apply your style modifiers to the ZStack to apply them to all of the Polygons in the ZStack.

🎹 TextField & Keyboard

Is there any way to present an editable TextField that never presents a keyboard or responds to a USB keyboard? I’m building a calculator app with its own keypad that appends to an expression. But I’d like to give the user the ability to select parts of the expression or place the insertion point.

SwiftUI doesn’t provide a way to replace the system-provided keyboard with an input view. I’d suggest that you file a feedback report for that. As a rescue, you can use UITextField + UIViewRepresentable (assuming iOS / iPadOS), and give the UITextField instance an inputView.

Textfield - inline formatting. Currently, Textfield format API doesn’t support inline formatting . What is recommended way to format inline forms on swift ui text fields?

I would start by looking at the prompt of a TextField, see: https://developer.apple.com/documentation/swiftui/textfield/init(_:value:format:prompt:)

🛡️ Security

Where is the best place to keep Access Token and Refresh token/s handling most secure session for Swift Apps?

Use the Keychain to store tokens and other secrets. See the API reference for Keychain items for more information.

🏎️ Concurrency

Say the code is already on Main queue, I used a check Thread.isMainThread and then dispatch on main if false, if true, execute as it is. I want to achieve similar behaviour using modern concurrency. Is it possible? Task {@MainActor} will always behave like main.async

You can await MainActor.run to execute a synchronous piece of code on the MainActor, which should avoid suspending execution if you are already on the MainActor. If you need to know specifically what actor you are on, you can use the #isolation function argument to introspect the current execution context (which returns a type of isolated (any Actor)?). When you are nonisolated, this will be nil. Conversely, when you are isolated--and on the MainActor--it will be .some(MainActor).

🖌️ Icons & App Design

Can I build an app icon from scratch in Icon Composer app or I’d need to first design the icon in Figma/Sketch first than import to Icon Composer to add liquid glass design?

Hi, have you checked out the guide Creating your app icon using Icon Composer? You can download an App Icon Template to create the layers in Figma and Sketch, before importing to Icon Composer. Template available here: https://developer.apple.com/design/resources/

I am having trouble getting the new app icon process to work. My icons in the assets catalog work fine, but icons that I create in IconMaker do not appear at runtime after I add them to my project, whether iOS or macOS.

Hi, you can review the Creating your app icon using Icon Composer article. It’s a great resource to learn about using Icon Composer and adding your Icon Composer file to your Xcode project.

🎬 Toolbar & Actions

Is there a heuristic for the number of toolbar actions to show before moving them into a “more” menu in the toolbar?

You can’t predict the number of toolbar actions that can be shown before they will be displayed in a “more” menu. This will be highly dependent on the size of the device, the size of the window or view, and the size of the toolbar items.

On iPad, DocumentGroup’s title/rename UI gets clipped when I fill .topBarLeading, .principal, and .topBarTrailing (trailing is an HStack). Any recommended toolbar structure to preserve the system rename affordance without dropping .principal or using a menu?

I think this would be a great question for the Developer Forums. I encourage you to post this question there so we can more easily share code and others with the same issue can find help for the same issue. Visit Apple Developer Forums here: https://developer.apple.com/forums/

Apple encourages us to use the navigation bar, but some Apple apps are starting to use more controls in the bottom of the screen, i.e. Safari. Should we focus on using the navigation bar or try to add buttons at the bottom. Thank you!

I would encourage you to find what it works for you, recommendations are one thing, but we do not know your requirements, if the navigation bar fulfills your requirement

Your custom buttons have their merits and can be effective depending on the context and design goals of your app.

The navigation bar is a traditional element in iOS apps and is widely recognized by users. Typically occupies less screen space at the top, providing more room for content than buttons.

Consider how users naturally interact with the device. I don’t think this what you wanted to hear but personal requirements are hard to fulfill in one quick answer. I would recommend the forums if you have examples of what you trying to accomplish.

🔷 Miscellaneous

Is swift UI good at managing memory within messages or keyboard extensions? Lots of bandwidth issues causing crashes when loading a lot of data. Host app is fine…anything helps!

Extensions typically have a hard memory limit. The system doesn’t allow extensions to consume more memory than the limit. Simply switching to SwiftUI doesn’t change the limit, and probably doesn’t help reduce the memory consumption either. Memory consumption is typically related to data management, and so focusing on loading and using data more effectively may better help. I’d suggest that you ask this question in our Developer Forums with more details of how your extensions consumes memory, and we can have a deeper discussion from there. Thanks.

How to best abstract the model for views? A custom view like SearchRow(tripName:, photoName:) is already its own view model. But SwiftUI components like Button don’t give us access to their model. The scene would be like ForEach(searchRows) and ForEach(buttons) or more generally ForEach(rows)

Trying to understand your question and hope I got exactly what you mean with the best abstract model for a view as is hard to answer, I would recommend you to go to the Apple forums as well to follow up. When designing the SwiftUI views with models, for lists with interactive components like buttons, clearly separate and manage state effectively, a clear data model representing the information you display and interact with, view model holding instances of your data model and necessary business logic or state. Define custom views presentation logic for each item with state in the view model or pass closures to handle actions as your main view to iteratee over your view model’s data, passing state and actions to child views. Ensure state changes in interactive elements reflect in the view model, which updates the view due to properties.

I want to add a half screen mostly transparent dialog over the main window of a UI photo editing app. Examples or suggestions?

I’d probably consider using ZStack to lay out a view above the main window and to the target position, make it almost transparent, and use it as the dialog.

In the example of let _ = print(), will that print get called every time the view updates or just on initial creation?

It depends on where you put the print. If you put it at the beginning of the body, every time the SwiftUI recalculates the view body, the print will be called.

I use SwiftData and the @Query annotation to display my data. Each Item is rendered in a subview. Is there a way to pass the Item to be modifiable using either an annotation or something else? Let’s say a pinned attribute is being flipped and updating my @Query without an explicit call to SwiftData

Not sure if I understand your question correctly, but if you intent is to pass a SwiftData model to a view and change the model in the subview, you can definitely do so, and @Query will automatically detect the changes on the model. If you are seeking a way to change an attribute of the model without calling the setter of the attribute, no, there is no way to do that.

Why are views discarded? The dependency tracking- is this feature’s efficiency directly dependent on the discarded views? The Apple Developer Library-the extent of the resources pulled from there?(Customizable?)

SwiftUI efficiently manages memory by discarding views that are no longer visible or needed. This process optimizes performance by keeping only visible or recalculated views in memory. SwiftUI uses a declarative syntax to define the UI state, and the framework automatically updates views when the state changes. Instead of manually updating each view, SwiftUI only updates the affected parts of the view hierarchy. Views are part of a hierarchy, and when their state changes, SwiftUI recalculates the entire affected hierarchy. If a view is no longer visible or necessary, it is removed from memory, reducing memory usage and improving rendering performance.

There are numerous examples and code snippets demonstrating how to implement various features in SwiftUI and related technologies.

Yes, the efficiency of SwiftUI’s dependency tracking and rendering can be dependent on how effectively views are discarded. SwiftUI keeps track of which views depend on which other views

I don’t know what you want exactly from the library.

Is there a way to only draw a portion of a view at a time? With AppKit I’d use -[NSView drawRect:] to only draw visible parts of the view. I have a View whose body is a large Path, and I’d like to reduce the amount of drawing I need to do at once by only drawing the section of the Path visible.

SwiftUI is a different approach, and the view body is updated as a whole based on changes to its data. You might be able to split this into multiple views that each represent part of the Path which can each be individually updated when the underlying data changes. The Developer Forums are a great resource to get more assistance with your specific use case.

🏆 Acknowledgments

A huge thank-you to everyone who joined in and shared thoughtful, insightful, and engaging questions throughout the session — your curiosity and input made the discussion truly rich and collaborative.

Special thanks to:

Aap, Aaron Brooks, Abdalla Mohammed, Alexis Schotte, Andrew Hall, Arpad Larrinaga Aviles, Ash, Ativ Patel, Brian Leighty, Cyril Fonrose, Dan Fabulich, Dan Stoian, Dan Zeitman, David Ko, David Mehedinti, David Veeneman, Dipl.-Ing. Wilfried Bergmann, Eleanor Spenceley, Elif Arifoglu, Elilan, Etkin, Evelyn, Farhana Mustafa, Fred Baker, Greg C, Ian Shimabukuro, James Clarke, Jan Armbrust, Jason Howlin, Jay Graham, Jesse Wesson, Jobie, John Ellenich, John Gethoefer, John Lawter, Jon Bailey, Jon Judelson, Jonas Helmer, Joshua Arnold, Julien, Kaan, Kaylee, Lloyd W Sykes, Lucy, Luis Rebollo, Maic Lopez Saenz, Maisomage, Malcolm Hall, Marin Joe Garcia, Markus, Matthew Brown, Michael Bachand, Michael K., mustii, Muthuveerappan Alagappan, Nathan Odendahl, Nicolas Dunning, Oliver Dieke, Omar zuñiga, Oshua Arnold, Pete Hoch, Rayan Khan, Ricardo Moreno Martinez, Rick Mann, Rupinder kaur, Sam Wu, Satish Muthali, Siddhartha Khanna, Simon McLoughlin, SRINIVASA Potnuru, Tom Brodhurst-Hill, Tula W, Ulien, Vijay Ram, Walid Mohamed Nadim, Will Loew-Blosser, Willian Zhang, Yafes Duygulutuna, Yassin El Mouden, Yuriy Chekan and Zulfi Shah.

Now that’s a list!

Finally, a heartfelt thank-you to the Apple team and moderators for leading session, sharing expert guidance, and offering such clear explanations of the apps optimization techniques. Your contributions made this session an outstanding learning experience for everyone involved.

You can see a “New worktree“ and that attracted my attention. But that was not the first time I had used it. I just didn’t know about it.

Claude app also use it for parallel session:

Work in parallel with sessions

Click + New session in the sidebar to work on multiple tasks in parallel. For Git repositories, each session gets its own isolated copy of your project using worktrees, so changes in one session don’t affect another until you commit them. Worktrees are stored in~/.claude-worktrees/by default.
Docs

And that’s why worktrees are hitting the spotlight lately because AI-powered tools (like Conductor) and AI coding assistants: increasingly rely on running parallel workflows. And worktrees are the unsung hero that make those workflows fast and sane.

What Is Git Worktree, Really?

Imagine this: you could check out multiple branches of the same repo at the same time without cloning, without stashing, and without jumping between contexts.

That’s exactly what Git Worktrees let you do. Technically, worktrees create separate working directories that are all linked back to the same .git repository. You can have one directory on main, another on feature/foo, and another on hotfix/bar, all open at once. Each has its own working set of files, but they share the same Git history and object database — so commits, tags, and branches stay in sync without duplication.

It’s not magic! It’s Git’s native way of handling multiple working copies without wasting space. If you’ve ever cloned the same repo three times just to manage multitasking, consider this your apology from the universe.

This approach also solve the old merging problem when you need to commit fast to the feature branch to jump back to main/master. Just make a worktree from the problematic branch and keep working.

Also, you might now that we can’t have multiple branches for a repo. Well, seems that we can do that. Not sure why you might need it? Next section will tell you more.

How You Can Use It (Beyond “Just Another Git Trick”)

At first glance, worktrees are an efficiency hack for the multitasker. But their real superpower emerges in two increasingly common workflows:

🛠 Parallel Feature Development

Instead of constantly switching context, you can open separate features in separate worktrees. Want to build a UI component in one and debug an urgent bug in another? Done.

Our multiple branches issues from above

🤖 AI-Powered Development

With AI tools that spin up separate agents to run against your codebase (like Conductor does with parallel Claude Codes, each in its own sandboxed copy), worktrees make it possible to do this locally without cloning or spinning up separate VMs. Essentially, each agent gets a dedicated branch + working copy — without you having to manage massive clones.

This paradigm is quickly becoming the backbone of AI-augmented workflows: by avoiding stash chaos and enabling isolated contexts, worktrees let you let the machines do their thing without disrupting your flow.

A Simple Worktree Example: Create & Remove

Here’s the minimal set of commands you actually need. Think of these as your “git worktree starter pack”.

Create a Worktree for a Feature

# Create a new worktree for a feature branch
git worktree add ../feature-awesome -b feature/awesome

What this does:

• Makes a new folder ../feature-awesome

• Creates and checks out feature/awesome there

• Links it back to your central .git repository

  No stashing, no switching — everything stays in your current directory.

When You’re Done: Remove It

git worktree remove ../feature-awesome

Boom — worktree gone. Git cleans up references, and the branch stays in your repo just like any other.

💡If you are keen to working with IDEs: Codex app have an task location picker at the bottom bar and Claude have a “New Session“ which will all too use Worktree as we know now.

Final Thoughts

Git Worktree feels like one of those features that should have existed all along. It solves a real pain point: context switching chaos. And now that AI tools and agent managers are building their workflows on top of it, it’s fast becoming a tooling standard.

If you’re still in the mindset of git stash → git checkout → git stash pop, give Git Worktree a try. Your future self (and your future AI tools) will thank you.

Happy branching 🚀!

References

• Git worktree

• Claude Session Info

• Codex Worktree Info

Two concepts that frequently come up when building polished, animated interfaces are Transitions and Transactions. They sound similar (and they’re both related to motion and state changes) but they serve very different purposes.

Transition

A Transition in SwiftUI defines how a view appears and disappears when it is inserted into or removed from the view hierarchy. It’s about enter and exit animation — the visual effect used when a view changes state and is added or removed.

Transitions don’t control timing or easing. They describe the type of animation that happens. The actual animation timing comes from a surrounding animation context.

Built-in Transitions

SwiftUI provides several built-in transitions:

Text("Hello SwiftUI!")
    .transition(.opacity)

You can also combine transitions:

.transition(.scale.combined(with: .opacity))

Or define asymmetric transitions, where insertion and removal behave differently:

.transition(.asymmetric(
    insertion: .slide,
    removal: .scale
))

Or create a custom Transition relying on AnyTransition class. It’s pretty straightforward. How about blur and scale transition?
Need to make a transition modifier (yeah):

struct BlurAndScaleTransition: ViewModifier {
    let progress: CGFloat

    func body(content: Content) -> some View {
        content
            .scaleEffect(progress)
            .blur(radius: (1 - progress) * 10)
            .opacity(progress)
    }
}

Then wrap in AnyTransition:

extension AnyTransition {
    static var blurAndScale: AnyTransition {
        .modifier(
            active: BlurAndScaleTransition(progress: 0),
            identity: BlurAndScaleTransition(progress: 1)
        )
    }
}

// and use it! A plain example is shown in the next section
.transition(.blurAndScale)

How SwiftUI Applies Transitions

Transitions take effect only when views are inserted into or removed from the view hierarchy. This usually happens inside conditional statements such as if blocks or when modifying collections in List or ForEach.

SwiftUI compares the previous and current view tree, detects insertions and removals, and applies the transition accordingly.

Importantly, a transition alone does not animate. It must be wrapped in an animation context using withAnimation or .animation(_:).

Example: Using a Transition

struct MyView: View {
    @State private var show = false

    var body: some View {
        VStack {
            if show {
                RoundedRectangle(cornerRadius: 20)
                    .fill(.blue)
                    .frame(height: 100)
                    .transition(.move(edge: .top))
            }

            Button("Toggle") {
                withAnimation(.easeInOut) {
                    show.toggle()
                }
            }
        }
    }
}

Here:

• The rectangle is inserted and removed from the hierarchy

• The transition defines the movement

• The animation defines timing and easing

Transaction

A Transaction in SwiftUI represents the context of a state change. It carries information about how SwiftUI should process that change, including animation behavior.

Every time SwiftUI processes a state update, it creates a Transaction and propagates it through the view hierarchy.

A transaction can include:

• The animation associated with the update

• Whether animations are disabled

• Metadata used internally by SwiftUI during rendering

Why Transactions Matter

Transitions define what happens visually. Transactions define how that visual change is executed.

If you use withAnimation, SwiftUI attaches the animation to the transaction. That transaction then flows down to child views unless explicitly modified.

This mechanism explains why animations sometimes affect views you didn’t expect — they are all responding to the same transaction.

Let’s track what the transaction does in our example:

struct SwiftBitsTransactionView: View {
    
    @State private var show = false
    
    var body: some View {
        VStack {
            if show {
                RoundedRectangle(cornerRadius: 20)
                    .fill(.blue)
                    .frame(height: 200)
                    .transition(.move(edge: .top))
                    //Tracking transaction for animation
                    .transaction { thx in
                        print(thx as Any)
                    }
            }
            
            Button("Toggle Rect") {
                withAnimation(.easeInOut) {
                    show.toggle()
                }
            }
        }
    }
}

The console will reveal this:

Transaction(plist: [TransactionPropertyKey<AnimationKey> = Optional(AnyAnimator(SwiftUI.BezierAnimation(duration: 0.35, curve: (extension in SwiftUI):SwiftUI.UnitCurve.CubicSolver(ax: 0.52, bx: -0.78, cx: 1.26, ay: -2.0, by: 3.0, cy: 0.0))))])

And if we change it to Linear:

Transaction(plist: [TransactionPropertyKey<AnimationKey> = Optional(AnyAnimator(SwiftUI.BezierAnimation(duration: 0.35, curve: (extension in SwiftUI):SwiftUI.UnitCurve.CubicSolver(ax: -2.0, bx: 3.0, cx: 0.0, ay: -2.0, by: 3.0, cy: 0.0))))])

It really matches the result on screen. Nice!

Modifying Transactions

SwiftUI provides the .transaction(_:) modifier:

Text("No animation")
    .transaction { thx in
        thx.animation = nil
    }

this removes animation for that view and all of its children, even if the state change was wrapped in withAnimation.

Or, it can be used to override the original animation behavior:

struct SwiftBitsTransactionView: View {
    
    @State private var show = false
    
    var body: some View {
        VStack {
            if show {
                RoundedRectangle(cornerRadius: 20)
                    .fill(.blue)
                    .frame(height: 200)
                    .transition(.move(edge: .top))
                    .transaction { thx in
                        thx.animation = thx
                            .animation?
                            .delay(2.0)
                            .speed(2)
                    }
            }
            
            Button("Toggle Rect") {
                withAnimation(.linear) {
                    show.toggle()
                }
            }
        }
    }
}

Important Transaction Properties

• animation: The animation applied to this update, if any

• disablesAnimations: A Boolean that disables animations for this subtree

• addAnimationCompletion: Completion closure to run when the animations created with this transaction are all complete

Transactions allow very fine-grained control over animation behavior and are especially useful in complex view hierarchies.

Transition vs Transaction: Key Differences

Conceptual Difference

• Transitions answer: “How should this view appear or disappear?”

• Transactions answer: “How should this state change be animated?”

Transitions are declarative and visual. Transactions are contextual and behavioral.

When to Use Which

Use Transitions When:

• A view is conditionally shown or hidden

• A view is inserted or removed from a collection

• You want a clear visual effect for appearance or disappearance

Examples include modals, banners, expanding panels, or list rows.

Use Transactions When:

• You need to override or suppress animations

• You want different animation behavior in specific subtrees

• You need programmatic control over animation propagation

• Default animation behavior is too broad or unpredictable

Transactions are more advanced and typically used when standard .animation and .transition modifiers are not enough.

Happy coding!