On iOS 26, we have a new SwiftUI modifier, lineHeight(_:), for adjusting the distance between the baselines of two subsequent lines of text. This modifier accepts a new AttributedString attribute, AttributedString.LineHeight, which can also be used separately for styling attributed strings.

There are a few options available in this new API, so I thought I would look through how they behave in practice.

# LineHeight type properties

The most direct way to adjust a line height is by using one of the built-in static properties on the AttributedString.LineHeight, such as loose or tight, for example. These presets allow for quick adjustments without the need for precise manual control.

The loose line height increases the vertical distance between lines, resulting in a more open layout for paragraph text.

Text(loremIpsum)
    .lineHeight(.loose)

Below is a comparison showing the default line height on the left versus the loose configuration on the right.

Conversely, the tight preset reduces the baseline distance, creating a more compact vertical layout.

Text(loremIpsum)
    .lineHeight(.tight)

The left screen shows the default height, while the right screen demonstrates the increased density of the tight configuration.

The other two options, normal and variable, don't appear significantly different from the default line height in my experimentation. Documentation defines normal as a constant line height based on a multiple of the point size perceived as normal, whereas variable uses a height based specifically on font metrics.

If no line height is specified, SwiftUI will automatically select the appropriate one based on the context.

# LineHeight type methods

To get more precise control over the text layout, we can use the static methods provided by AttributedString.LineHeight instead of just the static presets. These allow us to define the baseline distance using specific numerical values.

The multiple(factor:) method sets a constant line height based on a multiple of the font's point size. For example, we can set the line height to double the font's point size, to give the paragraph a very spaced-out feel.

Text(loremIpsum)
    .lineHeight(.multiple(factor: 2))

When the font size increases with Dynamic Type, the line height scales along with it, maintaining the same proportional spacing.

We also have leading(increase:), which keeps the line height relative to the point size and adds a fixed numerical increase.

Text(loremIpsum)
    .lineHeight(.leading(increase: 30))

Since this method is still relative to the point size, the line height will continue to grow as the font size increases with Dynamic Type, but the point increase will remain constant.

For absolute control, we can use exact(points:). This sets a constant line height based on a fixed total value in points, completely bypassing any relative calculations based on the font size.

Text(loremIpsum)
    .lineHeight(.exact(points: 30))

We should be careful when setting an exact line height value, though, as it won't adjust with Dynamic Type and can result in unreadable text. Since the baseline distance remains fixed, the lines may eventually overlap or even become cut off if a user increases their system font size.

lineHeight(_:) vs lineSpacing(_:)

While the lineHeight(_:) modifier is new in iOS 26, the lineSpacing(_:) modifier has been available for a while. The difference between the two is that lineHeight(_:) defines the distance between the baselines of two subsequent lines of text, whereas lineSpacing(_:) sets the amount of spacing from the bottom of one line to the top of the next.

Because lineHeight(_:) comes with a variety of configurations and presets, it seems more versatile for modern layouts. I think I'll be using it more often than line spacing in my apps, though it always depends on the specific requirements of the project.

leading(_:) font modifier

SwiftUI also provides the leading(_:) font modifier that can be applied directly to an instance of a Font to adjust its line spacing.

Text(loremIpsum)
    .font(.title.leading(.loose))

The leading(_:) font modifier has been available since iOS 14. It takes Font.Leading parameter which is an enum with only three cases standard, loose, and tight.

Applying line spacing adjustments using this modifier results in a very subtle change, which may be good in some layouts, but is quite limiting in most cases.

I covered SwiftUI font modifiers in more detail in a separate article a while back - Font modifiers in SwiftUI.

It's encouraging to see the continued evolution of text APIs in SwiftUI, and having new options like lineHeight(_:) with its various configurations is a welcome improvement for fine-tuning typography. I think it would also be great to see more detailed documentation on text APIs in general, though, to make it easier for developers to understand how new additions fit into the broader text system on Apple platforms.

If you are looking to build a strong foundation in SwiftUI, my book SwiftUI Fundamentals takes a deep dive into the framework's core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

To apply animations in SwiftUI, we most commonly use either the withAnimation(_:_:) global function or the animation(value:) view modifier. These approaches work well in many cases. However, there are situations where we need more precise control over which attributes participate in the animation. This becomes especially important in reusable components that accept arbitrary child content, where unintended animations can easily occur.

First, let’s look at an example with an accidental animation.

Imagine, that we have a generic PremiumContentCard component that adjusts the opacity of its content based on availability. When premium content is enabled, the view is fully opaque. Otherwise, it becomes slightly transparent to reduce its visual prominence. To animate this change, we might reach for the familiar animation(_:value:) modifier.

struct PremiumContentCard<Content: View>: View {
    let isEnabled: Bool
    @ViewBuilder var content: Content
    
    var body: some View {
        content
            .padding()
            .background(.indigo.gradient)
            .opacity(isEnabled ? 1 : 0.4)
            .animation(.default, value: isEnabled)
    }
}

However, since our component accepts arbitrary content, we cannot guarantee that only the opacity change will be animated. For example, the content passed into PremiumContentCard may also depend on the same availability state and update its text accordingly.

PremiumContentCard(isEnabled: premiumContentEnabled) {
    VStack(alignment: .leading) {
        Text("Upper Body Workout")
            .font(.headline)
        Text("45 minutes • Intermediate")
            .font(.subheadline)
        
        if premiumContentEnabled {
            Text("Push ups, pull ups, dumbbell press, shoulder raises.")
        } else {
            Text("Upgrade to access the full workout plan.")
        }
    }
}

In that case, the text change will also be animated.

This may or may not be desirable. However, when designing generic container components, it's often better to be explicit about which attributes participate in the animation to avoid unexpected visual glitches. We can achieve this using the newer animation(_:body:) API introduced in iOS 17.

The animation(_:body:) modifier takes an Animation and a ViewBuilder closure. The closure receives a proxy of the modified view, allowing us to specify attributes that should participate in the animation. Anything outside that closure remains unaffected. So we can rewrite PremiumContentCard and apply the opacity modifier inside an isolated animation context.

struct PremiumContentCard<Content: View>: View {
    let isEnabled: Bool
    @ViewBuilder var content: Content
    
    var body: some View {
        content
            .padding()
            .background(.indigo.gradient)
            .clipShape(RoundedRectangle(cornerRadius: 20))
            .animation(.default) {
                $0.opacity(isEnabled ? 1 : 0.3)
            }
    }
}

Now we can guarantee that only the opacity change is animated, independent of any other changes within the content passed into our component.

By isolating the animation to specific modifiers, we can make the intent of our components explicit and keep generic container views more predictable.

If you are looking to build a strong foundation in SwiftUI, my book SwiftUI Fundamentals is a great place to start. It takes a deep dive into the framework's core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

Swift’s string interpolation system is more powerful than it first appears. Beyond simple value substitution, it can be customized to perform additional logic directly inside string literals.

Custom interpolation can be implemented by extending String.StringInterpolation. This allows us to define custom interpolation behavior tailored to specific types or formatting requirements.

The example below adds support for inline formatting using the FormatStyle protocol.

import Foundation

extension String.StringInterpolation {
    mutating func appendInterpolation<F: FormatStyle>(
        _ value: F.FormatInput,
        format: F
    ) where F.FormatInput: Equatable, F.FormatOutput == String {
        appendLiteral(format.format(value))
    }
}

With this extension in place, a Date can be formatted directly within a string literal.

let today = Date()

let formattedString = """
Today's date is \(today, format: .dateTime.year().month().day())
"""

// Today's date is 13 Jan 2026
print(formattedString)

Here, the interpolation extension applies the provided format style and inserts the formatted result into the string. This makes the formatting more expressive, avoids repetition, and keeps the interpolation logic close to where it's used.

Custom string interpolation is not limited to formatting. It can be used to validate values, apply conditional logic, or control how domain specific values are rendered. This lets us encode that behavior once and reuse it across string literals.

SF Symbols are a natural choice for icons in SwiftUI apps. The system provides a very large symbol catalog, and extensive customization options. Size, weight, rendering mode, and color can all be adjusted to match the surrounding UI, making symbols easy to integrate across an app.

Beyond static icons, SF Symbols also support animation. These animations are called symbol effects. They allow icons to respond to state changes and interactions, bringing more life to the interface without custom drawing or complex animation code.

Symbol effects are provided by the Symbols framework, which is implicitly available when working with SwiftUI. There is a built-in collection of effects that can be applied to any symbol, including custom symbols. Effects are configurable, and options can be chained to create very specific behavior. The SF Symbols app documents each effect and its supported options.

In this post, we'll explore the SwiftUI APIs for animating SF Symbols and use the groupings based on protocol conformance in the Symbols framework as a mental model. We'll look at four effect groups: indefinite effects (IndefiniteSymbolEffect), discrete effects (DiscreteSymbolEffect), content transitions (ContentTransitionSymbolEffect), and transitions (TransitionSymbolEffect). Each group represents a distinct animation intent and naturally aligns with the SwiftUI API patterns used to apply these animations.

# Indefinite symbol effects

Indefinite symbol effects apply a modification that remains in place for as long as the effect is active. This category includes the largest set of effects, such as ScaleSymbolEffect, RotateSymbolEffect, BreatheSymbolEffect, and many others. The full list of animations that conform to the IndefiniteSymbolEffect protocol can be found in the Apple documentation.

Indefinite effects can be configured using the symbolEffect(_:options:isActive:) modifier, where the isActive parameter is used to turn the effect on or off.

Such effects can help provide feedback for a continuous user interaction, like an active hover, for example. Here is how we can scale symbols up when the mouse is over them.

struct HoverScalingSymbol: View {
    let systemName: String
    
    @State private var isHovering = false
    
    var body: some View {
        Image(systemName: systemName)
            .symbolEffect(.scale.up, isActive: isHovering)
            .onHover { hovering in
                isHovering = hovering
            }
    }
}

Some animations in the indefinite effects group, such as breathe, bounce, pulse, and rotate, repeat forever while active. These are great for indicating an ongoing activity or process.

Image(systemName: "record")
    .symbolVariant(.circle)
    .symbolEffect(.breathe, isActive: isRecording)

If we omit the isActive parameter for such effects, it will default to true and the animation will be active forever.

Indefinite effects really shine with configuration options that control how the animation progresses and repeats over time. By chaining these options, we can arrive at a variant that best suits our use case. Here is an example of how the variable color animation can be customized:

Image(systemName: "waveform")
    .symbolEffect(.variableColor.iterative.reversing)

# Discrete symbol effects

Discrete symbol effects perform a transient, one-off animation that is triggered by a change in a specific value. These effects are great for drawing attention to an element in the UI or indicating that an action has taken place.

A few animation types that support indefinite behavior also support discrete behavior. The full list can be found in the conforming types of the DiscreteSymbolEffect protocol.

To add a discrete animation to a symbol in a SwiftUI app, we can use the symbolEffect(_:options:value:) modifier. Here is how we can trigger a one-off bounce effect every time a value is incremented:

struct BasketView: View {
    @State private var numOfItems = 0
    
    var body: some View {
        VStack(spacing: 30) {
            Image(systemName: "basket")
                .symbolEffect(.bounce, value: numOfItems)
            
            Button("Add to basket") {
                numOfItems += 1
            }
        }
    }
}

To customize how the effect is performed, how fast and how many times, we can also provide the options parameter. For example, we might want to bounce the symbol twice very quickly.

Image(systemName: "basket")
    .symbolEffect(
        .bounce,
        options: .repeat(2).speed(2),
        value: numOfItems
    )

# Symbol effect content transitions

When we want to switch between symbol variants or distinct symbols, we can take advantage of built-in symbol animations with the symbol effect content transitions.

When a symbolEffect content transition is applied without any configuration options, the system will choose the most appropriate transition for the context.

In the example below, the slash will be drawn on and off as we toggle the setting.

struct NotificationButton: View {
    @State private var notificationsEnabled = true
    
    var body: some View {
        Button {
            notificationsEnabled.toggle()
        } label: {
            Image(systemName: "bell")
        }
        .buttonStyle(.borderless)
        .symbolVariant(notificationsEnabled ? .none : .slash)
        .contentTransition(.symbolEffect)
    }
}

When switching between unrelated symbols the system will do its best to interpolate between the two.

struct WeatherSymbol: View {
    @State private var isSunny = true
    
    var body: some View {
        Image(systemName: isSunny ? "sun.max" : "cloud")
            .contentTransition(.symbolEffect)
            .onTapGesture {
                isSunny.toggle()
            }
    }
}

We can still customize the transition with parameters passed to the symbolEffect(_:options:) function, for example .contentTransition(.symbolEffect(.replace.upUp)), but I've found that the defaults work best for many cases.

# Symbol effect transitions

When adding a symbol to the hierarchy, or removing it, we can provide a symbol effect transition using the transition(_:) modifier.

if isSnowing {
    Image(systemName: "snowflake")
        .transition(.symbolEffect)
}

Note, that unlike other types of transitions, the symbolEffect transition will be activated even if we don't apply an implicit animation to the view hierarchy with the animation(_:value:) modifier or wrap the state modification into a withAnimation {} function.

Instead of relying on the default behavior of the symbol effect transition, we can provide an explicit effect type to achieve a more interesting animation. For example, on iOS and macOS 26, we can set the drawOn as a preference and it will be activated for symbols that support this new animation type.

if isWindy {
    Image(systemName: "wind")
        .transition(.symbolEffect(.drawOn))
}

SF Symbols are very flexible, and they continue to be updated every year with new behaviors and customization options. Symbol effect animations were introduced in iOS 17, and have significantly evolved since then. It's great to see how easy it is to use these animations in our SwiftUI apps and adapt them to different interaction patterns and use cases.

If you are looking to build a strong foundation in SwiftUI, my book SwiftUI Fundamentals is a great place to start. It takes a deep dive into the framework's core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

SwiftUI offers a great variety of APIs to define and customize image views with SF Symbols to create beautiful icons with minimal effort. One of the lesser known techniques is the ability to apply a foreground style with an inner shadow to create an icon that looks like it's cut out of its background.

Image(systemName: "cloud.rain")
    .symbolVariant(.circle)
    .foregroundStyle(
        .indigo
            .shadow(.inner(radius: 2))
    )

We can set different shadow radii and colors to make the effect stronger or more subtle. This works especially well with circular or rounded symbol variants when we want icons that feel slightly inset into the surface instead of sitting on top of it.

I've noticed that many iOS developers, even those who have been working with SwiftUI for a while, still have questions about how @Observable classes work with SwiftUI views, how they should be initialized, and whether we need to store our observable models in @State. In this post, we'll look at some examples of managing observable state in SwiftUI, explore the recommended approaches, and see what can go wrong if our observable classes are not stored correctly.

# Storing @Observable models in @State

When we initialize an @Observable class in a SwiftUI view and read its properties, SwiftUI will automatically refresh any views that depend on those properties when they change. This happens even if we simply assign the observable class to a stored property in the view struct. Because of this, it may not be immediately obvious why we need to bother with storing the model in @State.

In the following example, the text view will update as we increment the count property of DataModel.

@Observable
class DataModel {
    var count = 0
}

struct ContentView: View {
    private let dataModel: DataModel = DataModel()
    
    var body: some View {
        VStack(spacing: 30) {
            Text("Count: \(dataModel.count)")
                .font(.title)
            
            Button("Increment") {
                dataModel.count += 1
            }
            .font(.title2)
            .buttonStyle(.borderedProminent)
        }
    }
}

However, when an @Observable model is not stored in @State, it's not tied to the SwiftUI view lifecycle. A new instance will be created every time the view struct is initialized. In SwiftUI, view structs are ephemeral and only exist long enough to describe the view hierarchy. The actual views and their state are managed by SwiftUI in an internal data structure, so the lifetime of a view struct is not the same as the lifetime of the on screen view.

We can see the issue with not assigning the observable model to @State in the next example. Here we refactor the counter into a separate CountView and add a ColorPicker to ContentView, which controls the tint color of the app.

struct ContentView: View {
    @State private var tint: Color = Color.accentColor
    
    var body: some View {
        NavigationStack {
            CountView()
                .tint(tint)
                .toolbar {
                    ColorPicker("Tint Color", selection: $tint)
                        .labelsHidden()
                }
        }
    }
}

struct CountView: View {
    private let dataModel = DataModel()
    
    var body: some View {
        VStack(spacing: 30) {
            Text("Count: \(dataModel.count)")
                .font(.title)
            
            Button("Increment") {
                dataModel.count += 1
            }
            .font(.title2)
            .buttonStyle(.borderedProminent)
        }
    }
}

Every time the tint color changes, ContentView's body is rebuilt, the CountView initializer runs again, and DataModel is recreated, losing its previous state.

Simply changing the dataModel property in CountView from a stored let on the view struct to a variable annotated with @State fixes the issue. The @State annotation tells SwiftUI that this property is tied to the view lifecycle, so SwiftUI manages its storage on our behalf and keeps it alive while the view is present in the hierarchy.

struct CountView: View {
    @State private var dataModel = DataModel()
    
    var body: some View {
        VStack(spacing: 30) {
            Text("Count: \(dataModel.count)")
                .font(.title)
            
            Button("Increment") {
                dataModel.count += 1
            }
            .font(.title2)
            .buttonStyle(.borderedProminent)
        }
    }
}

The state persists even though the view struct itself may be created and discarded many times during that period.

# Deferring Observable model initialization

One caveat to remember when deciding when and where to perform the observable class initialization is that, even though the state will persist across recreations of the view struct, if the model is initialized as the default value of a state property, its initializer will still be called every time the view initializer runs, creating a new temporary instance that SwiftUI discards.

Let's add a print statement inside the DataModel initializer to observe what happens.

@Observable
class DataModel {
    var count = 0
    
    init() {
        print("DataModel initialized")
    }
}

struct ContentView: View {
    @State private var tint: Color = Color.accentColor
    
    var body: some View {
        NavigationStack {
            CountView()
                .tint(tint)
            
            ...
        }
    }
}

struct CountView: View {
    @State private var dataModel = DataModel()
    
    var body: some View {
        VStack(spacing: 30) {
            Text("Count: \(dataModel.count)")
                .font(.title)
            
            ...
        }
    }
}

When the tint color changes, ContentView’s body runs again, the CountView initializer is called, and "DataModel initialized" is printed to the console, even though we can see in the UI that the state of dataModel is preserved. SwiftUI does not overwrite the existing state with a new DataModel instance on each rebuild, but it still evaluates the initializer expression, so the print runs every time.

This aspect is important to keep in mind, because any heavy logic inside the @Observable class initializer may run multiple times and potentially degrade app performance, since SwiftUI relies on view initializers being very cheap.

In cases where our observable class initializer logic is not quick and simple, we can defer creating the model by moving that work into a task modifier.

struct CountView: View {
    @State private var dataModel: DataModel?
    
    var body: some View {
        VStack(spacing: 30) {
            Text("Count: \(dataModel?.count, default: "0")")
                .font(.title)
            
            Button("Increment") {
                dataModel?.count += 1
            }
            .font(.title2)
            .buttonStyle(.borderedProminent)
        }
        .task {
            dataModel = DataModel()
        }
    }
}

In this setup, the DataModel initializer will run only once, when CountView is added to the hierarchy.

Deferring observable model creation would also let us configure it based on a value passed into the view. But it's important to use the task() modifier with the id parameter, so that the task runs again when that value changes.

@Observable
class DataModel {
    var text: String
    
    init(id: UUID) {
        text = "ID: \(id)"
        print("DataModel initialized for id: \(id)")
    }
}

struct ContentView: View {
    @State private var id = UUID()
    
    var body: some View {
        NavigationStack {
            IDView(id: id)
                .toolbar {
                    Button(
                        "Reset ID",
                        systemImage: "arrow.trianglehead.2.clockwise"
                    ) {
                        id = UUID()
                    }
                }
        }
    }
}

struct IDView: View {
    let id: UUID
    @State private var dataModel: DataModel?
    
    var body: some View {
        Text(dataModel?.text ?? "")
            .task(id: id) {
                dataModel = DataModel(id: id)
            }
    }
}

In a real-world app, this pattern can be useful when we need to load different data based on the current selection or other changing state.

# Initializing observable state in the App struct

It's important to remember that state initialized in views inside a WindowGroup scene is scoped to that scene. On devices that support multiple scenes, such as iPad or Mac, each window gets its own fresh copy of that state. If we want shared state across all scenes, we can initialize our observable model in the App struct and then pass it down through the environment.

@Observable
class DataModel {
    var count = 0
}

@main
struct ObservableExampleApp: App {
    @State private var dataModel = DataModel()
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(dataModel)
        }
    }
}

struct ContentView: View {
    var body: some View {
        CountView()
    }
}

struct CountView: View {
    @Environment(DataModel.self)
    private var dataModel
    
    var body: some View {
        VStack(spacing: 30) {
            Text("Count: \(dataModel.count)")
                .font(.title)
            
            Button("Increment") {
                dataModel.count += 1
            }
            .font(.title2)
            .buttonStyle(.borderedProminent)
        }
    }
}

This way, each scene will read and write to the same shared state. This is a good choice for application wide data, but not for state that should be scene specific, such as selection or navigation.

Even though the App struct initializer should only run once per application lifecycle, it's best to still annotate the observable model with @State or, at least make it a singleton with a static declaration, to be 100% certain that it will not get reset in any unexpected scenario.

If we want to defer the initialization of the application wide state, we cannot simply assign it in a task() modifier like we did for view state. A task attached to the root view will run once per scene, not once per app launch. To ensure the state is initialized only once, we would need an additional flag or some other guard around the initialization.

To learn more about @Observable in SwiftUI, including when to annotate it with @Bindable and how it differs from ObservableObject, you can read my other post: Using @Observable in SwiftUI views.

If you are looking to build a strong foundation in SwiftUI, my book SwiftUI Fundamentals is a great place to start. It takes a deep dive into the framework's core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

UIKit continues to evolve with modern patterns and better SwiftUI interoperability. This year it adds native support for Swift Observation. When we read properties of an @Observable class in update methods, UIKit records those reads and wires up the dependencies so it can invalidate and update the right views without extra manual logic on our behalf.

This automatic observation tracking is enabled by default on iOS 26, but it can also be backported to iOS 18. In this post we'll look at how automatic observation tracking works in practice on iOS 26 and iOS 18, and how it makes it easy to share data between UIKit and integrated SwiftUI components.

The example we'll use is a very basic UIKit app that shows an image and a title, and includes a settings view, the contents of which are built with SwiftUI. The SwiftUI settings view is presented in a half-sheet, and we need to make sure that as the user switches the selection in the SwiftUI view, the UIKit view below refreshes to reflect the new state.

Here are the relevant code parts, with the UIKit update logic omitted for now:

@Observable
class SelectionState {
    var image: ImageName = .lake
    
    enum ImageName: String, CaseIterable {
        ...
    }
}

class ViewController: UIViewController {
    private let selectionState = SelectionState()
    
    private var imageView: UIImageView!
    private var imageLabel: UILabel!

    ...
    
    @objc private func showHalfSheet() {
        let settingsView = SettingsView(selectionState: selectionState)
        let settingsController = UIHostingController(rootView: settingsView)
        
        ...
        
        present(settingsController, animated: true, completion: nil)
    }
}

struct SettingsView: View {
    let selectionState: SelectionState
    
    var body: some View {
        NavigationStack {
            List(
                SelectionState.ImageName.allCases, id: \.self
            ) { image in
                Button {
                    selectionState.image = image
                } label: {
                    ...
                }
            }
        }
    }
}

# Automatic observation tracking on iOS 26

On iOS 26, we can use the new updateProperties() method to write new values to the image and label views. This method runs just before viewWillLayoutSubviews(), but is independent and is now the recommended place for populating content, applying styling, or configuring behaviors.

class ViewController: UIViewController {
    private let selectionState = SelectionState()
    
    private var imageView: UIImageView!
    private var imageLabel: UILabel!
    
    ...
    
    override func updateProperties() {
        super.updateProperties()

        imageView.image = UIImage(named: selectionState.image.rawValue)
        imageLabel.text = selectionState.image.rawValue.capitalized
    }
}

UIKit automatically tracks any @Observable we read inside updateProperties(), so we don't need to add any extra logic, like we had to do previously by calling withObservationTracking() when using the Observation framework outside of SwiftUI. The UIKit view will automatically refresh as soon as SwiftUI sets a new image value on the shared SelectionState.

# Automatic observation tracking on iOS 18

If we want the same automatic update behavior on iOS 18, we first need to add the UIObservationTrackingEnabled key to Info.plist and set its value to YES.

We also have to move the code that updates the image and label into viewWillLayoutSubviews(), since the new updateProperties() method is only available starting with iOS 26.

class ViewController: UIViewController {
    private let selectionState = SelectionState()
    
    private var imageView: UIImageView!
    private var imageLabel: UILabel!
    
    ...
    
    override func viewWillLayoutSubviews() {
        super.viewWillLayoutSubviews()
        
        imageView.image = UIImage(named: selectionState.image.rawValue)
        imageLabel.text = selectionState.image.rawValue.capitalized
    }
}

The viewWillLayoutSubviews() method supports observation tracking as well. When the feature is enabled, UIKit automatically establishes dependencies on any @Observable class properties read inside it and triggers the necessary updates, just like with updateProperties() on iOS 26.

Automatic observation tracking is a welcome addition to UIKit and brings a more consistent approach to state driven updates in projects that mix UIKit and SwiftUI.

If you are looking for more detailed guidance on using SwiftUI in existing UIKit projects, take a look at my book Integrating SwiftUI into UIKIt apps, which has been recently updated for iOS 26 and Xcode 26. For more resources on Swift and SwiftUI, check out my other books and book bundles.

By default, a ScrollView in SwiftUI uses the system's standard deceleration rate and the scrolling velocity to determine where the scroll motion should stop. While this behavior works well in most situations, it doesn't consider the dimensions of the scroll view or its content.

In some interfaces, it can be useful to customize the scroll behavior and make the scroll view snap precisely to a page or a specific view.

I've been exploring the APIs that SwiftUI provides to customize scroll snapping, and in this post I'll share what I've learned and what to keep in mind to avoid unexpected results.

# Paging scroll behavior

When the content of each scroll view item fills the full height of the screen in a vertical scroll, or the full width of the screen in a horizontal scroll, it often makes sense to enable paging so that scrolling snaps in page-sized increments based on the visible region rather than stopping at arbitrary positions.

Let's look at a simple example with a horizontal gallery of cat images where each image matches the container visible width.

ScrollView(.horizontal) {
    LazyHStack {
        ForEach(catPhotos, id: \.self) { photo in
            Image(photo)
                .resizable()
                .scaledToFit()
                .containerRelativeFrame(.horizontal)
        }
    }
}
.scrollIndicators(.hidden)

As the user scrolls through the images, the final offset is determined by velocity and deceleration, so it can settle between pages and leave an image partially visible.

To customize where scroll gestures should end, SwiftUI provides the scrollTargetBehavior(_:) modifier. We can apply it to the ScrollView in our code, and pass it the paging value. This value tells SwiftUI to adjust the deceleration and target calculation so the final resting position aligns with the visible container size.

ScrollView(.horizontal) {
    LazyHStack(spacing: 0) {
        ForEach(catPhotos, id: \.self) { photo in
            Image(photo)
                .resizable()
                .scaledToFit()
                .containerRelativeFrame(.horizontal)
        }
    }
}
.scrollIndicators(.hidden)
.scrollTargetBehavior(.paging)

Note that for it to work correctly with our horizontal scroll example, we also need to set the LazyHStack spacing to zero. Without it, the default spacing assigned by SwiftUI will interfere with the scroll offset calculations and the result won't be correct.

With this setup, the scroll gesture will flip through each image, always settling on one image per page that takes up the full width of the screen.

While this works well in the vertical orientation, in the horizontal one the safe area insets seem to affect the offset preventing correct alignment. If the layout allows it, as in our image gallery example, we can ignore the horizontal safe area insets so that paging works as expected.

ScrollView(.horizontal) {
    ...
}
.scrollIndicators(.hidden)
.scrollTargetBehavior(.paging)
.ignoresSafeArea(.container, edges: .horizontal)

# View aligned scroll behavior

# View-aligned snapping with full-width content

In addition to the paging scroll behavior, where the scroll snaps to the container’s visible region, SwiftUI also provides a viewAligned option that makes the scroll snap to individual views instead. When using this behavior, we also need to mark the scrollable content with the scrollTargetLayout(isEnabled:) modifier so SwiftUI knows which views should act as snap targets.

We can apply the view aligned scroll snapping to our image gallery by using the scrollTargetBehavior() modifier with the viewAligned value and marking the LazyHStack with scrollTargetLayout().

ScrollView(.horizontal) {
    LazyHStack {
        ForEach(catPhotos, id: \.self) { photo in
            Image(photo)
                .resizable()
                .scaledToFit()
                .containerRelativeFrame(.horizontal)
        }
    }
    .scrollTargetLayout()
}
.scrollIndicators(.hidden)
.scrollTargetBehavior(.viewAligned)

