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:
- Long View Body Updates — View bodies taking too long to run
- 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
TripRow(trip: trip)
}
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
- Better frame scheduling — SwiftUI gets more time to prepare for upcoming frames
- Improved responsiveness — UI updates scheduled more efficiently
- 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)
}
}
}
}
}
}
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:
- Long View Body Updates — Identify expensive body computations
- Platform View Updates — Track UIKit/AppKit bridging performance (Long Representable Updates)
- 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:
- Open project in Xcode
- Press Command-I to profile
- Choose SwiftUI template from template chooser
- Click Record button
Template Contents
The SwiftUI template includes three instruments:
- SwiftUI Instrument (NEW) — Identifies performance issues in SwiftUI code
- Time Profiler — Shows CPU work samples over time
- 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:
Problem 1: Long View Body Updates
Identifying Long Updates
- Record trace in Instruments with SwiftUI template
- Look at Long View Body Updates lane — any orange/red bars?
- Expand SwiftUI track to see subtracks
- Select View Body Updates subtrack
- Filter to long updates:
- Detail pane → Dropdown → Choose "Long View Body Updates summary"
Analyzing with Time Profiler
Workflow:
- Find long update in Long View Body Updates summary
- Hover over view name → Click arrow → "Show Updates"
- Right-click on long update → "Set Inspection Range and Zoom"
- 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:
- Option-click to expand main thread call stack
- Command-F to search for your view name (e.g., "LandmarkListItemView")
- 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 {
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)
}
}
}
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
let numberFormatter = NumberFormatter()
numberFormatter.maximumFractionDigits = 1
