1# SwiftUI View Structure Reference
2 
3## Table of Contents
4 
5- [View Structure Principles](#view-structure-principles)
6- [View File Structure (optional readability suggestion)](#view-file-structure-optional-readability-suggestion)
7- [Struct or Method / Computed Property?](#struct-or-method--computed-property)
8- [Prefer Modifiers Over Conditional Views](#prefer-modifiers-over-conditional-views)
9- [Extract Subviews, Not Computed Properties](#extract-subviews-not-computed-properties)
10- [@ViewBuilder](#viewbuilder)
11- [Keep View Body Simple and Avoid High-Cost Operations](#keep-view-body-simple-and-avoid-high-cost-operations)
12- [Keep View `init` Cheap](#keep-view-init-cheap)
13- [Single-Child Group](#single-child-group)
14- [When to Extract Subviews](#when-to-extract-subviews)
15- [Container View Pattern](#container-view-pattern)
16- [Utilize Lazy Containers for Large Data Sets](#utilize-lazy-containers-for-large-data-sets)
17- [ZStack vs overlay/background](#zstack-vs-overlaybackground)
18- [Compositing Group Before Clipping](#compositing-group-before-clipping)
19- [Split State-Driven Parts into Custom View Types](#split-state-driven-parts-into-custom-view-types)
20- [Reusable Styling with ViewModifier](#reusable-styling-with-viewmodifier)
21- [Skeleton Loading with Redacted Views](#skeleton-loading-with-redacted-views)
22- [AnyView](#anyview)
23- [UIViewRepresentable Essentials](#uiviewrepresentable-essentials)
24- [Troubleshooting](#troubleshooting)
25- [Summary Checklist](#summary-checklist)
26 
27## View Structure Principles
28 
29SwiftUI's diffing algorithm compares view hierarchies to determine what needs updating. Proper view composition directly impacts performance.
30 
31## View File Structure (optional readability suggestion)
32 
33Property ordering has no effect on correctness or performance, so treat this as a personal/team readability preference rather than a rule. Some developers find a consistent order easier to scan — for example, environment, then state, then passed-in properties, then `init`, body, and helper subviews. Adopt it only if your team wants the consistency; never reorder existing code solely to match it.
34 
35```swift
36struct ContentView: View {
37    // MARK: - Environment Properties
38    @Environment(\.colorScheme) var colorScheme
39 
40    // MARK: - State Properties
41    @Binding var isToggled: Bool
42    @State private var viewModel: SomeViewModel
43 
44    // MARK: - Private Properties
45    private let title: String = "SwiftUI Guide"
46 
47    // MARK: - Initializer (if needed)
48    init(isToggled: Binding<Bool>) {
49        self._isToggled = isToggled
50    }
51 
52    // MARK: - Body
53    var body: some View {
54        VStack {
55            header
56            content
57        }
58    }
59 
60    // MARK: - Computed Subviews
61    private var header: some View {
62        Text(title).font(.largeTitle).padding()
63    }
64 
65    private var content: some View {
66        VStack {
67            Text("Counter: \(counter)")
68        }
69    }
70}
71```
72 
73## Struct or Method / Computed Property?
74 
75If a `View` is intended to be reusable across multiple screens, encapsulate it within a separate `struct`. If its usage is confined to a single context, it can be declared as a function or computed property within the containing `View`.
76 
77However, if a view maintains state using `@State`, `@Binding`, `@ObservedObject`, `@Environment`, `@StateObject`, or similar wrappers, it should generally be a separate `struct`.
78 
79- For simple, static views: a computed property is acceptable.
80- For views requiring parameters: a method is more appropriate, but only when those parameters are stable. If parameters change per-call (e.g. inside a `ForEach` where each call receives a different item), prefer a separate `struct` so SwiftUI can diff inputs and skip body evaluation.
81- For reusable, stateful, or logically independent UI sections: prefer a dedicated `struct`.
82 
83```swift
84struct ContentView: View {
85    var titleView: some View {
86        Text("Hello from Property")
87            .font(.largeTitle)
88            .foregroundColor(.blue)
89    }
90 
91    func messageView(text: String, color: Color) -> some View {
92        Text(text)
93            .font(.title)
94            .foregroundColor(color)
95            .padding()
96    }
97 
98    var body: some View {
99        VStack {
100            titleView
101            messageView(text: "Hello from Method", color: .red)
102        }
103    }
104}
105```
106 
107## Prefer Modifiers Over Conditional Views
108 
109**Prefer "no-effect" modifiers over conditionally including views.** When you introduce a branch, consider whether you're representing multiple views or two states of the same view.
110 
111### Use Opacity Instead of Conditional Inclusion
112 
113```swift
114// Good - same view, different states
115SomeView()
116    .opacity(isVisible ? 1 : 0)
117 
118// Avoid - creates/destroys view identity
119if isVisible {
120    SomeView()
121}
122```
123 
124**Why**: Conditional view inclusion can cause loss of state, poor animation performance, and breaks view identity. Using modifiers maintains view identity across state changes.
125 
126### When Conditionals Are Appropriate
127 
128Use conditionals when you truly have **different views**, not different states:
129 
130```swift
131// Correct - fundamentally different views
132if isLoggedIn {
133    DashboardView()
134} else {
135    LoginView()
136}
137 
138// Correct - optional content
139if let user {
140    UserProfileView(user: user)
141}
142```
143 
144### Conditional View Modifier Extensions Break Identity
145 
146A common pattern is an `if`-based `View` extension for conditional modifiers. This changes the view's return type between branches, which destroys view identity and breaks animations:
147 
148```swift
149// Problematic -- different return types per branch
150extension View {
151    @ViewBuilder func `if`<T: View>(_ condition: Bool, transform: (Self) -> T) -> some View {
152        if condition {
153            transform(self)  // Returns T
154        } else {
155            self              // Returns Self
156        }
157    }
158}
159```
160 
161Prefer applying the modifier directly with a ternary or always-present modifier:
162 
163```swift
164// Good -- same view identity maintained
165Text("Hello")
166    .opacity(isHighlighted ? 1 : 0.5)
167 
168// Good -- modifier always present, value changes
169Text("Hello")
170    .foregroundStyle(isError ? .red : .primary)
171```
172 
173When writing new code, never reach for a `.if` modifier. When reviewing existing code that already uses one, point out the identity/animation risk and show the ternary alternative, but don't silently refactor it as part of an unrelated change — swapping it can alter behavior (state resets, transition timing) and belongs in its own focused edit.
174 
175## Extract Subviews, Not Computed Properties
176 
177A view is SwiftUI's unit of invalidation. When an input changes, SwiftUI re-runs the body of the smallest enclosing **view type** that depends on it — every conditional, modifier chain, and string interpolation in that body, even if only one leaf actually depends on what changed. A computed property or `@ViewBuilder` helper is inlined into the parent's body, so it shares the parent's invalidation boundary and does not reduce update cost; it only reorganizes the code. A separate `View` type with narrow inputs becomes its own boundary and re-runs only when its own inputs change.
178 
179This is why "split your body for readability" is also a performance tool — but only when you split into real `View` types, not computed properties.
180 
181### The Problem with @ViewBuilder Functions
182 
183When you use `@ViewBuilder` functions or computed properties for complex views, the entire function re-executes on every parent state change:
184 
185```swift
186// BAD - re-executes complexSection() on every tap
187struct ParentView: View {
188    @State private var count = 0
189 
190    var body: some View {
191        VStack {
192            Button("Tap: \(count)") { count += 1 }
193            complexSection()  // Re-executes every tap!
194        }
195    }
196 
197    @ViewBuilder
198    func complexSection() -> some View {
199        // Complex views that re-execute unnecessarily
200        ForEach(0..<100) { i in
201            HStack {
202                Image(systemName: "star")
203                Text("Item \(i)")
204                Spacer()
205                Text("Detail")
206            }
207        }
208    }
209}
210```
211 
212### The Solution: Separate Structs
213 
214Extract to separate `struct` views. SwiftUI can skip their `body` when inputs don't change:
215 
216```swift
217// GOOD - ComplexSection body SKIPPED when its inputs don't change
218struct ParentView: View {
219    @State private var count = 0
220 
221    var body: some View {
222        VStack {
223            Button("Tap: \(count)") { count += 1 }
224            ComplexSection()  // Body skipped during re-evaluation
225        }
226    }
227}
228 
229struct ComplexSection: View {
230    var body: some View {
231        ForEach(0..<100) { i in
232            HStack {
233                Image(systemName: "star")
234                Text("Item \(i)")
235                Spacer()
236                Text("Detail")
237            }
238        }
239    }
240}
241```
242 
243### Why This Works
244 
2451. SwiftUI compares the `ComplexSection` struct (which has no properties)
2462. Since nothing changed, SwiftUI skips calling `ComplexSection.body`
2473. The complex view code never executes unnecessarily
248 
249### Multi-section detail views
250 
251The most common place this rule gets dropped is a detail screen with several distinct sections — `header + gallery + description + reviews`, `header + ingredients + steps`, `hero + specs + related`. The tempting shape is one big view with `private var header: some View`, `private var gallery: some View`, and so on. That shape shares one invalidation boundary, so a change that affects one section re-evaluates all of them. Factor each named section into its own `View` type that takes only the fields it renders, and keep the parent thin — it just composes the sections.
252 
253```swift
254// PREFER: each section is its own type with narrow inputs.
255struct ProductDetailView: View {
256    let product: Product
257 
258    var body: some View {
259        ScrollView {
260            VStack(alignment: .leading, spacing: 24) {
261                ProductHeader(name: product.name, price: product.price)
262                ProductGallery(images: product.imageURLs)
263                ProductDescription(text: product.descriptionText)
264                ProductReviews(average: product.averageStars, count: product.reviewCount)
265            }
266            .padding()
267        }
268    }
269}
270```
271 
272This generalizes to every `*DetailView`: one `View` type per section, narrow inputs each, a thin parent that composes them. Small `@ViewBuilder` fragments reused two or three times within the same body are still fine — the rule targets factoring done for organization or to manage body length, where a real `View` type does the right thing.
273 
274## @ViewBuilder
275 
276Use `@ViewBuilder` functions for small, simple sections (a few views, no expensive computation) that don't affect performance. They work particularly well for static content that doesn't depend on any `@State` or `@Binding`, since SwiftUI won't need to diff them independently. Extract to a separate `struct` when the section is complex, depends on state, or needs to be skipped during re-evaluation.
277 
278The `@ViewBuilder` attribute is only required when a function or computed property returns multiple different views conditionally, for example through `if` or `switch`:
279 
280```swift
281@ViewBuilder
282private var conditionalView: some View {
283    if isExpanded {
284        VStack {
285            Text("Expanded View")
286            Image(systemName: "star")
287        }
288    } else {
289        Text("Collapsed View")
290    }
291}
292```
293 
294If every branch returns the same concrete type, `@ViewBuilder` is unnecessary:
295 
296```swift
297var conditionalText: some View {
298    if Bool.random() {
299        Text("Hello")
300    } else {
301        Text("World")
302    }
303}
304```
305 
306Prefer `@ViewBuilder` when:
307 
308- there is conditional branching between multiple view types
309- extracting a separate `struct` would not provide meaningful separation
310 
311## Keep View Body Simple and Avoid High-Cost Operations
312 
313Refrain from performing complex operations within the `body` of your view. Instead of passing a ready-to-use sequence with filtering, mapping, or sorting directly into `ForEach`, prepare the sequence outside the body.
314 
315```swift
316// Avoid such things ...
317var body: some View {
318    List {
319        ForEach(model.values.filter { $0 > 0 }, id: \.self) {
320            Text(String($0))
321                .padding()
322        }
323    }
324}
325```
326 
327Prefer:
328 
329```swift
330struct FilteredListView: View {
331    private let filteredValues: [Int]
332 
333    init(values: [Int]) {
334        self.filteredValues = values.filter { $0 > 0 } // Perform filtering once
335    }
336 
337    var body: some View {
338        List {
339            content
340        }
341    }
342 
343    private var content: some View {
344        ForEach(filteredValues, id: \.self) { value in
345            Text(String(value))
346                .padding()
347        }
348    }
349}
350```
351 
352The reason this matters is that the system can call `body` multiple times during a single layout phase. Complex body computation makes those calls more expensive than necessary.
353 
354General guidance:
355 
356- avoid filtering, sorting, and mapping inline in `body`
357- avoid constructing expensive formatters in `body`
358- avoid heavy branching in large view trees
359- move data preparation into the model layer or dedicated helpers
360 
361## Keep View `init` Cheap
362 
363A view's `init` runs every time the parent re-evaluates its body, which can be many times per second for views inside `List`, `LazyVStack`, scroll containers, or animated parents. Treat `init` as a constant-time copy of inputs into stored properties. Don't decode JSON, build a `DateFormatter`, touch the file system, or allocate large structures there — that work repeats on every parent body pass even when the inputs are identical.
364 
365```swift
366// AVOID: decoding and formatting on every init
367init(rawJSON: Data, date: Date) {
368    self.summary = try! JSONDecoder().decode(WeatherSummary.self, from: rawJSON)
369    let formatter = DateFormatter()
370    formatter.dateStyle = .medium
371    self.formattedDate = formatter.string(from: date)
372}
373 
374// PREFER: take already-prepared values; format lazily in body
375let summary: WeatherSummary
376let date: Date
377 
378var body: some View {
379    VStack {
380        Text(summary.headline)
381        Text(date, format: .dateTime.day().month().year())  // cached, locale-aware
382    }
383}
384```
385 
386If a derived value genuinely needs to be computed once and kept, store it on an `@State`-owned `@Observable` model or compute it asynchronously in `.task` — not in `init`. `init` is not a one-time setup hook; it runs as often as the parent's body does.
387 
388## Single-Child Group
389 
390`Group { SomeView() }` — a `Group` with exactly one concrete child — wraps the view in an extra `Group<SomeView>` type for no visual benefit. Every modifier chained after it must be type-checked against that wrapper, adding avoidable type-checking overhead in long chains. Drop the `Group` and chain modifiers directly on the child.
391 
392```swift
393// AVOID: single concrete child wrapped in Group
394Group { Text(status) }
395    .padding(.horizontal, 8)
396    .background(.thinMaterial, in: Capsule())
397 
398// PREFER: chain directly on the child
399Text(status)
400    .padding(.horizontal, 8)
401    .background(.thinMaterial, in: Capsule())
402```
403 
404The rule is specifically about one concrete view. A `Group` whose content is a `ForEach`, multiple sibling views, or an `if`/`else` (which produces `_ConditionalContent`) is doing real work — applying a shared modifier across siblings or both branches — and is fine.
405 
406## When to Extract Subviews
407 
408Extract complex views into separate subviews when:
409- The view has multiple logical sections or responsibilities
410- The view contains reusable components
411- The view body becomes difficult to read or understand
412- You need to isolate state changes for performance
413- The view is becoming large (keep views small for better performance)
414- The section may evolve independently over time
415 
416## Container View Pattern
417 
418### Avoid Closure-Based Content
419 
420Closures can't be compared, causing unnecessary re-renders:
421 
422```swift
423// BAD - closure prevents SwiftUI from skipping updates
424struct MyContainer<Content: View>: View {
425    let content: () -> Content
426 
427    var body: some View {
428        VStack {
429            Text("Header")
430            content()  // Always called, can't compare closures
431        }
432    }
433}
434 
435// Usage forces re-render on every parent update
436MyContainer {
437    ExpensiveView()
438}
439```
440 
441### Use @ViewBuilder Property Instead
442 
443```swift
444// GOOD - view can be compared
445struct MyContainer<Content: View>: View {
446    @ViewBuilder let content: Content
447 
448    var body: some View {
449        VStack {
450            Text("Header")
451            content  // SwiftUI can compare and skip if unchanged
452        }
453    }
454}
455 
456// Usage - SwiftUI can diff ExpensiveView
457MyContainer {
458    ExpensiveView()
459}
460```
461 
462## Utilize Lazy Containers for Large Data Sets
463 
464When displaying extensive lists or grids, prefer `LazyVStack`, `LazyHStack`, `LazyVGrid`, or `LazyHGrid`. These containers load views only when they appear on the screen, reducing memory usage and improving performance.
465 
466```swift
467struct ContentView: View {
468    let items = Array(0..<1000)
469 
470    var body: some View {
471        ScrollView {
472            LazyVStack {
473                ForEach(items, id: \.self) { item in
474                    Text("Item \(item)")
475                }
476            }
477        }
478    }
479}
480```
481 
482Prefer lazy containers when:
483 
484- rendering large collections
485- row views are non-trivial
486- memory usage matters
487- the content is inside `ScrollView`
488 
489## ZStack vs overlay/background
490 
491Use `ZStack` to **compose multiple peer views** that should be layered together and jointly define layout.
492 
493Prefer `overlay` / `background` when you’re **decorating a primary view**.  
494Not primarily because they don’t affect layout size, but because they **express intent and improve readability**: the view being modified remains the clear layout anchor.
495 
496A key difference is **size proposal behavior**:
497- In `overlay` / `background`, the child view implicitly adopts the size proposed to the parent when it doesn’t define its own size, making decorative attachments feel natural and predictable.
498- In `ZStack`, each child participates independently in layout, and no implicit size inheritance exists. This makes it better suited for peer composition, but less intuitive for simple decoration.
499 
500Use `ZStack` (or another container) when the “decoration” **must explicitly participate in layout sizing**—for example, when reserving space, extending tappable/visible bounds, or preventing overlap with neighboring views.
501 
502### Examples
503 
504```swift
505// GOOD - decoration via overlay (layout anchored to button)
506Button("Continue") { }
507    .overlay(alignment: .trailing) {
508        Image(systemName: "lock.fill").padding(.trailing, 8)
509    }
510 
511// BAD - ZStack when overlay suffices (layout no longer anchored to button)
512ZStack(alignment: .trailing) {
513    Button("Continue") { }
514    Image(systemName: "lock.fill").padding(.trailing, 8)
515}
516 
517// GOOD - background shape takes parent size
518HStack(spacing: 12) { Text("Inbox"); Text("Next") }
519    .background { Capsule().strokeBorder(.blue, lineWidth: 2) }
520```
521 
522## Compositing Group Before Clipping
523 
524**Always add `.compositingGroup()` before `.clipShape()` when clipping layered views (`.overlay` or `.background`).** Without it, each layer is antialiased separately and then composited. Where antialiased edges overlap — typically at rounded corners — you get visible color fringes (semi-transparent pixels of different colors blending together).
525 
526```swift
527let shape = RoundedRectangle(cornerRadius: 16)
528 
529// BAD - each layer antialiased separately, producing color fringes at corners
530Color.red
531    .overlay(.white, in: shape)
532    .clipShape(shape)
533    .frame(width: 200, height: 150)
534 
535// GOOD - layers composited first, antialiasing applied once during clipping
536Color.red
537    .overlay(.white, in: .rect)
538    .compositingGroup()
539    .clipShape(shape)
540    .frame(width: 200, height: 150)
541```
542 
543`.compositingGroup()` forces all child layers to be rendered into a single offscreen buffer before the clip is applied. This means antialiasing only happens once — on the final composited result — eliminating the fringe artifacts.
544 
545## Split State-Driven Parts into Custom View Types
546 
547Large views often depend on multiple independent state sources. If a single view body depends on all of them, then any state change can cause the entire body to re-evaluate.
548 
549```swift
550struct BigAndComplicatedView: View {
551    @State private var counter = 0
552    @State private var isToggled = false
553    @StateObject private var viewModel = SomeViewModel()
554 
555    let title = "Big and Complicated View"
556 
557    var body: some View {
558        VStack {
559            Text(title)
560                .font(.largeTitle)
561 
562            Text("Counter: \(counter)")
563                .font(.title)
564 
565            Toggle("Enable Feature", isOn: $isToggled)
566                .padding()
567 
568            Button("Increment Counter") {
569                counter += 1
570            }
571 
572            Text("ViewModel Data: \(viewModel.data)")
573                .padding()
574 
575            Button("Fetch Data") {
576                viewModel.fetchData()
577            }
578        }
579    }
580}
581```
582 
583### Better: Split Into Smaller Components
584 
585```swift
586struct BigAndComplicatedView: View {
587    @State private var counter = 0
588    @State private var isToggled = false
589    @StateObject private var viewModel = SomeViewModel()
590 
591    var body: some View {
592        VStack {
593            titleView
594            CounterView(counter: $counter)
595            ToggleView(isToggled: $isToggled)
596            ViewModelDataView(data: viewModel.data) {
597                viewModel.updateData()
598            }
599            .equatable()
600        }
601    }
602 
603    private var titleView: some View {
604        Text("Big and Complicated View")
605            .font(.largeTitle)
606    }
607}
608```
609 
610Why this is better:
611 
612- changing `counter` only affects `CounterView`
613- toggling only affects `ToggleView`
614- updating the model data only affects `ViewModelDataView`
615 
616### Notes on Equatable
617 
618Using `Equatable` for a view is not a universal best practice, but it can be useful in targeted cases where:
619 
620- the input is small and well-defined
621- the comparison logic is meaningful
622- you want to reduce unnecessary body evaluation for a specific subtree
623 
624Do not use `Equatable` as a blanket optimization technique.
625 
626## Reusable Styling with ViewModifier
627 
628Extract repeated modifier combinations into a `ViewModifier` struct. Expose via a `View` extension for autocompletion:
629 
630```swift
631private struct CardStyle: ViewModifier {
632    func body(content: Content) -> some View {
633        content
634            .padding()
635            .background(Color(.secondarySystemBackground))
636            .clipShape(.rect(cornerRadius: 12))
637    }
638}
639 
640extension View {
641    func cardStyle() -> some View {
642        modifier(CardStyle())
643    }
644}
645```
646 
647### Custom ButtonStyle
648 
649Use the `ButtonStyle` protocol for reusable button designs. Use `PrimitiveButtonStyle` only when you need custom interaction handling (e.g., simultaneous gestures):
650 
651```swift
652struct PrimaryButtonStyle: ButtonStyle {
653    func makeBody(configuration: Configuration) -> some View {
654        configuration.label
655            .bold()
656            .foregroundStyle(.white)
657            .padding(.horizontal, 16)
658            .padding(.vertical, 8)
659            .background(Color.accentColor)
660            .clipShape(Capsule())
661            .scaleEffect(configuration.isPressed ? 0.95 : 1)
662            .animation(.smooth, value: configuration.isPressed)
663    }
664}
665```
666 
667### Discoverability with Static Member Lookup
668 
669Make custom styles and modifiers discoverable via leading-dot syntax:
670 
671```swift
672extension ButtonStyle where Self == PrimaryButtonStyle {
673    static var primary: PrimaryButtonStyle { .init() }
674}
675 
676// Usage: .buttonStyle(.primary)
677```
678 
679This pattern works for any SwiftUI style protocol (`ButtonStyle`, `ListStyle`, `ToggleStyle`, etc.).
680 
681## Skeleton Loading with Redacted Views
682 
683Use `.redacted(reason: .placeholder)` to show skeleton views while data loads. Use `.unredacted()` to opt out specific views:
684 
685```swift
686VStack(alignment: .leading) {
687    Text(article?.title ?? String(repeating: "X", count: 20))
688        .font(.headline)
689    Text(article?.author ?? String(repeating: "X", count: 12))
690        .font(.subheadline)
691    Text("SwiftLee")
692        .font(.caption)
693        .unredacted()
694}
695.redacted(reason: article == nil ? .placeholder : [])
696```
697 
698Apply `.redacted` on a container to redact all children at once.
699 
700## AnyView
701 
702`AnyView` is type erasure. SwiftUI uses structural identity based on type information to determine when views should be updated.
703 
704```swift
705private var nameView: some View {
706    if isEditable {
707        TextField("Your name", text: $name)
708    } else {
709        Text(name)
710    }
711}
712```
713 
714Avoid patterns like:
715 
716```swift
717private var nameView: some View {
718    if isEditable {
719        return AnyView(TextField("Your name", text: $name))
720    } else {
721        return AnyView(Text(name))
722    }
723}
724```
725 
726Because `AnyView` erases type information, SwiftUI loses some optimization opportunities. Prefer `@ViewBuilder` or conditional branches with concrete view types.
727 
728Use `AnyView` only when type erasure is truly necessary for API design.
729 
730## UIViewRepresentable Essentials
731 
732When bridging UIKit views into SwiftUI:
733 
734- `makeUIView(context:)` is called **once** to create the UIKit view
735- `updateUIView(_:context:)` is called on **every SwiftUI redraw** to sync state
736- The representable struct itself is **recreated on every redraw** -- avoid heavy work in its init
737- Use a `Coordinator` for delegate callbacks and two-way communication
738 
739```swift
740struct MapView: UIViewRepresentable {
741    let coordinate: CLLocationCoordinate2D
742 
743    func makeUIView(context: Context) -> MKMapView {
744        let map = MKMapView()
745        map.delegate = context.coordinator
746        return map
747    }
748 
749    func updateUIView(_ map: MKMapView, context: Context) {
750        map.setCenter(coordinate, animated: true)
751    }
752 
753    func makeCoordinator() -> Coordinator { Coordinator() }
754 
755    class Coordinator: NSObject, MKMapViewDelegate { }
756}
757```
758 
759## Troubleshooting
760 
761### Debug SwiftUI Renderings
762 
763> See `references/performance-patterns.md` (item #8) for the `_printChanges()` vs `_logChanges()` comparison and the `@self`/`@identity` output meaning. The snippets below show the call sites.
764 
765If it is needed to debug render cycles and read console output you can leverage the `_printChanges()` or `_logChanges()` methods on `View`. These methods print information about when the view is being evaluated and what changes are triggering updates. This can be very helpful when your view body is called multiple times and you want to know why.
766 
767```swift
768struct ContentView: View {
769    @State private var counter: Int = 99
770 
771    init() {
772        print(Self.self, #function)
773    }
774 
775    var body: some View {
776        let _ = Self._printChanges()
777 
778        VStack {
779            Text("Counter: \(counter)")
780            Button {
781                counter += 1
782            } label: {
783                Text("Counter +1")
784            }
785            .buttonStyle(.borderedProminent)
786        }
787        .padding()
788    }
789}
790```
791 
792As an alternative to `Self._printChanges()`, you can use `_logChanges()`
793 
794```swift
795struct ContentView: View {
796    @State private var counter: Int = 99
797 
798    var body: some View {
799        let _ = Self._logChanges()
800 
801        VStack {
802            Text("Counter: \(counter)")
803            Button {
804                counter += 1
805            } label: {
806                Text("Counter +1")
807            }
808            .buttonStyle(.borderedProminent)
809        }
810        .padding()
811    }
812}
813```
814 
815Use these tools only for debugging and remove them from production code.
816 
817### Handling "The Compiler Is Unable to Type-Check This Expression in Reasonable Time"
818 
819If you encounter:
820 
821> The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
822 
823it is often caused by overly complex view structures or expressions.
824 
825Ways to fix it:
826 
827- break large expressions into smaller computed values
828- extract subviews
829- split long modifier chains
830- simplify nested generics and builders
831- avoid huge inline closures
832 
833## Summary Checklist
834 
835- [ ] Prefer modifiers over conditional views for state changes
836- [ ] Avoid `if`-based conditional modifier extensions (they break view identity)
837- [ ] Extract complex views into separate subviews, not computed properties
838- [ ] Keep views small for readability and performance
839- [ ] Use `@ViewBuilder` only where it actually adds value
840- [ ] Avoid heavy filtering, mapping, sorting, or formatter creation inside `body`
841- [ ] Keep view `init` cheap (no decoding/formatting/allocation; it runs on every parent body pass)
842- [ ] Avoid single-child `Group { OneView() }` (chain modifiers directly on the child)
843- [ ] Use lazy containers for large data sets
844- [ ] Container views use `@ViewBuilder let content: Content`
845- [ ] Prefer `overlay` / `background` for decoration and `ZStack` for peer composition
846- [ ] `.compositingGroup()` before `.clipShape()` on layered views to avoid antialiasing fringes
847- [ ] Split state-heavy areas into smaller view types
848- [ ] Extract repeated styling into `ViewModifier` or `ButtonStyle`
849- [ ] Expose reusable styles via static member lookup when it improves discoverability
850- [ ] Use `.redacted(reason: .placeholder)` for loading skeletons
851- [ ] Avoid `AnyView` unless type erasure is truly needed
852- [ ] In `UIViewRepresentable`, keep heavy work out of struct init
853- [ ] Use `_printChanges()` / `_logChanges()` to debug rendering behavior
854- [ ] Break up overly complex expressions when the compiler struggles
855