Since each image still takes up the full width of the container, this approach produces the same paging-like behavior as the paging option we used earlier, but it works without setting the LazyHStack spacing to zero.

Another benefit is that it also behaves correctly when the horizontal safe area insets are preserved, allowing it to work as expected in horizontal phone orientation without any additional adjustments.

# View-aligned snapping with multiple items visible

The view aligned scrolling behavior is particularly useful in horizontal galleries that display several items at once, with one partially visible to hint at more content beyond the edge. When view aligned snapping is not enabled, scrolling through such a layout can require precise aiming from the user, while the view aligned behavior makes scrolling feel guided and intentional, snapping cleanly to the nearest item.

ScrollView(.horizontal) {
    LazyHStack {
        ForEach(catPhotos, id: \.self) { photo in
            Image(photo)
                .resizable()
                .scaledToFit()
                .containerRelativeFrame(
                    .horizontal, count: 5,
                    span: 2, spacing: 0
                )
        }
    }
    .scrollTargetLayout()
}
.scrollIndicators(.hidden)
.scrollTargetBehavior(.viewAligned)

# View-aligned snapping and oversized items

One important consideration to keep in mind when applying the view aligned scroll behavior, is that each scroll target should fit within the visible region of the scroll view. If an item's width in a horizontal scroll or height in a vertical one exceeds the container's size, scrolling can feel broken. The oversized item will interfere with the snapping logic and make it difficult to continue scrolling once reached.

Let's say we wanted to modify our horizontal gallery by changing the containerRelativeFrame() axis from horizontal to vertical, so that each photo takes the same height while growing in width as its aspect ratio requires.

ScrollView(.horizontal) {
    LazyHStack {
        ForEach(catPhotos, id: \.self) { photo in
            Image(photo)
                .resizable()
                .scaledToFit()
                .containerRelativeFrame(
                    .vertical, count: 5,
                    span: 2, spacing: 0
                )
        }
    }
    .scrollTargetLayout()
}
.scrollIndicators(.hidden)
.scrollTargetBehavior(.viewAligned)

In this case, some cat photos can become too wide, wider than the phone screen. When such a wide photo is reached, the scrolling will feel stuck.

In layouts with large items that extend beyond the visible bounds and require custom snapping, it can make sense to define a custom ScrollTargetBehavior, which provides finer control over how the content should scroll, for example by snapping at fixed distances or to specific offsets.

These are just a few ways to customize scrolling in SwiftUI, and there's still plenty more to explore. Since iOS 17, SwiftUI has gained a much richer scrolling system, not just for snapping, but also for defining scroll targets, margins, and positions, giving us finer control over how content moves, aligns, and interacts with its container.

If you are looking to build a strong foundation in SwiftUI, my book SwiftUI Fundamentals is a great place to start. It takes a deep dive into the framework's core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

In iOS 26, SwiftUI introduces a new close button role designed for buttons that dismiss informational views or modals, for example, sheets showing read-only content or contextual details.

Unlike the existing cancel role, which indicates discarding edits or abandoning progress, the close role doesn't imply data loss. It doesn't perform any automatic dismissal by itself but provides internal semantics that help SwiftUI and the system understand the intent of the button, such as for accessibility and platform-consistent presentation.

Here's how we might use it in a modal sheet:

struct BirdDescriptionSheet: View {
    @Environment(\.dismiss) private var dismiss

    var body: some View {
        NavigationStack {
            BirdDescription()
                .toolbar {
                    Button(role: .close) {
                        dismiss()
                    }
                }
        }
    }
}

This adds a system-standard close button with an xmark symbol without the need to define a custom label or icon.

It's a small but useful addition for aligning SwiftUI modals with platform conventions.

I'm happy to share that I've updated SwiftUI Fundamentals for iOS 26, bringing refreshed visuals and refinements throughout the book. This new edition aligns with the Liquid Glass design introduced across Apple platforms, giving every example and screenshot an updated look that matches the latest system appearance.

While the visual style has evolved, the fundamental workings of the framework remain the same. The core principles of view composition, state flow, and layout behavior continue to define how SwiftUI operates. This update focuses on clarity and accuracy rather than new concepts, keeping the material fully relevant for developers building with SwiftUI in 2025.

I've verified all examples against the current SwiftUI APIs and refined explanations where needed to reflect minor behavioral changes on iOS 26.

If you already own the book, you can download the updated edition here: Download the October 2025 Edition.

If you haven't checked out the book yet and want to deepen your understanding of SwiftUI, this is a great place to start. I wrote "SwiftUI Fundamentals" to help developers build a clear mental model of how SwiftUI works, from layout and state flow to the principles that guide its design, drawing on my experience contributing to the framework at Apple.

You can learn more or get your copy here: SwiftUI Fundamentals.

When declaring a simple button in SwiftUI, we usually provide a title and an image name, and rely on SwiftUI to adapt its display based on the context the button is used in. This adaptable behavior has changed for buttons in swipe actions on iOS 26.

Previously, a button with a title and a symbol would only display the symbol when placed inside a swipe action.

RecipeRow(recipe: recipe)
    .swipeActions {
        Button(
            "Delete", systemImage: "trash",
            role: .destructive
        ) {
            delete(recipe: recipe)
        }
    }

On iOS 26, however, the same button includes both the title and the symbol either stacked vertically, if the row height allows it, or placed side by side.

This new behavior can be useful for actions that don't have obvious icons to depict them, but it may be overkill for something simple like "Delete", where the trash icon by itself is clear enough.

To return to the previous button look in swipe actions and show only the icons, we can apply the labelStyle() modifier to the button and pass in the iconOnly option.

RecipeRow(recipe: recipe)
    .swipeActions {
        Button(
            "Delete", systemImage: "trash",
            role: .destructive
        ) {
            delete(recipe: recipe)
        }
        .labelStyle(.iconOnly)
    }

This works because a SwiftUI button constructed with a title and an image uses a label under the hood, so setting an explicit label style in the environment makes it adjust its appearance based on the provided style, rather than follow an automatic behavior that comes from SwiftUI's internal logic.

If you are looking to build a strong foundation in SwiftUI, make sure to check out my book: SwiftUI Fundamentals. It takes a deep dive into the framework's core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, take a look at my other books and book bundles.

When testing Breve with Dynamic Type, I noticed that in some layouts, text would get truncated at larger text sizes instead of wrapping onto the next line, even when there is no line limit and no vertical size constraint on the element. Text truncation can still occur even when the UI element containing the text is inside a scroll view and can grow infinitely.

I had run into similar truncation issues before, but they seem to have become more frequent in iOS 26.

To ensure that text doesn't truncate, I had to apply the fixedSize(horizontal:vertical:) modifier to the text view, passing false for the horizontal parameter and true for the vertical one. This tells the text to respect horizontal size constraints so it wraps normally, while at the same time forcing it to ignore vertical constraints and expand as needed.

Text(drink.description)
    .fixedSize(
        horizontal: false,
        vertical: true
    )

When using this workaround, make sure the layout can grow vertically as much as required, even at the largest accessibility sizes, so the text doesn't get cut off.

I'm really excited to finally introduce my new app, Breve: Barista Recipes, released just a few days ago. Breve is available on iPhone and iPad and comes with a large collections of coffee recipes and guides that adapt to whatever equipment users have on hand, from espresso machines, to simple hands-on tools.

Breve is built for iOS 26 and combines the new Liquid Glass design with soft colorful background gradients and watercolor-style artworks. If you want to check it out, you can find it on the App Store. If you feel like leaving a rating or review, it would mean a lot and help more people come across it.

I've been working on Breve for the last few months, and it gave me a great platform to experiment with the new iOS 26 APIs, and system integrations. While I kept the app itself secret until the launch date, I've been documenting many of my technical learnings on the blog. Now that Breve is out, I'd like to revisit those key learnings and share insights that may be useful for others working on their iOS 26 projects too.

# Background extension effect

One of the interesting design solutions in Breve is the recipe detail header with the watercolor illustration blending into the background. I achieved this look using a combination of background extension effects, blurs and gradient overlays.

The new backgroundExtensionEffect() modifier in iOS 26 lets us extend and blur visual content beyond a view's bounds, creating continuous backgrounds behind elements like sidebars, inspectors, and overlay controls. But we can also use it more creatively, for example, by extending and blurring an image into the surrounding safe area.

If you want to learn more about the new backgroundExtensionEffect() modifier in SwiftUI and see some examples of how it can be used, take a look at my post: Create immersive backgrounds in SwiftUI with backgroundExtensionEffect().

# Stretchy header

It's a common design pattern in modern iOS apps to have a large image at the top of a scroll view, extending all the way into the top safe area, like I have in the recipe view in Breve. To avoid revealing empty space above the image, when the user pulls down to overscroll, I added a stretchy header effect.

There are a few ways to achieve this effect in SwiftUI and I most commonly see developers using onScrollGeometryChange() where they get the scroll offset, write it to a shared app state, and then use it to compute the frame of the image. But we can also do it in a slightly simpler way using the visualEffect() API.

If you'd like to add something similar in your apps, feel free to use my strechy() modifier built with the visualEffect(). You can get the code for it from my post: Stretchy header in SwiftUI with visualEffect().

# Search functionality

For the search functionality in Breve I decided to use a separate tab. This pattern appears in many Apple apps such as Health, Music, and Books and works nicely with the Liquid Glass tab view in iOS 26. To adopt this pattern in SwiftUI, we need to create a Tab with the search role and apply the searchable() modifier to the TabView. You can see the example code for it, and other search placements in iOS 26 in my article: SwiftUI Search Enhancements in iOS and iPadOS 26.

On iPhone the search tab appears visually separated from the others and transforms into a glassy search field when selected.

On iPad, the search field is placed in the navigation bar by default, and it works well with a sidebar adaptable tab view.

Breve is a very content-rich app, so making sure users can quickly find what they are looking for is important. To make the content searchable not only within the app but also through system-wide Spotlight search, I indexed it with Core Spotlight. It's possible to use the same search index for both, and I wrote a detailed post on how this can be done: Core Spotlight integration for Spotlight and internal app search.

# Liquid glass sheets

In addition to the Liquid Glass tab view with search, Breve also makes use of the new Liquid Glass sheet appearance for preferences, paired with a morphing transition from the settings button.

To take advantage of the new iOS 26 Liquid Glass sheet design, we need to make sure that our presentation detents include at least one partial-height option. And to implement the morphing transition, we can use the matchedTransitionSource() modifier on the ToolbarItem, paired with navigationTransition() on the view inside the sheet. I walk through all the necessary setup in Presenting Liquid Glass sheets in SwiftUI on iOS 26.

Like in many other apps, the Preferences sheet in Breve contains a form and also pushes views onto a navigation stack within the sheet content. In such cases, the default Liquid Glass background in partial-height gets obscured by the form and the navigation destination background, unless we add a few extra configurations. I described how the glassy sheet appearance can be achieved in more complex sheets in my post on SwiftUI Liquid Glass sheets with NavigationStack and Form. I use the techniques covered in my article, such as reading the current sheet detent and adjusting the scroll content background, to make sure that my Preferences sheet presents the form appropriately in both medium and large detents.

# AlarmKit integration

In terms of system integration, I thought the most appropriate iOS 26 framework to bring into the first release of Breve would be AlarmKit.

AlarmKit lets us schedule one-time alarms, weekly repeating alarms, and countdown timers that start immediately, and in Breve it's used for brewing timers. The framework provides APIs to request authorization from users, customize alerts that cut through silent mode and Focus, and display a live countdown in a Live Activity. I walk through the setup, which is quite involved, in my blog post: Schedule a countdown timer with AlarmKit.

Unfortunately, there are no APIs for displaying a live countdown inside the app, so I had to write some custom logic for it in Breve, placing the countdown either in a tab view accessory or in the bottom toolbar, depending on where in the app the user is. I'll try to cover that in an upcoming post.

Breve gave me plenty of chances to try out new APIs and design ideas, and I've got a backlog of learnings that I haven't had a chance to turn into blog posts yet. I'm going to do my best to share as much as I can in the near future.

A few weeks ago I wrote a post on Presenting Liquid Glass sheets in SwiftUI on iOS 26, including setting up presentation detents and configuring morphing transitions from toolbar buttons. But if sheets include forms or push views onto a NavigationStack, which is common for preferences sheets in many apps, they won't get the Liquid Glass appearance by default. In this post I'm going to walk through the extra steps required in such cases to keep the Liquid Glass effect visible throughout.

# Liquid Glass sheet with a Form

Form views, like lists, provide their own opaque background that covers the glassy sheet surface. To give a sheet with a form the Liquid Glass appearance, in addition to specifying at least one partial-height detent in its presentation detents, the default form background needs to be hidden. This can be done by applying .scrollContentBackground(.hidden) directly to the Form.

struct SettingsSheet: View {
    var body: some View {
        NavigationStack {
            Form {
                SettingsToggles()
                NotificationsSection()
            }
            .settingsToolbar()
            .scrollContentBackground(.hidden)
        }
        .presentationDetents([.medium, .large])
    }
}

With this configuration the main form background will be removed, leaving only the row backgrounds visible, which results in a glassy sheet appearance in the medium detent.

As the sheet transitions to the large detent and takes the full height of the screen, the Liquid Glass background will get replaced by a regular opaque one. In dark color scheme the form will still look as expected, but in light the row backgrounds will not be visible anymore. This is slightly inconsistent and might not be what you want in your design. To fix this issue we can dynamically hide and show the default form background based on the current sheet detent. We can keep the glassy appearance in half-sheet by hiding the scroll content background and set it back to default in full screen sheet.

struct SettingsSheet: View {
    @State
    private var currentDetent: PresentationDetent = .medium
    
    var body: some View {
        NavigationStack {
            Form {
                SettingsToggles()
                NotificationsSection(currentDetent: currentDetent)
            }
            .settingsToolbar()
            .scrollContentBackground(
                currentDetent == .medium ? .hidden : .automatic
            )
        }
        .presentationDetents(
            [.medium, .large], selection: $currentDetent
        )
    }
}

This keeps the form appearance consistent in both light and dark color schemes.

In case we do want to remove the row backgrounds altogether to maximize the glassy look of the sheet, we can apply the listRowBackground() modifier to the form sections or to individual rows and set their backgrounds to Color.clear.

# Liquid Glass sheet with navigation destinations

While the root view of the NavigationStack doesn't set an opaque background for its content by default, navigation destinations pushed onto the stack have an opaque extra layer behind, which obscures the Liquid Glass in the sheet. To maintain the translucency of the sheet as users navigate inside it, we need to remove that default background from navigation destinations.

For example, we might have a screen with multiple notification settings that has its own form and is pushed onto the root view of the settings sheet. To make it translucent, apart from removing the form scroll content background like we saw earlier, we also have to remove its container background by adding .containerBackground(.clear, for: .navigation).

struct NotificationsSection: View {
    let currentDetent: PresentationDetent
    
    var body: some View {
        Section {
            NavigationLink("Notifications") {
                Form {
                    NotificationSettingsForm(currentDetent: currentDetent)
                }
                .scrollContentBackground(
                    currentDetent == .medium ? .hidden : .automatic
                )
                .containerBackground(.clear, for: .navigation)
                .navigationTitle("Notifications")
            }
        }
    }
}

It's also common to include a picker with a navigationLink style in the settings, which pushes the list of options onto the navigation stack. The setup to ensure that the sheet maintains its glassy appearance with such pickers is similar to the one with plain navigation destinations. We have to remove the scroll content background first by applying the scrollContentBackground() modifier to the Picker view, and then remove the navigation container background by adding containerBackground(.clear, for: .navigation) to the picker content.

struct WeatherAlertsSections: View {
    let currentDetent: PresentationDetent
    
    @State private var selection = "Off"
    let options = ["Off", "Severe only", "Daily forecast", "All updates"]
    
    var body: some View {
        Section {
            Picker("Weather alerts", selection: $selection) {
                ForEach(options, id: \.self) { option in
                    Text(option)
                }
                .containerBackground(.clear, for: .navigation)
            }
            .pickerStyle(.navigationLink)
            .scrollContentBackground(
                currentDetent == .medium ? .hidden : .automatic
            )
        }
    }
}

With these few extra steps, our sheets can take full advantage of the Liquid Glass design and preserve their translucent appearance at partial height in all contexts.

If you're looking to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

At WWDC 25, Apple talked a lot about corner concentricity in their new design system. The idea of concentric corners, rounded corners where the curved portions of the inner and outer shapes share the same center and create a visually consistent and nested appearance, was highlighted multiple times. They also showed how to create concentric shapes in SwiftUI in one of the WWDC sessions, but the API was missing from the early betas.

Now that we are approaching the iOS 26 launch and the ConcentricRectangle API is finally available in SwiftUI, I thought it would be a good time to take a closer look at how concentric shapes work in practice, where in our apps they can be applied, and the caveats to be aware of along the way.

# Concentric shape definition

To define a concentric shape in SwiftUI we can either use one of the ConcentricRectangle initializers or call the static rect(corners:) function defined on the Shape protocol passing it a concentric corner style.

ConcentricRectangle()
    .fill(Color.indigo.gradient)
    .padding(8)
    .ignoresSafeArea()

Rectangle()
    .fill(Color.blue.gradient)
    .clipShape(.rect(corners: .concentric))
    .padding(8)
    .ignoresSafeArea()

Both of these versions will produce the same visual result, which is a concentric version of the current container shape. If it's the root view of the app, or a full screen cover, then the container shape comes from the device.

The corner radii for the concentric shape are derived from the container corner radii and the distance between the container and the inner shape corners. If the distance between the inner shape's corners and the container corners is larger than the container’s corner radii, the radii of the inner corners will be set to 0. That is why I applied ignoresSafeArea() in my examples to remove the default distance between my shape and the device's edge for demo purposes.

# Default container shapes

Depending on where in the app hierarchy we need a concentric shape, its container shape will either be provided by the system or defined by us. The default container shape could be the device’s bezel, or the shape of a sheet or a popover, for example.

I noticed that to get a uniform concentric shape inside a sheet, I just needed to ignore the safe area, similar to a shape concentric to the device bezel. But for a shape inside a popover, I had to add the isUniform parameter set to true, otherwise the two corners closer to the popover arrow wouldn’t be rounded enough for visual balance.

.sheet(isPresented: .constant(true)) {
    ConcentricRectangle()
        .fill(.blue.gradient)
        .padding()
        .ignoresSafeArea()
        .presentationDetents([.medium])
}

.popover(isPresented: .constant(true)) {
    ConcentricRectangle(
        corners: .concentric, isUniform: true
    )
    .fill(.mint.gradient)
    .frame(width: 200, height: 200)
    .padding()
    .presentationDetents([.medium])
    .presentationCompactAdaptation(.popover)
}

# Setting a custom container shape

For many custom UI elements, such as cards, tags, custom controls and containers, we'll need to set a custom container shape if we want the corners of nested views to be correctly rounded. We can do it by applying the new containerShape(_:) modifier to the parent container.

struct Card: View {
    let color: Color
    let text: String
    
    var body: some View {
        ZStack {
            ConcentricRectangle()
                .fill(.thickMaterial)
            
            VStack {
                ConcentricRectangle(
                    corners: .concentric,
                    isUniform: true
                )
                .fill(color.gradient)
                
                Text(text)
                    .font(.headline)
            }
            .padding(12)
        }
        .containerShape(
            .rect(cornerRadius: 24)
        )
    }
}

In this example, applying .containerShape(.rect(cornerRadius: 24)) to the ZStack in Card ensures that the background ConcentricRectangle matches the 24‑point corner radius exactly, while the foreground ConcentricRectangle becomes a concentric version of the container shape where the corner radius is computed as 24 minus the padding. The top corners of the foreground ConcentricRectangle will be rounded by default, but the bottom corners would get a radius of 0 because of their greater distance to the parent container corners unless we set isUniform to true.

The container shape that we use must conform to the RoundedRectangularShape protocol, otherwise, ConcentricRectangle won't be able to resolve its corner radius based on concentricity and will revert to a ContainerRelativeShape. Standard SwiftUI shapes such as RoundedRectangle, Capsule, and Circle all conform to RoundedRectangularShape, so they can be used as container shapes for concentric rectangles.

# Corner radius resolution

The resolved corner radius for each corner of a concentric shape can vary based on how the shape is positioned within its container. If it’s not centered, the corners closer to the edge will get a larger radius than those farther away. Corners that are too far from the container’s edge will default to a radius of 0 points.

ZStack(alignment: .topTrailing) {
    ConcentricRectangle()
        .fill(.thickMaterial)
    
    ConcentricRectangle()
        .fill(.indigo.gradient)
        .frame(width: 300, height: 300)
        .padding()
}
.containerShape(
    .rect(cornerRadius: 60)
)
.frame(width: 360, height: 500)

If we want a uniform shape instead, we need to use the init(corners:isUniform:) initializer and pass true to isUniform, which is false by default.

ConcentricRectangle(
    corners: .concentric,
    isUniform: true
)
.fill(.indigo.gradient)
.frame(width: 300, height: 300)
.padding()

Corners of a uniform concentric shape will all have the same corner radius, equal to the largest resolved radius among the corners.

# Minimum corner radius

To make sure a concentric shape never gets corners that are not rounded, we can provide a minimum corner radius.

Text("Hello, world!")
    .padding()
    .background(
        .teal.gradient,
        in: .rect(
            corners: .concentric(minimum: 24),
            isUniform: true
        )
    )

When the shape is too far from the edge of its container to resolve rounded concentric corners, it will use the minimum radius. If it moves closer to the edge or grows, for example as dynamic text size changes, it will switch to concentric corners that match the container.

There are a few more customizations we can do with concentric rectangles, such as setting a corner style for each corner individually, or applying styles to groups of corners like the top or bottom ones, in case we need more control over how our shapes adapt to different layouts and containers.

Overall, I think that concentric rectangles are a welcome addition to SwiftUI that give us new ways to make our interfaces more consistent, adaptive, and polished for iOS 26.

If you're looking to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

We can increase the visibility of our app’s content by making it available to the system so it appears in Spotlight search results on the device. This can be done by indexing the content with Core Spotlight APIs. The same index can also be used to power search inside the app, allowing us to avoid writing custom search logic.

In this post, I’ll walk through how we can leverage Core Spotlight for both system-wide and in-app search. Core Spotlight indexing APIs have been available since iOS 9, but they’ve evolved over the years. I’ll show the approach I’ve found to work best with the latest updates.

# Expose app data in Spotlight search

# Adding data to Spotlight index

There are several ways to integrate app data with Spotlight, including CSSearchableItem, NSUserActivity, and IndexedEntity. I’ve been using CSSearchableItem because it’s a simple, lightweight solution that also allows linking data to NSUserActivity via relatedUniqueIdentifier, or to IndexedEntity with associateAppEntity(_:priority:) when we need the additional functionality they provide.

We can start indexing data as soon as it’s available in the app, for example after a network call retrieves it, after the user creates an item, or on app launch if the data is bundled with the app. In our simple example, the data is hardcoded, so we can index it immediately. The recent Core Spotlight APIs provide async versions, which allows us to place the indexing logic inside the SwiftUI task() modifier.

import SwiftUI
import CoreSpotlight

@main
struct CoreSpotlightExampleApp: App {
    var body: some Scene {
        WindowGroup {
            SmoothiesView()
                .task {
                    await indexAppContent()
                }
        }
    }
    
    private func indexAppContent() async {
        // index app content
    }
}

The first step in indexing content is to create CSSearchableItem instances. For each item, we define an attribute set that specifies the properties to index and display in Spotlight search. We then create the searchable item with this attribute set and a unique identifier.

private func indexAppContent() async {
    let items = RecipeProvider.shared.recipes.map { recipe in
        let attributeSet = CSSearchableItemAttributeSet(
            contentType: .content
        )
        attributeSet.title = recipe.title
        attributeSet.thumbnailData = recipe.imageData
        
        return CSSearchableItem(
            uniqueIdentifier: recipe.id,
            domainIdentifier: nil,
            attributeSet: attributeSet
        )
    }
    
    ...
}

Once the searchable items are prepared, the next step is to define a CSSearchableIndex. This index can be created using the shared default instance or by initializing a custom index with a specific name. Using a custom index provides additional control, such as specifying a protection class and performing batch updates, which we will cover later. In this example, we create a named custom index and call indexSearchableItems() to add the items to it.

private func indexAppContent() async {
    ...
    
    let index = CSSearchableIndex(name: "SpotlightSearchExample")
    
    do {
        try await index.indexSearchableItems(items)
    } catch {
        print("Error indexing content: \(error.localizedDescription)")
    }
}

After completing this setup and running the app, we can open Spotlight search and look for a term that matches our content. My example project contains smoothie recipes, so when I search for a term like "berry", I will see matching berry smoothie entries.

# Deep linking from Spotlight results

By default, when the user taps a search result in Spotlight, the system launches the app on its initial page. We can improve this experience by taking them directly to the detail page of the selected item.

When the app is opened from a Spotlight result, we can use the onContinueUserActivity() modifier in SwiftUI to retrieve the tapped item’s identifier and navigate to it. The activity type is CSSearchableItemActionType, and the identifier is available under the CSSearchableItemActivityIdentifier key in the activity’s userInfo dictionary.

NavigationStack(path: $navigationPath) {
    ...
}
.onContinueUserActivity(
    CSSearchableItemActionType
) { activity in
    if let uniqueIdentifier = activity.userInfo?[
        CSSearchableItemActivityIdentifier
    ] as? String {
        navigateToRecipe(withID: uniqueIdentifier)
    }
}

Here’s an example of deep linking from a Spotlight search result directly to an item in the app.

# Avoiding unnecessary re-indexing

With this navigation in place, we can turn our attention back to indexing. There are a few improvements we can make to the basic setup to make it smarter and more efficient. Firstly, we can utilize the batch update APIs, which also allow us to attach some custom metadata to the updates called client state. By reading and writing the client state, we can ensure that we only index content when necessary, avoiding re-indexing the same items every time the app starts.

The client state type that Core Spotlight accepts is Data, so it can contain anything we need to include. For my example, I defined a simple Codable struct with a date.

struct SearchIndexData: Codable {
    let date: Date
}

We can update our previous indexing logic to check if client data already exists, and depending on that, proceed with indexing or skip it. When indexing is required, we should create a new index data instance, perform the indexing within a batch update, then end the update and attach the new data. This ensures that the next time the app starts, fetching client data returns the value we stored. Since there is no way to add client data without using batch updates, this API is still useful even when the content is small enough not to require batching.

private func indexAppContent() async {
    ...
    
    let index = CSSearchableIndex(name: "SpotlightSearchExample")
    
    if
        let clientState = try? await index.fetchLastClientState(),
        let indexData = try? JSONDecoder().decode(
            SearchIndexData.self, from: clientState
        )
    {
        print("Search index exists, created on: \(indexData.date)")
    } else if
        let newData = try? JSONEncoder().encode(
            SearchIndexData(date: Date())
        )
    {
        do {
            index.beginBatch()
            try await index.indexSearchableItems(items)
            try await index.endBatch(withClientState: newData)
        } catch {
            print("Error indexing content: \(error.localizedDescription)")
        }
    }
}

# Customizing result ranking

Another improvement we can make is to inform Core Spotlight when the user interacts with indexed content in the app. This helps Spotlight prioritize search results, making it more likely that items the user engages with frequently will appear first.

We can achieve this by setting the lastUsedDate in the attribute set for the CSSearchableItem, which requires re-indexing the last used item. Depending on the application flow, we can choose the most suitable place to perform this re-indexing. In my example, I’ll do it in the onAppear() modifier of the recipe detail view.

struct RecipeView: View {
    let recipe: Recipe
    
    var body: some View {
        ScrollView {
            ...
        }
        .onAppear {
            let attributeSet = CSSearchableItemAttributeSet(
                contentType: .content
            )
            attributeSet.title = recipe.title
            attributeSet.thumbnailData = recipe.imageData
            attributeSet.lastUsedDate = Date()
            
            let item = CSSearchableItem(
                uniqueIdentifier: recipe.id,
                domainIdentifier: nil,
                attributeSet: attributeSet
            )
            
            item.isUpdate = true
            let index = CSSearchableIndex(
                name: "SpotlightSearchExample"
            )
            index.indexSearchableItems([item])
        }
    }
}

Note that we should set isUpdate property on the item to true in this case. This allows the system to update an existing item with the same identifier instead of deleting and reinserting it, which is more efficient.

To test whether this prioritization works in practice, we can open the same item several times in the app and then search in Spotlight for a term that matches it along with a few other items. In my case, after interacting with the Summer Berry Blend smoothie a few times, it appears at the top of the Spotlight results for the app.

# Provide a reindexing app extension

Apple recommends providing a reindexing app extension to keep the index up to date even when the app isn’t running. This extension can be used to update the app’s index if it appears to be incomplete, corrupted or lost.

To add the extension, we need to create a new target using the CoreSpotlight Delegate template.

