Mastering Anchor Preferences in SwiftUI for Dynamic Layouts

Understanding SwiftUI's Layout System and Its Limitations

SwiftUI's declarative nature makes UI development intuitive. You describe what your UI should look like, and SwiftUI handles the 'how'. However, this unidirectional data flow for layout information—from parent to child—can sometimes be a limitation. While a parent view dictates its children's positions and sizes (at least in part, based on their preferred sizes), children typically can't directly inform a parent about their actual computed layout metrics.

Consider a scenario where you want to draw an overlay that perfectly matches the frame of one of your child views, but the parent view needs to render this overlay. Or perhaps you want to animate a transition based on the initial and final positions of a view that changes its place in the hierarchy. Without a mechanism to push layout information up, these tasks become challenging, often requiring imperative GeometryReader hacks or complex coordinate space conversions. This is precisely the problem Anchor Preferences solve, providing a declarative and elegant solution.

What Are Anchor Preferences?

Anchor Preferences are a sophisticated mechanism introduced in SwiftUI (iOS 13.0+, macOS 10.15+) that allows child views to communicate their layout metrics (like size, position, or specific anchor points) up the view hierarchy to a parent view. Unlike regular Preference keys which accumulate simple values, AnchorPreference keys deal with Anchor<Value> types. An Anchor<Value> is a proxy for a specific point or frame in a view's coordinate space that can be resolved into a concrete CGRect or CGPoint later, when the layout is finalized.

The power of Anchor Preferences lies in their ability to capture layout information after the child view has been laid out, but before the parent view needs to react to that information. This ensures that the parent receives accurate, post-layout data. You define a custom AnchorKey that specifies how values are combined when multiple child views contribute, and then attach modifiers to your views to publish and consume these preferences.

The Core Components:

1. PreferenceKey (specifically AnchorKey): You define a custom AnchorKey conforming to PreferenceKey that holds an Anchor<CGRect> or Anchor<CGPoint>. It must implement defaultValue and a reduce(value:next:) static method to combine multiple preferences.
2. .anchorPreference(key:value:): This view modifier is attached to a child view to publish an anchor or a collection of anchors up the view hierarchy. You provide a key path to the desired anchor (.bounds, .top, .center, etc.).
3. .onPreferenceChange(key:_:): This view modifier is attached to a parent view (or an ancestor) to read the preference value. The closure receives the accumulated preference value when it changes.
4. GeometryReader: Often used in conjunction with .onPreferenceChange to resolve the into concrete layout metrics within a specific coordinate space. 's or methods are crucial here.

Defining a Custom AnchorKey

The first step is to define a custom PreferenceKey that will carry our anchor information. This key must conform to PreferenceKey where its Value is an Anchor<CGRect> (or Anchor<CGPoint>). The reduce static method is particularly important as it dictates how multiple values of the same key, published by different child views, are combined. For layout information, you typically want to either collect all of them into an array or select one specific anchor.

Let's create a key to track the bounding CGRect of specific views.

import SwiftUI

struct ItemRectsKey: PreferenceKey {
    static var defaultValue: [Int: Anchor<CGRect>] = [: ]

    static func reduce(value: inout [Int: Anchor<CGRect>], next: () -> [Int: Anchor<CGRect>]) {
        // Merge new preferences into the existing dictionary
        value.merge(next()) { (current, new) in new }
    }
}

Publishing Anchor Preferences from Child Views

Now that we have our PreferenceKey, we can attach the .anchorPreference modifier to any child view from which we want to extract layout information. This modifier takes the PreferenceKey type and a closure that returns the anchor value to publish. You typically use a GeometryProxy inside this closure to access a view's anchor.

In this example, we'll create a list of items and publish their individual frames, keyed by their index.

import SwiftUI

// (ItemRectsKey definition from above here)

struct ItemView: View {
    let id: Int
    let text: String
    let color: Color

