Xcode 27 Instruments SwiftUI template shows empty lanes: a reproducible triage checklist

Some teams on Xcode 27 are hitting a nasty failure mode: you choose the SwiftUI Instruments template, hit Record, interact with the app, stop… and the SwiftUI lanes are empty. In a worse variant, including the SwiftUI instrument appears to silence the entire recording, while removing it makes the rest of the template work again. (developer.apple.com)

If you’re a founder or head of engineering, the immediate risk is wasted profiling time and bad decisions (“it’s not the UI”, “it must be network”) based on missing data. This is a triage checklist designed to quickly tell you whether you’re looking at an app problem, a template/instrument problem, or an environment mismatch — and how to keep getting useful performance answers even when the SwiftUI lane goes dark.

What ‘empty lanes’ usually means in practice

The SwiftUI instrument is supposed to show timeline lanes like Update Groups and highlight long view body / representable updates; you then pivot into Time Profiler to see what was on-CPU during a selected update. Apple’s own walkthrough is explicit that the top lane indicates when SwiftUI is doing work, and that the template commonly includes Time Profiler plus responsiveness instruments. (developer.apple.com)

When people say “empty SwiftUI lanes”, they typically mean one of these:

• SwiftUI lanes are empty, but Time Profiler has samples and other instruments show data.
• Everything is empty (Time Profiler, Hangs/Hitches, etc.), even though the app clearly ran.
• The trace looks like it recorded but fails during post-processing (the “stop and process” phase), resulting in missing lanes or a broken trace.

The current reports worth paying attention to are the second and third: a forum report describes the same app/device/session producing an all-empty trace when the SwiftUI instrument is present, and a “normal” trace when the SwiftUI instrument is removed — suggesting an Instruments pipeline problem rather than an app-level issue. (developer.apple.com)

Minimal repro matrix (15 minutes, not an afternoon)

The point of a repro matrix is not to be thorough. It’s to remove ambiguity fast.

Start with a clean SwiftUI app and a single interaction that should trigger updates (scroll a long list, animate a view, toggle state). Then run the exact same interaction through these variants.

1) Template variants: isolate the SwiftUI instrument

Run three traces, same target, same run duration:

1. “SwiftUI” template as shipped.
2. Same template, remove only the SwiftUI instrument (keep Time Profiler etc.).
3. A known-good baseline template (often just Time Profiler).

Interpretation:

• If (1) is empty and (2)/(3) contain normal data, you almost certainly have an Instruments/SwiftUI-instrument issue, not an app bug. This matches current field reports. (developer.apple.com)
• If all three are empty, stop blaming SwiftUI: you likely have a broader attach/record/signing problem.
• If only SwiftUI lanes are empty but Time Profiler works, proceed — you can still ship a good performance investigation without SwiftUI lanes.

2) OS + Xcode build: test the simplest “changed variable”

Practitioners are reporting this across macOS 27.0 → 27.0.1 and Xcode 27 builds in active use, i.e. it doesn’t look like a one-off local corruption. (developer.apple.com)

In your matrix, capture (in your notes, not your blog post screenshots):

• macOS version
• Xcode version/build
• Device OS version
• Whether Instruments is launched via Xcode Profile (⌘I) or as a standalone app

Two reasons:

• Apple’s SwiftUI instrument support has historically been OS-version sensitive (“update your device OS to the latest releases which include support for recording SwiftUI traces”). (developer.apple.com)
• Small build deltas matter when the failure is in post-processing/modeling (as the forum crash frame hints). (developer.apple.com)

3) Device vs Simulator: don’t assume parity

Do one run on:

• Physical device (USB attached)
• Simulator

If you can only do one: prefer physical device, because several Xcode performance surfaces (e.g. gauges like Energy/FPS) are device-only, and you want the closest-to-real scheduling/thermal behaviour when you’re chasing jank. (help.apple.com)

Interpretation:

• If device works and simulator doesn’t, treat it as simulator tooling mismatch and move on.
• If simulator works and device doesn’t, treat it as a device OS / symbol / entitlement / trust issue.
• If both fail only when SwiftUI instrument is present, you’re back to instrument/template failure.

4) Attach mode: “launch from Instruments” vs “attach to process”

Record two ways:

• Launch the app from Instruments via the template
• Attach to the running process

This matters because different attach paths can change what gets injected and when. If one attach path works reliably, standardise on it for the current Xcode line until the bug is fixed.

Fast checks that avoid chasing ghosts

These are boring, but they stop you losing hours to a misconfiguration that looks like an Apple tooling bug.

• Confirm you’re profiling a Release-like configuration (Profile action defaults to Release in many setups, but teams often customise schemes). Apple’s SwiftUI profiling walkthrough uses Xcode’s Profile flow (⌘I) which compiles and launches Instruments. (developer.apple.com)
• Confirm you’re not pausing at a breakpoint or stopping early: paused apps freeze gauges and can yield traces that look “dead” if you don’t notice you halted execution. (help.apple.com)
• Confirm you have a sustained interaction that should trigger updates (e.g. scrolling a long list, repeated state toggles). SwiftUI traces aren’t magic; if nothing changes, lanes can be sparse.