This extension requires implementing two methods: one for reindexing all searchable items and another for reindexing specific items by their identifiers. It’s important to call the acknowledgementHandler once indexing is completed.

class SearchReindexing: CSIndexExtensionRequestHandler {
    
    private func searchableItems(for recipes: [Recipe]) -> [CSSearchableItem] {
        recipes.map { recipe in
            let attributeSet = CSSearchableItemAttributeSet(
                contentType: .content
            )
            attributeSet.title = recipe.title
            attributeSet.thumbnailData = recipe.imageData
            
            return CSSearchableItem(
                uniqueIdentifier: recipe.id,
                domainIdentifier: nil,
                attributeSet: attributeSet
            )
        }
    }

    override func searchableIndex(
        _ searchableIndex: CSSearchableIndex,
        reindexAllSearchableItemsWithAcknowledgementHandler acknowledgementHandler: @escaping () -> Void
    ) {
        let items = searchableItems(for: RecipeProvider.shared.recipes)
        
        searchableIndex.indexSearchableItems(items) { error in
            // handle possible errors
            
            acknowledgementHandler()
        }
    }

    override func searchableIndex(
        _ searchableIndex: CSSearchableIndex,
        reindexSearchableItemsWithIdentifiers identifiers: [String],
        acknowledgementHandler: @escaping () -> Void
    ) {
        let items = searchableItems(
            for: RecipeProvider.shared.recipes
                .filter { identifiers.contains($0.id) }
        )
        
        searchableIndex.indexSearchableItems(items) { error in
            // handle possible errors
            
            acknowledgementHandler()
        }
    }
    
    ...
}

To reindex your data inside the extension, make sure the files where it’s stored are included in both the main app target and the extension target.

# Power in-app search with Core Spotlight

Exposing our app data in Spotlight search is an effective way to increase its visibility outside the app, but the Core Spotlight index can also provide value within the app itself. We can leverage this index to power in-app search without building and maintaining separate search logic.

I’m going to show how we can integrate Core Spotlight search capability, continuing from my SwiftUI sample project. To let users perform searches inside the app, I’ll add a searchable() modifier to the SmoothiesView.

import SwiftUI
import CoreSpotlight

struct SmoothiesView: View {
    ...
    
    @State private var searchText = ""
    
    var body: some View {
        NavigationStack(path: $navigationPath) {
            ...
        }
        .searchable(text: $searchText)
    }
}

# Querying Core Spotlight index inside the app

To query Core Spotlight for search results, we first need to prepare Spotlight by calling the prepare() class method on CSUserQuery. This only needs to be called once per app lifecycle and should be done only when necessary, for example, when the view with the search interface first appears.

NavigationStack(path: $navigationPath) {
    ...
}
.searchable(text: $searchText)
.onAppear {
    CSUserQuery.prepare()
}

The Core Spotlight APIs for querying search results have async versions, so we can call them within a task() modifier. It’s recommended to wait at least 0.3 seconds after the user’s input to allow them to finish typing and avoid unnecessary search queries, which can be expensive. We can then initialize a Core Spotlight query by passing the search text to the userQueryString parameter, and read the results as they arrive by iterating over the responses async sequence. This sequence can return an enum with two cases: a search result or a search suggestion. However, I’ve never seen it return any suggestions in practice. It’s possible this functionality is incomplete, or that it depends on factors I’m not aware of.

NavigationStack(path: $navigationPath) {
    ...
}
.searchable(text: $searchText)
.onAppear {
    CSUserQuery.prepare()
}
.task(id: searchText) {
    guard !searchText.isEmpty else { return }
    
    do {
        try await Task.sleep(for: .seconds(0.3))
    
        let query = CSUserQuery(
            userQueryString: searchText,
            userQueryContext: nil
        )
        
        for try await element in query.responses {
            switch(element) {
            case .item(let item):
                print("Got a result: \(item.item.uniqueIdentifier)")
            case .suggestion(let suggestion):
                let str = suggestion
                    .suggestion.localizedAttributedSuggestion
                print("Got a suggestion: \(str)")
            @unknown default: break
            }
        }
    } catch {
        // handle possible errors
        return
    }
}

When constructing a search query, it’s important to use the correct initializer: init(userQueryString:userQueryContext:), not init(queryString:queryContext:). Using the latter results in an invalid query error (CSSearchQueryErrorDomain/-2002), but it’s easy to select it by accident when using Xcode autocomplete, so I thought it was worth mentioning.

# Displaying search results

Depending on the desired search experience in our app, we can either display a dedicated search interface while a search is in progress or filter the content in place. I’ll filter the list of smoothies as the user types a search query. To do this, I’ll assemble all the search results into an array and then transform this array of query items into recipe objects. If you are doing the same, don’t forget to reset the results when a new query starts.

struct SmoothiesView: View {
    @State private var navigationPath: [Recipe] = []
    
    private let recipes = RecipeProvider.shared.recipes
    
    @State private var searchText = ""
    @State private var filteredRecipes: [Recipe] = []
    @State private var queryItems: [CSUserQuery.Item] = []
    
    var recipesToDisplay: [Recipe] {
        searchText.isEmpty ? recipes : filteredRecipes
    }
    
    var body: some View {
        NavigationStack(path: $navigationPath) {
            List(recipesToDisplay) { recipe in
               ...
            }
        }
        ...
        
        .task(id: searchText) {
            ...
            
            do {
                ...
            
                queryItems = []
            
                for try await element in query.responses {
                    switch(element) {
                    case .item(let item):
                        queryItems.append(item)
                    case .suggestion(let suggestion):
                        ...
                    @unknown default: break
                    }
                }
            } catch {
                // handle possible errors
                return
            }
            
            filteredRecipes = queryItems.compactMap { item in
                recipes.first(
                    where: { $0.id == item.item.uniqueIdentifier }
                )
            }
        }
    }
}

Now, when the search text is not empty, the list of smoothies will consist of the recipes that match the search.

# Personalizing results based on engagement

Similar to how we informed Spotlight about the items the user engages with for improved result ranking in the "Customizing result ranking" section for Spotlight search, we can also personalize the results in internal app search, although the APIs to do this are a bit different. First, we need to detect when the user engages with a search result and call the userEngaged() method on the query instance. This method requires the engaged item as a CSUserQuery.Item and the currently visible items as an array of the same type.

struct SmoothiesView: View {
    @State private var navigationPath: [Recipe] = []
    
    @State private var searchText = ""
    @State private var queryItems: [CSUserQuery.Item] = []
    
    ...
    
    var body: some View {
        NavigationStack(path: $navigationPath) {
            ...
        }

        ...
        .onChange(of: navigationPath) { oldValue, newValue in
            guard
                !searchText.isEmpty,
                let selection = newValue.first,
                let item = queryItems.first(
                    where: {
                        $0.item.uniqueIdentifier == selection.id
                    }
                )
            else { return }
            
            let query = CSUserQuery(
                userQueryString: searchText,
                userQueryContext: nil
            )
            
            query.userEngaged(
                item, visibleItems: queryItems,
                interaction: .select
            )
        }
    }
}

We also need to enable ranked results for the Core Spotlight query used to power the search, and sort the results based on rank before preparing them for display. Even though the documentation claims that enableRankedResults is true by default, I found that without defining the query context, the ranking won't work.

struct SmoothiesView: View {
    ...
    
    @State private var queryItems: [CSUserQuery.Item] = []
    
    ...
    
    var body: some View {
        NavigationStack(path: $navigationPath) {
            ...
        }
        .task(id: searchText) {
            ...
            
            do {
                ...
                
                let context = CSUserQueryContext()
                context.enableRankedResults = true
                
                let query = CSUserQuery(
                    userQueryString: searchText,
                    userQueryContext: context
                )
                
                ...
                
            } catch {
                // handle possible errors
                return
            }
            
            queryItems.sort { first, second in
                first.item.compare(
                    byRank: second.item
                ) == .orderedAscending
            }
            
            filteredRecipes = queryItems.compactMap { item in
                recipes.first(
                    where: {
                        $0.id == item.item.uniqueIdentifier
                    }
                )
            }
        }
    }
}

Now, if I search for "milk" in my sample smoothie app and interact with the "Chocolate Almond Milk" result, the next time it appears in search it will be moved to the top of the list.

As we’ve seen, Core Spotlight provides powerful APIs for exposing our app’s data on the user’s device, even when the app isn’t running, and for driving search functionality inside the app. It’s not perfect, and some promised features like search suggestions and semantic search announced by Apple last year don’t appear to be working properly, but it’s still a useful framework to understand and integrate.

If you’d like to try it out yourself, you can download the sample code I used to demo the examples in this post from our GitHub repository. Note that I created the project using Xcode 26 beta 5.

If you’re looking for more Swift and SwiftUI reading, take a look at my books and book bundles. They offer detailed guides and practical tips to deepen your understanding of both the Swift language and the SwiftUI framework.

In iOS and iPadOS 26, the search experience has been updated with new placement behaviors and visual styling, and we also have new SwiftUI APIs to support the changes. In this post, we'll explore how we can take advantage of these enhancements to build search interfaces that feel modern and consistent with the system.

We'll focus on two common search patterns in iOS apps: search in the toolbar and search in the tab bar, and review how each works, what has changed, and how to implement them in SwiftUI.

# Toolbar search

In apps that use hierarchical navigation with NavigationStack or NavigationSplitView, it's common to enable global search by applying the searchable() modifier to the entire navigation view.

NavigationSplitView {
    List(notes, selection: $selectedNote) { note in
        NavigationLink(note.title, value: note)
    }
    .navigationTitle("Notes")
} detail: {
    NoteDetailView(note: selectedNote)
}
.searchable(text: $searchText)

Applying searchable() to the navigation container instead of an individual column allows the system to determine the appropriate placement for the search field.

In earlier versions of iOS and iPadOS, this setup would place the search field at the top of the sidebar on iPad and at the top of the root view on iPhone. Starting with iOS 26, the same configuration results in a search field presented in a Liquid Glass container, positioned in the top trailing corner of the window on iPad, and at the bottom of the screen on iPhone for easier reach.

We can still explicitly position the search field in the sidebar on iPad if that better suits our app by specifying the sidebar placement in the searchable() modifier.

NavigationSplitView {
    List(filteredNotes, selection: $selectedNote) { note in
        NavigationLink(note.title, value: note)
    }
    .navigationTitle("Notes")
} detail: {
    NoteDetailView(note: selectedNote)
}
.searchable(text: $searchText, placement: .sidebar)

This restores the previous behavior, placing the search field at the top of the sidebar column instead of using the new floating style.

For applications where search is scoped to the detail content rather than applied globally, we should attach the searchable() modifier directly to the detail view.

NavigationSplitView {
    List(notes, selection: $selectedNote) { note in
        NavigationLink(note.title, value: note)
    }
    .navigationTitle("Notes")
} detail: {
    NoteDetailView(note: selectedNote)
        .searchable(text: $searchText)
}

This placement has also been updated with the new design in iOS and iPadOS 26.

When the detail view includes other bottom toolbar items on iPhone, and we want the search field to still appear at the bottom, we can use two new toolbar content types introduced in iOS 26: DefaultToolbarItem with the search kind, and ToolbarSpacer.

NoteDetailView(note: selectedNote)
    .toolbar {
        if #available(iOS 26.0, *) {
            DefaultToolbarItem(kind: .search, placement: .bottomBar)
            ToolbarSpacer(.flexible, placement: .bottomBar)
        }
        ToolbarItem(placement: .bottomBar) {
            NewNoteButton()
        }
    }
    .searchable(text: $searchText)

This ensures that the search field is allocated space in the bottom toolbar layout and remains visually separated from the other toolbar items.

If search isn't the primary experience we want to promote in our app, we can use the new SwiftUI modifier searchToolbarBehavior() to minimize the search field into a toolbar button. The system may also apply this behavior automatically based on factors such as device size or the number of toolbar items.

extension View {
    @ViewBuilder func minimizedSearch() -> some View {
        if #available(iOS 26.0, *) {
            self.searchToolbarBehavior(.minimize)
        } else { self }
    }
}

struct NotesView: View {
    ...
    
    var body: some View {
        NavigationSplitView {
            ...
        } detail: {
            NoteDetailView(note: selectedNote)
                .toolbar {
                    if #available(iOS 26.0, *) {
                        DefaultToolbarItem(kind: .search, placement: .bottomBar)
                        ToolbarSpacer(.flexible, placement: .bottomBar)
                    }
                    ToolbarItem(placement: .bottomBar) {
                        NewNoteButton()
                    }
                }
                .searchable(text: $searchText)
                .minimizedSearch()
        }
    }
}

# Tab bar search

In apps that use tab-based navigation, it’s common to place search in a dedicated tab where users can browse suggestions or enter queries directly. This pattern appears in many Apple apps such as Health, Music, and Books. To adopt it, we can create a Tab with the search role and apply the searchable() modifier to the view inside the tab. For the search field to appear and function correctly, the contents of the search tab should be wrapped in a NavigationStack.

TabView {
    Tab("Library", systemImage: "books.vertical") {
        LibraryView()
    }
    Tab("Book Store", systemImage: "bag") {
        StoreView()
    }
    
    Tab(role: .search) {
        NavigationStack {
            SearchView()
                .navigationTitle("Search")
        }
        .searchable(text: $searchText)
    }
}

With the new Liquid Glass tab bar design in iOS 26, the search tab appears visually separated from the others and transforms into a search field when selected.

Just like with other standard system components, adopting the new Liquid Glass design for search doesn’t require much effort. By taking advantage of the updates to standard search patterns and adjusting behavior to suit our app’s needs, we can ensure that our search experience feels at home on iOS and iPadOS 26.

If you're looking to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

iOS 26 introduces the new Liquid Glass design, which brings updates to the appearance and behavior of sheets in SwiftUI. In this post, we'll explore these changes and how we can adopt them in our apps.

# Liquid Glass background

In iOS 26, partial height sheets appear to float above the interface, with rounded corners that follow the shape of the device and edges that don’t touch the screen. They also use the new Liquid Glass background by default.

To take advantage of this new design, we need to specify presentation detents in the sheet content and include at least one partial height option, such as medium or a custom height detent.

BirdImage()
    .sheet(isPresented: $showInfo) {
        InfoView()
            .presentationDetents([.medium, .large])
    }

When the sheet is expanded to the large detent, its background transitions to an opaque appearance, and it becomes attached to the sides and bottom of the screen.

In earlier versions of iOS, we often customized sheet backgrounds using the presentationBackground() modifier, typically with a translucent material. On iOS 26, this is no longer needed and should be avoided if we want the system to apply the new Liquid Glass appearance automatically.

# Morphing sheet transitions

Another update in iOS 26 is that sheets can now morph from the toolbar button that presents them. This creates a fluid transition that fits with the Liquid Glass design and makes the sheet feel visually connected to its source.

To implement this behavior in our apps, we first need to indicate that the ToolbarItem presenting the sheet is the source by applying the matchedTransitionSource() modifier to it. We also need to apply a zoom navigation transition to the sheet content, using a matching sourceID to link it to the button.

struct ContentView: View {
    @Namespace private var transition
    @State private var showInfo = false
    
    var body: some View {
        NavigationStack {
            BirdImage()
                .toolbar {
                    ToolbarSpacer(placement: .bottomBar)
                    
                    ToolbarItem(placement: .bottomBar) {
                        Button("Info", systemImage: "info") {
                            showInfo = true
                        }
                    }
                    .matchedTransitionSource(
                        id: "info", in: transition
                    )
                }
                .sheet(isPresented: $showInfo) {
                    InfoView()
                        .presentationDetents([.medium, .large])
                        .navigationTransition(
                            .zoom(sourceID: "info", in: transition)
                        )
                }
        }
    }
}

With this setup, the toolbar button will transition into the sheet when pressed, and the sheet will return to the button when dismissed.

Note that for the transition to work correctly, the view containing the toolbar must be inside a NavigationStack or NavigationSplitView, even when using a bottom bar that would otherwise work without navigation. As of beta 3, the transition can still be glitchy at times, but this will hopefully be improved in future betas.

By adopting both the new visual appearance and morphing transitions for our sheets, we can align our apps with the updated system design in iOS 26 and use the tools SwiftUI now provides to create presentations that fit naturally within the new interface style.

If you're looking to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

At WWDC 2025 Apple introduced AlarmKit, a framework that lets us schedule one-time alarms, weekly repeating alarms, and countdown timers that start immediately. Unlike notifications we schedule with UserNotifications, which stay quiet in silent mode or during a Focus unless the app holds the rarely granted Critical Alerts entitlement, AlarmKit alerts cut through silent mode and focus with a permanent banner and sound. This makes AlarmKit the first widely available way to ensure that everyday timers and alarms always surface at the right moment.

I've been experimenting with integrating countdown timer scheduling with AlarmKit into one of my projects, and in this post I’ll share how it can be done.

# Check and request authorization

Because an AlarmKit timer ends with an alert that plays sound and appears even when a Focus is active, we must ask the user for explicit permission. The first step is to add the NSAlarmKitUsageDescription key to Info.plist and write a short explanation of why our app needs to schedule alarms or timers. This text will be shown in a system prompt that we'll trigger when the user schedules a timer in our app for the first time.

The next step is to check the current authorization status and, if it’s still undetermined, prompt the user. We can do that with the AlarmManager APIs. The shared AlarmManager instance exposes the authorizationState property for reading the status and the requestAuthorization() method for showing the system prompt.

import SwiftUI
import AlarmKit

struct TimerButton: View {
    private let manager = AlarmManager.shared
    
    var body: some View {
        Button("Start a timer", systemImage: "timer") {
            Task {
                if await checkForAuthorization() {
                    // Schedule the countdown timer
                } else {
                    // Handle unauthorized status
                }
            }
        }
    }
    
    private func checkForAuthorization() async -> Bool {
        switch manager.authorizationState {
        case .notDetermined:
            do {
                let state = try await manager.requestAuthorization()
                return state == .authorized
            } catch {
                print("Authorization error: \(error)")
                return false
            }
        case .authorized: return true
        case .denied: return false
        @unknown default: return false
        }
    }
}

Calling requestAuthorization() in the .notDetermined branch triggers a system alert that shows Apple’s standard explanation of alarms and timers, followed by the custom text from NSAlarmKitUsageDescription.

If the user denies permission, we can’t schedule AlarmKit timers. Depending on the app, we can disable timer-related features and direct users to Settings to enable them, or fall back to another timing method. If the user grants permission, we can go ahead and schedule a timer with AlarmKit.

# Schedule a timer

Scheduling a timer is unfortunately not as straightforward as checking for authorization, because even the simplest configuration needs a bit of setup. Let’s go over it step by step.

First we need to describe the alert that appears when the timer finishes by creating an AlarmPresentation.Alert. It requires a title and a stopButton, and can optionally have a secondary button as well.

import SwiftUI
import AlarmKit

struct TimerButton: View {
    private let manager = AlarmManager.shared
    
    var body: some View {
        Button("Start a timer", systemImage: "timer") {
            Task {
                if await checkForAuthorization() {
                    await scheduleTimer()
                } else {
                    // Handle unauthorized status
                }
            }
        }
    }
    
    private func scheduleTimer() async {
        let alert = AlarmPresentation.Alert(
            title: "Ready!",
            stopButton: AlarmButton(
                text: "Done",
                textColor: .pink,
                systemImageName: "checkmark"
            )
        )
    }
    
    ...
}

The alert appears in two sizes: a small banner when the timer ends while the device is unlocked and a larger one on the lock screen. We should keep the title short so it doesn't get truncated in the compact version.

Once the alert is in place, we can create AlarmAttributes, which requires a presentation and a tintColor. The metadata parameter is optional, but AlarmAttributes is generic over Metadata, so we still need to provide a type that conforms to AlarmMetadata, even if it’s empty. Without that type the code won’t compile and we'll see the error Generic parameter 'Metadata' could not be inferred. In projects created with Xcode 26, where types are MainActor-isolated by default, we should mark our type as nonisolated to satisfy the protocol conformance.

import SwiftUI
import AlarmKit

nonisolated struct TimerData: AlarmMetadata {}

struct TimerButton: View {
    ...
    
    private func scheduleTimer() async {
        let alert = AlarmPresentation.Alert(
            title: "Ready!",
            stopButton: AlarmButton(
                text: "Done",
                textColor: .pink,
                systemImageName: "checkmark"
            )
        )
        
        let attributes = AlarmAttributes<TimerData>(
            presentation: AlarmPresentation(alert: alert),
            tintColor: .pink
        )
    }
}

Now we can finally start a timer by calling the schedule() method of AlarmManager and passing a configuration that includes the AlarmAttributes we defined earlier together with a duration. In this example we schedule a 30-second timer, but in a real app we would set the duration from context or let the user choose it.

import SwiftUI
import AlarmKit

nonisolated struct TimerData: AlarmMetadata {}

struct TimerButton: View {
    private let manager = AlarmManager.shared
    
    ...
    
    private func scheduleTimer() async {
        let alert = AlarmPresentation.Alert(
            title: "Ready!",
            stopButton: AlarmButton(
                text: "Done",
                textColor: .pink,
                systemImageName: "checkmark"
            )
        )
        
        let attributes = AlarmAttributes<TimerData>(
            presentation: AlarmPresentation(alert: alert),
            tintColor: .pink
        )
        
        do {
            let timerAlarm = try await manager.schedule(
                id: UUID(),
                configuration: .timer(
                    duration: 30,
                    attributes: attributes
                )
            )
        } catch {
            print("Scheduling error: \(error)")
        }
    }
}

# Configure a countdown Live Activity

So far we've scheduled a timer and set up the alert presentation that appears when the timer ends. To display a continuous countdown while the timer is running, we need to set up a Live Activity that shows on the Lock Screen and in the Dynamic Island.

We'll need to add a Widget Extension target to our project and remove all the widget-related code, as we just need a Live Activity. The most basic starter configuration only requires a WidgetBundle declaration marked with @main and the Live Activity definition itself with an ActivityConfiguration using AlarmAttributes.

import WidgetKit
import SwiftUI
import AlarmKit

@main
struct CountdownTimerBundle: WidgetBundle {
    var body: some Widget {
        CountdownTimerLiveActivity()
    }
}

struct CountdownTimerLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: AlarmAttributes<TimerData>.self) { context in

        } dynamicIsland: { context in
            DynamicIsland {
                DynamicIslandExpandedRegion(.leading) {
                    
                }
                DynamicIslandExpandedRegion(.trailing) {

                }
                DynamicIslandExpandedRegion(.bottom) {

                }
            } compactLeading: {
                
            } compactTrailing: {
                
            } minimal: {
                
            }
        }
    }
}

We also need to ensure that the TimerData declaration defined in the main application target is compiled into the Widget Extension. The simplest approach is to place it in a dedicated Swift file and assign that file to both targets.

The context provided inside the Live Activity contains the AlarmPresentationState, from which we can extract the countdown, create a timer-interval range, and pass it to a Text view. This text will be updating automatically as the seconds pass.

struct CountdownTimerLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: AlarmAttributes<TimerData>.self) { context in
            CountdownTextView(state: context.state)
                .font(.largeTitle)
                .padding()
        } dynamicIsland: { context in
            ...
        }
    }
}

struct CountdownTextView: View {
    let state: AlarmPresentationState
    
    var body: some View {
        if case let .countdown(countdown) = state.mode {
            Text(
                timerInterval: Date.now ... countdown.fireDate
            )
            .monospacedDigit()
            .lineLimit(1)
        }
    }
}

For the Dynamic Island presentation, we can either reuse the text countdown or choose a different approach. In this example we’ll define an additional progress view to explore a more compact alternative.

struct CountdownTimerLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: AlarmAttributes<TimerData>.self) { context in
            ...
        } dynamicIsland: { context in
            DynamicIsland {
                DynamicIslandExpandedRegion(.bottom) {
                    HStack {
                        CountdownTextView(state: context.state)
                            .font(.headline)
                        CountdownProgressView(state: context.state)
                            .frame(maxHeight: 30)
                    }
                }
            } compactLeading: {
                CountdownTextView(state: context.state)
            } compactTrailing: {
                CountdownProgressView(state: context.state)
            } minimal: {
                CountdownProgressView(state: context.state)
            }
        }
    }
}

struct CountdownProgressView: View {
    let state: AlarmPresentationState
    
    var body: some View {
        if case let .countdown(countdown) = state.mode {
            ProgressView(
                timerInterval: Date.now ... countdown.fireDate,
                label: { EmptyView() },
                currentValueLabel: { Text("") }
            )
            .progressViewStyle(.circular)
        }
    }
}

# Show active timers in the app

With scheduling and Live Activity presentation complete, the next logical step is to surface any timer that is currently running inside the foreground app itself.

AlarmKit provides a dedicated asynchronous sequence that emits the full set of active alarms every time the system adds, removes, or mutates one. By iterating over that sequence, we can keep local state in sync and render an up-to-date list.

struct TimerList: View {
    @State private var timerAlarms: [Alarm] = []
    
    var body: some View {
        List(timerAlarms) { alarm in
            TimerAlarmRow(alarm: alarm)
        }
        .task {
            for await alarms in AlarmManager.shared.alarmUpdates {
                timerAlarms.removeAll { local in
                    alarms.allSatisfy { $0.id != local.id }
                }
                
                for alarm in alarms {
                    if let index = timerAlarms.firstIndex(
                        where: { $0.id == alarm.id }
                    ) {
                        timerAlarms[index] = alarm
                    } else {
                        timerAlarms.insert(alarm, at: 0)
                    }
                }
            }
        }
    }
}

Every Alarm instance exposes just a few properties we can work with, such as its identifier, the countdown duration it was originally configured with, and its current state, such as countdown, alerting, or paused, if we support pausing. It doesn't report the live time-remaining value, that comes through the presentation state we used in the Live Activity, so the list can only display the static duration and the state label. The identifier, lets us cancel the alarm programmatically, so we can surface a cancel action in the app’s UI.

struct TimerAlarmRow: View {
    let alarm: Alarm
    
    var body: some View {
        HStack {
            VStack(alignment: .leading, spacing: 12) {
                Text("\(alarm.id)")
                    .font(.caption)
                
                if let countdown = alarm.countdownDuration?.preAlert {
                    let duration = Duration.seconds(countdown)
                    Text("\(duration, format: .units(width: .wide))")
                        .font(.title)
                }
                
                switch alarm.state {
                case .countdown: Text("running")
                case .alerting: Text("alerting")
                default: EmptyView()
                }
            }
            
            Spacer()
            
            Button(role: .cancel) {
                try? AlarmManager.shared.cancel(id: alarm.id)
            }
            .labelStyle(.iconOnly)
        }
    }
}

AlarmKit is a welcome addition, yet even the simplest end-to-end timer flow requires setting up several components: authorization, scheduling, Live Activity configuration, Dynamic Island presentation, and an in-app overview. In this post we walked through that baseline flow to see every step in context. The sample project I used is available on GitHub, so feel free to download it and experiment. There is still plenty to explore, for example adding secondary buttons to alerts or surfacing extra details carried in the metadata.

If you are after more Swift and SwiftUI reading, take a look at my books and book bundles, they provide detailed guides and practical tips to deepen your understanding of both the Swift language and the SwiftUI framework.

When displaying items in SwiftUI, we sometimes want to include their position in the sequence, for example, to show a list of instructions or ranked results. A common way to achieve this is by calling enumerated() on the collection. This returns an EnumeratedSequence, which is a sequence of (offset, element) pairs, where offset is a counter starting from zero and element is the corresponding value from the original collection.

Until recently, enumerated() wasn’t directly compatible with ForEach or List in SwiftUI, because the result did not conform to RandomAccessCollection. As a workaround, we had to wrap the sequence in an array.

RecipeStepsView: View {
    let steps = [
        "Chop lettuce, tomatoes, and cucumber.",
        "Drizzle with olive oil and lemon juice.",
        "Toss gently and serve."
    ]
    
    var body: some View {
        VStack(alignment: .leading) {
            ForEach(
                Array(steps.enumerated()), id: \.element
            ) { offset, step in
                Text("\(offset + 1). \(step)")
            }
        }
    }
}

As of Swift 6.2 and iOS 26, this extra step is no longer required. Proposal SE-0459 adds Collection, RandomAccessCollection, and BidirectionalCollection conformance to EnumeratedSequence when the base collection supports those protocols.

ForEach(
    steps.enumerated(), id: \.element
) { offset, step in
    Text("\(offset + 1). \(step)")
}

It’s important to note that the offset in EnumeratedSequence is a counter and should not be used as an index to access elements from the original collection. While it may appear to work when the base collection is zero-based and uses integer indices, this assumption breaks down in other scenarios, for example, when iterating over a SubSequence or any collection that does not start at zero. For more details and recommended approaches, see my other post: Iterate over items and indices in Swift collections.

