1# Profiling intake and collection checklist
2 
3## Intent
4 
5Use this checklist when code review alone cannot explain the SwiftUI performance issue and you need runtime evidence from the user.
6 
7## Ask for first
8 
9- Exact symptom: CPU spike, dropped frames, memory growth, hangs, or excessive view updates.
10- Exact interaction: scrolling, typing, initial load, navigation push/pop, animation, sheet presentation, or background refresh.
11- Target device and OS version.
12- Whether the issue was reproduced on a real device or only in Simulator.
13- Build configuration: Debug or Release.
14- Whether the user already has a baseline or before/after comparison.
15 
16## Default profiling request
17 
18Ask the user to:
19- Run the app in a Release build when possible.
20- Use the SwiftUI Instruments template.
21- Reproduce the exact problematic interaction only long enough to capture the issue.
22- Capture the SwiftUI timeline and Time Profiler together.
23- Export the trace or provide screenshots of the key SwiftUI lanes and the Time Profiler call tree.
24 
25## Ask for these artifacts
26 
27- Trace export or screenshots of the relevant SwiftUI lanes
28- Time Profiler call tree screenshot or export
29- Device/OS/build configuration
30- A short note describing what action was happening at the time of the capture
31- If memory is involved, the memory graph or Allocations data if available
32 
33## When to ask for more
34 
35- Ask for a second capture if the first run mixes multiple interactions.
36- Ask for a before/after pair if the user has already tried a fix.
37- Ask for a device capture if the issue only appears in Simulator or if scrolling smoothness matters.
38 
39## Common traps
40 
41- Debug builds can distort SwiftUI timing and allocation behavior.
42- Simulator traces can miss device-only rendering or memory issues.
43- Mixed interactions in one capture make attribution harder.
44- Screenshots without the reproduction note are much harder to interpret.
45