SwiftUI Performance Optimization

When to Use This Skill

Use when:

• App feels less responsive (hitches, hangs, delayed scrolling)
• Animations pause or jump during execution
• Scrolling performance is poor
• Profiling reveals SwiftUI is the bottleneck
• View bodies are taking too long to run
• Views are updating more frequently than necessary
• Need to understand cause-and-effect of SwiftUI updates

Example Prompts

These are real questions developers ask that this skill is designed to answer:

1. "My app has janky scrolling and animations are stuttering. How do I figure out if SwiftUI is the cause?"

→ The skill shows how to use the new SwiftUI Instrument in Instruments 26 to identify if SwiftUI is the bottleneck vs other layers

2. "I'm using the new SwiftUI Instrument and I see orange/red bars showing long updates. How do I know what's causing them?"

→ The skill covers the Cause & Effect Graph patterns that show data flow through your app and which state changes trigger expensive updates

3. "Some views are updating way too often even though their data hasn't changed. How do I find which views are the problem?"

→ The skill demonstrates unnecessary update detection and Identity troubleshooting with the visual timeline

4. "I have large data structures and complex view hierarchies. How do I optimize them for SwiftUI performance?"

→ The skill covers performance patterns: breaking down view hierarchies, minimizing body complexity, and using the @Sendable optimization checklist

5. "We have a performance deadline and I need to understand what's slow in SwiftUI. What are the critical metrics?"

→ The skill provides the decision tree for prioritizing optimizations and understands pressure scenarios with professional guidance for trade-offs

---

Overview

Core Principle: Ensure your view bodies update quickly and only when needed to achieve great SwiftUI performance.

NEW in WWDC 2025: Next-generation SwiftUI instrument in Instruments 26 provides comprehensive performance analysis with:

• Visual timeline of long updates (color-coded orange/red by severity)
• Cause & Effect Graph showing data flow through your app
• Integration with Time Profiler for CPU analysis
• Hangs and Hitches tracking

Key Performance Problems:

1. Long View Body Updates — View bodies taking too long to run
2. Unnecessary View Updates — Views updating when data hasn't actually changed

---

iOS 26 Framework Performance Improvements

"Performance improvements to the framework benefit apps across all of Apple's platforms, from our app to yours." — WWDC 2025-256

SwiftUI in iOS 26 includes major performance wins that benefit all apps automatically. These improvements work alongside the new profiling tools to make SwiftUI faster out of the box.

List Performance (macOS Focus)

Massive gains for large lists

• 6x faster loading for lists of 100,000+ items on macOS
• 16x faster updates for large lists
• Even bigger gains for larger lists
• Improvements benefit all platforms (iOS, iPadOS, watchOS, not just macOS)

List(trips) { trip in // 100k+ items
    TripRow(trip: trip)
}
// iOS 26: Loads 6x faster, updates 16x faster on macOS
// All platforms benefit from performance improvements

Impact on your app

• Large datasets (10k+ items) see noticeable improvements
• Filtering and sorting operations complete faster
• Real-time updates to lists are more responsive
• Benefits apps like file browsers, contact lists, data tables

Scrolling Performance

Reduced dropped frames during high-speed scrolling

SwiftUI has improved scheduling of user interface updates on iOS and macOS. This improves responsiveness and lets SwiftUI do even more work to prepare for upcoming frames. All in all, it reduces the chance of your app dropping a frame while scrolling quickly at high frame rates.

Key improvements

1. Better frame scheduling — SwiftUI gets more time to prepare for upcoming frames
2. Improved responsiveness — UI updates scheduled more efficiently
3. Fewer dropped frames — Especially during quick scrolling at 120Hz (ProMotion)

When you'll notice

• Scrolling through image-heavy content
• High frame rate devices (iPhone Pro, iPad Pro with ProMotion)
• Complex list rows with multiple views

Nested ScrollViews with Lazy Stacks

Photo carousels and multi-axis scrolling now properly optimize

ScrollView(.horizontal) {
    LazyHStack {
        ForEach(photoSets) { photoSet in
            ScrollView(.vertical) {
                LazyVStack {
                    ForEach(photoSet.photos) { photo in
                        PhotoView(photo: photo)
                    }
                }
            }
        }
    }
}
// iOS 26: Nested scrollviews now properly delay loading with lazy stacks
// Great for photo carousels, Netflix-style layouts, multi-axis content

Before iOS 26 Nested ScrollViews didn't properly delay loading lazy stack content, causing all nested content to load immediately.

After iOS 26 Lazy stacks inside nested ScrollViews now delay loading until content is about to appear, matching the behavior of single-level ScrollViews.

Use cases

• Photo galleries with horizontal/vertical scrolling
• Netflix-style category rows
• Multi-dimensional data browsers
• Image carousels with vertical detail scrolling

SwiftUI Performance Instrument Enhancements

New lanes in Instruments 26

The SwiftUI instrument now includes dedicated lanes for:

1. Long View Body Updates — Identify expensive body computations
2. Platform View Updates — Track UIKit/AppKit bridging performance (Long Representable Updates)
3. Other Long Updates — All other types of long SwiftUI work

These lanes are covered in detail in the next section.

Performance Improvement Summary

Automatic wins (recompile only)

• ✅ 6x faster list loading (100k+ items, macOS)
• ✅ 16x faster list updates (macOS)
• ✅ Reduced dropped frames during scrolling
• ✅ Improved frame scheduling on iOS/macOS
• ✅ Nested ScrollView lazy loading optimization

No code changes required — rebuild with iOS 26 SDK to get these improvements.