Another important point to consider is that neither offset nor an index should be used as the id in ForEach unless the collection is immutable and the ordering is guaranteed to remain stable. In dynamic collections where elements can be added, removed, or reordered, such as in user-editable lists, using a counter or index as the identifier can result in incorrect view updates and animations. In these cases, a stable and unique identifier should be used instead, either by conforming the element type to Identifiable or by supplying a unique key path.

struct Task: Identifiable {
    var id = UUID()
    var title: String
}

struct TaskListView: View {
    @State private var tasks = [
        Task(title: "Buy vegetables"),
        Task(title: "Prep dressing"),
        Task(title: "Set the table")
    ]
    
    var body: some View {
        List {
            ForEach(
                tasks.enumerated(),
                id: \.element.id
            ) { offset, task in
                Text("\(offset + 1). \(task.title)")
            }
            .onDelete { indices in
                tasks.remove(atOffsets: indices)
            }
        }
    }
}

This pattern keeps the display numbering from enumerated() while maintaining stable identity through the task’s id. By decoupling numbering from identity, it ensures correct behavior as the data changes.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

It’s a common design pattern in modern iOS apps to have a large image at the top of a scroll view, extending all the way into the top safe area. When the user pulls down to overscroll, instead of revealing empty space above the image, the image expands, growing in size and creating a dynamic visual effect.

There are a few ways to achieve this effect in SwiftUI and I most commonly see developers using onScrollGeometryChange() where they get the scroll offset, write it to a shared app state, and then use it to compute the frame of the image. But we can also do it in a slightly simpler way using the visualEffect() modifier.

This modifier takes a closure with two arguments: an EmptyVisualEffect that we can apply additional effects to, and a GeometryProxy that gives us access to the size and coordinates of the view, which we can use to get its frame in scroll view coordinate space. Given we have everything we need for our stretchy effect inside this closure, we can create a simple, self-contained view modifier that doesn’t need any additional state tracking.

extension View {
    func stretchy() -> some View {
        visualEffect { effect, geometry in
            let currentHeight = geometry.size.height
            let scrollOffset = geometry.frame(in: .scrollView).minY
            let positiveOffset = max(0, scrollOffset)
            
            let newHeight = currentHeight + positiveOffset
            let scaleFactor = newHeight / currentHeight
            
            return effect.scaleEffect(
                x: scaleFactor, y: scaleFactor,
                anchor: .bottom
            )
        }
    }
}

We get the view’s current height and its scroll offset from the GeometryProxy, and we make sure to only account for the positive offset, since we just want the image to grow when the user overscrolls and don’t want it to shrink when the user scrolls up to reveal more content below the image. We then compute the view’s new height and the scale factor, and apply a scale effect to the EmptyVisualEffect with the bottom anchor, so that the image stretches up without affecting the rest of the layout underneath it.

Now all that’s left is to apply our new stretchy() modifier to the image we want to grow when the user pulls down.

struct FlowerView: View {
    let flower: Flower
    
    var body: some View {
        ScrollView {
            VStack {
                Image(flower.name)
                    .resizable()
                    .scaledToFill()
                    .stretchy()
                
                FlowerInfo(flower: flower)
            }
        }
        .ignoresSafeArea(edges: .top)
    }
}

This gives us a smooth, self-contained stretchy header effect with no extra state or offset tracking needed, and it can be easily reused throughout the app.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

WWDC25 introduced a wave of visual and functional updates, from the new Liquid Glass design language to redesigned system apps and deeper SwiftUI integration across platforms. With the first iOS 26 betas now available, I’ve been exploring some of the new APIs, and one that immediately caught my eye is backgroundExtensionEffect().

This modifier is mentioned in the updated Human Interface Guidelines and WWDC sessions as a way to extend content behind the control layer. It’s designed for cases like showing content beneath sidebars, inspectors, toolbars, or custom controls, and it can add an immersive effect to SwiftUI interfaces.

# Extend the detail column image behind the sidebar

The most obvious use case for backgroundExtensionEffect() is to apply it to a view in the detail column of a NavigationSplitView. We can use it on the graphic placed at the top of the detail view, and it will mirror and blur that content to continue its colors underneath the sidebar. This creates a sense of visual continuity, similar to what we see in some system apps, like Podcasts, for example.

In the code sample below, we are using this technique in a recipe detail view. The header image extends behind the sidebar using backgroundExtensionEffect(), making the layout feel more connected across the interface.

struct RecipeDetailView: View {
    let recipe: Recipe
    
    var body: some View {
        ScrollView {
            VStack(alignment: .leading) {
                Image(recipe.imageName)
                    .resizable()
                    .scaledToFill()
                    .backgroundExtensionEffect()
                
                RecipeNameAndDescription(recipe: recipe)
            }
        }
        .ignoresSafeArea(edges: .top)
    }
}

# Extend and blur images to create continuous backgrounds in cards

Another interesting effect we can achieve with a creative use of the new backgroundExtensionEffect() modifier is the kind of continuous background in cards sometimes seen in system apps. Instead of treating the image as a standalone element, we can extend and blur it to serve as a visual backdrop for overlay content like text or controls.

In the example below, we're building a horizontal scroll of recipe cards. Each card displays an image at the top, and by applying backgroundExtensionEffect(), we extend and blur that image into the surrounding safe area. To make use of this extended region, we place the text content inside a safeAreaInset() attached to the image itself. This lets us position labels or controls on top of the extended background without overlapping the original image bounds. To ensure readability across a variety of images, we also add a subtle linear gradient behind the text.

struct RecipeCards: View {
    let recipes: [Recipe]
    
    var body: some View {
        ScrollView(.horizontal) {
            HStack(spacing: 24) {
                ForEach(recipes) { recipe in
                    RecipeCard(recipe: recipe)
                }
            }
            .padding()
        }
    }
}

struct RecipeCard: View {
    let recipe: Recipe
    
    var body: some View {
        Image(recipe.imageName)
            .resizable()
            .scaledToFill()
            .frame(
                minWidth: 0, maxWidth: .infinity,
                minHeight: 0, maxHeight: .infinity
            )
        
            .backgroundExtensionEffect()
            .safeAreaInset(edge: .bottom) {
                RecipeNameAndDescription(recipe: recipe)
                    .foregroundStyle(.white)
                    .padding()
                    .background(
                        LinearGradient(
                            colors: [
                                .black.opacity(0.6),
                                .clear
                            ],
                            startPoint: .bottom,
                            endPoint: .top
                        )
                    )
            }
            .clipShape(
                RoundedRectangle(
                    cornerRadius: 26,
                    style: .continuous
                )
            )
        
            .frame(width: 400)
    }
}

This approach can work well in layouts where we layer text or controls over images, such as titles, labels, or playback indicators. The blurred extension softens the transition between the image and interface elements, helping the layout feel more unified and balanced. But as with any visual effect, it’s important to test that the content remains clear and legible across different images, themes, and contexts.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

When designing interfaces in SwiftUI, it’s often a good idea to wrap our app’s content in a scroll view, even if the content usually fits on screen. This helps ensure that users who enable larger text sizes in accessibility settings can still access all the content without layout issues, clipped views and truncated text. However, doing this introduces an unintended side effect. By default, ScrollView adds a bouncy scrolling behavior, even when the content fits entirely within the available space. This can make the interface feel oddly springy when no scrolling is actually needed.

To address this, we can use the scrollBounceBehavior(_:axes:) modifier introduced in iOS 16.4. When we apply this modifier to a ScrollView or to a view hierarchy that contains one, and pass the basedOnSize value, SwiftUI automatically disables bounce behavior when the content fits and enables it only when scrolling is actually required.

ScrollView {
    WalkDetailView()
}
.scrollBounceBehavior(.basedOnSize)

This small adjustment helps create a more polished experience, adapting gracefully to both default and accessibility text sizes.

A mesh gradient is a technique for rendering smooth, multi-directional color transitions across a surface using a structured network of control points. Unlike linear or radial gradients, which interpolate color along fixed axes, a mesh gradient defines colors at specific positions within a two-dimensional grid. These positions act as anchors, and the rendering engine computes smooth interpolations between them across the surface.

This makes mesh gradients particularly well-suited for complex, organic color transitions that cannot be achieved with simpler gradient types. They have been part of vector illustration tools for years and are now available in SwiftUI starting with iOS 18 and macOS 15, where they can be used for both static designs and animated effects.

# Defining a mesh gradient

To define a mesh gradient in SwiftUI, we can use the MeshGradient struct and choose one of its available initializers. We always have to provide the width and height of the mesh, which define how many points are arranged horizontally and vertically in the grid.

The simplest mesh gradient we can make is a 2×2 grid. This gives us four corner points, each with its own position and color, and defines a single patch, which is a rectangular area where SwiftUI blends the colors between the four corners.

MeshGradient(
    width: 2,
    height: 2,
    points: [
        [0, 0], [1, 0],
        [0, 1], [1, 1]
    ],
    colors: [
        .purple, .mint,
        .orange, .blue
    ]
)

Mesh points are expressed as SIMD2<Float>, but we can also use array literals to create each point, as in our example. The points array defines the position of each vertex in the mesh, laid out row by row. The colors array assigns a color to each point in the same order. SwiftUI takes care of interpolating the color transitions between these points to produce a smooth blend across the surface.

# Gradient geometry

The points we use to define a mesh gradient are in the coordinate space of the gradient view. A point like [0, 0] refers to the top-left corner, while [1, 1] refers to the bottom-right. If we want the gradient to fit exactly within its container, the outermost points in the mesh must span the full range from 0 to 1 along both axes. This means the top row of points should have a y-coordinate of 0, the bottom row a y-coordinate of 1, and the left and right columns x-coordinates of 0 and 1 respectively.

But we can also assign coordinates outside that range. For example, if we move the top-left point to [-0.4, -0.4] instead of [0, 0], the most intense purple color will begin outside the visible area, resulting in a more subtle appearance within the view.

MeshGradient(
    width: 2,
    height: 2,
    points: [
        [-0.4, -0.4], [1, 0],
        [0, 1], [1.0, 1.0]
    ],
    colors: [
        .purple, .mint,
        .orange, .blue
    ],
)

In contrast, if a point that lies along the outer edge of the mesh doesn’t reach the corresponding edge of the view, the gradient will stop short in that area. Setting the bottom-right point to [0.8, 0.9], for instance, leaves part of the view uncovered, since the mesh no longer fully reaches the bottom and trailing edges.

MeshGradient(
    width: 2,
    height: 2,
    points: [
        [0, 0], [1, 0],
        [0, 1], [0.8, 0.9]
    ],
    colors: [
        .purple, .mint,
        .orange, .blue
    ]
)

# Background fill

By default, the background of a mesh gradient is set to Color.clear. This means that any part of the view not covered by the mesh, such as areas where the points don’t extend all the way to the edges, will show whatever is behind the gradient. That might be the background of the containing view or the window itself if nothing else is drawn underneath. If we want to fill those uncovered areas with a specific color instead, we can pass a background parameter to the initializer.

MeshGradient(
    width: 2,
    height: 2,
    points: [
        [0, 0], [1, 0],
        [0, 1], [0.8, 0.9]
    ],
    colors: [
        .purple, .mint,
        .orange, .blue
    ],
    background: .indigo
)

# Color adjustments

Each color in the colors array we provide to the gradient initializer can be modified using any method on Color that returns a Color. For example, we can adjust the opacity of individual segments to create a more muted appearance.

MeshGradient(
    width: 2,
    height: 2,
    points: [
        [0, 0], [1, 0],
        [0, 1], [1.0, 1.0]
    ],
    colors: [
        .purple.opacity(0.6), .mint.opacity(0.7),
        .orange.opacity(0.5), .blue.opacity(0.8)
    ],
    background: .indigo
)
.background(.white)

In this case, the color passed in the background parameter of the initializer does not show through the semi-transparent colors. It only fills areas outside the bounds of the mesh if the points don’t fully span the view, as we saw earlier. The transparency of the colors themselves allows the view behind the gradient to show through, which in this example is the white background applied to the gradient view.

# Bezier points

While creating a mesh gradient from SIMD2<Float> points is the most straightforward approach, we can also declare it using MeshGradient.BezierPoint instead. This gives us more control over how the colors stretch and blend. Even if we stick to a simple 2×2 grid, we can shape the color transitions by adjusting the control points of each Bezier point. For example, we could make the orange color in the bottom-leading corner take up more space by positioning its top control point above the center of the mesh and its trailing control point farther toward the trailing edge.

MeshGradient(
    width: 2,
    height: 2,
    bezierPoints: [
        // Top-left: [0, 0]
        MeshGradient.BezierPoint(
            position: [0.0, 0.0],
            leadingControlPoint: [0.0, 0.0],
            topControlPoint: [0.0, 0.0],
            trailingControlPoint: [0.0, 0.0],
            bottomControlPoint: [0.0, 0.0]
        ),
        // Top-right: [1, 0]
        MeshGradient.BezierPoint(
            position: [1.0, 0.0],
            leadingControlPoint: [1.0, 0.0],
            topControlPoint: [1.0, 0.0],
            trailingControlPoint: [1.0, 0.0],
            bottomControlPoint: [1.0, 0.0]
        ),
        // Bottom-left: [0, 1]
        MeshGradient.BezierPoint(
            position: [0.0, 1.0],
            leadingControlPoint: [0.0, 1.0],
            topControlPoint: [0.0, 0.4],
            trailingControlPoint: [0.9, 1.0],
            bottomControlPoint: [0.0, 1.0],
        ),
        // Bottom-right: [1, 1]
        MeshGradient.BezierPoint(
            position: [1.0, 1.0],
            leadingControlPoint: [1.0, 1.0],
            topControlPoint: [1.0, 1.0],
            trailingControlPoint: [1.0, 1.0],
            bottomControlPoint: [1.0, 1.0]
        )
    ],
    colors: [
        .purple, .mint,
        .orange, .blue
    ]
)

# Advanced grids

Whether we are using SIMD2<Float> or BezierPoint to construct the grid, we can experiment by adding more points to create unique and expressive gradients. Below is an example of a 4×4 mesh that uses bright colors and an interesting distribution of points across the surface. The slight shifts in interior point positions introduce gentle curves and directionality.

MeshGradient(
    width: 4,
    height: 4,
    points: [
        [0.0, 0.0], [0.3, 0.0], [0.7, 0.0], [1.0, 0.0],
        [0.0, 0.3], [0.2, 0.4], [0.7, 0.2], [1.0, 0.3],
        [0.0, 0.7], [0.3, 0.8], [0.7, 0.6], [1.0, 0.7],
        [0.0, 1.0], [0.3, 1.0], [0.7, 1.0], [1.0, 1.0]
    ],
    colors: [
        .purple, .indigo, .purple, .yellow,
        .pink, .purple, .pink, .yellow,
        .orange, .pink, .yellow, .orange,
        .yellow, .orange, .pink, .purple
    ]
)

As we add more points, though, it becomes increasingly important to pay attention to how they are arranged. We should place the points in a consistent progression from lower to higher values, both across rows and down columns, for the automatic blending of colors to work correctly. Specifically, the x-values should increase from left to right within each row, and the y-values should increase from top to bottom within each column.

For instance, in the second row of our earlier example, the points were ordered as [0.0, 0.3], [0.3, 0.4], [0.7, 0.2], [1.0, 0.3]. If we swap the x-values of the two middle points so the row becomes [0.0, 0.3], [0.7, 0.4], [0.2, 0.2], [1.0, 0.3], the horizontal progression is no longer valid. As a result, the color blending breaks down. Instead of transitioning gradually, we'll get a clean-edged wave running through the middle. This might be the intended effect in some designs, but it's important to understand that point ordering affects how colors blend across the surface.

MeshGradient(
    width: 4,
    height: 4,
    points: [
        [0.0, 0.0], [0.3, 0.0], [0.7, 0.0], [1.0, 0.0],
        [0.0, 0.3], [0.7, 0.4], [0.2, 0.2], [1.0, 0.3],
        [0.0, 0.7], [0.3, 0.8], [0.7, 0.6], [1.0, 0.7],
        [0.0, 1.0], [0.3, 1.0], [0.7, 1.0], [1.0, 1.0]
    ],
    colors: [
        .purple, .indigo, .purple, .yellow,
        .pink, .purple, .pink, .yellow,
        .orange, .pink, .yellow, .orange,
        .yellow, .orange, .pink, .purple
    ]
)

# Animated gradients

If we want to take mesh gradient design even further, we can animate the positions of individual points. This creates a dynamic, flowing visual effect as the gradient continuously shifts and reshapes itself. Since the mesh is defined by precise point positions, even small changes can produce interesting motion and fluid transitions in how the colors blend.

In the example below, we use a TimelineView with the animation schedule to update the mesh over time. A sine and cosine wave are used to offset a few of the interior points, which results in a smooth oscillating effect across the gradient.

TimelineView(.animation) { context in
    let time = context.date.timeIntervalSince1970
    let offsetX = Float(sin(time)) * 0.1
    let offsetY = Float(cos(time)) * 0.1
    
    MeshGradient(
        width: 4,
        height: 4,
        points: [
            [0.0, 0.0],
            [0.3, 0.0],
            [0.7, 0.0],
            [1.0, 0.0],
            [0.0, 0.3],
            [0.2 + offsetX, 0.4 + offsetY],
            [0.7 + offsetX, 0.2 + offsetY],
            [1.0, 0.3],
            [0.0, 0.7],
            [0.3 + offsetX, 0.8],
            [0.7 + offsetX, 0.6],
            [1.0, 0.7],
            [0.0, 1.0],
            [0.3, 1.0],
            [0.7, 1.0],
            [1.0, 1.0]
        ],
        colors: [
            .purple, .indigo, .purple, .yellow,
            .pink, .purple, .pink, .yellow,
            .orange, .pink, .yellow, .orange,
            .yellow, .orange, .pink, .purple
        ]
    )
}

By animating only a few internal points and keeping the outer edges fixed, the gradient maintains its overall frame while producing natural movement within. This technique is especially effective for backgrounds, loading states, or interactive visualizations where a subtle sense of motion adds depth and interest.

Mesh gradients are an interesting component to explore. They can be used in a variety of ways, such as dynamic backgrounds, decorative fills for shapes, or to draw attention to specific elements like buttons. When used thoughtfully and in moderation, they can add visual variety without overwhelming the interface.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

I’ve just started a new "Nil Coalescing" YouTube channel, and in the first video I take a closer look at how we can use FormatStyle and Text.DateStyle directly inside SwiftUI Text views to format values inline using string interpolation. This approach allows us to display arrays of strings, measurements, dates and other types of data in a clean, declarative way without writing additional formatting code.

If you enjoy video content, make sure to check out the video on YouTube and subscribe to our channel.

▶️ Formatting Data inside SwiftUI Text Views

In this post, I’ll go through the same examples I cover in the video, with written explanations and code you can easily reference or copy as needed.

# Interpolation and formatting in Text

Text is one of my favorite components in SwiftUI. It looks simple at first, but it handles a significant amount of logic internally. It has some really useful capabilities that are not immediately obvious, and one of my favorites is the ability to format values directly inside string interpolation.

When we initialize a Text view from a string literal, SwiftUI treats it as a LocalizedStringKey. In addition to enabling automatic localization, LocalizedStringKey supports interpolation of values and lets us provide an optional format parameter, which is intended for formatting dates, numbers, measurements, and other types of data directly inside the text view.

let date = Date()
        
Text("Today's date is \(date, format: .dateTime.day().month()).")

# Formatting arrays of strings

When interpolating an array of strings inside a Text view, we can apply the list format style and specify the list type. SwiftUI will turn the array into a grammatically correct list and automatically include a conjunction — like "and" or "or" — based on the list type we choose.

let activities = ["hiking", "swimming", "cycling"]
           
// Weekend activities: hiking, swimming, and cycling
Text("Weekend activities: \(activities, format: .list(type: .and))")

The format including the conjunction, will be adapted to the user’s locale, so we don’t need to add any extra logic to display list data in a natural way.

let activités = ["randonnée", "natation", "vélo"]

// Activités du week-end: randonnée, natation et vélo
Text("Activités du week-end: \(activités, format: .list(type: .and))")
    .environment(\.locale, Locale(identifier: "fr"))

# Displaying measurements inline

Displaying measurements inline is another case where interpolation with format styles is especially useful. Instead of converting units ourselves or building strings manually, we can just interpolate a Measurement value and use the measurement format. SwiftUI will take care of converting and displaying measurements using the most appropriate unit.

We can set the value in whatever unit we prefer, like meters in our example, and SwiftUI will automatically display it in miles for users in the US, or kilometers for users in New Zealand, without any extra logic on our part.

let distance = Measurement(value: 3200, unit: UnitLength.meters)

// You walked 2 mi.
Text("You walked \(distance, format: .measurement(width: .abbreviated)).")
    .environment(\.locale, Locale(identifier: "en_US"))

// You walked 3.2 km.
Text("You walked \(distance, format: .measurement(width: .abbreviated)).")
    .environment(\.locale, Locale(identifier: "en_NZ"))

We can also control how the unit is shown - with a short abbreviation, or a full name. It keeps the code clean, and the result is always localized and consistent.

# Formatting dates

Dates can be formatted in two different ways. To show a static date, like the time of an event, the format parameter can be used just like with arrays and measurements.

let eventDate = Calendar.current.date(
    from: DateComponents(year: 2025, month: 5, day: 5, hour: 13)
)!

// Event time: 1:00 PM
Text("Event time: \(eventDate, format: .dateTime.hour().minute())")

But if we want to display dynamic information, like the time left until the event, we can use the style parameter instead. Applying styles like relative, offset and timer, will result in an autoupdating date without any additional code.

Text("\(eventDate, style: .relative) left until the event")
    .monospacedDigit()

The relative style, that we are using in our example, displays the date as relative to now, and the Text view automatically refreshes. When displaying dynamic times like this it’s also a good idea to apply the monospacedDigit() modifier to the Text. It makes sure that all numeric characters take up the same width, so the UI doesn’t jitter as the value changes.

These are just a few examples of how we can format data directly inside a Text view using interpolation. It keeps the code simple, handles localization automatically, and works great for displaying structured or time-sensitive information without much effort.

If you’re interested in learning more about how Text and other core components work in SwiftUI, and how to use the framework effectively in your projects, check out my book SwiftUI Fundamentals. It combines what I’ve learned from using SwiftUI since its release and working on its source code at Apple, to give you a solid understanding of the most important aspects of the framework.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

When working with functions or initializers that take many parameters, especially when some values are closures or long arrays, the code can become difficult to scan and maintain. Xcode includes a useful keyboard shortcut for improving the readability of these calls.

To reformat them quickly, place the cursor inside the parentheses and press Control (⌃) + M. Xcode will automatically place each parameter on its own line.

If the entire expression is selected before using the shortcut, Xcode will also format the values, making closures and collections easier to read at a glance.

We commonly use Apple system fonts in our apps, but sometimes we may need something custom for company branding or a specific design. For example, in my macOS word game LexiMorph, I needed a cleanly outlined typeface for the glowing base word, and the default system font didn’t work for what I had in mind.

To use a custom font in our UI, we need to embed it directly into the app bundle so we are not relying on that particular typeface being installed on the user's machine. This involves copying the font file into the project in Xcode, making sure it’s included in the built product, and then referencing it in code when styling our text.

The process of embedding a custom font in a macOS app is a little different from how things work on iOS, and it’s not particularly well documented. I decided to write up the exact steps that worked for me, both as a reference for myself and in case it helps other developers trying to add custom fonts to their Mac apps.

# Add custom font file to Xcode project

Imagine we want to embed a Google font named "Indie Flower" and use it in our app. We’ll download the font file and the accompanying license from Google Fonts, then drag both into our Xcode project and place them in a folder named "Fonts".

Notice that we’ll leave their target membership unchecked, as we’ll be adding them to the build using a separate copy step.

# Copy font files to application resources

To make sure the custom font is loaded and accessible to our code, we need to copy it into the Resources folder of the app bundle. To do that, we’ll define a custom Copy Files build phase with the destination set to Resources and the subpath set to Fonts. Then we’ll add the font files from the "Fonts" folder in Xcode to that phase.

# Provide font path in Info.plist

The final step is to tell the system where to find the font. We do this by adding the ATSApplicationFontsPath key to the Info.plist file and setting its value to the path of the font files relative to the Resources folder. In our case, the value will simply be Fonts.

# Load custom font and apply it to text

At this point, the font is embedded in the app bundle and registered with the system, so we can start using it in code. The way we reference it is by name, the same name that’s defined inside the font file itself, not necessarily the file name.

To load the custom font in AppKit, we can use the NSFont(name:size:) initializer:

let font = NSFont(name: "IndieFlower", size: 28)!

In SwiftUI, we can initialize a custom font using the Font.custom(_:size:) method and apply it to a Text view using the font(_:) modifier:

Text("Hello, world!")
    .font(.custom("IndieFlower", size: 28))

If you're using SwiftUI in your projects and want to get a more thorough grasp of the framework, my new book SwiftUI Fundamentals takes an in-depth look at the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

Mac apps typically include an About window that displays basic app information such as the version number and other details. Every macOS app project comes with a default About window accessible from the main app menu. This built-in panel shows the app icon, name, version, and build number.

Back in 2020, I wrote a post about how we can enhance this default panel using a mix of SwiftUI and AppKit APIs, along with credits files and Info.plist entries — Customize About panel on macOS. But starting with macOS 13, thanks to the introduction of the Window scene and the openWindow environment value, we can now create and present a fully custom About window using just standard SwiftUI APIs.

# Define a custom About window view

We can define the layout of the About window using SwiftUI, just like we would for any other window in the app. This gives us full control over the appearance and content, so we can make the About window match our app’s style and include whatever information we want.

struct AboutView: View {
    private var appVersionAndBuild: String {
        let version = Bundle.main
            .infoDictionary?["CFBundleShortVersionString"] as? String ?? "N/A"
        let build = Bundle.main
            .infoDictionary?["CFBundleVersion"] as? String ?? "N/A"
        return "Version \(version) (\(build))"
    }
    
    private var copyright: String {
        let calendar = Calendar.current
        let year = calendar.component(.year, from: Date())
        return "© \(year) Nil Coalescing Limited"
    }
    
    private var developerWebsite: URL {
        URL(string: "https://nilcoalescing.com/")!
    }
    
    var body: some View {
        VStack(spacing: 14) {
            Image(.mainIcon)
                .resizable().scaledToFit()
                .frame(width: 80)
            Text("PhotoTune")
                .font(.title)
            VStack(spacing: 6) {
                Text(appVersionAndBuild)
                Text(copyright)
            }
            .font(.callout)
            Link(
                "Developer Website",
                destination: developerWebsite
            )
            .foregroundStyle(.accent)
        }
        .padding()
        .frame(minWidth: 400, minHeight: 260)
    }
}

We are free to lay this out however we like, and include any details we find useful, such as version and build number, copyright, or a link to the developer’s website.

# Present the custom About window

To present our custom AboutView in place of the default About panel, we first need to wrap it in a Window scene. This is the right scene type to use because it creates a unique window, unlike WindowGroup, which allows users to open multiple instances of the same window template.

Once the scene is defined, we can replace the default About button in the app menu with a custom one. We'll do this by overriding the appInfo command placement with a new CommandGroup. Inside the custom button, we'll call the openWindow action from the environment to present our window.

@main
struct PhotoTuneApp: App {
    @Environment(\.openWindow) private var openWindow
    
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .commands {
            CommandGroup(replacing: CommandGroupPlacement.appInfo) {
                Button {
                    openWindow(id: "about")
                } label: {
                    Text("About PhotoTune")
                }
            }
        }
        
        Window("About PhotoTune", id: "about") {
            AboutView()
        }
    }
}

Now, when selecting "About PhotoTune" from the app menu, our custom AboutView will be presented in a standalone window.

# Fine-tune window appearance and behavior

By presenting a custom window with the Window scene, we gain full control over not just the content of the About window, but also its appearance and behavior. This includes styling the background, adjusting window chrome, modifying drag and resize options, and more.

Let’s look at a few examples of what we can do, but note that while the Window scene and openWindow environment value have been available since macOS 13, many of the APIs for customizing window appearance and behavior, such as containerBackground(), windowBackgroundDragBehavior(), windowMinimizeBehavior(), and others, were introduced in later versions, so these features will require a newer deployment target.

One example is applying a translucent material background to the window and removing the title and toolbar, allowing the material effect to extend all the way to the top. When doing this, it’s a good idea to let users drag the window by its background area, which we can enable using the windowBackgroundDragBehavior() scene modifier.

Window("About PhotoTune", id: "about") {
    AboutView()
        .containerBackground(.regularMaterial, for: .window)
        .toolbar(removing: .title)
        .toolbarBackground(.hidden, for: .windowToolbar)
}
.windowBackgroundDragBehavior(.enabled)

Another example is controlling how the window can be resized. Since the contents of our AboutView are static, we may want to prevent resizing altogether. We can do that by applying windowResizability(.contentSize) to the window.

We can also customize the window controls in the top-left corner. Because our window isn’t resizable, the green zoom control is already disabled by default, but we can additionally disable the yellow minimize control. This control isn't needed here, since the About window only shows static content and can always be reopened from the app menu.