If you can’t make a clean SwiftUI list app show updates, stop. That’s no longer “my app is weird”; it’s environment.

When the SwiftUI lane is empty: how to still get actionable performance data

Even if the SwiftUI lanes are unavailable, you can still answer the two questions that matter:

• Where is CPU time going during the hitch/jank?
• What code path correlates with the moment the UI stutters?

Here’s the pragmatic workflow.

1) Use Time Profiler as the ground truth

The SwiftUI template exists to help you focus your investigation, but the mechanical work of finding hotspots still goes through CPU sampling. Apple’s own SwiftUI performance session demonstrates pivoting from a selected SwiftUI update into Time Profiler and then searching within stacks for the relevant view/body work. (developer.apple.com)

When SwiftUI lanes are empty:

• Run Time Profiler alone.
• Reproduce the stutter with a tight loop of interactions.
• Use time range selection around the visible spike / stutter window.
• Look for main-thread heavies first (layout, formatting, JSON decoding on main, image decoding, synchronisation).

This is less convenient than clicking a “Long View Body Update” marker, but it still yields fixes.

2) Instrument your own “UI update boundaries” (do this when SwiftUI tooling is flaky)

If you need correlation points, add lightweight signposts around the behaviours you suspect (e.g. “feed refresh”, “cell render”, “image pipeline”, “search results diff”). Then profile with an instrument that will still record signposts even when SwiftUI lanes don’t.

The trade-off is obvious: this is manual and adds code you later remove. But it gives you timestamps you control, which is exactly what you need when built-in lanes go dark.

Rule: do not over-instrument. Add 3–6 signposts around high-level operations, not every view body.

3) Use responsiveness indicators even if SwiftUI lanes are gone

The SwiftUI template commonly pairs SwiftUI with responsiveness tooling (e.g. hangs/hitches) and CPU sampling. (developer.apple.com)

If the “all lanes empty” bug is triggered by the SwiftUI instrument’s presence, you may need to create a “Responsiveness + CPU” template that excludes SwiftUI:

• Time Profiler
• Hangs / hitch detection (where available)
• Points of Interest / signposts (if that track is reliable in your environment)

The goal is to answer: “is the hitch CPU starvation on main, blocking I/O, lock contention, or something else?” You don’t need SwiftUI lanes to answer that.

A reproducible triage checklist (copy/paste into your ticket)

Use this as your internal runbook so your team stops re-discovering the same dead ends.

1. Create a brand-new SwiftUI app (List + navigation + a small animation) and confirm it runs.
2. Profile with SwiftUI template as-is for 30–60 seconds.
3. Duplicate the trace document and remove the SwiftUI instrument only; re-run same steps.
4. Profile with Time Profiler only.
5. Repeat steps 2–4 on: - Simulator - Physical device
6. Repeat on an alternate machine or a clean user account if available.
7. Record environment details: - macOS version - Xcode version/build - Device model + OS version - Launch mode (Xcode Profile vs Instruments standalone; attach vs launch)
8. If “SwiftUI present => everything empty” is reproducible, stop there and file it as a tooling regression with your minimal project and steps.

That “stop there” matters: if the SwiftUI instrument is silencing the rest of the recording, no amount of app code archaeology will fix it.

What to tell leadership (and what not to do)

If you need to brief a CTO/founder quickly:

• The SwiftUI instrument is a convenience layer; it’s not your only route to performance fixes. Apple’s own guidance uses it to guide you into Time Profiler, but Time Profiler remains the bedrock. (developer.apple.com)
• Current field reports indicate a regression where including the SwiftUI instrument can result in empty traces, and removing it restores normal recording. (developer.apple.com)
• The right mitigation is not “don’t profile”; it’s “profile with a template that excludes SwiftUI lanes for now, and add signposts where we need correlation”.

Do not do this:

• Don’t accept “empty lane” as proof your UI isn’t the problem.
• Don’t block a release on a single instrument lane being present when CPU sampling can still find the hotspot.

Where Codeversols fits (briefly)

At Codeversols we do mobile engineering work where performance investigations have to be repeatable, not artisanal: minimal repros, clean profiling templates, and tight feedback loops from trace to code change. If you’re currently burning senior engineer time fighting tooling regressions, we can help you put a pragmatic profiling workflow in place while you wait for upstream fixes.

Close

When Instruments’ SwiftUI template shows empty lanes on Xcode 27, your best move is to treat it like any other production incident: reduce variables, reproduce in a clean project, and isolate whether the SwiftUI instrument’s presence is poisoning the whole recording. If it is, remove SwiftUI from the template and keep working with Time Profiler plus a small set of signposts.

You’ll still ship fixes — and you’ll have a crisp bug report ready when Apple tooling catches up.