Claude Code lacks SwiftUI layout understanding — repeated failed attempts waste user time
Summary
During a task to fix iPad sheet presentation sizing, Claude Code (Opus 4.6) made 3 consecutive failed attempts at solving the problem, each requiring the user to build, run on a device, observe the broken result, screenshot it, and report back. Claude did not use SwiftUI Previews, did not trace the view hierarchy before proposing changes, and did not understand fundamental SwiftUI layout concepts.
What happened
Task: Show Detail sheet on iPad clips "Where can I watch this?" at .medium detent. User asked for Apple's recommended approach.
Attempt 1: .presentationSizing(.fitted) — Sheet collapsed to a tiny size. Claude didn't understand that ScrollView has no intrinsic content size, so .fitted gets zero height.
Attempt 2: Removed ScrollView, kept .presentationSizing(.form.fitted(horizontal: false, vertical: true)) — Sheet still collapsed. Claude didn't trace the hierarchy to realize NavigationStack (the sheet root) ALSO has no intrinsic content size.
Attempt 3: Proposed ViewThatFits wrapper with content duplicated in both a plain VStack and a ScrollView — user correctly identified this as unnecessary complexity. Claude then proposed a 4th approach (size-class conditional detents) which the user rejected as giving up.
Each failed attempt required the user to:
- Wait for Claude to make the edit
- Build the project in Xcode
- Run on iPad simulator
- Observe the broken behavior
- Screenshot it
- Send it back to Claude
- Wait for Claude to understand the failure
Root causes
- No understanding of SwiftUI intrinsic sizing: Claude didn't know that
ScrollView,NavigationStack, andTextEditorreport no intrinsic content size. This is fundamental SwiftUI layout knowledge — not an edge case.
- No view hierarchy tracing: Claude never traced the full chain (
NavigationStack→Group→ScrollView→VStack→ content) before proposing changes. Each failure revealed ONE more layer that breaks.fitted, when all of them should have been identified upfront.
- No use of Previews: Claude could have suggested or created SwiftUI Previews to test sizing behavior without requiring the user to do full build-run-screenshot cycles. This would have caught failures in seconds instead of minutes.
- Research was shallow: Claude's "research" returned Apple documentation links and WWDC session names but failed to internalize the key constraint:
.fittedonly works when the entire view chain from sheet root to content has intrinsic size. The research identified that ScrollView breaks it but missed NavigationStack.
- Reactive coding pattern: Despite having prior feedback memories saying "never build reactively" and "think through the full change before writing ANY code", Claude wrote → failed → patched → failed → patched. The existing memory system didn't prevent the behavior it was supposed to prevent.
Time wasted
Approximately 20-30 minutes of user time across 3 failed attempts, each requiring build + run + screenshot + feedback cycles. The user had to repeatedly correct Claude's understanding of basic SwiftUI concepts.
Expected behavior
Claude should have:
- Traced the full view hierarchy BEFORE proposing any change
- Identified ALL containers without intrinsic size (NavigationStack, ScrollView) in one pass
- Presented the constraint clearly: "
.fittedwon't work here because NavigationStack is the sheet root and has no intrinsic size" - Discussed viable alternatives with the user BEFORE writing any code
- If unsure about SwiftUI layout behavior, said so honestly rather than guessing
Environment
- Claude Code with Opus 4.6
- iOS 26 / SwiftUI app
- iPad sheet presentation sizing
Additional context
The user's prior feedback memory already contained entries like "never build reactively", "understand architecture before coding", and "slow down, discuss before coding" — all of which were violated during this session. The memory system alone is insufficient to fix this class of problem; the model needs better SwiftUI layout understanding at the training level.
🤖 Generated with Claude Code
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