Window("About PhotoTune", id: "about") {
    AboutView()
        .toolbar(removing: .title)
        .toolbarBackground(.hidden, for: .windowToolbar)
        .containerBackground(.regularMaterial, for: .window)
        .windowMinimizeBehavior(.disabled)
}
.windowBackgroundDragBehavior(.enabled)
.windowResizability(.contentSize)

By default, windows in SwiftUI support state restoration, they remember whether they were open when the app last quit and reopen automatically. This behavior isn’t necessary for an About window, so we can turn it off using the restorationBehavior() modifier.

Window("About PhotoTune", id: "about") {
    ...
}
.windowBackgroundDragBehavior(.enabled)
.windowResizability(.contentSize)
.restorationBehavior(.disabled)

Creating a fully custom About window in SwiftUI gives us the flexibility to match the design and behavior of the rest of the app, while still integrating cleanly with macOS conventions. With just a few modifiers, we can control layout, appearance, and window behavior — all using familiar SwiftUI tools.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

When an image is loaded by name using the Image(_:) initializer in SwiftUI, VoiceOver uses the image name itself as the default accessibility label.

For example, if we have a custom image in the asset catalog named person.bicycle, VoiceOver will read "person bicycle" unless a custom label is explicitly provided.

// VoiceOver reads "person bicycle" by default
Image("person.bicycle")

However, if a localized string is defined for the image name, either in a Localizable.strings file or a string catalog, SwiftUI will automatically use the localized value as the accessibility label, without requiring the accessibilityLabel() modifier.

In our example, using "person.bicycle" = "Person on a bicycle" for the English localization causes VoiceOver to read "Person on a bicycle" when the image is focused, with no additional code changes needed.

SwiftUI provides several ways to change the color of text, including the foregroundStyle(_:) modifier, the older (now deprecated) foregroundColor(_), AttributedString attributes, the tint(_:) modifier, and, for advanced use cases, the textRenderer(_:) modifier. While some of these can produce similar visual results, they differ in behavior, styling capabilities, and how they interact with system themes and view hierarchies. In this post, we’ll look at common use cases and consider which approach works best in each context.

# Foreground style

In earlier versions of SwiftUI, foregroundColor(_:) was the standard way to set a custom color for text in SwiftUI. It accepted a Color and applied it in the environment, affecting text and other foreground elements within the view hierarchy. This modifier is now deprecated, and the recommended approach is to use foregroundStyle(_:) instead.

Introduced in iOS 15, foregroundStyle(_:) has since become the preferred way to control foreground appearance. It works with any value that conforms to ShapeStyle, which makes it more versatile than foregroundColor(_:).

In its simplest form, foregroundStyle(_:) can be used to apply a solid color to all foreground elements within a view hierarchy:

VStack {
    Image(systemName: "globe")
    Text("Hello, world!")
}
.foregroundStyle(.cyan)

Unlike foregroundColor(_:), the foregroundStyle(_:) modifier supports more advanced styling. For example, it allows applying gradients:

VStack {
    Image(systemName: "globe")
    Text("Hello, world!")
}
.foregroundStyle(
    LinearGradient(
        colors: [.mint, .blue],
        startPoint: .leading,
        endPoint: .trailing
    )
)

The modifier also supports hierarchical styling. We can use levels like primary, secondary, tertiary, and quaternary to control how elements are rendered in the current foreground style:

VStack {
    Image(systemName: "globe")
    Text("Hello, world!")
        .foregroundStyle(.secondary)
}
.foregroundStyle(.green)

In this example, the base style is green. The image uses the default primary level, while the text uses secondary. Both share the same base style but differ in intensity.

Starting with iOS 17, foregroundStyle(_:) can be used to style individual fragments of text inside a larger string. When applied directly to a Text instance, the modifier returns a Text instead of some View, which allows us to use it inside text interpolation:

Text("Hello, \(Text("world").foregroundStyle(.mint))!")

# Foreground color attribute in an AttributedString

Another way to customize text color in SwiftUI is by using AttributedString. This API offers a modern, strictly typed approach to styling specific portions of text, and it works well when we want to apply styles dynamically based on the content.

For example, we can search for a substring, set its foreground color, and pass the resulting attributed string to a Text view:

struct MessageView: View {
    var attrString: AttributedString {
        var attrString = AttributedString("Don't miss the event today!")
        
        if let range = attrString.range(of: "today") {
            attrString[range].foregroundColor = .yellow
        }
        
        return attrString
    }
    
    var body: some View {
        Text(attrString)
    }
}

This gives us full control over which parts of the text are styled, and can be especially useful when the text content isn’t known ahead of time. However, the foreground color attribute only supports solid colors. We can’t use gradients or hierarchical styles like secondary when styling text via AttributedString.

# Tint

The tint(_:) modifier was introduced in iOS 16. Its purpose is to override the accent color for a view rather than to set the color of all foreground elements. When applied to a view hierarchy, tint(_:) affects the color of text inside controls such as buttons and links, but it doesn't change the color of plain Text views.

VStack {
    Text("Welcome!")
    Button("Log in") {
        // perform login
    }
}
.tint(.teal)

The tint(_:) modifier can also be used to change the color of links embedded inside Text views, whether they're defined using Markdown or an AttributedString. In this case, the modifier only affects the portion of text with the link attribute and leaves the rest of the string unchanged.

Text("Visit our [website](https://example.com).")
    .tint(.cyan)

# Text renderer

If we need more advanced control over how text is colored, SwiftUI offers the textRenderer(_:) modifier, introduced in iOS 18. This modifier lets us replace the system’s default text rendering with a fully custom renderer that conforms to the TextRenderer protocol.

This is a lower-level API intended for advanced visual effects and animations, but it can also be used when we want to apply complex coloring that isn't possible or is difficult to achieve with modifiers like foregroundStyle(_:).

For example, we can use hue rotation to apply a varying color across glyphs:

struct HueRotationRenderer: TextRenderer {
    func draw(layout: Text.Layout, in context: inout GraphicsContext) {
        for line in layout {
            for run in line {
                let glyphCount = run.count
                for (index, glyph) in run.enumerated() {
                    var glyphContext = context
                    let hueAngle = (Double(index) / Double(glyphCount)) * 360.0
                    glyphContext.addFilter(.hueRotation(.degrees(hueAngle)))
                    glyphContext.draw(glyph)
                }
            }
        }
    }
}

struct ContentView: View {
    var body: some View {
        Text("Hello, world!")
            .foregroundStyle(.blue)
            .textRenderer(HueRotationRenderer())
    }
}

This approach gives us full flexibility in how we draw each glyph. While it’s not necessary for most text styling needs, it opens the door to rich, animated, or highly customized effects when needed.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

I’m excited to share that my book Swift Gems has just received a major update, bringing a fresh collection of practical tips and techniques for writing better Swift code. The new edition includes insights from the latest language advancements in Swift 6.0 and 6.1, as well as new examples and refinements based on features introduced in earlier versions of Swift.

This book is designed for experienced Swift developers looking to sharpen their skills and make the most of what the language has to offer. From working with optionals and generics to mastering async programming and improving collection performance, each tip is focused, actionable, and grounded in real-world usage.

The latest update introduces new techniques for working with noncopyable types, static dispatch, metatype key paths, and more. You’ll also find new content on using AsyncStream and TaskGroup, enhancing error handling with typed throws, and structuring your code for better runtime performance and clarity.

This update also refreshes existing tips with updated examples.

If you already own a copy of Swift Gems, you can now read the updated version online or download it from the book page. You can also view the release notes for a detailed list of what’s new and changed.

If you haven’t picked up a copy yet, this is a great time to dive in. The book continues to grow with new tips as Swift evolves, and all future updates are included with your purchase.

SwiftUI allows us to combine multiple Text views into a single view using the plus (+) operator. This enables us to apply different styles to individual parts of the text.

Here's a simple example that colors the word "spicy" in red:

Text("Tortilla chips with ") +
Text("spicy 🌶️🌶️🌶️").foregroundStyle(.red) +
Text(" dip")

I often see developers using this technique, but it's important to understand its limitations, especially regarding localization.

When we concatenate text like in the example above, each segment will be extracted and translated separately. Here's how it might look in a String Catalog file for French:

Firstly, some segments have trailing and preceding spaces, which can be quite difficult to spot. Translators must carefully preserve these spaces to ensure that when the translated segments are combined, words still have spaces between them. But there's also a larger issue: concatenation doesn't allow translators to reorder the segments for languages with different grammatical structures. For example, in French, adjectives usually follow the noun, unlike English. The correct translation would be "Chips tortilla avec sauce épicée 🌶️🌶️🌶️", but with simple concatenation, the app would incorrectly display "Chips tortilla avec épicée 🌶️🌶️🌶️ sauce", reflecting a direct translation from English that sounds unnatural.

To handle localization properly, we should use text interpolation rather than concatenation. Text interpolation lets us insert variables directly inside a single localizable string, even if these variables are styled Text views. This means we can apply text modifiers exactly like we do with concatenated segments.

Here's how the previous example looks using interpolation:

Text("Tortilla chips with \(Text("spicy 🌶️🌶️🌶️").foregroundStyle(.red)) dip")

Visually, this renders exactly the same in English:

However, the extracted localizable strings in the String Catalog will be very different. While the styled segment is still extracted separately, the main localized string includes a format specifier, allowing translators to reposition the interpolated segment freely within the sentence structure. Additionally, translators no longer need to manage leading and trailing spaces for segments manually.

Now, when the app runs in French, SwiftUI correctly inserts the styled adjective into the appropriate place:

In summary, while text concatenation works well for simple styling scenarios, it's best practice to always prefer interpolation for localized text to ensure grammatically correct and natural translations. In real projects, it's also recommended to include comments, especially for strings with format specifiers, so translators understand what each placeholder represents.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

Method dispatch refers to the process of determining which method implementation to execute when a method is called. In Swift, this can be either dynamic or static, each with distinct implications for performance and flexibility.

Dynamic dispatch is resolved at runtime based on the actual type of the object, enabling features like polymorphism but introducing runtime overhead due to method lookup. At a low level, this is implemented using virtual tables (V-Tables) for classes, which store pointers to method implementations. When a method is called through a base class reference, the V-Table of the actual instance type is used to determine the correct implementation at runtime. For protocols, Swift uses witness tables, which map protocol requirements to the implementations provided by conforming types. When a method is called through a protocol-typed value, the witness table for the underlying type is used to locate and invoke the appropriate implementation.

Static dispatch, on the other hand, is resolved at compile time based on the declared type of the variable. This allows the compiler to determine exactly which method to call before the program runs, avoiding the overhead of runtime lookup. At a low level, static dispatch, used by value types (structs and enums) and in non-overridable contexts like final classes, involves direct addressing: the compiler embeds the method’s memory address directly into the compiled code. Since there are no inheritance hierarchies in value types and no overriding in final classes, the call target is guaranteed to be fixed. This enables further optimizations such as inlining, where the method call is replaced with its body for improved performance.

# Dynamic dispatch: cases and examples

In Swift, only specific types of method calls use dynamic dispatch, such as those involving overridable class methods, protocol requirements, and Objective-C or virtual C++ methods. These scenarios leverage runtime resolution to provide the flexibility needed for dynamic behavior.

# Overridable class methods

Methods in classes not marked as final can be overridden by subclasses, enabling polymorphic behavior where different types respond uniquely to the same method call. When such a method is called through a base class reference, dynamic dispatch resolves the call at runtime based on the actual object type, using the virtual table of the instance to locate the correct implementation.

class Vehicle {
    func startEngine() {
        print("Vehicle engine initiated")
    }
}

class Car: Vehicle {
    override func startEngine() {
        print("Car engine initiated")
    }
}

class Truck: Vehicle {
    override func startEngine() {
        print("Truck engine initiated")
    }
}

let vehicles: [Vehicle] = [Car(), Truck()]

for vehicle in vehicles {
    // Dynamic dispatch via V-Table at runtime
    vehicle.startEngine()
}

In this example, the vehicles array contains a Car and a Truck, both referenced as Vehicle. Iterating over the array and calling startEngine() on each triggers dynamic dispatch: the V-Table for each instance is consulted at runtime, ensuring Car’s startEngine() prints "Car engine initiated" and Truck’s prints "Truck engine initiated," despite the reference type being Vehicle.

# Protocol requirements

Methods declared in a protocol’s main body are requirements that must be implemented by any conforming type, enabling polymorphic behavior across different implementations. When called through a value of the protocol type, these methods use dynamic dispatch, relying on a witness table to map each requirement to the correct implementation. This runtime resolution is necessary because the concrete type is not known until runtime when the protocol type is used as an abstraction.

protocol Drivable {
    func drive()
}

struct Truck: Drivable {
    func drive() {
        print("Truck drive initiated")
    }
}

struct Car: Drivable {
    func drive() {
        print("Car drive initiated")
    }
}

let drivables: [Drivable] = [Truck(), Car()]

for drivable in drivables {
    // Dynamic dispatch via witness table
    drivable.drive()
}

In this scenario, each call to drivable.drive() uses dynamic dispatch to invoke the correct implementation based on the underlying type, either Truck or Car. At runtime, Swift consults the witness table for each instance to resolve the method, ensuring the appropriate implementation is executed for the actual type.

# Objective-C or virtual C++ methods

When interacting with methods from Objective-C or C++ that inherently use dynamic dispatch, such as Objective-C message passing or virtual C++ methods, Swift adopts dynamic dispatch to handle these calls appropriately, ensuring compatibility with these languages’ runtime systems.

@objc protocol LegacyVehicleProtocol {
    func logMaintenance()
}
class LegacyVehicleSystem: NSObject, LegacyVehicleProtocol {
    @objc func logMaintenance() {
        print("Logging maintenance for vehicle in legacy system")
    }
}
let legacySystem: LegacyVehicleProtocol = LegacyVehicleSystem()

// Dynamic dispatch via Objective-C message passing
legacySystem.logMaintenance()

In this case, legacySystem.logMaintenance() is dispatched dynamically using Objective-C’s message passing system, which resolves the method at runtime.

# Static dispatch: cases and examples

Static method dispatch in Swift is used for all cases not listed in the dynamic dispatch section, for example with value types, final classes, private methods, and non-requirement methods in protocol extensions. These scenarios leverage compile-time resolution to ensure efficient execution without runtime overhead.

# Methods on value types

Since value types like structs and enums cannot be subclassed, their methods are always statically dispatched based on their known types at compile-time, eliminating the need for runtime lookups due to the absence of inheritance hierarchies.

struct VehicleRecord {
    let id: Int
    let mileage: Double
    
    func calculateFuelEfficiency() -> Double {
        // Simplified calculation
        return mileage / 30.0
    }
}

let record = VehicleRecord(id: 101, mileage: 300.0)

// Static dispatch - method resolved at compile time
print(record.calculateFuelEfficiency())

Here, record.calculateFuelEfficiency() employs static dispatch to call VehicleRecord’s implementation. Since VehicleRecord is a struct, its type is known at compile-time, allowing the compiler to directly embed the method’s address into the compiled code for efficient execution.

# Final classes and methods

Marking a class or method as final prevents overriding, ensuring that method calls are statically dispatched since the compiler can guarantee no subclass will provide a different implementation, eliminating the need for runtime resolution.

final class ElectricCar {
    let batteryLevel: Double
    
    init(batteryLevel: Double) {
        self.batteryLevel = batteryLevel
    }
    
    func checkBattery() {
        print("Battery level is \(batteryLevel)%")
    }
}

let electricCar = ElectricCar(batteryLevel: 85.0)

// Static dispatch - final class prevents overriding
electricCar.checkBattery()

With this setup, electricCar.checkBattery() uses static dispatch to call ElectricCar’s implementation. Since ElectricCar is marked as final, the compiler knows no subclass can override checkBattery(), allowing it to resolve the call at compile-time and embed the method’s address directly into the compiled code.

# Private class declarations

Applying the private or fileprivate keywords to a declaration restricts its visibility to the scope or file in which it is defined. This allows the compiler to determine all other potentially overriding declarations. In the absence of such declarations within the file, the compiler can treat method calls as non-overridable and eliminate indirect dispatch.

private class VehicleManager {
    private var vehicleCount = 0
    
    func addVehicle() {
        vehicleCount += 1
    }
}

private let manager = VehicleManager()

// Static dispatch - no visible subclass in file
manager.addVehicle()

Since VehicleManager is a private class and no subclass is declared in the same file, the compiler can guarantee that addVehicle() is not overridden. As a result, the call to addVehicle() can be devirtualized and replaced with a direct call, avoiding the overhead of dynamic dispatch.

# Protocol extension methods (non-requirements)

Methods defined only in protocol extensions and not declared as requirements are always resolved using static dispatch. Even if a conforming type provides its own implementation, calling these methods through a value of the protocol type will consistently use the version from the extension, as they do not participate in dynamic dispatch through the witness table.

protocol Vehicle {
    func startEngine()
}

extension Vehicle {
    func stopEngine() {
        print("Vehicle engine stopped")
    }
}

struct Sedan: Vehicle {
    func startEngine() {
        print("Sedan engine started")
    }
    
    func stopEngine() {
        print("Sedan engine stopped")
    }
}

struct Van: Vehicle {
    func startEngine() {
        print("Van engine started")
    }
}

let vehicles: [Vehicle] = [Sedan(), Van()]

for vehicle in vehicles {
    // Dynamic dispatch via witness table
    vehicle.startEngine()
    
    // Static dispatch to protocol extension
    vehicle.stopEngine()
}

Here, the vehicles array contains a Sedan and a Van, both conforming to Vehicle. Iterating over the array, each vehicle.startEngine() call uses dynamic dispatch to invoke the type’s specific implementation, while each vehicle.stopEngine() call uses static dispatch to the extension’s implementation, printing "Vehicle engine stopped" in both cases, even though Sedan defines its own version.

# Performance considerations

The performance differences between static and dynamic dispatch aren't always obvious, but understanding how these mechanisms work helps us make targeted optimizations when needed. To encourage static dispatch and reduce runtime overhead, we can mark classes as final when inheritance isn’t required. This allows the compiler to safely resolve method calls at compile time without relying on V-Table lookups. Similarly, declaring a class as private or fileprivate limits its visibility to the current file, giving the compiler full knowledge of any subclassing or overriding that may occur. If no subclass is present in the file, the compiler can treat method calls as non-overridable and emit direct calls, avoiding dynamic dispatch.

Enabling Whole Module Optimization (WMO) may improve performance further. By analyzing the entire module as a unit, the compiler can replace dynamic dispatch with static calls for internal declarations that aren't overridden elsewhere, eliminating unnecessary indirection.

When working with protocols, we can reduce dynamic dispatch by limiting method requirements to those essential for conformance-based polymorphism. Methods declared in the protocol body become requirements and are dispatched via witness tables at runtime, enabling dynamic behavior across conforming types. In contrast, methods defined only in protocol extensions are not included in the witness table and are resolved through static dispatch at compile-time, resulting in more efficient calls.

In performance-sensitive code, it also helps to avoid unnecessary Objective-C interoperability, as its message-passing system is slower than Swift’s native dispatch model.

Finally, profiling with Instruments can reveal dispatch-related overhead, helping us focus our optimization efforts where they have the most impact.

If you're an experienced Swift developer looking to level up your skills, take a look at my book Swift Gems. It offers 100+ advanced Swift tips, from optimizing collections and leveraging generics, to async patterns, powerful debugging techniques, and more - each designed to make your code clearer, faster, and easier to maintain.

Dynamic Type allows users to adjust text size across the system, improving readability and accessibility. When we use built-in fonts in SwiftUI, text scales automatically to match the user’s preferred size. However, text is only part of the interface. Other elements, such as images and symbols, also need to adapt to maintain a balanced layout.

In this post, we'll look at how to handle images in a Dynamic Type environment, covering both SF Symbols and custom images. We'll explore techniques to ensure meaningful icons remain clear at larger text sizes, scale custom images appropriately, and exclude decorative images when necessary to optimize space.

# Using SF Symbols with Dynamic Type

If we use icons to communicate important information, they need to stay clear and legible at larger font sizes. SF Symbols make this easy by scaling automatically with Dynamic Type, ensuring they adjust as text size changes.

These symbols integrate with the San Francisco system font, aligning naturally with different weights and sizes. They work well for conveying concepts or representing objects, especially alongside text.

Even though SF Symbols are placed inside an Image view, they behave more like text. They inherit font attributes from the environment to match surrounding content.

VStack {
    Image(systemName: "cloud.sun")
    Text("Partly Cloudy")
}
.font(.title)

An important detail to keep in mind is that it's generally not recommended to use the resizable() modifier with SF Symbols. Applying resizable() to a symbol causes it to lose its symbol properties, meaning it will be treated more like a regular image. This prevents it from scaling automatically with Dynamic Type.

VStack {
    Image(systemName: "cloud.sun")
        .resizable()
        .scaledToFit()
        .frame(height: 28)
    Text("Partly Cloudy")
}
.font(.title)

There may be cases where converting a symbol into an image and manually scaling it, as we would with custom images, is appropriate. However, in most situations, it's best to use SF Symbols as intended to ensure they remain consistent with surrounding text and provide the best user experience.

# Scaling custom images

Custom images from an asset catalog don't automatically resize with text. If an image is not purely decorative but conveys meaning, we should manually ensure it scales appropriately when the user adjusts their preferred font size.

SwiftUI provides the ScaledMetric API to make this easier to handle. Instead of defining multiple sizes for an image, we can specify a base value and store it in a property annotated with the @ScaledMetric property wrapper. By default, ScaledMetric adjusts relative to the body text style, but we can customize it to match a different text style.

In the example below, the image height will scale relative to the title font size.

struct ContentView: View {
    @ScaledMetric(relativeTo: .title)
    private var imageHeight = 28
    
    var body: some View {
        VStack {
            Image(.partlyCloudy)
                .resizable()
                .scaledToFit()
                .frame(height: imageHeight)
            Text("Partly Cloudy")
        }
        .font(.title)
    }
}

When designing with scaled metrics, it's important to start with a size that works well for the default Dynamic Type setting and ensure that images have a high enough resolution to scale up without losing quality.

# Handling decorative images

Decorative images that don't convey important meaning shouldn't be scaled, as they can take up valuable screen space that could be used for more important content. In some cases, it may even be best to remove decorative images altogether at larger text sizes.

We can determine the current Dynamic Type size by reading the dynamicTypeSize environment value. In the example below, the image remains visible for standard text sizes but is removed entirely when an accessibility text size is enabled, ensuring that text has as much space as possible.

struct ContentView: View {
    @Environment(\.dynamicTypeSize)
    private var typeSize
    
    var body: some View {
        VStack {
            if !typeSize.isAccessibilitySize {
                Image(decorative: "forecast")
            }
            Text("Weather Forecast")
        }
        .font(.title)
    }
}

Adapting images and symbols to Dynamic Type ensures that interfaces remain clear, accessible, and visually balanced across different text sizes. By making thoughtful adjustments to how images scale, or whether they appear at all, we can create layouts that adapt seamlessly to user preferences while maintaining clarity and usability.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

SwiftUI environment provides a way to pass values through the view hierarchy without manually forwarding them. While SwiftUI includes built-in environment values for system settings, we can also define custom environment values to share app-specific data. This allows us to store and propagate values such as user preferences, feature flags, or custom styling configurations in a structured and reusable way.

To use a custom environment value, we need to define it, provide a default value, and inject it into the environment so that any child view can access it.

# Defining custom environment values before Xcode 16

Before Xcode 16, defining a custom environment value required writing a fair amount of boilerplate. We had to create a key conforming to EnvironmentKey, provide a default value, and extend EnvironmentValues to add a computed property for accessing and modifying the value.

For example, to define a custom environment value for storing a user's preferred color, we had to write the following code:

private struct FavoriteColorKey: EnvironmentKey {
    static let defaultValue: Color = .blue
}

extension EnvironmentValues {
    var favoriteColor: Color {
        get { self[FavoriteColorKey.self] }
        set { self[FavoriteColorKey.self] = newValue }
    }
}

This setup allowed us to store and retrieve the value through the environment, but it required multiple declarations for a single property.

# Defining custom environment values with the @Entry macro

With the introduction of the @Entry macro in Xcode 16, manually defining environment keys is no longer necessary. Now, we can declare an environment value directly inside the EnvironmentValues struct and assign it a default value at the same time.

extension EnvironmentValues {
    @Entry var favoriteColor: Color = .blue
}

The @Entry macro automatically generates the necessary environment key and computed property, eliminating the need for additional boilerplate. If you're curious, you can expand the macro by right-clicking on @Entry in Xcode and selecting "Expand Macro" to view the generated code.

Even though the @Entry macro is new in Xcode 16, it works with older iOS and macOS versions as long as the app is built with Xcode 16. This means we can use it while supporting iOS 13 and later, as well as macOS 10.15 and later. There’s no need to drop compatibility with older systems to take advantage of this improved syntax.

# Setting and reading custom environment values

To pass a value into the environment, we can use the environment(_:_:) modifier, which sets the environment value for a specific key path.

For built-in values, SwiftUI provides dedicated view modifiers that encapsulate this logic, and the same approach is recommended when defining custom values. To achieve this, we can extend View and create a method that writes the value to the environment.

extension View {
    func favoriteColor(_ color: Color) -> some View {
        environment(\.favoriteColor, color)
    }
}

By defining a dedicated modifier, we make setting the value more intuitive and consistent with SwiftUI’s built-in environment APIs.

In the following example, we let the user select their favorite color using a ColorPicker. The selected color is then stored in a @State property and injected into the environment using our custom favoriteColor(_:) modifier, making it available to all child views.

struct ContentView: View {
    @State private var favoriteColor: Color = .blue
    
    var body: some View {
        NavigationStack {
            TodoList()
                .toolbar {
                    ColorPicker(
                        "Favorite color",
                        selection: $favoriteColor
                    )
                    .labelsHidden()
                }
        }
        .favoriteColor(favoriteColor)
    }
}

Once the value is set in the environment, any child view, no matter how deeply nested, can read it using the @Environment property wrapper.

For example, suppose we have a TaskCheckmark view that displays a checkmark icon next to a completed task in the TodoList. Instead of passing the color manually from ContentView through TodoList and its subviews, TaskCheckmark can directly retrieve favoriteColor from the environment and apply it to the checkmark’s foreground style.

struct TaskCheckmark: View {
    @Environment(\.favoriteColor)
    private var favoriteColor
    
    var body: some View {
        Image(systemName: "checkmark")
            .foregroundStyle(favoriteColor)
    }
}

Because SwiftUI’s environment propagates changes, any updates to favoriteColor in ContentView will instantly reflect in all views that use it. If the user selects a new color, the checkmark (and any other dependent views) will update automatically without requiring any additional code.

You can find the sample code for this post on GitHub.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

SwiftUI provides built-in modifiers to customize the background appearance of modal presentations. These modifiers allow us to apply a solid color, a gradient, a translucent material, or even a custom view as the background of sheets, popovers, and full-screen covers.

# Setting a background style

The presentationBackground(_:) modifier lets us define a background for a modal presentation using any ShapeStyle. This includes colors, gradients, and materials.

For example, we can make a sheet’s background translucent by applying a thin material:

.sheet(isPresented: $showSheet) {
    Text("Sheet content...")
        .presentationBackground(.thinMaterial)
}

This gives the sheet a frosted glass effect, allowing the content behind it to subtly show through, as seen in the screenshot below.

# Using a custom background view

For more flexibility, SwiftUI provides the presentationBackground(alignment:content:) modifier, which allows us to set a custom SwiftUI view as the background. This is particularly useful when we want to use an image or a complex visual design as the modal background.

.sheet(isPresented: $showSheet) {
    Text("Sheet content...")
        .presentationBackground {
            Image(.clouds)
                .resizable()
                .scaledToFill()
        }
}

These background customization options work consistently across all modal presentation types. However, one interesting detail is that translucency appears more pronounced in sheets and full-screen covers than in popovers.

# Removing default backgrounds from container views

Some SwiftUI container views, such as List and Form, come with a default opaque background. When placed inside a modal, they obscure the presentation background, preventing customizations from taking effect. To make the presentation background visible, we need to disable the default styling of these container views.

Consider the following example, where a List is placed inside a sheet with a material background applied:

.sheet(isPresented: $showSheet) {
    List(1...10, id: \.self) {
        Text("Item \($0)")
    }
    .presentationBackground(.thinMaterial)
}

Even though we have applied a translucent material, the sheet appears fully opaque.

To allow the presentation background to show through, we first need to disable the List view's background using the scrollContentBackground(_:) modifier.

.sheet(isPresented: $showSheet) {
    List(1...10, id: \.self) {
        Text("Item \($0)")
    }
    .scrollContentBackground(.hidden)
    .presentationBackground(.thinMaterial)
}

This removes the opaque background from the empty areas of the list, making them transparent. However, the default row backgrounds remain visible.

