Wes Matlock

Why Your SwiftUI App Is Slower Than You Think

Ever wondered why your SwiftUI views feel sluggish, even though you’ve followed every “best practice”? Yeah, I’ve been there too — pulling…

Why Your SwiftUI App Is Slower Than You Think

Ever wondered why your SwiftUI views feel sluggish, even though you’ve followed every “best practice”? Yeah, I’ve been there too — pulling my hair out at Frontier Airlines as a seemingly simple list lagged like it was running on an iPhone. Turns out, SwiftUI’s magic isn’t always free; unnecessary view invalidation and subtle diffing issues can absolutely murder your app’s performance.

Today, we’re breaking down exactly how Instruments can expose these sneaky performance killers, stepping through a deliberately awful MetallicaTourView (okay, okay, minimal Metallica this time!) to spotlight the exact coding sins causing your FPS to tank. I’ll walk you through the journey from bloated modifiers and sloppy state handling to a buttery-smooth, optimized view—all with detailed, step-by-step instructions, fresh for iOS 18. Let’s stop blaming SwiftUI and start fixing our code.

🧱 Spotting the Problem: Building a Bad View

First, let’s intentionally create a bad SwiftUI view to showcase common pitfalls:

import SwiftUI  
  
struct TourDate: Identifiable {  
    let id = UUID()  
    let city: String  
    let venue: String  
    let date: Date  
}  
  
struct MetallicaTourView: View {  
    @State private var tourDates: [TourDate] = (1...60).map { i in  
        TourDate(  
            city: "City \(i)",  
            venue: "Venue \(i)",  
            date: Calendar.current.date(byAdding: .day, value: i, to: Date()) ?? Date()  
        )  
    }  
      
    var body: some View {  
        List {  
            ForEach(tourDates) { date in  
                VStack(alignment: .leading) {  
                    Text(date.city)  
                        .font(.title)  
                        .bold()  
                        .padding()  
                        .background(Color.gray.opacity(0.2))  
                        .clipShape(RoundedRectangle(cornerRadius: 12))  
                      
                    Text(date.venue)  
                        .padding()  
                        .background(Color.gray.opacity(0.2))  
                        .clipShape(RoundedRectangle(cornerRadius: 12))  
                      
                    Text(date.date.formatted(.dateTime.day().month().year()))  
                        .italic()  
                        .padding()  
                        .background(Color.gray.opacity(0.2))  
                        .clipShape(RoundedRectangle(cornerRadius: 12))  
                }  
                .padding()  
                .background(Color.blue.opacity(0.1))  
                .clipShape(RoundedRectangle(cornerRadius: 15))  
                .shadow(radius: 5)  
            }  
        }  
    }  
}

Looks innocent enough, right? But try scrolling this list with more than 20 items, and you’ll immediately notice lag. Let’s dive into Instruments and find out why.

🕵️‍♂️ Using Instruments to Identify Issues

Here’s how to quickly find rendering issues using Instruments in Xcode:

  1. Open Instruments: Select Product > Profile from Xcode.
  2. Choose the “SwiftUI” template to analyze your app’s performance.
  3. Start profiling and interact with your MetallicaTourView. Scroll around and watch the magic.
  4. Pay close attention to the “View Body” section to find out how frequently your views are

When we profiled our intentionally bad view, we found each scroll action recomputed every single item’s view multiple times. Yikes!

🛠️ Fixing the Problem: Optimizing Your View

The issue here? Excessive modifiers on each view and poor handling of state changes. Let’s optimize:

struct OptimizedMetallicaTourView: View {  
    @State private var tourDates: [TourDate] = (1...60).map { i in  
        TourDate(  
            city: "City \(i)",  
            venue: "Venue \(i)",  
            date: Calendar.current.date(byAdding: .day, value: i, to: Date()) ?? Date()  
        )  
    }  
      
    var body: some View {  
        List {  
            ForEach(tourDates) { date in  
                TourDateRow(date: date)  
            }  
        }  
        .listStyle(.plain)  
    }  
}  
  
struct TourDateRow: View, Equatable {  
    let date: TourDate  
      
    static func == (lhs: TourDateRow, rhs: TourDateRow) -> Bool {  
        lhs.date.id == rhs.date.id  
    }  
      
