TLDR: The Swift type-checker timed out on a fat SwiftUI view body. Extracting one section into its own subview fixed it instantly — and it was the right call architecturally anyway.

The Feature

We're building an iOS companion app to an ecommerce business's KOL CRM (KOL = Key Opinion Leader, the doctors and researchers they work with).

The feature sounded simple: add a relationship warmth slider and a location field to each contact detail screen. A 0–10 warmth scale for "how solid is this relationship, really?"

Perfectly reasonable. I wired it into the existing KOLDetailView and shipped it.

The Wall

Next build — and I'm staring at the one error you never want to see in Swift:

The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

My first instinct? I wrote a type error somewhere. Started hunting. Checked the new slider bindings, the @State types, the Double vs Int coercions. Everything looked fine.

So then I did what every Swift developer does at this point: started throwing explicit type annotations at the problem. : Double, as? Double, redundant as casts everywhere. Still timed out.

Took a beat. Looked at the view body in full.

Oh.

The Real Problem

The KOLDetailView body had grown into one enormous expression — contact fields, phone/email rows, topic tags, notes, and now location + the warmth section on top. The Swift type-checker (which bounds its constraint-solving to avoid exponential blowup) had simply hit its complexity budget and given up.

This is a deliberate compiler limit, not a bug. SwiftUI's heavy use of generic ViewBuilder closures means every nested modifier and conditional adds constraints the type system has to solve simultaneously. At some point, a big enough body tips over the edge.

The fix wasn't a type annotation anywhere. It was composition.

The Fix That Worked

Extracted the warmth slider and its supporting state into a dedicated WarmthSectionView.

One commit. Literally just:

// Before: all inline in KOLDetailView body
// After:
WarmthSectionView(warmth: $warmth, onSave: saveWarmth)

Build time: instant. Zero type errors. The parent view got smaller, and the warmth logic got encapsulated.

(A follow-up commit fixed a slider glitch — but that was a real logic bug, nothing to do with the compiler. Separate story.)

Why This Actually Matters

Here's what I've learned about resource limits — compiler timeouts, rate limits, memory caps, context windows: they are almost always telling you something true about your design.

The type-checker didn't time out because Swift is bad. It timed out because I had put too many concerns in one place.

The compiler was right. The warmth section belongs in its own view. It has its own state, its own save action, its own reason to exist. The limit forced the composition I should have chosen anyway.

When you see that timeout: don't scatter annotations across the body hoping one sticks.

Split the view. The compiler is doing code review.

That lesson transfers well beyond Swift — any time a system's hard limit kicks in, ask what the limit is actually protecting you from. Nine times out of ten, it's the thing you didn't want to build that way regardless.