To ensure a fully translucent appearance, we also need to remove the background from list rows by setting it to a clear color.

.sheet(isPresented: $showSheet) {
    List(1...10, id: \.self) {
        Text("Item \($0)")
            .listRowBackground(Color.clear)
    }
    .scrollContentBackground(.hidden)
    .presentationBackground(.thinMaterial)
}

Now, both the list’s empty areas and its rows become translucent, creating a consistent material effect throughout the modal.

# Controlling the color scheme

In addition to customizing the background, we can also specify a preferred color scheme for modal presentations. This ensures that the text, controls, and other UI elements remain legible regardless of the system-wide appearance settings.

Setting a color scheme can be particularly useful when using a custom background. For example, if our modal uses a dark image, we may want the text and buttons to appear in a light color for contrast.

To enforce a dark appearance inside a full-screen cover, we can apply the preferredColorScheme(_:) modifier:

.fullScreenCover(isPresented: $showCover) {
    PresentationContent()
        .preferredColorScheme(.dark)
}

With this in place, even if the rest of the app adapts dynamically to light and dark mode, the full-screen cover will always be displayed in a dark color scheme with light text elements, ensuring proper contrast between foreground and background.

The preferred color scheme value flows up the view hierarchy and is intercepted at the nearest presentation. However, this modifier can also be used outside of modal content, in which case it will affect the entire application.

For a more detailed discussion on working with color schemes in SwiftUI, including how to detect the current mode and respond to system changes, you can read my post: Reading and setting color scheme in SwiftUI.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

Mac apps often need to handle large datasets efficiently, but SwiftUI’s standard List can struggle with performance on macOS as the number of items grows. Scrolling may become sluggish, and memory usage can increase significantly.

For example, an app that enumerates files in a folder can easily generate a list with over 10,000 rows. While List is the obvious choice, its performance degrades at scale. A common alternative is wrapping a LazyHStack in a ScrollView, but this approach also struggles with large datasets.

So what’s the solution? We can build a custom layout that aggressively recycles rows, repositioning them just in time as the user scrolls while reusing the same view identity as a row fragment. This works particularly well with a fixed row height, which is common in macOS applications, since it allows us to determine visible rows based on the scroll offset. While this solution was designed for macOS, the same technique can also be applied to iOS.

The first step is to create a view that calculates the visible range of rows within the ScrollView. This allows us to determine which rows should be displayed at any given time.

struct RecyclingScrollingLazyView: View {
    let numberOfRows: Int
    let rowHeight: CGFloat
    @State var visibleRange: Range<Int> = 0..<1
    
    var body: some View {
        ScrollView(.vertical) {
            Color.red.frame(
                height: rowHeight * CGFloat(numberOfRows)
            )
        }
        .onScrollGeometryChange(
            for: Range<Int>.self,
            of: { geo in
                self.computeVisibleRange(in: geo.visibleRect)
            },
            action: { oldValue, newValue in
                self.visibleRange = newValue
            }
        )
    }
    
    func computeVisibleRange(in rect: CGRect) -> Range<Int> {
        let lowerBound = Int(
            max(0, floor(rect.minY / rowHeight))
        )
        let rowsThatFitInRange = Int(
            ceil(rect.height / rowHeight)
        )
        
        let upperBound = max(
            lowerBound + rowsThatFitInRange, 
            lowerBound + 1
        )
        
        return lowerBound..<upperBound
    }
}

Here, we create a vertical ScrollView and use the onScrollGeometryChange() modifier. This modifier is powerful because it calls the transform method every time the scroll offset updates but only triggers the action block if the result of the transform changes.

Next, we need to create the rows. Our RecyclingScrollingLazyView will take a list of row IDs and a ViewBuilder closure to create each row given its ID.

struct RecyclingScrollingLazyView<
    ID: Hashable, Content: View
>: View {
    let rowIDs: [ID]
    let rowHeight: CGFloat
    
    @ViewBuilder
    var content: (ID) -> Content
    
    var numberOfRows: Int { rowIDs.count }
    
    ...
}

The updated view is generic in both the row ID and the row content.

We can now use it as follows:

RecyclingScrollingLazyView(
    rowIDs: [1, 2, 3], rowHeight: 42
) { id in
    HStack {
        Text("Row \(id)")
        Spacer()
        Text("Some other row content")
    }
}

So far, our view only renders a large red rectangle without displaying any rows. To fix this, we need to map the visible range of rows to actual row content.

Since we want SwiftUI to reuse views efficiently, we’ll introduce a reusable identifier for each row, which we'll call a fragment. To achieve this, we'll define a nested struct called RowData inside our view. This struct will help manage row identity and ensure proper recycling of views as the user scrolls.

struct RecyclingScrollingLazyView<
    ID: Hashable, Content: View
>: View {
    ... 
    
    struct RowData: Identifiable {
        let fragmentID: Int
        let index: Int
        let value: ID
        
        var id: Int { fragmentID }
    }
    
    ...
}

Next, we’ll define a computed property that returns the visible range of rows as RowData. This ensures that only the necessary rows are displayed while efficiently reusing fragments.

struct RecyclingScrollingLazyView<
    ID: Hashable, Content: View
>: View {
    ... 

    var visibleRows: [RowData] {
        if rowIDs.isEmpty { return [] }
        
        let lowerBound = min(
            max(0, visibleRange.lowerBound),
            rowIDs.count - 1
        )
        let upperBound = max(
            min(rowIDs.count, visibleRange.upperBound),
            lowerBound + 1
        )
        
        let range = lowerBound..<upperBound
        let rowSlice = rowIDs[lowerBound..<upperBound]
        
        let rowData = zip(rowSlice, range).map { row in
            RowData(
                fragmentID: row.1 % range.count,
                index: row.1, value: row.0
            )
        }
        return rowData
    }
}

We determine the visible rows by slicing rowIDs based on the computed visible range. To maximize reuse, we assign each row a fragment ID, calculated as the row index modulo the total number of visible rows.

We can now replace the large empty rectangle with actual rows inside the scroll view.

struct RecyclingScrollingLazyView<
    ID: Hashable, Content: View
>: View {
    ...
    
    var body: some View {
        ScrollView(.vertical) {
            ForEach(visibleRows) { row in
                content(row.value)
            }
        }
        .onScrollGeometryChange(
            ...
        )
    }
}

The key to this approach is ensuring that our nested struct conforms to Identifiable and uses the fragment ID as the row identifier. This allows SwiftUI to reuse rows as we scroll, rather than creating new leaf nodes in the SwiftUI view hierarchy. By maintaining consistent view identities, we ensure that off-screen rows are efficiently recycled instead of being recreated.

However, if we run this now, we'll notice that only a small number of rows appear, always positioned at the top of the ScrollView. This happens because we're not explicitly positioning the rows or defining the total height of the content.

To fix this, we need a custom layout that places each row at the correct vertical position while ensuring the total height matches the full dataset.

We'll define an OffsetLayout struct that conforms to the Layout protocol, allowing precise control over row positioning.

struct OffsetLayout: Layout {
    let totalRowCount: Int
    let rowHeight: CGFloat
    
    func sizeThatFits(
        proposal: ProposedViewSize, 
        subviews: Subviews, 
        cache: inout ()
    ) -> CGSize {
        CGSize(
            width: proposal.width ?? 0,
            height: rowHeight * CGFloat(totalRowCount)
        )
    }
    
    func placeSubviews(
        in bounds: CGRect,
        proposal: ProposedViewSize, 
        subviews: Subviews, 
        cache: inout ()
    ) {
        for subview in subviews {
            let index = subview[LayoutIndex.self]
            subview.place(
                at: CGPoint(
                    x: bounds.midX,
                    y: bounds.minY + rowHeight * CGFloat(index)
                ),
                anchor: .top,
                proposal: .init(
                    width: proposal.width, height: rowHeight
                )
            )
        }
    }
}

struct LayoutIndex: LayoutValueKey {
    static var defaultValue: Int = 0
    
    typealias Value = Int
}

The sizeThatFits() method calculates the total height by multiplying the number of rows by the height of each row. This ensures the scrollable area reflects the full dataset.

In placeSubviews(), each visible row is positioned at its correct vertical offset. To determine its position, we need to know its index within the full list. We achieve this by defining a LayoutValueKey, which allows us to pass the index to the layout.

struct RecyclingScrollingLazyView<
    ID: Hashable, Content: View
>: View {
    ...
    
    var body: some View {
        ScrollView(.vertical) {
            OffsetLayout(
                totalRowCount: rowIDs.count,
                rowHeight: rowHeight
            ) {
                // The fragment ID is used instead of the row ID
                ForEach(visibleRows) { row in
                    content(row.value)
                        .layoutValue(
                            key: LayoutIndex.self, value: row.index
                        )
                }
            }
        }
        .onScrollGeometryChange(
            ...
        )
    }
}

Using the custom OffsetLayout, we can position each visible row precisely in the scroll view according to its index. The LayoutIndex value is set on each row and read back within our custom layout.

Since our approach reuses a limited number of rows, local state can persist when a row is recycled. For example, storing user input in a @State property may cause it to appear in a different row after scrolling.

To avoid this issue, we need to reset or clear any local state whenever the row ID changes.

struct MyRow: View {
    let id: Int
    @State private var text: String = ""
    
    var body: some View {
        TextField("Enter something", text: $text)
            .onChange(of: id) { newID in
                self.text = ""
            }
    }
}

RecyclingScrollingLazyView(
    rowIDs: [1, 2, 3], rowHeight: 42
) { id in
    MyRow(id: id)
}

Our custom approach is faster because we reuse a limited set of view identities instead of creating a new view for every row in a large list. We achieve this by calculating a fragment ID, which is the row’s index modulo the maximum number of visible rows. This allows SwiftUI to recycle view identities as rows move off-screen, rather than instantiating new views each time. By reusing existing views, we significantly improve performance and reduce memory usage.

In contrast, built-in components like List and LazyHStack cannot reuse views as aggressively. They assign each row a unique identity (provided in the ForEach statement) to properly maintain per-row state. As a result, SwiftUI’s view graph must create a separate leaf for each row and compute its height individually—an expensive process as the number of rows grows.

The performance difference becomes even more pronounced when using AppKit-backed controls such as text views, sliders, or buttons. By reusing view identities, previously instantiated AppKit views remain attached and are efficiently recycled, much like how a native NSTableView optimizes performance at scale.

If you're looking to gain a deeper understanding of SwiftUI state management, view identity, layout system, and rendering internals, make sure to check out SwiftUI Fundamentals by Natalia Panferova. It explores these core concepts in depth, helping you write more efficient and scalable SwiftUI apps.

Previously, I relied on the controlActiveState environment value to check whether a window was focused in SwiftUI on macOS. However, this API has been deprecated since macOS 15.

The replacement is the appearsActive environment value, which is true when the window is focused and false when it's not.

struct ContentView: View {
    @Environment(\.appearsActive) var appearsActive
    
    var body: some View {
        Text("Window is focused: \(appearsActive)")
            .onChange(of: appearsActive) { oldValue, newValue in
                let oldStatus = oldValue ? "active" : "inactive"
                let newStatus = newValue ? "active" : "inactive"
                print("Window focus changed from \(oldStatus) to \(newStatus).")
            }
    }
}

This value is useful for adjusting the appearance of controls or other UI elements when the window becomes inactive. We may also want to trigger actions when focus changes.

I used appearsActive in a settings window to update the state of a control. You can find an example in my previous post: Add launch at login setting to a macOS app.

I'm excited to announce the release of my new book – SwiftUI Fundamentals. This book takes a deep dive into the core principles and APIs that power SwiftUI, the modern UI framework for building apps across Apple platforms.

Unlike step-by-step tutorials, "SwiftUI Fundamentals" focuses on helping you go beyond surface-level knowledge. The book provides a solid foundation in how SwiftUI works under the hood, equipping you with the insights you need to write more efficient, maintainable, and expressive code.

You'll learn how SwiftUI handles view updates, data flow, and layout calculations. We'll look at how views negotiate size and position, how navigation is driven by state and data, and how animations and gestures are built into the system. The book also covers the most important APIs and patterns that developers encounter when building apps for iOS, macOS and other platforms.

Having contributed to SwiftUI's development as part of the team at Apple, I wrote this book to share what I’ve learned along the way. My goal is to help developers deepen their understanding of the framework, so they can confidently solve real-world problems without guesswork.

If you've used SwiftUI before and want to strengthen your understanding of how it really works, "SwiftUI Fundamentals" is for you.

Get your copy today and take your SwiftUI knowledge to the next level.

I hope you find it helpful as you continue building with SwiftUI.

SwiftUI’s MenuBarExtra scene provides a simple way to integrate menu bar functionality into macOS apps. It can complement a traditional app by offering quick access to frequently used features or serve as the foundation for a standalone menu bar utility.

In this post, I’ll walk through the process of building a menu bar–only app using MenuBarExtra. I recently developed EncodeDecode, a small tool for encoding and decoding strings with percent encoding (URL encoding), and I’ll share what I learned along the way.

# Create a menu bar app

Once we have created a macOS app project in Xcode, we can modify the app declaration by replacing the default WindowGroup with a MenuBarExtra scene. This scene can be initialized with just a title or both a title and an image. If an image is provided, only the image will be visible in the menu bar, otherwise, the title text will be displayed.

@main
struct MenuBarExampleApp: App {
    var body: some Scene {
        MenuBarExtra(
            "Menu Bar Example",
            systemImage: "characters.uppercase"
        ) {
            ContentView()
                .frame(width: 300, height: 180)
        }
        .menuBarExtraStyle(.window)
    }
}

By default, MenuBarExtra uses the menu style, which behaves like a standard dropdown menu. However, for a standalone app, we may want to use the window style instead, as it allows for greater flexibility in presenting content. The window can either resize dynamically based on its content or have a fixed frame set on the root view.

The ContentView serves as the root view of the utility, defining the app's interface within the window. For this example, we can create a simple app that allows users to paste a string, convert it to uppercase, and copy the result to the clipboard.

Here’s an example of how ContentView might look:

struct ContentView: View {
    @State private var textInput: String = ""
    
    var body: some View {
        VStack(alignment: .leading) {
            Text("Add your text below:")
                .foregroundStyle(.secondary)
            TextEditor(text: $textInput)
                .padding(.vertical, 4)
                .scrollContentBackground(.hidden)
                .background(.thinMaterial)
            Button(
                "Copy uppercased result",
                systemImage: "square.on.square"
            ) {
                let pasteboard = NSPasteboard.general
                pasteboard.clearContents()
                pasteboard.setString(
                    textInput.uppercased(),
                    forType: .string
                )
            }
            .buttonStyle(.plain)
            .foregroundStyle(.blue)
            .bold()
        }
        .padding()
    }
}

# Hide the app from the Dock and application switcher

For apps that only appear in the menu bar, it's common to hide them from both the Dock and the application switcher. This can be achieved by setting the LSUIElement flag to true in the Info.plist file. This tells macOS that the app is an agent that runs in the background.

# Providing a way to quit the app

After removing the app from the Dock and the app switcher, it’s important to provide a way for users to quit it, as they can no longer do so from the Dock. Unfortunately, SwiftUI doesn’t offer a built-in way to add a right-click menu to a menu bar item, so the simplest approach is to include a Quit button somewhere in the app’s interface.

For this example, we can place a small close button in the top-right corner of the window:

MenuBarExtra(
    "Menu Bar Example",
    systemImage: "characters.uppercase"
) {
    ContentView()
        .overlay(alignment: .topTrailing) {
            Button(
                "Quit",
                systemImage: "xmark.circle.fill"
            ) {
                NSApp.terminate(nil)
            }
            .labelStyle(.iconOnly)
            .buttonStyle(.plain)
            .padding(6)
        }
        .frame(width: 300, height: 180)
}

# Use a custom icon for the menu bar item

Before releasing the app, replacing the system symbol with a custom icon can make the menu item easier to recognize. A simplified version of the app icon, similar to the one used in the App Store, helps users associate the menu bar button with the app they downloaded.

To use a custom image, we need a different MenuBarExtra initializer that takes a label instead of a text and system image. If the image asset is already sized correctly for the menu bar button, we can load it directly, as shown in the example below.

MenuBarExtra {
    ContentView()
        .overlay(alignment: .topTrailing) {
            ...
        }
        .frame(width: 300, height: 180)
} label: {
    Label(
        "Menu Bar Example",
        image: .menuBarIcon
    )
}

However, when using a PNG that was larger than needed, I ran into sizing issues when creating a SwiftUI image directly. A workaround that worked for me was to first load the image as an NSImage, adjust its size, and then convert it to a SwiftUI Image.

MenuBarExtra {
    ContentView()
        .overlay(alignment: .topTrailing) {
            ...
        }
        .frame(width: 300, height: 180)
} label: {
    Label {
        Text("Menu Bar Example")
    } icon: {
        let image: NSImage = {
            let ratio = $0.size.height / $0.size.width
            $0.size.height = 18
            $0.size.width = 18 / ratio
            return $0
        }(NSImage(named: "MenuBarIcon")!)
        
        Image(nsImage: image)
    }
}

To take your macOS app further, consider integrating it with system features, such as adding a launch-at-login option or providing system-wide services. You can check out my other blog posts for instructions on how to do that: Add launch at login setting to a macOS app and Provide macOS system-wide services from your app.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

When we need to ensure that an iOS app preserves its state, such as tab selection or navigation, across launches, we can use the SceneStorage property wrapper in SwiftUI. This allows us to retain small pieces of UI-related state automatically.

struct ContentView: View {
    @SceneStorage("selectedTab")
    private var selectedTab: Int = 0
    
    var body: some View {
        TabView(selection: $selectedTab) {
            ...
        }
    }
}

We can test whether state preservation works as expected using the Xcode simulator, but it's crucial to follow the correct sequence of steps. Otherwise, the state might not be restored, leading us to mistakenly think that our implementation is incorrect.

To properly test state preservation with SceneStorage in Xcode:

1. Run the app in the Xcode simulator.
2. Change the state (e.g., switch tabs or navigate within the app).
3. Press the Home button in the simulator to send the app to the background.
4. Press the Stop button in Xcode to terminate the app.
5. Run the app again in Xcode and check if the state is preserved.

SwiftUI automatically clears SceneStorage values if the user explicitly quits the app from the app switcher. So when testing state preservation, avoid force-quitting the app and follow the steps above instead.

When working with UUIDs in Swift, we may need to match and extract them using regular expressions. To achieve this in a type-safe and reusable way, we can define a custom RegexComponent leveraging the Capture component.

# Defining a reusable RegexComponent for UUIDs

The following implementation creates a CaptureUUID struct that conforms to RegexComponent. This struct defines a regular expression pattern for matching UUIDs while ensuring type safety through a transformation function.

import RegexBuilder

struct CaptureUUID: RegexComponent {
    let reference: Reference<UUID>
    
    init(as reference: Reference<UUID>) {
        self.reference = reference
    }
    
    @RegexComponentBuilder
    var regex: Regex<(Substring, UUID)> {
        Capture(as: reference) {
            Repeat(count: 8) { .hexDigit }
            "-"
            Repeat(count: 4) { .hexDigit }
            "-"
            Repeat(count: 4) { .hexDigit }
            "-"
            Repeat(count: 4) { .hexDigit }
            "-"
            Repeat(count: 12) { .hexDigit }
        } transform: { substring in
            try Self.transform(substring)
        }
    }
    
    private static func transform(
        _ substring: Substring
    ) throws -> UUID {
        guard
            let uuid = UUID(uuidString: String(substring))
        else {
            throw RegexTransformError
                .unableToDecode(UUID.self, from: substring)
        }
        return uuid
    }
}

enum RegexTransformError: Error {
    case unableToDecode(Any.Type, from: Substring)
}

# Using CaptureUUID in a regex expression

This component can be integrated into a larger regex pattern to extract UUID values from a given string. For example, the following regex captures a UUID from a URL path:

let accountID = Reference<UUID>()

let regex = Regex {
    "accounts/"
    CaptureUUID(as: accountID)
    "/"
    Optionally {
        "index.json"
    }
    Anchor.endOfSubject
}

let match = url
    .path(percentEncoded: false)
    .firstMatch(of: regex)
    
if let match {
    // Returns the account id as a UUID
    return match[accountID]
}

By using CaptureUUID, we ensure type-safe access to extracted values while improving the clarity and maintainability of our regex-based parsing logic.

When using Django Channels, WebSocket consumers handle one message at a time for each connection. This means long-running async tasks block the consumer from processing other messages.

With Django Channels Rest Framework, you can run actions in a detached manner, allowing your consumer to handle other messages concurrently.

To enable this, add detached=True to your @action method decorator:

from djangochannelsrestframework.decorators import action
from djangochannelsrestframework.consumers import AsyncAPIConsumer

class MyConsumer(AsyncAPIConsumer):
    @action(detached=True)
    async def send_email(self, pk=None, to=None, **kwargs):
        # Perform long-running async tasks like making network requests

Detached actions are essential for handling long-running async operations, such as upstream network requests. Without them, your consumer will queue all incoming messages until the current action finishes.

Services on macOS allow us to extend our app’s functionality to the entire system, enabling users to interact with our app’s features while working in other contexts without explicitly opening it. These services are accessible via the context menu or from an application's Services menu in the macOS menu bar.

I recently implemented services for URL encoding and decoding strings in my macOS utility, EncodeDecode, and in this post, I’ll explain how I did it.

For my app, I implemented two services: URL-Encode and URL-Decode. These services become available when users select text anywhere on the system, such as in TextEdit or Xcode. When a user selects text and invokes one of the services, macOS launches EncodeDecode, passes the selected string to my app for processing, and replaces the original text with the processed result.

# Define service methods in code

To implement this functionality, I needed to define the required methods in code. This involved creating a service provider class that inherits from NSObject and implementing methods that process the text from the pasteboard.

import AppKit

class EncodeDecodeServiceProvider: NSObject {
    @objc func encode(
        _ pasteboard: NSPasteboard,
        userData: String?,
        error: AutoreleasingUnsafeMutablePointer<NSString>
    ) {
        guard let string = pasteboard.string(
            forType: NSPasteboard.PasteboardType.string
        ) else {
            return
        }
        pasteboard.clearContents()
        pasteboard.setString(
            EncodingManager.encodeUrl(string),
            forType: .string
        )
    }
    
    @objc func decode(
        _ pasteboard: NSPasteboard,
        userData: String?,
        error: AutoreleasingUnsafeMutablePointer<NSString>
    ) {
        guard let string = pasteboard.string(
            forType: NSPasteboard.PasteboardType.string
        ) else {
            return
        }
        pasteboard.clearContents()
        pasteboard.setString(
            EncodingManager.decode(urlString: string),
            forType: .string
        )
    }
}

# Register the service provider

After defining the service methods, the next step was to register the service provider. I did it in the applicationDidFinishLaunching(_:) method of my application delegate.

class AppDelegate: NSObject, NSApplicationDelegate {
    func applicationDidFinishLaunching(
        _ aNotification: Notification
    ) {
        NSApplication.shared
            .servicesProvider = EncodeDecodeServiceProvider()
    }
}

Only one service provider can be registered per application. If our app provides multiple services, a single object must handle all of them, as I did in EncodeDecode.

# Update Info.plist

Finally, I needed to declare the services in the Info.plist file. Here is how the NSServices key is configured for EncodeDecode:

<key>NSServices</key>
<array>
    <dict>
        <key>NSKeyEquivalent</key>
        <dict>
            <key>default</key>
            <string>E</string>
        </dict>
        <key>NSMenuItem</key>
        <dict>
            <key>default</key>
            <string>URL-Encode</string>
        </dict>
        <key>NSMessage</key>
        <string>encode</string>
        <key>NSPortName</key>
        <string>EncodeDecode</string>
        <key>NSRestricted</key>
        <false/>
        <key>NSRequiredContext</key>
        <dict/>
        <key>NSReturnTypes</key>
        <array>
            <string>NSStringPboardType</string>
        </array>
        <key>NSSendTypes</key>
        <array>
            <string>NSStringPboardType</string>
        </array>
    </dict>
    <dict>
        <key>NSKeyEquivalent</key>
        <dict>
            <key>default</key>
            <string>D</string>
        </dict>
        <key>NSMenuItem</key>
        <dict>
            <key>default</key>
            <string>URL-Decode</string>
        </dict>
        <key>NSMessage</key>
        <string>decode</string>
        <key>NSPortName</key>
        <string>EncodeDecode</string>
        <key>NSRestricted</key>
        <false/>
        <key>NSRequiredContext</key>
        <dict/>
        <key>NSReturnTypes</key>
        <array>
            <string>NSStringPboardType</string>
        </array>
        <key>NSSendTypes</key>
        <array>
            <string>NSStringPboardType</string>
        </array>
    </dict>
</array>

The NSServices key contains an array of dictionaries, each defining a service. For EncodeDecode, there are two services: URL-Encode and URL-Decode. Each service specifies the name as it appears in the Services menu, along with a keyboard shortcut for quick access. The NSMessage key maps to the selector method handling the service, and NSPortName identifies the app providing the service. Both services define NSSendTypes and NSReturnTypes to specify that they work with text data from the pasteboard.

To simplify the process of adding and editing these configurations, I used the XML editor in Xcode. You can access it by right-clicking on the Info.plist file and selecting Open As > Source Code. This approach provides full control and makes it easier to define the necessary keys and values.

# Testing and debugging

During development and testing, I found that the most reliable way to see updated services was to log out of my macOS user account and log back in.

To ensure that the system has recognized your service, you can also use the pbs tool to list the registered services. Run the following command in the terminal with the dump_pboard option:

/System/Library/CoreServices/pbs -dump_pboard

This command will display a list of registered services, allowing you to verify that your service has been correctly registered.

Users can manage available services in System Settings under Keyboard > Keyboard Shortcuts > Services. They can enable or disable services, assign shortcuts for quick access, and ensure only relevant services appear in an app’s Services menu.

If you're an experienced Swift developer looking to learn advanced techniques, check out my book Swift Gems. It’s packed with tips and tricks focused solely on the Swift language and Swift Standard Library. From optimizing collections and handling strings to mastering asynchronous programming and debugging, "Swift Gems" provides practical advice that will elevate your Swift development skills to the next level. Grab your copy and let's explore these advanced techniques together.

In SwiftUI, we can use the popover() modifier to present a popover when a given condition is true. By default, it shows a popover on iPad in a regular horizontal size class but turns into a sheet on iPhone.

Starting with iOS 16.4, we can use the presentationCompactAdaptation(_:) modifier to tell SwiftUI that we prefer popover presentation even in compact size classes. This modifier is applied to the view inside the popover's content.

Here’s an example of how we can show a popover for a list of ingredients in a recipe app when the user clicks on the list button:

IngredientsListButton(
    showIngredients: $showIngredients
)
.popover(isPresented: $showIngredients) {
    IngredientsList(
        ingredients: recipe.ingredients
    )
    .presentationCompactAdaptation(.popover)
}

Since we indicated that we prefer a popover for compact adaptation, SwiftUI will show a popover instead of a sheet, even on a phone.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

I recently built a macOS menu bar utility for URL encoding and decoding strings called EncodeDecode, and I thought it would be nice to include a setting to launch the app at login for users who might need frequent access to it. In this post, I'll show how this can be easily implemented using SMAppService.

It's important to note that it's best to have an explicit setting for this functionality in the app, set to false by default, to avoid any issues with App Store review. According to Apple's App Review Guidelines, Mac apps may not auto-launch or execute code at startup or login without user consent.

I included a toggle to control this setting within the Settings panel of my app.

Here's the UI code for that section:

struct LaunchAtLoginSettingsSection: View {
    @Environment(AppState.self) var appState
    
    var body: some View {
        @Bindable var appState = appState
        
        Section {
            VStack(alignment: .leading, spacing: 8) {
                Toggle("Launch at login", isOn: $appState.launchAtLogin)
                Text("""
                Add EncodeDecode app to the menu bar automatically \
                when you log in on your Mac.
                """)
                    .font(.callout)
                    .foregroundStyle(.secondary)
            }
        }
    }
}


@Observable
class AppState {
    var launchAtLogin = false
}

To use the SMAppService APIs, we need to import the ServiceManagement framework. Once imported, we can register the app service object corresponding to the main application as a login item when the user enables the setting, and unregister it when the setting is disabled.

import ServiceManagement

struct LaunchAtLoginSettingsSection: View {
    @Environment(AppState.self) var appState
    
    var body: some View {
        ...
        
        Section {
            ...
        }
        .onChange(of: appState.launchAtLogin) { _, newValue in
            if newValue == true {
                try? SMAppService.mainApp.register()
            } else {
                try? SMAppService.mainApp.unregister()
            }
        }
    }
}

When the user enables the setting and we register the app with SMAppService, they will see a notification informing them that a login item was added.

Users can view and manage their login items in the System Settings. They can also remove our app from the login items list if they wish.

The SMAppService API allows us to check the current status of our app, so we can use it to ensure the UI is up to date.

import ServiceManagement