    var body: some View {
        Text(text)
            .font(.headline)
            .padding()
            .background(color.opacity(0.8))
            .cornerRadius(8)
            .anchorPreference(key: ItemRectsKey.self, value: .bounds) { anchor in
                // Publish this view's bounds anchor, keyed by its ID
                [id: anchor]
            }
    }
}

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Tap an item to see its frame!").font(.title2).padding()
            
            HStack {
                ItemView(id: 0, text: "Swift", color: .blue)
                ItemView(id: 1, text: "UI", color: .green)
                ItemView(id: 2, text: "Layout", color: .red)
            }
        }
    }
}

Consuming and Resolving Anchor Preferences

The final step is to consume these published preferences in an ancestor view. You use the .onPreferenceChange modifier, which provides the accumulated value whenever it changes. Inside the closure, you'll often need a GeometryReader to resolve the Anchor<Value> into concrete CGRects or CGPoints within a specific coordinate space. The GeometryProxy's anchor(_:) method is key here, which takes an Anchor<Value> and returns the resolved Value in the GeometryReader's coordinate space.

Let's extend our ContentView to draw a border around the last selected item using the collected preferences. We'll add a state variable to track the selected item's ID.

import SwiftUI

// (ItemRectsKey and ItemView definitions from above here)

struct ContentView: View {
    @State private var selectedItemID: Int? = nil
    @State private var selectedItemRect: CGRect? = nil

    var body: some View {
        VStack {
            Text("Tap an item to highlight it.").font(.title2).padding()
            
            HStack {
                ItemView(id: 0, text: "Swift", color: .blue)
                    .onTapGesture { selectedItemID = 0 }
                ItemView(id: 1, text: "UI", color: .green)
                    .onTapGesture { selectedItemID = 1 }
                ItemView(id: 2, text: "Layout", color: .red)
                    .onTapGesture { selectedItemID = 2 }
            }
            .padding()
        }
        .overlayPreferenceValue(ItemRectsKey.self) { preferences in
            // Use a GeometryReader to resolve the anchored preferences
            GeometryReader {
                geometry in
                self.createHighlightOverlay(geometry: geometry, preferences: preferences)
            }
        }
    }

    @ViewBuilder
    private func createHighlightOverlay(geometry: GeometryProxy, preferences: [Int: Anchor<CGRect>]) -> some View {
        if let id = selectedItemID,
           let anchor = preferences[id],
           let rect = geometry[anchor] {
            Rectangle()
                .stroke(Color.yellow, lineWidth: 3)
                .frame(width: rect.size.width,
                       height: rect.size.height)
                .offset(x: rect.minX, y: rect.minY)
                .animation(.easeInOut(duration: 0.2), value: rect)
        }
    }
}

// Preview Provider
#if DEBUG
struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}
#endif

Advanced Usage: Animating with Anchor Preferences

Anchor preferences are incredibly powerful for animations, especially when a view moves between different parts of the screen or changes its size. By capturing the 'before' and 'after' anchors, you can precisely animate custom effects.

Consider a scenario where you want to animate a custom transition of a ProgressView from a collapsed state to an expanded state, where its final position is determined by an AnchorPreference. You can use transaction and animation modifiers to smoothly transition between preference updates.

Another common advanced use case involves forEach loops where items might dynamically appear or disappear. You can collect all item anchors, and when an item is removed, its last known anchor can be used to animate a 'fly-off' effect or to adjust the layout of other items smoothly. The reduce function in your PreferenceKey becomes crucial for managing these dynamic sets of anchors.

import SwiftUI

// Defines a custom PreferenceKey to store a single Anchor<CGPoint>
// This key will store the center of the 'TargetView'
struct TargetCenterKey: PreferenceKey {
    static var defaultValue: Anchor<CGPoint>? = nil

    static func reduce(value: inout Anchor<CGPoint>?, next: () -> Anchor<CGPoint>?) {
        // We only care about the last value provided if multiple views published
        value = next() ?? value
    }
}

struct DynamicAnimationView: View {
    @State private var showCircle = false
    @State private var targetRect: CGRect = .zero