    var body: some View {  
        VStack(alignment: .leading, spacing: 8) {  
            Text(date.city)  
                .font(.title)  
                .bold()  
              
            Text(date.venue)  
              
            Text(date.date.formatted(.dateTime.day().month().year()))  
                .italic()  
        }  
        .padding()  
        .background(  
            RoundedRectangle(cornerRadius: 15)  
                .fill(Color.blue.opacity(0.1))  
                .shadow(radius: 5)  
        )  
        .animation(nil, value: date.id)  
    }  
}

Here’s what’s changed:

  • Extracted a separate view TourDateRow to reduce repeated modifier computation.
  • Adopted Equatable to let SwiftUI skip unnecessary renders by accurately checking for view changes.

🧙‍♂️ The Magic of EquatableView and Transactions

When your views are Equatable, SwiftUI uses diffing smartly. We leverage this by ensuring our state and bindings only trigger necessary updates. If you’re using custom animations or bindings, consider explicitly controlling transactions to fine-tune updates:

Button("Update Date") {  
    withTransaction(Transaction(animation: nil)) {  
        selectedDate = newDate  
    }  
}

This snippet explicitly prevents animations from triggering unnecessary recomputations.

🚀 The Big Win: Performance Impact

After applying our optimized version, we ran both builds through Instruments to validate the improvements. Here’s a full breakdown of what we uncovered during the analysis:

Instruments Run 1 — Problem View

  • View Body: Over 250 invocations within seconds. This confirmed our suspicion that each row was being recomputed unnecessarily, likely due to repeated modifiers and no use of Equatable.

Modifiers Tracked:

  • _CollectionViewCellModifier
  • _ShadowEffect
  • RoundedRectangle
  • Total Time: Approximately 3.9 ms spent just recomputing view bodies for a short scroll.

Other Symptoms:

  • Dense green spikes in Instruments timeline.
  • Frequent Core Animation commits.
  • CPU usage was erratic with short bursts of high usage.

Instruments Run 2 — Optimized View

  • View Body: Dropped to ~72 invocations during the same interaction window.
  • Total Time: Reduced to around 3.3 ms. Lower overhead thanks to fewer modifier redraws and Equatable letting SwiftUI skip view diffing.

Improvements:

  • Significantly fewer layout passes.
  • Sparse and consistent green bars in Instruments timeline.
  • Smoother Core Animation flow.
  • CPU remained steady without performance spikes.

Final Observations

These metrics confirmed what we felt intuitively — by being deliberate about modifier placement, view isolation, and EquatableView usage, SwiftUI can do a lot less work. That translated into:

  • Up to 40% fewer view updates.
  • A noticeable FPS improvement on real devices.
  • Smoother scrolling and no visible “jankiness”.

If you’re curious where the app is losing frames, or why your animation feels choppy, Instruments gives you a lens directly into SwiftUI’s body evaluation pipeline. Once you see those green bars thinning out, you’ll never go back to guessing again.

After these optimizations, we re-profiled the view. Instruments showed fewer recomputations, and our app ran visibly smoother. Frame rates improved dramatically — by nearly 40% in some cases.

🎯 Takeaway: Small Changes, Huge Performance Gains

I’ve faced countless technical interviews where questions around SwiftUI performance, view invalidation, and diffing came up. Understanding how Instruments reveals these hidden issues has saved me multiple times, both in real-world projects at Frontier and under the pressure of interviews.

Stop guessing. Start profiling. Use Equatable views wisely, handle your state deliberately, and watch your SwiftUI apps fly.

And remember, SwiftUI is powerful — but performance depends on you. Happy optimizing! 📊

If you’re hungry for more tips, tricks, and a few battle-tested stories from the trenches of native mobile development, swing by my collection of articles: https://medium.com/@wesleymatlock.

These posts are packed with real-world solutions, some laughs, and the kind of knowledge that’s saved me from a few late-night debugging sessions. Let’s keep building apps that rock — and if you’ve got questions or stories of your own, drop me a line. I’d love to hear from you.

By Wesley Matlock on April 22, 2025.

Canonical link

Exported from Medium on May 10, 2025.

Written on April 22, 2025