struct LaunchAtLoginSettingsSection: View {
    @Environment(AppState.self) var appState
    
    var body: some View {
        ...
        
        Section {
            ...
        }
        .onAppear {
            if SMAppService.mainApp.status == .enabled {
                appState.launchAtLogin = true
            } else {
                appState.launchAtLogin = false
            }
        }
    }
}

In most cases, checking the status in onAppear() should be sufficient, as it’s unlikely that the user would modify this setting in the System Settings while the app's settings window is open. However, if that does happen, we can update the UI state when the settings window regains focus by using the appearsActive environment value. This ensures that when the user refocuses on the settings window, the correct system settings status is reflected.

import ServiceManagement

struct LaunchAtLoginSettingsSection: View {
    @Environment(AppState.self) var appState
    @Environment(\.appearsActive) var appearsActive
    
    var body: some View {
        ...
        
        Section {
            ...
        }
        .onChange(of: appearsActive) { _, newValue in
            guard newValue else { return }
            if SMAppService.mainApp.status == .enabled {
                appState.launchAtLogin = true
            } else {
                appState.launchAtLogin = false
            }
        }
    }
}

Since users can remove our app from the login items at any time, it’s important to read the status from SMAppService rather than storing this setting locally in the app, to ensure that our UI reflects the most recent state.

If you're an experienced Swift developer looking to learn advanced techniques, check out my book Swift Gems. It’s packed with tips and tricks focused solely on the Swift language and Swift Standard Library. From optimizing collections and handling strings to mastering asynchronous programming and debugging, "Swift Gems" provides practical advice that will elevate your Swift development skills to the next level.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

The Foundation framework has a feature called automatic grammar agreement that reduces the number of localized strings we need to provide while making our code simpler. It ensures text follows grammatical rules like pluralization and gender. It works seamlessly with SwiftUI, allowing us to handle plurals directly in Text views without any extra manual logic.

To make text automatically adjust to plural values, we can specify that we want it to use the inflection rule and define the scope for the inflection using the following syntax:

Text("You read ^[\(bookCount) book](inflect: true) this year!")

SwiftUI recognizes this syntax as a custom Markdown attribute and processes it accordingly. When a Text view is created with a string literal, as shown in the example above, SwiftUI treats the string as a LocalizedStringKey and parses the Markdown it contains. It identifies inflection attributes within the string and uses the automatic grammar agreement feature from Foundation to apply the necessary adjustments during rendering.

Here’s how that would look in a complete SwiftUI view:

struct BookReadingTracker: View {
    @State private var bookCount: Int = 0
    
    var body: some View {
        VStack(spacing: 16) {
            Text("""
            You read ^[\(bookCount) book](inflect: true) this year!
            """)

            Button("Add a book") {
                bookCount += 1
            }
        }
    }
}

In this example, tapping the button increases the bookCount value, and the text updates automatically. When bookCount is 1, it uses the singular form book. As the value increases, such as to 2 or higher, the text dynamically switches to the plural form, ensuring grammatical correctness.

This integration makes handling plurals in SwiftUI both simple and efficient. The automatic grammar agreement feature and the inflection attribute were introduced in iOS 15 with initial support for English and Spanish. Over the years, the grammar engine was expanded to include additional languages, and as of iOS 18, it also supports German, French, Italian, Portuguese, Hindi, and Korean, making it even more versatile for multilingual apps.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

Enums in Swift are a fundamental way to model a fixed set of choices or states in a type-safe manner. Adding Codable conformance allows enums to be serialized and deserialized, enabling them to work seamlessly with data formats like JSON or property lists. This is particularly useful when interacting with APIs, saving app data, or exchanging information between systems.

# Automatic Codable conformance

In many cases, all we need to do is mark an enum as Codable, and the compiler handles the rest. Before Swift 5.5, only enums conforming to RawRepresentable could automatically conform to Codable. Now, enums without raw values, including those with or without associated values, can also benefit from automatic Codable synthesis if all associated types are themselves Codable.

Let’s look at how automatic conformance works for different kinds of enums.

# Raw value enums

For enums with raw values, the encoded value corresponds to the raw value that represents it.

enum Direction: String, Codable {
    case north
    case south
    case east
    case west
}

let direction: Direction = .north
let jsonData = try JSONEncoder().encode(direction)

// Output: "north"
let jsonString = String(data: jsonData, encoding: .utf8)!

Decoding works the same way, the raw value is mapped back to the appropriate case.

# Enums without raw or associated values

Enums without associated values are encoded as an empty container, preserving the case name as the key.

enum Status: Codable {
    case success
    case failure
}

let status: Status = .success
let jsonData = try JSONEncoder().encode(status)

// Output: {"success":{}}
let jsonString = String(data: jsonData, encoding: .utf8)!

Decoding restores the enum case from the JSON key.

# Enums with associated values

For enums with associated values, each case is treated as a container with a key matching the case name. The associated values are encoded as nested key-value pairs within that container.

enum Command: Codable {
    case load(key: String)
    case store(key: String, value: Int)
}

let command: Command = .store(key: "exampleKey", value: 42)
let jsonData = try JSONEncoder().encode(command)

// Output: {"store":{"value":42,"key":"exampleKey"}}
let jsonString = String(data: jsonData, encoding: .utf8)!

For cases with unlabeled associated values, the compiler generates underscore-prefixed numeric keys, such as _0, _1, etc., based on their position.

enum Role: Codable {
    case vipMember(String, Int)
}


let role: Role = .vipMember("1234", 5)
let jsonData = try JSONEncoder().encode(role)

// Output: {"vipMember":{"_0":"1234","_1":5}}
let jsonString = String(data: jsonData, encoding: .utf8)!

Optional associated values are treated as nil if they are missing, which results in them being excluded from the encoded data.

# Customizing automatic conformance

# Customizing case names

By defining a CodingKeys enum, we can map case names to custom keys during encoding and decoding.

enum Status: Codable {
    case success
    case failure(reason: String)
    
    enum CodingKeys: String, CodingKey {
        case success
        case failure = "error"
    }
}

This customization alters the JSON structure:

let status: Status = .failure(reason: "Invalid request")
let jsonData = try JSONEncoder().encode(status)

// Output: {"error":{"reason":"Invalid request"}}
let jsonString = String(data: jsonData, encoding: .utf8)!

# Customizing associated value keys

We can also customize the keys used for associated values by defining separate coding keys enums for each case. These coding keys enums have to be prefixed with the capitalized case name.

enum Command: Codable {
    case load(key: String)
    case store(key: String, value: Int)
    
    enum StoreCodingKeys: String, CodingKey {
        case key
        case value = "data"
    }
}

let command: Command = .store(key: "code", value: 123)
let jsonData = try JSONEncoder().encode(command)

// Output: {"store":{"key":"code","data":123}}
let jsonString = String(data: jsonData, encoding: .utf8)!

This approach is particularly useful when we need to align the encoded structure with external data formats.

# Excluding cases or values

Certain cases or associated values can be excluded by omitting them from the CodingKeys declaration.

enum Event: Codable {
    case start
    case end(description: String, metadata: String = "")

    enum EndCodingKeys: String, CodingKey {
        case description
    }
}

Values that are excluded must have a default value defined, if a Decodable conformance should be synthesized.

# Custom Codable conformance

Automatic conformance doesn’t fit all use cases. For example, enums with overloaded case identifiers or complex encoding requirements might require custom implementations of encode(to:) and init(from:).

enum Response: Codable {
    case success(data: String)
    case error(reason: String)
    
    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        switch self {
        case .success(let data):
            try container.encode(["status": "success", "data": data])
        case .error(let reason):
            try container.encode(["status": "error", "reason": reason])
        }
    }
    
    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let rawData = try container.decode([String: String].self)
        if let data = rawData["data"] {
            self = .success(data: data)
        } else if let reason = rawData["reason"] {
            self = .error(reason: reason)
        } else {
            throw DecodingError.dataCorrupted(
                DecodingError.Context(
                    codingPath: decoder.codingPath,
                    debugDescription: "Invalid data"
                )
            )
        }
    }
}

This allows a custom structure that doesn’t follow the default nested encoding format.

Codable conformance makes enums in Swift even more powerful and versatile. While automatic synthesis covers many scenarios, customization and fully manual implementations offer the flexibility to handle complex requirements. With these tools, we can work confidently with serialized data, ensuring that our enums integrate seamlessly into real-world applications.

As someone who has worked extensively with Swift, I've gathered many insights over the years and compiled them in my book, Swift Gems. The book focuses exclusively on the Swift language and Swift Standard Library, offering over 100 advanced tips and techniques on topics such as optimizing collections, leveraging generics, asynchronous programming, and debugging. Each tip is designed to help intermediate and advanced Swift developers write clearer, faster, and more maintainable code by fully utilizing Swift's built-in capabilities.

Customizing the appearance of macOS windows can help create a unique and polished user experience. One of the key aspects we can modify is the window's background. In this post, we’ll explore how to customize the background of macOS windows in SwiftUI, adjust the toolbar appearance, and remove the window title. These simple changes can make our apps look more modern and clean.

By default, macOS windows have an opaque background and a toolbar with its own background on top. Here's how a basic default window looks when we create a fresh SwiftUI app.

To customize the background of our window, we can use the containerBackground(_:for:) modifier. This allows us to pass a style for the background, setting the container parameter to .window. The style can be any type that conforms to ShapeStyle, such as a color, gradient, or material. For example, we can apply a translucent material to our window, which allows the desktop color to shine through.

  @main
struct MyAppApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .containerBackground(
                    .thinMaterial, for: .window
                )
        }
    }
}

If we also want to remove the toolbar background, we can apply the toolbarBackgroundVisibility(_:for:) modifier to the contents of the window. We pass .hidden for the visibility parameter and .windowToolbar for the bars parameter, which will hide the toolbar's background.

@main
struct MyAppApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .containerBackground(
                    .thinMaterial, for: .window
                )
                .toolbarBackgroundVisibility(
                    .hidden, for: .windowToolbar
                )
        }
    }
}

If we want to go further, we can remove the window title as well. This can be done either by adding toolbar(removing: .title) to the contents of the window or by applying windowStyle(.hiddenTitleBar) to the WindowGroup. The latter removes both the title and the toolbar background in one step.

@main
struct MyAppApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .containerBackground(
                    .thinMaterial, for: .window
                )
        }
        .windowStyle(.hiddenTitleBar)
    }
}

When there is no visible toolbar, it might be helpful to allow users to drag the window by clicking anywhere on the background. We can achieve this by applying windowBackgroundDragBehavior(.enabled) to the WindowGroup.

@main
struct MyAppApp: App {
    var body: some Scene {
        WindowGroup {
            ...
        }
        .windowStyle(.hiddenTitleBar)
        .windowBackgroundDragBehavior(.enabled)
    }
}

With just a few SwiftUI modifiers, we can adjust the appearance of macOS windows to better fit our needs. Customizing the background, toolbar, and title can help us create the design we're looking for in our apps.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

In SwiftUI, we can use the convenient brightness(_:) modifier to adjust the brightness of colors in our views. It accepts a Double value, where passing 0 keeps the original color, and a value of 1 makes the color fully white.

Here’s an example of how we can use it to lighten a color:

ForEach(0..<8) { num in
    Color.purple
        .brightness(Double(num) * 0.1)
}

This creates a gradient effect, transitioning the purple color from its original shade to almost white.

We can also use negative values with the brightness(_:) modifier to darken a color as it approaches -1:

ForEach(0..<8) { num in
    Color.purple
        .brightness(Double(num) * -0.1)
}

This results in a gradient effect where the purple transitions from its original shade to almost black.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

In Swift, types are copyable by default. This design simplifies development by allowing values to be easily duplicated when assigned to new variables or passed to functions. While convenient, this behavior can sometimes lead to unintended issues. For instance, copying a single-use ticket or duplicating a database connection could result in invalid states or resource conflicts.

To address these challenges, Swift 5.9 introduced noncopyable types. By marking a type as ~Copyable, we explicitly prevent Swift from duplicating it. This guarantees unique ownership of the value and enforces stricter constraints, reducing the risk of errors.

Here’s a simple example of a noncopyable type:

struct SingleUseTicket: ~Copyable {
    let ticketID: String
}

In contrast to the regular behavior of value types, when we assign an instance of a noncopyable type to a new variable, the value gets moved instead of being copied. If we attempt to use the original variable later, we'll get a compile-time error.

let originalTicket = SingleUseTicket(ticketID: "S645")
let newTicket = originalTicket

// Error: 'originalTicket' used after consume
// print(originalTicket.ticketID)

Classes can't be declared noncopyable. All class types remain copyable by retaining and releasing references to the object.

# Methods in noncopyable types

Methods in noncopyable types can read, mutate, or consume self.

# Borrowing methods

Methods inside a noncopyable type are borrowing by default. This means they only have read access to the instance, allowing safe inspection of the instance without affecting its validity.

struct SingleUseTicket: ~Copyable {
    let ticketID: String
    
    func describe() {
        print("This ticket is \(ticketID).")
    }
}

let ticket = SingleUseTicket(ticketID: "A123")

// Prints `This ticket is A123.`
ticket.describe()

# Mutating methods

A mutating method provides temporary write access to self, allowing modifications without invalidating the instance.

struct SingleUseTicket: ~Copyable {
    var ticketID: String

    mutating func updateID(newID: String) {
        ticketID = newID
        print("Ticket ID updated to \(ticketID).")
    }
}

var ticket = SingleUseTicket(ticketID: "A123")

// Prints `Ticket ID updated to B456.`
ticket.updateID(newID: "B456")

# Consuming methods

A consuming method takes ownership of self, invalidating the instance once the method completes. This is useful for tasks that finalize or dispose of a resource. After the method is called, any attempt to access the instance results in a compile-time error.

struct SingleUseTicket: ~Copyable {
    let ticketID: String
    
    consuming func use() {
        print("Ticket \(ticketID) used.")
    }
}

func useTicket() {
    let ticket = SingleUseTicket(ticketID: "A123")
    ticket.use()
    
    // Error: 'ticket' consumed more than once
    // ticket.use()
}

useTicket()

Note that we can't consume noncopyable types stored in global variables, that's why we wrapped the code into the useTicket() function in our example.

# Noncopyable types in function arguments

When passing noncopyable types as arguments to functions, Swift requires us to specify the ownership model for that function. We can mark parameters as borrowing, inout, or consuming, each offering different levels of access, similar to methods inside the types.

# Borrowing parameters

Borrowing ownership allows the function to temporarily read the value without consuming or mutating it.

func inspectTicket(_ ticket: borrowing SingleUseTicket) {
    print("Inspecting ticket \(ticket.ticketID).")
}

# Inout parameters

The inout modifier provides temporary write access to a value, allowing the function to modify it while returning ownership to the caller.

func updateTicketID(_ ticket: inout SingleUseTicket, to newID: String) {
    ticket.ticketID = newID
    print("Ticket ID updated to \(ticket.ticketID).")
}

# Consuming parameters

When a parameter is marked as consuming, the function takes full ownership of the value, invalidating it for the caller. This is ideal for tasks where the value is no longer needed after the function.

func processTicket(_ ticket: consuming SingleUseTicket) {
    ticket.use()
}

# Deinitializers and the discard operator

Noncopyable structs and enums can have deinitializers, like classes, which run automatically at the end of the instance's lifetime.

struct SingleUseTicket: ~Copyable {
    let ticketID: Int
    
    deinit {
        print("Ticket deinitialized.")
        
        // cleanup logic
    }
}

However, when both a consuming method and a deinitializer perform cleanup, there is a risk of redundant operations. To address this, Swift introduced the discard operator.

By using discard self in a consuming method, we explicitly stop the deinitializer from being called, avoiding duplicate logic:

struct SingleUseTicket: ~Copyable {
    let ticketID: Int
    
    consuming func invalidate() {
        print("Ticket \(ticketID) invalidated.")
        
        // cleanup logic
        
        discard self
    }
    
    deinit {
        print("Ticket deinitialized.")
        
        // cleanup logic
    }
}

Note that we can only use discard if our type contains trivially-destroyed stored properties. It can't have reference-counted, generic, or existential fields.

Noncopyable types are invaluable in scenarios where unique ownership is essential. They prevent duplication of resources like single-use tokens, cryptographic keys, or database connections, reducing the risk of errors. By enforcing ownership rules at compile time, Swift enables developers to write safer, more efficient code.

While noncopyable types might not be required in every project, they provide a powerful tool for ensuring safety and clarity in critical systems. As Swift continues to evolve, these types represent a significant step forward in the language’s focus on performance and correctness.

As someone who has worked extensively with Swift, I've gathered many insights over the years and compiled them in my book, Swift Gems. The book focuses exclusively on the Swift language and Swift Standard Library, offering over 100 advanced tips and techniques on topics such as optimizing collections, leveraging generics, asynchronous programming, and debugging. Each tip is designed to help intermediate and advanced Swift developers write clearer, faster, and more maintainable code by fully utilizing Swift's built-in capabilities.

I’ve been implementing copy-to-clipboard functionality in a Mac app and realized that it’s a bit different from iOS. With UIPasteboard, assigning a string automatically replaces the previous contents of the clipboard with the new string. But on macOS, we need to clear the previous contents manually, otherwise, it won’t work.

So essentially, to copy a string to the clipboard on macOS, our code will look like this:

func copyToClipboard(string: String) {
    let pasteboard = NSPasteboard.general
    pasteboard.clearContents()
    pasteboard.setString(string, forType: .string)
}

We should use clearContents() as the first step when providing data to the pasteboard.

I found a few solutions online suggesting the use of declareTypes(_:owner:) as the initial step for setting up the pasteboard. However, according to Apple’s documentation for NSPasteboard, this approach was meant for writing data to the pasteboard on macOS versions 10.5 and earlier.

If you're an experienced Swift developer looking to deepen your skills, my book Swift Gems covers advanced techniques like optimizing collections, handling strings, and mastering asynchronous programming, perfect for taking your Swift expertise to the next level.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

SwiftUI provides a simple way to set a view's background to a shape, like a capsule or rounded rectangle, using the background(_:in:fillStyle:) modifier. This avoids the need to clip the background or separately define and fill a shape.

Here's an example:

Text("Hello, world!")
    .font(.title)
    .fontWeight(.semibold)
    .padding(22)
    .background(
        Color.yellow.gradient,
        in: Capsule()
    )

In this case, the capsule filled with a subtle yellow gradient is layered behind the text using background(Color.yellow.gradient, in: Capsule()).

This convenience method works with shapes that conform to the InsettableShape protocol, like Capsule, Rectangle, Circle, and RoundedRectangle.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

I'm working on a small macOS utility app and using it as an opportunity to experiment with some SwiftUI features. As part of this project, I decided to build a custom segmented control and looked for a simple, clean way to animate a capsule shape that highlights the selected option as it transitions between choices when the user interacts with the control. I found that using matchedGeometryEffect() was the most straightforward solution.

While many examples of the matchedGeometryEffect() modifier focus on hero animations, it can also be applied in other contexts, like my custom segmented control. Here, it's not used to transition geometry when one view disappears and another appears. Instead, it matches the geometry of a non-source view to that of the source view while both remain present in the view hierarchy simultaneously.

Let me show you how I set it up.

First, I defined the foundation of my segmented control: an HStack of buttons. Tapping a button updates the selection state. I also added a background around all the options to form the control. At this stage, tapping a button changes the selection, but there’s no visual indication of the currently selected option.

enum SegmentedControlState: String, CaseIterable, Identifiable {
    var id: Self { self }
    
    case option1 = "Option 1"
    case option2 = "Option 2"
    case option3 = "Option 3"
}

struct SegmentedControl: View {
    @State private var state: SegmentedControlState = .option1
    
    var body: some View {
        HStack {
            ForEach(SegmentedControlState.allCases) { state in
                Button {
                    self.state = state
                } label: {
                    Text(state.rawValue)
                        .padding(10)
                }
            }
        }
        
        .background(.indigo)
        .clipShape(
            Capsule()
        )
        .buttonStyle(.plain)
    }
}

Next, I added another capsule in the background of the HStack containing the buttons. This capsule will eventually highlight the selected option once everything is set up. For now, however, it simply fills the entire available space within the control, minus some padding.

struct SegmentedControl: View {
    @State private var state: SegmentedControlState = .option1
    
    var body: some View {
        HStack {
            ...
        }
        
        .background(
            Capsule()
                .fill(.background.tertiary)
        )
        .padding(6)
        
        .background(.indigo)
        .clipShape(
            Capsule()
        )
        .buttonStyle(.plain)
    }
}

To make the inner capsule dynamically match the size and position of the selected option, I used the matchedGeometryEffect(). First, I defined a namespace with the @Namespace property wrapper. Then, I applied the matchedGeometryEffect() modifier to the inner capsule, linking it to the namespace and using the selection state as the identifier. This identifier ensures that the capsule matches the geometry of the source view with the same ID. Additionally, it’s important to set the capsule as a non-source view by specifying isSource: false.

struct SegmentedControl: View {
    @State private var state: SegmentedControlState = .option1
    @Namespace private var segmentedControl
    
    var body: some View {
        HStack {
            ...
        }
        
        .background(
            Capsule()
                .fill(.background.tertiary)
                .matchedGeometryEffect(
                    id: state,
                    in: segmentedControl,
                    isSource: false
                )
        )
        .padding(6)
        
        ...
    }
}

For now, nothing will visibly change since it's not specified which view should act as the source for the geometry. That’s the next step.

I applied the matchedGeometryEffect() modifier to each button in the HStack, assigning each button a unique ID corresponding to the state it represents. Note that I didn’t specify the isSource parameter for the buttons, as it defaults to true. This means the currently selected button automatically acts as the source for the matched geometry effect, allowing the capsule to align with the button whose ID matches the selection state.

struct SegmentedControl: View {
    @State private var state: SegmentedControlState = .option1
    @Namespace private var segmentedControl
    
    var body: some View {
        HStack {
            ForEach(SegmentedControlState.allCases) { state in
                Button {
                    self.state = state
                } label: {
                    Text(state.rawValue)
                        .padding(10)
                }
                .matchedGeometryEffect(
                    id: state,
                    in: segmentedControl
                )
            }
        }
        
        .background(
            Capsule()
                .fill(.background.tertiary)
                .matchedGeometryEffect(
                    id: state,
                    in: segmentedControl,
                    isSource: false
                )
        )
        .padding(6)
        
        ...
    }
}

If we check the preview now, we’ll see the capsule positioned just behind the selected option, matching its size and position. By default, the matched geometry effect aligns both size and position, but this behavior can be customized using the properties parameter. In this case, however, the default behavior works perfectly.

To animate the capsule when switching options, I wrapped the state change in a withAnimation block.

struct SegmentedControl: View {
    @State private var state: SegmentedControlState = .option1
    @Namespace private var segmentedControl
    
    var body: some View {
        HStack {
            ForEach(SegmentedControlState.allCases) { state in
                Button {
                    withAnimation {
                        self.state = state
                    }
                } label: {
                    Text(state.rawValue)
                        .padding(10)
                }
                .matchedGeometryEffect(
                    id: state,
                    in: segmentedControl
                )
            }
        }
        
        ...
    }
}

Now, the capsule slides smoothly between options as the selection changes.

With just a few lines of code, I got a custom segmented control with a sliding animation. Using the matched geometry effect makes this approach much cleaner and simpler compared to alternative methods.

Keep in mind that when creating custom UI components, it's essential to test for accessibility features like Dynamic Type and VoiceOver. This example focuses on using the matched geometry effect for the background animation, so be sure to add any required accessibility functionality if you use it in your app. Here is a good accessibility solution using accessibilityRepresentation() from Bas Broek.

Since SwiftUI doesn’t yet allow custom styles for pickers, creating a custom segmented control like this requires building it as a separate component.

You can find the code example for this post on GitHub.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

iOS 18 introduced a powerful new feature: the ability to animate UIKit views using SwiftUI animation types. This bridges the gap between the two frameworks even further, allowing us to bring the flexibility and expressiveness of SwiftUI animation system into UIKit-based projects.

Let’s take a look at a simple example to see how this works in practice. We’ll animate a UIImageView that scales up and down continuously.

Here is the initial setup:

class ViewController: UIViewController {
    private var animatingView: UIView?

    override func viewDidLoad() {
        super.viewDidLoad()
        
        animatingView = UIImageView(
            image: UIImage(systemName: "volleyball.fill")
        )
        animatingView?.tintColor = .systemPink
        animatingView?.contentMode = .scaleAspectFit
        animatingView?.frame = CGRect(
            origin: .init(x: 0, y: 0),
            size: .init(width: 80, height: 80)
        )
        view.addSubview(animatingView!)
        animatingView?.center = view.center
    }
}

Next, we'll define the animation logic. The animation will start when the view appears on the screen, so we’ll implement it in the viewDidAppear() method. We'll use SwiftUI Animation API to create a linear animation lasting 1.3 seconds that repeats indefinitely. We'll apply this animation to the image view using the new UIView.animate() method, which accepts a SwiftUI Animation as an argument.

class ViewController: UIViewController {
    ...

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        self.startAnimating()
    }

    private func startAnimating() {
        let animation = SwiftUI.Animation
            .linear(duration: 1.3)
            .repeatForever()
        
        UIView.animate(animation) { [weak self] in
            self?.animatingView?.transform = .init(scaleX: 2, y: 2)
        }
    }
}

Finally, we can preview the animation directly in Xcode to ensure everything is working as expected:

#Preview {
    ViewController()
}

When the app runs, the volleyball icon smoothly scales up to twice its size and continuously repeats this effect.

SwiftUI animation API makes it simple to define animations and manage their timing and repetition. By using SwiftUI animations in UIKit, we can create smoother, more cohesive animations across our entire app, improving the overall experience for users.

If you have older iOS apps and want to enhance them with modern SwiftUI features, check out my book Integrating SwiftUI into UIKit Apps. It provides detailed guidance on gradually adopting SwiftUI in your UIKit projects. Additionally, if you're eager to enhance your Swift programming skills, my book Swift Gems offers over a hundred advanced tips and techniques, including optimizing collections, handling strings, mastering asynchronous programming, and debugging, to take your Swift code to the next level.

When we create a new file in Xcode, it's set to build for all platforms that the app supports by default. If the code in the file uses platform-specific APIs, such as NSDocumentController for macOS, the app won't compile for other platforms like iOS unless we wrap the platform-specific code in #if os(macOS) checks:

import SwiftUI

#if os(macOS)
struct MacDocumentList: View {
    
    var body: some View {
        List(
            NSDocumentController.shared.recentDocumentURLs,
            id: \.self
        ) { url in
            Text(url.absoluteString)
        }
    }
}
#endif

Alternatively, we can edit the file’s target membership options in Xcode and restrict the file to a specific platform. For instance, we can configure the file to only build for macOS. To do this, we open the file inspector panel in Xcode, select the target membership, and click the pencil icon to edit. From there, we uncheck the "Any Supported Platform" checkbox, choose the platform the file should build for, and click save.

This avoids wrapping the entire file in conditional compilation checks when its contents are specific to one platform.

Note that this feature is only available for files managed by Xcode and it won't work in a Swift package.

If you're an experienced Swift developer looking to learn advanced techniques, check out my book Swift Gems. It dives into topics like optimizing collections, handling strings, and mastering asynchronous programming - perfect for taking your Swift skills to the next level.

When migrating from the ObservableObject protocol to the @Observable macro, I encountered an issue with using a lazy variable in my observable class. In this post, I’ll explain the problem and show how I resolved it.

Here’s a simplified version of my class using ObservableObject:

class WalksViewModel: ObservableObject {
    let walks = [
        Walk(title: "Central Park Loop", difficulty: .easy),
        Walk(title: "Mountain Ridge Trail", difficulty: .hard),
        Walk(title: "Riverbank Stroll", difficulty: .medium)
    ]
    
    @Published var sortingIsOn = false
    
    lazy var sortedWalks: [Walk] = {
        walks.sorted(
            using: KeyPathComparator(\Walk.difficulty)
        )
    }()
}

This works as expected. However, after updating the class to use the @Observable macro, the following error appeared: 'lazy' cannot be used on a computed property.

@Observable
class WalksViewModel {
    let walks = [
        Walk(title: "Central Park Loop", difficulty: .easy),
        Walk(title: "Mountain Ridge Trail", difficulty: .hard),
        Walk(title: "Riverbank Stroll", difficulty: .medium)
    ]
    
    var sortingIsOn = false
    
    // Error: 'lazy' cannot be used on a computed property
    lazy var sortedWalks: [Walk] = {
        walks.sorted(
            using: KeyPathComparator(\Walk.difficulty)
        )
    }()
}

This happens because the @Observable macro automatically generates observation logic for all variables in the class, but it cannot synthesize the necessary observation code for a lazy property.

While searching for a solution, I found this discussion on Swift Forums. I learned that to use lazy variables in observable classes, we can annotate them with @ObservationIgnored. This tells the observation system to skip synthesizing observation logic for the property.

Here’s how my final solution looks:

@Observable
class WalksViewModel {
    let walks = [
        Walk(title: "Central Park Loop", difficulty: .easy),
        Walk(title: "Mountain Ridge Trail", difficulty: .hard),
        Walk(title: "Riverbank Stroll", difficulty: .medium)
    ]
    
    var sortingIsOn = false
    
    @ObservationIgnored
    lazy var sortedWalks: [Walk] = {
        walks.sorted(
            using: KeyPathComparator(\Walk.difficulty)
        )
    }()
}

If you're an experienced Swift developer looking to level up your skills, take a look at my book Swift Gems. It offers 100+ advanced Swift tips, from optimizing collections and leveraging generics, to async patterns, powerful debugging techniques, and more - each designed to make your code clearer, faster, and easier to maintain.

Xcode 16 introduced the Previewable macro, making it easier to preview SwiftUI views with bindings. By annotating dynamic properties like @State in a #Preview body with @Previewable, we can pass them as bindings to views directly.

Here is an example on how we can easily setup a fully interactive preview for a basic counter view that accepts a binding:

struct CounterView: View {
    @Binding var count: Int
    
    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment count") {
                count += 1
            }
        }
    }
}

#Preview {
    @Previewable @State var count = 0
    CounterView(count: $count)
}

This example creates an interactive preview where the count value can be updated in real-time using the provided button.

@Previewable is supported on iOS 17, macOS 14, and other platforms.

I’m excited to announce that my book Integrating SwiftUI into UIKit Apps has been updated to include the latest features from iOS 18 and Xcode 16. This guide is designed to help UIKit developers seamlessly integrate SwiftUI into their existing projects, blending the declarative power of SwiftUI with the flexibility of UIKit.

The book covers everything you need to know to bridge the two frameworks effectively, from embedding SwiftUI views and managing data flow to migrating entire projects to the SwiftUI app lifecycle. It also includes techniques for enhancing apps with modern SwiftUI components like widgets and Swift Charts while maintaining compatibility with your existing UIKit code.

The new edition brings exciting updates. Projects now use the @Observable macro, simplifying data sharing between UIKit and SwiftUI. The book also shows how to work with Xcode’s updated preview system, leveraging the #Preview macro to accelerate UI development and testing. Additionally, there’s a brand new subchapter on using SwiftUI animations to animate UIKit views, a capability introduced with iOS 18.

This book is ideal for developers who want to incrementally adopt SwiftUI without rewriting their entire app. Each chapter includes practical examples and sample projects to help you follow along and implement the techniques in your own work. Whether you’re adding a single SwiftUI view to a UIKit app or planning a full transition, this book has you covered.

If you’re ready to enhance your projects with the latest advancements in SwiftUI, the updated Integrating SwiftUI into UIKit Apps is here to guide you every step of the way. Grab your copy and start building today!

We are all familiar with view modifiers in SwiftUI, such as font(), background(), frame(), etc. We use them all the time to style and customize views in our apps. They are methods defined on the View type that return a different version of the original view. I previously wrote about text modifiers, which are methods applied directly to Text, returning a modified Text, that can be used inside text interpolation. In this post I'd like to explore font modifiers, which work similarly to view and text modifiers but are applied to the Font type, returning a modified font.

Here is an example of font modifiers in action. We apply bold(), monospaced() and smallCaps() to the largeTitle font to customize the way it looks.

Text("Hello, world!")
    .font(
        .largeTitle
            .bold()
            .monospaced()
            .smallCaps()
    )

We can view the full list of font modifiers in SwiftUI Font documentation in the "Styling a font" section. We can see that they are not exactly the same as modifiers available on the Text type or methods for styling text on the View type.

For example, there is a font modifier for customizing leading, which lets us adjust the line spacing of a font and takes a Font.Leading enum as an argument. This modifier can't be applied to a Text or any other view, only to a Font.

VStack(spacing: 20) {
    Text(exampleText)
        .font(
            .largeTitle
                .leading(.tight)
        )
    Text(exampleText)
        .font(
            .largeTitle
                .leading(.loose)
        )
}

Font modifiers are a great way to manage typography in SwiftUI, letting us style text directly at the font level. Using these modifiers thoughtfully can help us create a polished look that improves our app’s user experience.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

When implementing search functionality in Swift apps, it’s important to make sure it behaves in a way users expect. Typically, when users search within apps or the system, they expect loose matches that ignore case and accents. For this reason, instead of using strict checks like range(of:) or contains(), it’s better to use flexible, locale-aware methods.

In Swift, localizedStandardRange(of:) is the most appropriate method for performing user-level string searches, as it mirrors how searches are done generally in the system. It’s case-insensitive, diacritic-insensitive, and adjusts to the user’s locale settings, ensuring that results meet user expectations.

Here’s an example with German strings:

import Foundation

let germanStrings = ["STRASSE", "Straße", "straße"]
let searchStr = "strasse"

for str in germanStrings {
    if let rangeOfMatch = str.localizedStandardRange(of: searchStr) {
        print(str[rangeOfMatch])
    }
}

This will print STRASSE, Straße, and straße, as they are all considered equivalent in German.

Note that localizedStandardRange(of:) comes from the Foundation framework, so we'll need to import Foundation when using it.

To illustrate diacritic insensitivity, here’s a French example:

import Foundation

let frenchStrings = ["fête", "Fete", "FÊTE"]
let searchStr = "fete"

for str in frenchStrings {
    if let rangeOfMatch = str.localizedStandardRange(of: searchStr) {
        print(str[rangeOfMatch])
    }
}

This example will print all variants of "fête", illustrating that the search is accent-insensitive.

Use localizedStandardRange(of:) to provide users with a search experience that feels familiar and intuitive, just like in other system-wide searches.

If you're an experienced Swift developer looking to level up your skills, take a look at my book Swift Gems. It offers 100+ advanced Swift tips, from optimizing collections and leveraging generics, to async patterns, powerful debugging techniques, and more - each designed to make your code clearer, faster, and easier to maintain.

SwiftUI provides a powerful mechanism called the environment, allowing data to be shared across views in a view hierarchy. This is particularly useful when we need to pass data or configuration information from a parent view down to its children, even if they’re many levels deep. It enhances the flexibility of SwiftUI views and decouples the data source from its destination.

SwiftUI includes a predefined list of values stored in the EnvironmentValues struct. These values are populated by the framework based on system state and characteristics, user settings or sensible defaults. We can access these predefined values to adjust the appearance and behavior of custom SwiftUI views, and we can also override some of them to influence the behavior of built-in views. Additionally, we can define our own custom values by extending the EnvironmentValues struct.

In this post, we'll explore various ways to work with the SwiftUI environment, including reading and setting predefined values, creating custom environment keys, and using the environment to pass down actions and observable classes.

# Reading environment values

SwiftUI provides a convenient way to read values stored in the EnvironmentValues structure using the @Environment property wrapper.

For example, we can get the vertical size class of the user interface by specifying the verticalSizeClass key path. The value stored in this property is of type UserInterfaceSizeClass, and it informs our view about the amount of available vertical space based on the device type and orientation. SwiftUI automatically sets this value by considering factors like whether the device is an iPhone, iPad, or another screen size, and whether the device is in portrait or landscape mode.

struct ContentView: View {
    @Environment(\.verticalSizeClass)
    private var verticalSizeClass
    
    var body: some View {
        VStack {
            Text("Good morning!")
                .font(.largeTitle)
            if verticalSizeClass == .regular {
                Image("sunrise")
            }
        }
        .padding()
    }
}

In this example, we check the verticalSizeClass to determine whether the view has enough vertical space to display an additional image. If the size class is regular, the image will appear.

Reading environment values provided by SwiftUI helps us build flexible and adaptive UIs without hardcoding assumptions about the device or user preferences.

# Setting environment values

We can set or override some environment values using the environment() view modifier. This modifier allows us to define settings or configurations that automatically apply to a group of views. For example, we might use it to change text formatting, line limits, or layout behavior across multiple views. Note that not all environment values can be written to, some values are read-only and are managed by the system.

When we set an environment value, it affects all child views of the view where the modifier is applied, unless overridden later in the hierarchy.

struct ContentView: View {
    var body: some View {
        VStack(spacing: 30) {
            Text("Welcome to SwiftUI")
                .font(.title)
            Text("SwiftUI is a powerful UI framework.")
                .font(.body)
        }
        .padding()
        .multilineTextAlignment(.center)
        .environment(\.textCase, .uppercase)
    }
}

In this example, the textCase environment value is set to uppercase for all views within the VStack. As a result, both text views will display their content in uppercase letters. If needed, this setting can be overridden for specific child views by applying a different value at a lower level in the hierarchy.

# Custom environment values

SwiftUI lets us define custom environment values to share our own data across views in a flexible way. This allows us to inject values into the view hierarchy, so child views can access them without needing to pass properties manually. We can do this by extending the EnvironmentValues structure and defining a new property using the @Entry macro. Note that to be able to use @Entry, you'll need to build your apps with Xcode 16 or newer.

Imagine we are building an app where different views behave differently based on the user's role. We can create a custom environment value that holds the user role.

enum UserRole {
    case admin, regular, guest
}

extension EnvironmentValues {
    @Entry var userRole: UserRole = .guest
}

We can then set the user role on the application level and every view can read it from the environment.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(\.userRole, .admin)
        }
    }
}

struct ContentView: View {    
    var body: some View {
        UserRoleView()
    }
}

struct UserRoleView: View {
    @Environment(\.userRole)
    private var userRole
    
    var body: some View {
        Text("Current role: \(userRole)")
            .font(.title)
    }
}

Using custom environment values makes it easy to manage context-specific information without cluttering our view with manually passed properties.

# Environment-based view modifiers

SwiftUI offers dedicated methods on the View struct to set environment values, which make our code more readable and concise. Instead of using the environment() modifier directly, these dedicated methods provide a cleaner and more expressive way to set environment values.

For instance, rather than setting the textCase environment value manually by applying environment(\.textCase, .uppercase) to a view, we can use the built-in textCase() modifier. Under the hood, it still works exactly the same way and passes the value down the view hierarchy and sets it for all the Text views, unless it's overridden further down the stack.

struct ContentView: View {
    var body: some View {
        VStack(spacing: 30) {
            Text("Welcome to SwiftUI")
                .font(.title)
            Text("SwiftUI is a powerful UI framework.")
                .font(.body)
        }
        .padding()
        .multilineTextAlignment(.center)
        .textCase(.uppercase)
    }
}

To follow the same API design, we can define such view modifiers to set custom environment values as well.

extension View {
    func userRole(_ role: UserRole) -> some View {
        environment(\.userRole, role)
    }
}

This custom method encapsulates the process of setting the userRole environment value, making it easier to use in different parts of the app.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .userRole(.admin)
        }
    }
}

# Actions in SwiftUI environment

In addition to environment values, SwiftUI also injects certain actions into the environment, allowing views to perform specific tasks, such as opening a URL or dismissing a modal. These actions are defined as structs that behave like functions because they use Swift’s callAsFunction() feature. This makes them simple to use, as you can interact with them like regular functions, even though they are structs. You can learn more about this Swift feature in my book Swift Gems.

One commonly used action is the OpenURLAction, which allows us to open a URL in the default browser or another app. We can access it via the openURL environment value and call it with the URL we want to open.

struct ContentView: View {
    @Environment(\.openURL) private var openURL
    
    private let url = URL(string: "https://www.example.com")!
    
    var body: some View {
        Button("Check out our website") {
            openURL(url)
        }
    }
}

We can also override the default OpenURLAction in the environment if we need to customize its behavior. For example, we can create an action that processes the URL before it's opened, logs the link click, or navigates to a different screen in the app, instead of opening the link in a browser. This is particularly useful when we want to define custom behavior for links embedded within text views.

struct ContentView: View {
    var body: some View {
        Text("Check out [our policy](https://example.com) for more details.")
            .environment(\.openURL, OpenURLAction { url in
                handleURL(url)
                return .handled
            })
    }
    
    func handleURL(_ url: URL) {
        // handle URL here
        print("Link clicked: \(url.absoluteString)")
    }
}

In this example, we customize the openURL environment to call handleURL() whenever the link is clicked, allowing us to handle the URL in a specific way.

# Using environment for observable classes

With iOS 17 and the introduction of the Observation framework, SwiftUI’s environment has become even more versatile, allowing us to pass reference types marked with @Observable through the environment. Before iOS 17, the environment was primarily used for value types. If we needed to pass a class that conformed to ObservableObject, we had to use the dedicated environmentObject() modifier and access it with the @EnvironmentObject property wrapper. Now, with the enhanced environment support in iOS 17, we can use the environment() modifier to pass a reference type directly and read it using the @Environment property wrapper.

Here’s an example of how to pass an observable class through the environment:

import SwiftUI
import Observation

@Observable
class DataModel {
    var count = 0
}

@main
struct MyApp: App {
    @State
    private var dataModel = DataModel()
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(dataModel)
        }
    }
}

struct ContentView: View {
    var body: some View {
        IncrementCountView()
            .padding()
    }
}

struct IncrementCountView: View {
    @Environment(DataModel.self)
    private var dataModel
    
    var body: some View {
        VStack(spacing: 10) {
            Button("Increment") {
                dataModel.count += 1
            }
            Text("Count: \(dataModel.count)")
        }
    }
}

In this example, we define a DataModel class that will be used across multiple views. We initialize our data model at the top level of the app and make it available to all child views using the environment() modifier. In IncrementCountView, we then access the shared DataModel instance using the @Environment property wrapper with the object type, instead of a key path.

This new approach simplifies passing reference types through the environment, making it easier to share data models across views in a clean and consistent way.

The SwiftUI environment is a powerful way to share data and configurations across our views. We can read predefined values from the EnvironmentValues struct to adjust our views or override them to customize built-in components. We can also define our custom values to avoid cluttering our code with extra properties and create additional view methods to make it easier to set those values in the hierarchy. The environment also gives us access to system actions, like opening URLs, and allows us to customize their behavior. Finally, starting from iOS 17, we can use these same mechanisms to pass down reference types, simplifying state management throughout the app.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

Sorting arrays in Swift can be made more concise and readable by using comparison operators as closures. Swift’s sorted(by:) method allows us to pass operators like < or > directly, leveraging their ability to compare elements.

For example:

let numbers = [3, 1, 4, 1, 5, 9, 2]

// [1, 1, 2, 3, 4, 5, 9]
let ascending = numbers.sorted(by: <)

// [9, 5, 4, 3, 2, 1, 1]
let descending = numbers.sorted(by: >)

Here, < and > act as shorthand for closures, making the code more expressive and easier to understand. This technique elegantly utilizes Swift’s functional programming capabilities.

You can learn more about Sorting arrays using comparison operators as closures and many other Swift techniques in my book Swift Gems. It offers 100+ advanced Swift tips, from optimizing collections and leveraging generics, to async patterns, powerful debugging techniques, and more - each designed to make your code clearer, faster, and easier to maintain.

With the release of iOS 17 last year, Apple introduced the Observation framework, providing a Swift-specific implementation of the observer design pattern. This framework allows us to use the @Observable macro in SwiftUI as a way to provide observable data to our views.

Switching from the older ObservableObject to the new @Observable macro can be a good choice. This new approach lets us use familiar tools like State and Environment, instead of their object-based equivalents, making our code simpler and easier to work with. It can also help improve performance by only updating views when the properties they rely on change.

As iOS 18 approaches and we might consider dropping support for versions below iOS 17 soon, I thought that now is a great time to explore how we can use Observation in our SwiftUI projects.

# Declare and initialize an Observable

To start using @Observable, we apply the macro to a class. This allows SwiftUI to observe changes in the class's properties and update the UI accordingly. Here's a simple example:

import SwiftUI
import Observation

@Observable
class DataModel {
    var count = 0
}

struct ContentView: View {
    @State private var dataModel = DataModel()
    
    var body: some View {
        VStack(spacing: 10) {
            Button("Increment") {
                dataModel.count += 1
            }
            Text("Count: \(dataModel.count)")
        }
        .padding()
    }
}

In this example, the count property updates whenever the button is pressed, and the text view immediately reflects the new count. This approach makes it easy to keep our UI in sync with our data.

# Share an Observable between a parent and a child view

If we have a more complex view hierarchy, we can define our observable data higher up and pass it down through the views. This allows different parts of the app to share the same data model without needing to manually synchronize changes.

struct ContentView: View {
    @State private var dataModel = DataModel()
    
    var body: some View {
        VStack(spacing: 10) {
            IncrementButton(dataModel: dataModel)
            Text("Count: \(dataModel.count)")
        }
        .padding()
    }
}

struct IncrementButton: View {
    var dataModel: DataModel
    
    var body: some View {
        Button("Increment") {
            dataModel.count += 1
        }
    }
}

# Pass an Observable through the environment

We can also initialize our data model at the top level of the app and make it available to all child views using the environment() modifier. This way, we can easily access our data model by its type anywhere in the app.

import SwiftUI
import Observation

@main
struct MyApp: App {
    @State private var dataModel = DataModel()
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(dataModel)
        }
    }
}

struct ContentView: View {
    @Environment(DataModel.self) private var dataModel
    
    var body: some View {
        VStack(spacing: 10) {
            IncrementButton()
            Text("Count: \(dataModel.count)")
        }
        .padding()
    }
}

struct IncrementButton: View {
    @Environment(DataModel.self) private var dataModel
    
    var body: some View {
        Button("Increment") {
            dataModel.count += 1
        }
    }
}

# Create bindings to properties of an Observable

To create bindings to the mutable properties of an observable class, we need to mark it as bindable using the @Bindable property wrapper. This allows us to create bindings directly from the observable properties, which can then be passed down to child views.

struct ContentView: View {
    @Environment(DataModel.self) private var dataModel
    
    var body: some View {
        @Bindable var dataModel = dataModel
        
        VStack(spacing: 10) {
            IncrementButton(count: $dataModel.count)
            Text("Count: \(dataModel.count)")
        }
        .padding()
    }
}

struct IncrementButton: View {
    @Binding var count: Int
    
    var body: some View {
        Button("Increment") {
            count += 1
        }
    }
}

Note that in this example, it's important to place the @Bindable declaration at the top of the body. Placing it inside the VStack will cause a linker error Undefined symbol: unsafeMutableAddressor of self #1 : Observable.ContentView in Observable.ContentView.body.getter : some.

# @Observable vs ObservableObject

One of the biggest advantages of the new @Observable compared to the old ObservableObject is that views depending on it will only be re-rendered when the properties they read in their body change.

Here is an example of an @Observable with two mutable properties, count1 and count2:

import SwiftUI
import Observation

@Observable
class DataModel {
    var count1 = 0
    var count2 = 0
}

@main
struct MyApp: App {
    @State private var dataModel = DataModel()
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(dataModel)
        }
    }
}

struct ContentView: View {
    var body: some View {
        VStack(spacing: 40) {
            Count1()
            Count2()
        }
        .padding()
    }
}

struct Count1: View {
    @Environment(DataModel.self) private var dataModel
    
    var body: some View {
        let _ = Self._printChanges()
        @Bindable var dataModel = dataModel
        VStack(spacing: 10) {
            IncrementButton(count: $dataModel.count1)
            Text("Count 1: \(dataModel.count1)")
        }
    }
}

struct Count2: View {
    @Environment(DataModel.self) private var dataModel
    
    var body: some View {
        let _ = Self._printChanges()
        @Bindable var dataModel = dataModel
        VStack(spacing: 10) {
            IncrementButton(count: $dataModel.count2)
            Text("Count 2: \(dataModel.count2)")
        }
    }
}

struct IncrementButton: View {
    @Binding var count: Int
    
    var body: some View {
        Button("Increment") {
            count += 1
        }
    }
}

If we have two different views to display the two count values, and each of the views only reads one value in the body, the view body will only be recalled when that particular count value changes. We put Self._printChanges() here for debugging purposes to see which view body is called. If we run the app and only increment the first count, we will only see Count1: @dependencies changed. printed in the Xcode console each time we increment it. The body of the Count2 view will not be called.

Comparing this to using ObservableObject with @Published properties:

import SwiftUI

class DataModel: ObservableObject {
    @Published var count1 = 0
    @Published var count2 = 0
}

@main
struct MyApp: App {
    @StateObject private var dataModel = DataModel()
    
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environmentObject(dataModel)
        }
    }
}

struct ContentView: View {
    var body: some View {
        VStack(spacing: 40) {
            Count1()
            Count2()
        }
        .padding()
    }
}

struct Count1: View {
    @EnvironmentObject private var dataModel: DataModel
    
    var body: some View {
        let _ = Self._printChanges()
        VStack(spacing: 10) {
            IncrementButton(count: $dataModel.count1)
            Text("Count 1: \(dataModel.count1)")
        }
    }
}

struct Count2: View {
    @EnvironmentObject private var dataModel: DataModel
    
    var body: some View {
        let _ = Self._printChanges()
        VStack(spacing: 10) {
            IncrementButton(count: $dataModel.count2)
            Text("Count 2: \(dataModel.count2)")
        }
    }
}

struct IncrementButton: View {
    @Binding var count: Int
    
    var body: some View {
        Button("Increment") {
            count += 1
        }
    }
}

If we run this version of the app, we'll see both Count2: _dataModel changed. and Count1: _dataModel changed. printed in the console every time we increment a count. That's because with ObservableObject, if a view reads even one published property, it will be re-rendered when any published property changes. This often led to unnecessary re-renders in the past when using ObservableObject, causing views to update for no reason. With the new @Observable, we don't have this risk.

If you want to build a strong foundation in SwiftUI, my new book SwiftUI Fundamentals takes a deep dive into the framework’s core principles and APIs to help you understand how it works under the hood and how to use it effectively in your projects.

For more resources on Swift and SwiftUI, check out my other books and book bundles.

In Swift, an enumeration (enum) is a type that groups related values together. Recursive enums take this concept further by allowing an enum to include instances of itself within its cases. This feature is particularly useful when modeling data that is nested or recursive in nature. By enabling a type to reference itself, recursive enums provide a straightforward and type-safe way to represent complex relationships, like those found in file systems or organizational structures.

To allow recursion within an enum, Swift uses the indirect keyword. This keyword instructs Swift to handle the enum's memory in a way that supports safe recursion, preventing issues that could arise from circular references.

Consider the task of modeling a file system where folders can contain both files and other folders. This hierarchical structure is a perfect example of where a recursive enum can be effectively used. Here’s how we can define such a system in Swift:

enum FileSystemItem {
    case file(name: String)
    case folder(name: String, items: [FileSystemItem])
    indirect case alias(name: String, to: FileSystemItem)
}

In this example, FileSystemItem has three cases. The file case represents a single file with a name. The folder case represents a directory that can contain an array of FileSystemItem instances, allowing it to hold files and other folders. The alias case, marked with indirect, represents a symbolic link or shortcut that references another FileSystemItem. The indirect keyword is necessary here because the alias case directly references another instance of the FileSystemItem enum.

Using this recursive enum, we can easily create a simple file system. Imagine we have two files that we want to place inside a "Documents" folder. Additionally, we want to create an alias to one of these files within a "Desktop" folder:

let imageFile = FileSystemItem.file(name: "photo.png")
let textFile = FileSystemItem.file(name: "notes.txt")

let documentsFolder = FileSystemItem.folder(
    name: "Documents",
    items: [imageFile, textFile]
)

let profileImageAlias = FileSystemItem.alias(name: "ProfileImage", to: imageFile)

let desktopFolder = FileSystemItem.folder(
    name: "Desktop",
    items: [documentsFolder, profileImageAlias]
)

In this setup, imageFile and textFile are individual files, while documentsFolder is a folder containing these files. The profileImageAlias is an alias pointing to the imageFile, and desktopFolder contains both the documentsFolder and the alias. This structure illustrates how recursive enums can be used to create a hierarchical, yet easily manageable file system with the added flexibility of aliases.

To count the total number of items (files, folders, and aliases) in a folder, including those in subfolders and through aliases, we can write a recursive function:

func countItems(in item: FileSystemItem) -> Int {
    switch item {
    case .file:
        return 1
    case .folder(_, let items):
        return items.map(countItems).reduce(0, +)
    case .alias(_, let to):
        return countItems(in: to)
    }
}

let totalItems = countItems(in: desktopFolder)
print("Total items: \(totalItems)")

This function works by returning 1 for each file, recursively counting the items within each folder, and handling aliases by counting the items they reference. The reduce() function sums these counts to provide the total number of items, regardless of how deeply nested they are or how many aliases exist.

The use of the indirect keyword in the alias case is essential for enabling recursion in enums like this. The indirect keyword is required when a case directly references the enum itself, as seen in the alias case (alias(name: String, to: FileSystemItem)). However, when the reference is through a collection type, such as an array in items: [FileSystemItem], the compiler does not require indirect because the array itself introduces the necessary level of indirection.

Recursive enums are a powerful feature in Swift that allow us to model complex, hierarchical data structures like file systems with clarity and precision. By understanding how and when to use the indirect keyword, we can leverage recursive enums to create robust and maintainable models for a variety of applications.

If you're an experienced Swift developer looking to level up your skills, take a look at my book Swift Gems. It offers 100+ advanced Swift tips, from optimizing collections and leveraging generics, to async patterns, powerful debugging techniques, and more - each designed to make your code clearer, faster, and easier to maintain.

When developing our app Exsto, we needed to add GPU rendering to the app. As the curves are drawn by users with their fingers or pencil, the strokes end up with many hundreds, if not thousands, of points with multiple self-intersecting sections. What we settled on is by no means the most optimal method, nor have we implemented it in the most optimal way. However, we do believe it is one of the simplest solutions we have come across while researching the topic.

The method we present is a partial implementation of the algorithm in Kokojima et al. 2006 paper. The reason it is not a full implementation of Kokojima's solution is that we have not adopted their more optimal multi-sampling method and have rather followed a simpler, more costly, brute-force approach, as the performance difference on Apple GPUs is likely minimal.

Since these curves can (and commonly do) have many self-intersecting loops with a mixture of convex and concave curve sections, most solutions end up with a complex pre-processing stage that builds a detailed (non-overlapping) geometry. Kokojima et al. trades off this complexity for extra GPU rendering cost.

The Kokojima et al. method consists of three distinct steps. The initial two steps are dedicated to setting up a stencil buffer, while the final step is responsible for shading the stenciled area.

# Rendering your first curve

This method can only be used to render a CGPath that is made of moveToPoint, addQuadCurveToPoint and addLineToPoint CGPathElements.

For this post we will be re-creating the steps needed to render this curve.

The curve has multiple self-intersecting segments and is a good example of the types of curves created in our app Exsto.

# The triangle fan

The first step requires creating a triangle fan about a pivot including all of the points on the curve (but not the control points). We can use any pivot point, so for simplicity, we use the first point of the curve.

This is rendered into the stencil buffer using the invert operation. The stencil starts out with a value of 0, so only areas with an odd number of overlapping triangles end up set within the stencil.

// Invert for back facing primitives
depthStencilDescriptor.frontFaceStencil.depthStencilPassOperation = .invert
depthStencilDescriptor.backFaceStencil.depthStencilPassOperation = .invert

// Do not skip any primitives
depthStencilDescriptor.backFaceStencil.stencilCompareFunction = .always
depthStencilDescriptor.frontFaceStencil.stencilCompareFunction = .always
depthStencilDescriptor.frontFaceStencil.readMask = 0
depthStencilDescriptor.backFaceStencil.readMask = 0

We do not need to render any color values, so we do not attach a fragment function.

Notice how the upper left region of the stencil map has a chunk cut away. Looking back at the triangles in the geometry image, you can see the overlapping section that resulted in an even number of inversions on the stencil.

# Convex and concave curves

We render the curves by collecting all curve segments, including the control point, and creating a sequence of triangles with the control point as the second point in each triangle.

We apply a fragment shader to discard pixels outside the quadratic curve. Here we further update the stencil using the same invert function. The fragment function does not set any color values, so it has a void return type.

For maximum GPU compatibility, we use UV coordinates set in the vertex stage. Metal interpolates these for each pixel of the fragment shader. To set these coordinates within your vertex function, set the start point on each triangle as [0, 0], the control point as [0.5, 0], and the final point on the curve as [1, 1].

vertex CurvedVertexOut curveVertexFunction(
    uint vertexId [[vertex_id]],
    uint vertexOffset [[base_vertex]],
    constant simd_float2 *vertices [[buffer(0)]],
    constant MTLSceneState *sceneStatePointer [[buffer(1)]]

) {
    CurvedVertexOut out;
    float2 pixelSpacePosition = vertices[vertexId].xy;
    MTLSceneState sceneState = MTLSceneState(*sceneStatePointer);
    
    out.position = position(pixelSpacePosition, sceneState);
    
    // Compute UV values for interpolation
    uint adjustedIndex = vertexId - vertexOffset;
    uint vertexNumber = adjustedIndex % 3;
    out.uv.x = half(vertexNumber) * 0.5h;
    out.uv.y = floor(out.uv.x);
    return out;
}