Cross-reference SwiftUI 26 Features (swiftui-26-ref skill) — Comprehensive guide to all iOS 26 SwiftUI changes

---

The SwiftUI Instrument (Instruments 26)

Getting Started

Requirements:

• Install Xcode 26
• Update devices to latest OS releases (support for recording SwiftUI traces)
• Build app in Release mode for accurate profiling

Launch:

1. Open project in Xcode
2. Press Command-I to profile
3. Choose SwiftUI template from template chooser
4. Click Record button

Template Contents

The SwiftUI template includes three instruments:

1. SwiftUI Instrument (NEW) — Identifies performance issues in SwiftUI code
2. Time Profiler — Shows CPU work samples over time
3. Hangs and Hitches — Tracks app responsiveness

SwiftUI Instrument Track Lanes

Lane 1: Update Groups

• Shows when SwiftUI is actively doing work
• Empty during CPU spikes? → Problem likely outside SwiftUI

Lane 2: Long View Body Updates

• Highlights when body property takes too long
• Most common performance issue — start here

Lane 3: Long Representable Updates

• Identifies slow UIViewRepresentable/NSViewRepresentable updates
• UIKit/AppKit integration performance

Lane 4: Other Long Updates

• All other types of long SwiftUI work

Color-Coding System

Updates shown in orange and red based on likelihood to cause hitches:

• Red — Very likely to contribute to hitch/hang (investigate first)
• Orange — Moderately likely to cause issues
• Gray — Normal updates, not concerning

Note: Whether updates actually result in hitches depends on device conditions, but red updates are the highest priority.

---

Understanding the Render Loop

Normal Frame Rendering

Frame 1:
├─ Handle events (touches, key presses)
├─ Update UI (run view bodies)
│  └─ Complete before frame deadline ✅
├─ Hand off to system
└─ System renders → Visible on screen

Frame 2:
├─ Handle events
├─ Update UI
│  └─ Complete before frame deadline ✅
├─ Hand off to system
└─ System renders → Visible on screen

Result: Smooth, fluid animations

Frame with Hitch (Long View Body)

Frame 1:
├─ Handle events
├─ Update UI
│  └─ ONE VIEW BODY TOO SLOW
│  └─ Runs past frame deadline ❌
├─ Miss deadline
└─ Previous frame stays visible (HITCH)

Frame 2: (Delayed)
├─ Handle events (delayed by 1 frame)
├─ Update UI
├─ Hand off to system
└─ System renders → Finally visible

Result: Previous frame visible for 2+ frames = animation stutter

Frame with Hitch (Too Many Updates)

Frame 1:
├─ Handle events
├─ Update UI
│  ├─ Update 1 (fast)
│  ├─ Update 2 (fast)
│  ├─ Update 3 (fast)
│  ├─ ... (100 more fast updates)
│  └─ Total time exceeds deadline ❌
├─ Miss deadline
└─ Previous frame stays visible (HITCH)

Result: Many small updates add up to miss deadline

Key Insight: View body runtime matters because missing frame deadlines causes hitches, making animations less fluid.

Reference:

• Understanding hitches in your app
• Tech Talk on render loop and fixing hitches

---

Problem 1: Long View Body Updates

Identifying Long Updates

1. Record trace in Instruments with SwiftUI template
2. Look at Long View Body Updates lane — any orange/red bars?
3. Expand SwiftUI track to see subtracks
4. Select View Body Updates subtrack
5. Filter to long updates:
   • Detail pane → Dropdown → Choose "Long View Body Updates summary"

Analyzing with Time Profiler

Workflow:

1. Find long update in Long View Body Updates summary
2. Hover over view name → Click arrow → "Show Updates"
3. Right-click on long update → "Set Inspection Range and Zoom"
4. Switch to Time Profiler instrument track

What you see:

• Call stacks for samples recorded during view body execution
• Time spent in each frame (leftmost column)
• Your view body nested in deep SwiftUI call stack

Finding the bottleneck:

1. Option-click to expand main thread call stack
2. Command-F to search for your view name (e.g., "LandmarkListItemView")
3. Identify expensive operations in time column

Common Expensive Operations

Formatter Creation (Very Expensive)

❌ WRONG - Creating formatters in view body:

struct LandmarkListItemView: View {
    let landmark: Landmark
    @State private var userLocation: CLLocation

    var distance: String {
        // ❌ Creating formatters every time body runs
        let numberFormatter = NumberFormatter()
        numberFormatter.maximumFractionDigits = 1

        let measurementFormatter = MeasurementFormatter()
        measurementFormatter.numberFormatter = numberFormatter

        let meters = userLocation.distance(from: landmark.location)
        let measurement = Measurement(value: meters, unit: UnitLength.meters)
        return measurementFormatter.string(from: measurement)
    }

    var body: some View {
        HStack {
            Text(landmark.name)
            Text(distance) // Calls expensive distance property
        }
    }
}

Why it's slow:

• Formatters are expensive to create (milliseconds each)
• Created every time view body runs
• Runs on main thread → app waits before continuing UI updates
• Multiple views → time adds up quickly

✅ CORRECT - Cache formatters centrally:

@Observable
class LocationFinder {
    private let formatter: MeasurementFormatter
    private let landmarks: [Landmark]
    private var distanceCache: [Landmark.ID: String] = [:]

    init(landmarks: [Landmark]) {
        self.landmarks = landmarks

        // Create formatters ONCE during initialization
        let numberFormatter = NumberFormatter()
        numberFormatter.maximumFractionDigits = 1