    var body: some View {
        VStack {
            Spacer()
            
            Button("Toggle Circle") {
                withAnimation(.spring()) {
                    showCircle.toggle()
                }
            }
            .padding()

            if showCircle {
                Circle()
                    .fill(Color.orange)
                    .frame(width: 50, height: 50)
                    .offset(x: -100, y: -50) // Starting position
                    .transition(.move(edge: .leading))
            } else {
                // The 'target' for the circle when it's NOT shown
                Text("Target Position")
                    .font(.title)
                    .padding()
                    .background(Color.gray.opacity(0.2))
                    .cornerRadius(10)
                    .anchorPreference(key: TargetCenterKey.self, value: .center) { anchor in
                        // Publish the center anchor of this Text view
                        anchor
                    }
                    .onPreferenceChange(TargetCenterKey.self) { anchor in
                        // Resolve the anchor to get the actual CGPoint
                        if let anchor = anchor {
                            // This is where you would usually use a GeometryReader
                            // to resolve 'anchor'. For simplicity, we'll skip
                            // setting targetRect directly here as it's for demonstration.
                            // In a real app, you'd wrap this parent in GeometryReader
                            // and resolve 'anchor' using geometry[anchor].
                            print("Target center anchor changed: \(anchor)")
                        }
                    }
            }
            Spacer()
        }
        // Apply the preference reading to the common ancestor
        // The .overlayPreferenceValue is often a better choice for drawing overlays.
        .overlayPreferenceValue(TargetCenterKey.self) { centerAnchor in
             GeometryReader { geometry in
                 // Draw a marker at the resolved center point
                 if let center = geometry[centerAnchor] {
                     Circle()
                         .stroke(Color.purple, lineWidth: 2)
                         .frame(width: 10, height: 10)
                         .offset(x: center.x - 5, y: center.y - 5)
                 }
             }
         }
    }
}

Common Pitfalls and Best Practices

While powerful, Anchor Preferences can introduce complexity if not used carefully. Here are some common pitfalls and best practices:

• Performance: onPreferenceChange can be called frequently during layout passes. Avoid performing heavy computations inside its closure. Only update minimal state or trigger necessary downstream updates.
• Infinite Loops: Be cautious when updating state variables directly within onPreferenceChange. If the state change causes a layout recalculation that in turn changes the preference, you could end up in an infinite loop. It's often safer to use these values for drawing overlays or informing a distinct layout pass that won't immediately feedback into the preference source.
• Coordinate Spaces: Always be mindful of coordinate spaces. An Anchor<CGRect> from a child view is relative to that child's local coordinate space. When you resolve it using GeometryProxy, geometry[anchor] converts it into the GeometryReader's coordinate space. Ensure you are comparing or drawing in the correct space.
• reduce(value:next:) Implementation: This is critical. If your key collects an array of anchors, make sure your reduce function correctly appends or merges them. If it's a single value, decide whether to take the first, last, or combine them.
• overlayPreferenceValue vs. onPreferenceChange: For drawing dynamic overlays based on child view layouts, overlayPreferenceValue (or ) is often more idiomatic and performs better than followed by an or modifier. directly consumes the preferences to build a view in the overlay, avoiding a state update cycle.

When to Use Anchor Preferences

Anchor preferences are your go-to solution for specific layout challenges:

• Drawing Arrows/Indicators: When you need to draw an arrow or line from one view to another, or point to a specific element on screen.
• Highlighting/Overlaying: Creating dynamic highlight boxes or overlays around existing UI elements, like in our example.
• Custom Transitions/Animations: Animating views from one arbitrary position to another, leveraging precise start and end frame information.
• Alignment Guides: Implementing complex custom alignment logic where a parent needs to align views based on a child's specific internal point.
• Multi-View Coordination: Scenarios where several views contribute layout information that a common ancestor needs to aggregate and react to.

Compatibility Notes

Anchor Preferences were introduced with the initial release of SwiftUI. Therefore, they are available on:

• iOS 13.0+
• macOS 10.15+
• tvOS 13.0+
• watchOS 6.0+

This broad compatibility means you can confidently use them in most modern SwiftUI projects. Always verify your deployment targets.