Instruments and Apple’s performance tools

• demonstratedProfiling starts from Product › Profile in Xcode, which builds the app for release and launches Instruments already targeting it. WWDC22 10082@6:28exact time
• statedApple states the reason outright: “A debug build trades off runtime performance for debug ability, so profiling data from debug builds can be misleading. Profiling a release build is crucial to get the most actionable data.” WWDC26 268@3:39exact time
• demonstratedInstruments then presents the template chooser. WWDC23 picks Time Profiler as the default starting point “if you don’t yet know” where the problem is; WWDC26 picks the Swift Concurrency template because the codebase uses Swift concurrency, noting the Time Profiler instrument is still available inside it. WWDC23 10248@9:55exact timeWWDC26 268@3:43exact time
• statedEverything in the window is a trace document; Instruments can save and reopen them, so old recordings stay explorable. WWDC19 411@8:07exact time
• statedA custom template you configure can be saved and reappears under the Custom tab of the template chooser later. WWDC16 411@10:59exact time
• demonstratedTarget selection is a distinct area of the window; switching it to “All Processes” is demonstrated, and when Xcode launched the session the target area is already populated. WWDC19 411@9:31exact time
• statedRecording modes. Immediate mode is the default and visualizes data in real time. WWDC18 405@26:57exact time
• statedWindowed mode (also called Last Few Seconds mode) keeps only roughly the last five seconds; System Trace ships with it on by default because the data volume is otherwise enormous. WWDC16 411@2:52exact timeWWDC19 411@5:26exact time
• demonstratedDeferred mode is selected in the recorder settings for lower overhead; the default immediate mode “can be useful to confirm your interactions with an app are captured.” WWDC25 308@11:13exact time
• demonstratedNarrowing to a time range is the pivotal move in every modern demo. Three demonstrated gestures: triple-click an interval to create a time filter; secondary-click › Set Inspection Range, or hold Option for Set Inspection Range and Zoom; and control-click a row › Set Time Filter in the older System Trace idiom. WWDC22 10082@6:58exact timeWWDC23 10248@12:40exact timeWWDC16 411@14:10exact time
• demonstratedCall tree shaping. The Call Tree button in the bottom bar exposes the Hide System Libraries checkbox, which “filter[s] out all functions from the system libraries” and makes your own code easier to focus on. WWDC23 10248@13:50exact time
• demonstratedThe older, richer call tree popover plus context-menu operations: focus by context, Charge <symbol> to callers to remove a subtree’s content, and call tree constraints (e.g. a minimum sample count of 20) to suppress noise. This is a 2018 UI. WWDC18 407@19:43exact timeWWDC18 407@21:20exact timeWWDC18 407@22:31exact time
• demonstratedThree detail views, one segmented control — the outline call tree (“great when looking at sample counts”), the flame graph (easier to scan and spot issues visually), and Top Functions — all reached from “the segmented control in the bar above the call tree”. WWDC26 268@10:36exact timeWWDC26 268@11:15exact time
• demonstratedTop Functions lists functions by self weight on the left, with a flame graph of all code paths calling into the selected function on the right. It is the tool for “no single obvious issue… these different codepaths sum together to be costly enough to cause hangs.” WWDC26 268@11:25exact time
• demonstratedRun Comparisons (new at WWDC26). Instruments compares profiling data across runs in one document, matching each function from the baseline run to the new version, computing a delta per node and sorting by performance difference: red = regression, green = improvement, with regressions sorted to the top by default. Comparisons appear as a tab in the sidebar, you can create several, and they are saved into the document for collaboration. WWDC26 268@13:30exact timeWWDC26 268@14:43exact time
• demonstratedCrucially, before comparing, the demo filters both runs to the exact same os_signpost interval “to ensure an accurate comparison without noise.” WWDC26 268@14:08exact time
• demonstratedPinning a thread into the timeline to inspect it alongside other tracks — via the inspector in WWDC26, and via secondary-click › Pin Thread in Timeline in WWDC25. WWDC26 268@22:27exact timeWWDC25 308@16:37exact time
• demonstratedGetting back to source. From a call tree node, secondary-click › Reveal in Xcode opens the implementation; from the heaviest stack trace, Open in Source Viewer replaces the call tree with an inline source view. WWDC23 10248@19:34exact timeWWDC23 10248@24:01exact time
• demonstratedLaunching straight from a unit test. In Xcode’s test navigator, secondary-click a test name and choose its Profile item to open Instruments on exactly that test. WWDC25 308@10:51exact time
• statedSymbolication is what turns addresses into the function names a call tree needs; a whole session is devoted to how it works and to the sources of debug information you must configure. WWDC21 10211@0:22exact timeWWDC21 10211@0:34exact time

1. Reproduce the symptom by hand first, and know which gesture triggers it.
2. In Xcode, Product › Profile (release build, correct device).
3. Pick a template that matches the question — Time Profiler if you don’t know yet.
4. In the recorder settings, choose the recording mode: immediate to confirm your interactions are landing; deferred or windowed / last-few-seconds to cut overhead once you know what you’re reproducing.
5. Record, perform only the problem interaction, stop.
6. Find the interval — ideally via your own signpost in the Points of Interest track.
7. Set Inspection Range and Zoom (Option-secondary-click) on that interval.
8. Pin the thread you care about into the timeline.
9. Read the detail view: start on the flame graph or heaviest stack trace to orient, switch to the call tree with Hide System Libraries on to find your own code, switch to Top Functions when cost is diffuse rather than concentrated.
10. Reveal in Xcode / Open in Source Viewer to get to the line.
11. Fix, re-record with the same signpost interval, and use Run Comparisons against the baseline to prove the delta.
12. Save the .trace document — it is the shareable artifact.

• Profile a release build, always; a debug build’s data can be misleading. WWDC26 268@26:12exact time
• Add an os_signpost interval around the operation you’re tuning before you start, so that both the inspection range and any later run comparison are anchored to the identical window. WWDC26 268@26:14exact time
• Option-secondary-click gets you Set Inspection Range and Zoom in one gesture instead of two. WWDC23 10248@12:46exact time
• With System Trace specifically: because it records in windowed mode, “make sure that when you reproduce the problem” you stop promptly — you only get those last few seconds. WWDC16 411@11:31exact time
• Save a configured template to the Custom tab so a recurring investigation is one click next week. WWDC16 411@10:59exact time
• Run comparisons are saved into the trace document, so the document — not a screenshot — is what you hand a teammate. WWDC26 268@14:48exact time

Instruments is a Mac app used against both. The foundations here — templates, targets, recording modes, call-tree shaping, inspection ranges, source navigation — are platform-neutral in every session the crew read. System Trace specifically “works great in all four of our platforms.” The one clearly device-gated foundation is Processor Trace. WWDC16 411@2:33exact time

• Recording performance data, including Instruments basics. DocsRecording performance datadoc
• Diagnosing performance issues early. DocsDiagnosing performance issues earlydoc

• statedThe sampling model, stated precisely. Time Profiler “uses a hardware timer to sample the state of your app’s execution at regular intervals. The default sampling rate is one millisecond. When the timer fires, it records the current call stack on every core.” WWDC18 independently confirms the 1 ms interval. WWDC26 268@7:29exact timeWWDC26 268@7:35exact timeWWDC18 407@14:56exact time
• demonstratedHow samples become weights. A toy example: “In this first sample, main calls saveNote. In the call tree, each of these functions receives a weight of 1.” The longer a function runs, “the more likely it will be sampled.” WWDC26 268@7:48exact timeWWDC26 268@8:41exact time
• demonstratedThe heaviest stack trace appears in the Extended Detail view and is “the set of functions that were” most sampled; clicking a frame in it reveals the corresponding node in the call tree. WWDC19 411@14:17exact timeWWDC23 10248@13:27exact time
• demonstratedTime Profiler cannot distinguish one slow call from many fast ones. The worked Turtle/Unicorn example: with the same sample counts, “it could also be that this is a very fast Turtle, and Unicorn takes much longer, or other combinations. All of these scenarios would create the same data in Time Profiler.” The stated remedy: “To measure the execution time of a specific function, use os_signposts.” WWDC23 10248@16:37exact timeWWDC23 10248@16:45exact timeWWDC23 10248@16:50exact time
• statedWhich direction to look. For a long-running function, look at its implementation and callees — “look further down”. For a function called very often, look at what calls it and whether you can call it less — “look further up.” WWDC23 10248@15:51exact timeWWDC23 10248@16:10exact time
• statedTime Profiler only sees running threads. “time profiler only samples what’s actually running”, whereas the threads in question “are spending a lot of time in the blocked and runnable states.” WWDC26 restates it: “Because Time Profiler only monitors active CPU cycles, it provides no visibility into these events” — file I/O waits, lock waits, IPC waits. WWDC16 411@18:38exact timeWWDC26 268@2:54exact time
• statedWhy aliasing matters on Apple silicon specifically: “Apple silicon CPUs are asymmetric and some of them will run at a slower, but more power-efficient clock frequency than others. Individual CPUs that scale up their frequency will be sampled more often, without Time Profiler’s bias against faster-running CPUs.” WWDC25 308@10:28exact timeWWDC25 308@10:36exact time
• statedTime Profiler still has a stated strength: it “is helpful for analyzing how work is distributed over time or which threads are active at the same time.” WWDC25 308@9:31exact time
• demonstratedHang labelling is built in. Since Xcode 14, “the Time Profiler also detects hangs and labels them directly in the corresponding process track”, available by default in “the Time Profiler and CPU Profiler instruments.” WWDC22 10082@6:04exact timeWWDC22 10082@8:02exact time
• demonstratedReading a hang’s CPU signature. In the demo: “the main thread has barely any CPU usage during the hang interval, meaning the main thread was unresponsive because it was waiting on another thread, not because it was doing too much work itself.” WWDC22 10082@7:19exact time

1. Record with the Time Profiler (or the Swift Concurrency / Animation Hitches template, which contain it) on a release build.
2. Narrow to the symptom’s interval.
3. Pin and select the thread — usually the main thread first.
4. Ask the CPU-usage question before the call-tree question: is this thread near 100% CPU, or near zero? High means a code bottleneck; low means it’s blocked, and Time Profiler will not tell you on what.
5. If high: read the flame graph or heaviest stack trace to orient, then the call tree with Hide System Libraries on.
6. Decide up or down: long-running function → inspect its callees; frequently-called function → inspect its callers and call it less.
7. If cost is spread across many paths rather than concentrated, switch to Top Functions.
8. For CPU-throughput optimization work (as opposed to responsiveness triage), re-record under CPU Profiler instead.
9. To get a duration rather than a sample count for a specific function, add an os_signpost interval and re-record.

• Prefer CPU Profiler when the question is “which code burns the most CPU”; prefer Time Profiler when the question is how work is distributed over time or which threads are active at the same time. WWDC25 308@10:12exact time
• Launch straight from a unit test (test navigator → secondary-click → Profile) so the recording contains your workload and almost nothing else. WWDC25 308@10:51exact time
• Clicking a frame in the heaviest stack trace jumps the call tree to that node — faster than hunting down the tree by hand. WWDC23 10248@13:27exact time
• When a stack is “already pretty deep in the call tree”, that depth itself is the signal that a single leaf isn’t the story. WWDC23 10248@13:31exact time

Both. Nothing in any Time Profiler / CPU Profiler demo the crew read is platform-gated. The aliasing / asymmetric-core argument is specific to Apple silicon, which covers modern Macs and all iOS devices. WWDC25 308@10:28exact time

• Apple’s Performance video index lists no dedicated Time Profiler session after WWDC19, so the most current Time Profiler teaching lives inside WWDC26 268 and WWDC25 308 rather than in a “Time Profiler” session. DocsPerformance &mdash; Apple Developer vi…doc
• Improving app responsiveness (current guidance hub). DocsImproving app responsivenessdoc

• statedWhat it records. Taking a System Trace recording “puts the kernel into a special tracing mode that records all the scheduling activity, system calls, and virtual memory operations that are occurring.” WWDC16 411@2:40exact time
• statedWhy an app developer cares. A user “doesn’t see your application as a peer with all these system services and daemons contending for shared resources”; if your app “stutters due to a flurry of virtual memory activity or due to maybe a misprioritized thread, they’re going to come to you looking for a fix.” WWDC16 411@2:00exact time
• statedThe three second-order effects it exists to surface: “increases in preemption, lock contention, and virtual memory activity.” WWDC16 411@1:05exact time
• demonstratedThread states are visible in the track and hoverable. “if you hover over the thread states, you’ll see it was running for this period… Then it was blocked for a little while. Then it was runnable for kind of a long time, so that means it’s not actually running.” WWDC16 411@17:54exact timeWWDC16 411@18:06exact time
• demonstratedThe colour legend, read out against a real trace: “gray means it’s blocked, meaning that the thread isn’t doing any work. Red means it’s runnable, meaning that there’s work scheduled to [do but it lacks] resources. Orange means it’s preempted, meaning that it was doing work [and got evicted].” WWDC19 423@23:21exact timeWWDC19 423@23:35exact time
• demonstrated“Made runnable by” — who released the lock. “now it’ll show you which thread made your thread runnable. So basically who released that lock so that you could take it.” Independently demonstrated again in an app-launch trace: “afterwards, it was unblocked, or made runnable, by thread 0x12253.” WWDC16 411@17:01exact timeWWDC19 423@30:18exact time
• demonstratedThe Narrative view is the detail view that “tells us the story of the thread”, showing the entry for a blocked state. WWDC23 10248@37:47exact time
• demonstratedA concrete blocking diagnosis. “the thread was blocked for 6.64 seconds and it was blocked because it was calling mach_msg2_trap, a syscall.” The backtrace beside it is not an aggregation: “It is the precise backtrace of the mach_msg2_trap syscall that caused the thread to be blocked.” That stack then showed the syscall came from allocating an MLModel. 6.64 s is that demo’s number. WWDC23 10248@38:03exact timeWWDC23 10248@38:15exact timeWWDC23 10248@38:28exact time
• statedThe modern framing of the same machinery. “when a resource isn’t immediately available a thread enters the blocked state. When this occurs, the kernel evicts the thread from the processor. Only when the resource is finally ready, the thread becomes runnable, and returns to the core.” And on the runnable state: “the thread doesn’t immediately start executing. It first enters the runnable state, which means the resource is ready” — i.e. runnable time is queueing time. WWDC26 268@20:59exact timeWWDC26 268@21:18exact time
• demonstratedReading syscall intervals correctly. “The purple intervals you see indicate that a system call is running. However, just because a syscall is active does not mean the thread is actually executing the application code.” Selecting one segment highlights more than you clicked, because it “visualizes one continuous write system call that spans both on and off-core time.” WWDC26 268@22:52exact timeWWDC26 268@23:10exact time
• demonstratedReading a System Trace overlay for a hang. “the red line indicates system calls, the purple graph indicates virtual memory faults, and the horizontal blue bar indicates the main thread is busy doing work.” Note the colour conventions here differ from WWDC26’s purple-for-syscall — see the traps. WWDC21 10258@12:13exact time
• statedWhat System Trace adds over Time Profiler, stated compactly: it “adds more context with data on system calls, VM faults, I/O, as well as inter and intra-process interactions.” WWDC21 10258@11:40exact time
• statedThe two sub-instruments by name. “The Thread State Trace instrument shows a timeline of the thread’s state”; “The System Call Trace shows a narrative that details the system calls entered and how long they took.” WWDC21 10181@10:06exact timeWWDC21 10181@10:22exact time
• demonstratedWorkflow for isolating one thread’s story: “select the thread, create a time filter selection… and then change the detail section from the narrative” view. WWDC16 411@20:28exact time

1. Reach for System Trace after Time Profiler has shown you a low-CPU stall — not before.
2. Record with the System Trace template (windowed by default) and stop promptly after reproducing.
3. Narrow to the stall interval.
4. Pin the stalled thread and read its thread-state band: how much is blocked (grey), runnable (red), preempted (orange)?
5. For a blocked stretch, open the Narrative view to get the blocking reason, the duration, and the precise backtrace of the blocking syscall.
6. Follow “made runnable by” to the thread that released you — that’s your contention partner.
7. For runnable-heavy stretches, you have a scheduling or priority problem, not a code-speed problem.

• Long runnable time is the tell for a priority or contention problem: the work was ready and the thread still wasn’t on a core. WWDC16 411@18:06exact time
• The backtrace next to a blocked state in the Narrative view is exact, not aggregated — you can trust it the way you cannot trust a sampled stack. WWDC23 10248@38:15exact time
• Because the template records in windowed mode, reproduce first and stop immediately; you only keep the last few seconds. WWDC16 411@11:31exact time

Explicitly both, and more: “It works great in all four of our platforms.” WWDC16 411@2:33exact time

• WWDC16 411 is the only deep System Trace session in Apple’s Performance index and shows Instruments 8. Its concepts are intact; its UI is a decade old. The current UI for the same analysis is demonstrated in WWDC26 268 from 20:49 onward — cross-read them. WWDC26 268@20:49exact time
• Improving app responsiveness. DocsImproving app responsivenessdoc

• statedThe definition, verbatim. “A hang is reported when the main thread is busy doing work or waiting on another thread or system resource, causing a delay in updating the view content by at least 250 milliseconds. The main thread is also unavailable to process new user interactions until the hang is resolved.” A second session gives the same threshold. WWDC22 10082@1:26exact timeWWDC22 10082@1:35exact timeWWDC21 10181@8:32exact timeWWDC21 10181@8:37exact time
• statedMicro hangs. “most of our tools start reporting hangs by default starting at 250 ms, but we call these ‘micro hangs’ as they are easy to ignore. Depending on the context, those might be OK, but often they are not.” WWDC23 10248@5:21exact time
• demonstratedWhy micro hangs still matter — demonstrated, not hand-waved: the same code “was slow on an iPad, simply because the screen was bigger. This is one of the reasons why you should also fix micro hangs. What you might see as a micro hang during testing at your desk might be a major hang for some of your users under different conditions.” WWDC23 10248@22:45exact time
• demonstratedThread Performance Checker (Xcode 14+). It “notifies you in the Xcode Issue Navigator when it detects priority inversions and non-UI work on the main thread of your app, both of which are common causes of hangs” — and it works “while debugging your app without actively tracing it.” Enabled from the Diagnostics section of the scheme. WWDC22 10082@3:55exact timeWWDC22 10082@4:49exact timeWWDC22 10082@5:30exact time
• demonstratedPriority inversion, in the demo’s terms: “a higher priority thread was attempting to be synchronized with a lower priority thread. This may indicate the hang we are noticing is caused by the main thread waiting on different lower-priority threads.” WWDC22 10082@5:13exact time
• demonstratedThread Performance Checker now also surfaces in tests (Xcode 26): “Tests can now surface framework runtime issues as well as call out threading problems using the Thread Performance Checker.” WWDC25 247@35:37exact time
• statedThe Hangs instrument. Hang detection and labelling is on by default in Time Profiler and CPU Profiler; separately “There is also a new standalone hang tracing instrument that you can add to any trace documents… it allows you to configure a hang duration threshold to find specific periods of unresponsiveness.” WWDC23’s document “contains the Time Profiler instrument and the Hangs instrument, both of which will be useful for our analysis.” WWDC22 10082@8:06exact timeWWDC23 10248@10:15exact time
• statedSemaphores are called out as an anti-pattern: “be aware of semaphore use, as they do not propagate priority and can lengthen a hang due to preemption. A common anti-pattern is when trying to make asynchronous API [synchronous].” WWDC21 10258@9:14exact time
• demonstratedOn-device hang detection (iOS 16+). Enabled at Settings › Developer › Hang Detection, available “for development-signed or TestFlight apps”, giving real-time notifications plus diagnostics without Xcode or tracing. The Hang Threshold is configurable, minimum 250 ms, and “can be bumped to 500 milliseconds or higher.” WWDC22 10082@9:11exact timeWWDC22 10082@9:52exact timeWWDC22 10082@9:58exact time
• demonstratedWhat you get per hang: “both a text-based hang log and a tailspin”. The text log “has less information, but can give us an understanding of the hang at a glance”; for a deeper investigation, open the tailspin in Instruments. Diagnostics are “best-effort and processed in the background at a low priority to minimize performance overhead”, so they can take a while to appear. WWDC22 10082@10:30exact timeWWDC22 10082@10:58exact time
• demonstratedWhy the desk misses real hangs. A synchronous network request on the main thread showed no delay “at my desk with Xcode and a strong network connection”, but hung for over three seconds in the field. “It is important to test the beta version of your app under these different, real-world conditions.” WWDC22 10082@11:33exact time
• statedThe WWDC26 triage question — the cleanest formulation of the whole cluster. After Time Profiler orients you, “what is the CPU doing during the hang? If CPU usage is high, then the thread is busy and the work is taking too long… If the application hangs but the processor is idle, optimizing algorithms won’t be helpful. This, usually, suggest[s] that the main thread is stuck waiting for a resource to free up” — commonly file I/O, a synchronization lock, or IPC. WWDC26 268@2:02exact timeWWDC26 268@2:33exact timeWWDC26 268@2:46exact time
• statedThe two fixes for the high-CPU branch: “The first is code optimization: refactoring algorithms to execute faster. But, if the heavy workload is unavoidable, resolve it by offloading the work to a background task so the user interface remains responsive.” WWDC26 268@2:18exact time

1. Before tracing anything, enable the Thread Performance Checker in the scheme’s Diagnostics section and just run the app. Priority inversions and main-thread non-UI work show up in the Issue Navigator for free.
2. Reproduce under Product › Profile with a template containing the Hangs instrument.
3. Find the labelled hang interval in the process track; the label carries the duration.
4. Triple-click or Option-secondary-click to filter to exactly that interval.
5. Look at main-thread CPU usage first. High CPU → code bottleneck: read the call tree / Top Functions, then either optimize or move the work off the main thread. Low CPU → blocking: go to System Trace (thread states, Narrative, blocking backtrace) or the Swift Concurrency instruments.
6. Fix, re-record, and confirm the hang label is gone — then check for a remaining micro hang.
7. For the field: enable Settings › Developer › Hang Detection on a TestFlight build and test on bad networks; open the tailspin in Instruments for anything the text log can’t explain.

• The Thread Performance Checker costs you nothing to leave on during development and catches the two classic hang causes without tracing. WWDC22 10082@3:55exact time
• Raise the on-device Hang Threshold above 250 ms when the 250 ms notifications drown out the hangs you actually care about. WWDC22 10082@9:58exact time
• Test on a larger-screened device; the WWDC23 demo’s micro hang on iPhone was a real hang on iPad purely because of screen size. WWDC23 10248@22:45exact time
• Test on a weak network; a synchronous request that is invisible at your desk is a three-second hang in the field. WWDC22 10082@11:33exact time
• Don’t wrap async APIs in semaphores to make them synchronous — priority does not propagate. WWDC21 10258@9:14exact time

The concept and the Instruments tooling (Hangs instrument, Time Profiler hang labelling, Thread Performance Checker) are demonstrated on iOS but are not stated to be iOS-only. On-device hang detection is explicitly iOS 16, reached through Settings › Developer, so it is an iOS/iPadOS feature as demonstrated. Apple’s documentation notes macOS’s own vocabulary for the same phenomenon — “spin based on the spinning wait cursor that appears in macOS when an app is unresponsive” — and gives a perception threshold for discrete interactions: “A delay of less than 100 ms in a discrete user interaction is rarely noticeable, but even a few hundred milliseconds can make people feel that an app is unresponsive.” WWDC22 10082@9:11exact timeDocsUnderstanding hangs in your appdoc

• Understanding hangs in your app — current conceptual reference, including the macOS “spin” vocabulary and the 100 ms discrete-interaction figure. DocsUnderstanding hangs in your appdoc
• Improving app responsiveness. DocsImproving app responsivenessdoc

• statedHitch vs hang. A hitch is an interruption in continuous motion, not a period of unresponsiveness: “Hitches are caused when the Render Loop fails to finish a frame on time.” Apple’s documentation draws the same line: hitches “happen during continuous interactions, like scrolling or dragging, or during animations”, whereas a hang is the delay in a discrete interaction. Tech Talks 10855@1:33exact timeDocsUnderstanding hitches in your appdoc
• demonstratedThe render loop has five phases, demonstrated in order: event → commit → render prepare → render execute → display. “The loop begins with the first phase, the event phase. Here your app handles touch events and decides if a change is needed in the UI. Next is the commit phase. In the commit phase, your app updates its UI and submits that to the render server for rendering. On the next VSYNC, the render server takes that submission, and in the render prepare phase, prepares it for drawing on the GPU. In the render execute phase, the GPU draws your UI into a final image, so on the next VSYNC the frame can be displayed to your user.” Tech Talks 10855@3:15exact timeTech Talks 10855@3:19exact time
• statedThe render server does work on your behalf, and it’s still your problem: “Although it happens in a separate process, it does work on your app’s behalf, so it’s on you to ensure your layer tree can be processed and drawn in time.” Tech Talks 10855@3:57exact time
• statedTwo types of hitch: “a commit hitch and a render hitch.” Tech Talks 10855@11:20exact time
• demonstratedInside the commit phase, in sequence: layout runs parent-to-child (“Layout is a common performance bottleneck, so keep in mind that your app only has a couple of milliseconds to complete this work”), then setNeedsDisplay drawing into texture-backed Core Graphics contexts, then “the entire altered layer tree is collected and sent to the render server.” Tech Talks 10855@5:10exact timeTech Talks 10855@5:50exact time
• demonstratedInside the render phases: in prepare “the render server iterates through the app’s layer tree and prepares a linear pipeline that the GPU can then execute”, working back-to-front; in execute “each layer is composited into a final texture”, and “Some layers can take longer to render, and this is another common performance bottleneck”. Tech Talks 10855@6:04exact timeTech Talks 10855@6:30exact time
• statedHitch time ratio, defined. “Hitch time ratio is the total hitch time in an interval divided by its duration. Because it’s normalized to total time, we can compare it across experiences. It’s measured in hitch milliseconds per second.” WWDC20 restates it and gives the motivation: a raw hitch-time total “over a one-second test cannot be compared to that over a ten-second test.” Tech Talks 10855@9:30exact timeWWDC20 10077@3:24exact time
• statedThe 2020 target thresholds, read out on screen: “anything under five hitch milliseconds per second is considered good and mostly unnoticeable by a user. Between five and ten hitch milliseconds per second, the user is going to notice some interruptions, and these should be investigated. Over ten hitch milliseconds per second, hitches are greatly impacting the user experience, and you should immediately investigate.” WWDC20 gives the same 5 / 10 bands. See the traps — Apple’s current Organizer documentation gives different numbers. Tech Talks 10855@10:51exact timeTech Talks 10855@11:05exact timeWWDC20 10077@3:44exact time
• demonstratedThe Animation Hitches template. “you can use the new Animation Hitches template in Instruments to detect and investigate hitches”, and usefully “the animation hitches template includes Time Profiler”, so you can go straight from a hitching commit to the code that made it expensive. Tech Talks 10856@10:43exact timeTech Talks 10856@5:34exact time
• demonstratedReading a commit hitch: select the main thread of the process, display its call tree, and “We can see that this call tree is originated from a commit transaction”. Tech Talks 10856@5:54exact time
• demonstratedRender hitches are “hitches caused by slowness” in the render prepare and render execute phases; the session uses the animation hitches template plus the Xcode view debugger to optimize the layer tree. Tech Talks 10857@0:22exact timeTech Talks 10857@6:43exact time
• statedHitches are a first-class instrument in the modern roster: “we have the Hangs and Hitches instruments, which keep track of your app’s responsiveness.” WWDC25 306@2:45exact time
• statedAs a test metric: XCTHitchMetric “reports multiple metrics for your app’s hitch performance, such as Hitch Time Ratio.” WWDC25 247@35:06exact time

1. Record with the Animation Hitches template while performing the stuttering gesture.
2. Find a hitching frame in the display track; note whether the hitch is attributed to the commit phase (your process) or the render phase (render server).
3. Commit hitch → select the main thread, read the call tree rooted at the commit transaction; suspect layout, drawRect/setNeedsDisplay custom drawing, or work you scheduled into the event phase. The template’s bundled Time Profiler gets you to the code.
4. Render hitch → look at the layer tree; use the Xcode view debugger to find layers that are expensive to prepare or composite.
5. Quantify with hitch time ratio, not raw hitch milliseconds, so results compare across runs and devices.
6. Lock in the win with XCTHitchMetric in a performance test, with a baseline.

• Always normalize to hitch time ratio; a raw total is meaningless across tests of different length. WWDC20 10077@3:24exact time
• Your app has “only a couple of milliseconds” for layout in the commit phase — treat layout cost as a hard budget, not a soft one. Tech Talks 10855@5:10exact time
• For hitch performance tests, use “a separate test scheme”, “select the release build configuration and disable the debugger”, and disable automatic screenshot collection. WWDC20 10077@8:33exact time
• Set the measured average as a baseline so future runs are compared against it. WWDC20 10077@9:22exact time

The three hitch Tech Talks are iOS-framed — session 10856 opens with views “rendered onto the display by iOS” — and the render-loop / VSYNC / Core Animation model they teach is the UIKit one. No session the crew read teaches hitch analysis on macOS. Treat the macOS applicability of this specific tooling as unverified, not as established. Tech Talks 10856@0:24exact time

• Understanding hitches in your app — current thresholds and the Organizer Hitches metric. DocsUnderstanding hitches in your appdoc
• The three hitch talks are Tech Talks the crew dates to 2020, on the strength of another Apple session calling them “the… tech talks from 2020”. The Tech Talk pages themselves carry no year. They predate SwiftUI’s current instrument suite. WWDC21 10181@12:50exact time

• statedThe Points of Interest instrument is deliberately empty until you fill it: it “is essentially a blank canvas where you tell Instruments what you consider” interesting. WWDC19 shows it literally empty before instrumentation and populated after. WWDC16 411@3:37exact timeWWDC19 411@10:50exact timeWWDC19 411@26:12exact time
• demonstratedHow a signpost lands in that track: the category is the routing. You create a log handle with your subsystem identifier and the system’s points-of-interest category, and then in “Instruments, you can see that we have those points of interest prominently displayed.” WWDC26 does the same with modern API and says why: “I set the subsystem to ‘Demo App’ so that I know it’s related to my App. And, I set the category to points of interest, so that instruments will automatically surface this data in the points of interest track.” WWDC18 405@29:46exact timeWWDC18 405@30:25exact timeWWDC26 268@6:04exact time
• demonstratedSignpost IDs pair a begin with an end. “As long as you pass the same signpost ID at the begin call site and the end call site” the two are associated; you can derive the ID from an object so “you don’t have to carry or store the signpost ID around”, and for genuinely concurrent operations “we’re going to create new signpost IDs for each of them.” WWDC18 405@8:16exact timeWWDC18 405@8:42exact timeWWDC18 405@9:51exact time
• demonstratedThe modern API is OSSignposter: “I added an os.signpost interval around lasso selection. I achieved this by using the OSSignposter type which has APIs to start and stop tracing an interval.” WWDC26 268@5:46exact timeWWDC26 268@5:52exact time
• statedSignposts are the stated fix for Time Profiler’s blind spot: “To measure the execution time of a specific function, use os_signposts.” WWDC23 10248@16:50exact time
• demonstratedA signpost interval is a navigation handle in the trace. Both recent sessions use it the same way: “we’ll find the region where searches are happening in the Points of Interest track. Secondary-clicking on the region will offer to set the inspection range, limiting the detail view below to only the data captured in the signpost interval.” WWDC25 308@12:04exact timeWWDC26 268@19:30exact time
• demonstratedAnd it is the precondition for trustworthy run comparison: “we first filter both runs to the exact same os_signpost interval”; the session’s closing advice is “leverage os_signpost to make sure your intervals for run comparisons are reliable.” WWDC26 268@14:11exact timeWWDC26 268@26:14exact time
• demonstratedMissing signposts are a felt cost. On hangs it couldn’t contextualize: “Unfortunately, these don’t have any logs in the points of interest track to help contextualize what was happening at the time.” WWDC26 268@16:19exact time
• statedThe cost model, given explicitly — and hedged by Apple as order-of-magnitude, since “device type, hardware model, OS version, system load, thermals and more” all matter: release build, all signposts — under a microsecond; off-by-default dynamic categories — low nanoseconds when not recording; dynamic stacks category — low microseconds (it records a call stack); streaming (immediate) mode — tens of microseconds, “significantly more expensive”. WWDC19 414@6:33exact timeWWDC19 414@6:39exact timeWWDC19 414@7:05exact time
• statedThe stated mitigation: “you can use Instruments’ deferred or last few seconds mode instead of immediate mode. This keeps OSSignpost out of that streaming mode and reduces the overhead.” WWDC19 414@7:27exact time
• demonstratedCustom instruments build on signposts — a signpost becomes a schema, whose fields become modeled data: you “define what’s called an os signpost interval schema”. WWDC18 410@24:14exact timeWWDC19 421@16:11exact time
• statedCustom-instrument authors are advised that “the last five-second recording mode is by far the most efficient”, and that an instrument can opt out of immediate mode. WWDC18 410@54:00exact timeWWDC18 410@54:51exact time

1. Create a signposter with your subsystem and the points of interest category — the category is what makes it show up in that track automatically.
2. Wrap the operation you care about (OSSignposter begin/end, or os_signpost with a matching signpost ID at both call sites).
3. For concurrent operations, mint a distinct signpost ID per operation, or derive it from the object, so intervals don’t cross-pair.
4. Record. Use deferred / last-few-seconds mode if signpost overhead matters.
5. Use the Points of Interest region as your navigation handle: secondary-click → Set Inspection Range.
6. After a fix, re-record and compare the same signpost interval across runs.

• Add signposts before you need them. The WWDC26 session visibly loses time to a hang it can’t contextualize because no signpost covers it. WWDC26 268@16:19exact time
• The “points of interest” category is the whole trick — it is what auto-surfaces your data without writing a custom instrument. WWDC26 268@6:04exact time
• If signposts start showing up in your own profiles, switch off immediate mode before you start deleting signposts. WWDC19 414@7:27exact time
• Derive signpost IDs from the object the work is about, so you don’t have to thread an ID through your call stack. WWDC18 405@8:42exact time

os_signpost / OSSignposter are os-framework APIs used identically across Apple platforms in the sessions the crew read; nothing platform-gated appears. The Points of Interest instrument is demonstrated on both a Mac app (WWDC16 411) and iOS apps (WWDC26 268).

• OSSignposter — the modern Swift type used in WWDC26. DocsOSSignposterdoc
• Recording performance data. DocsRecording performance datadoc
• WWDC18 405 predates OSSignposter and shows the older os_signpost function form — the concepts transfer, the API surface has moved.

• statedProcessor Trace records everything, not samples. “Starting in Instruments 16.3, Processor Trace can collect a complete trace of all the instructions your app’s process executes in user space”, with “only a negligible 1% impact to your app’s performance”. WWDC25 308@14:09exact timeWWDC25 308@14:28exact time
• statedHardware requirement, stated in-session: “Processor Trace requires specialized CPU features that are only available on Mac and iPad Pro with M4 or iPhone with A18.” Device setup is needed first: on a Mac “under Privacy & Security and Developer Tools”, and on iPhone/iPad “in the Developer section”. WWDC25 308@14:31exact timeWWDC25 308@14:41exact timeWWDC25 308@14:46exact time
• documentedApple’s documentation states it more precisely — and adds the OS floor and an important escape hatch. Recording requires “iPhone 16 and iPhone 16 Pro, or later / iPad Pro with M4 or later / Mac with M4 or later”, on “iOS 18.4 or later, iPadOS 18.4 or later, or macOS 15.4 or later”. But: “You can use Instruments on any Mac to analyze a saved processor trace file, including those that don’t support recording processor traces.” DocsAnalyzing CPU usage with Processor Tracedoc
• statedThe flame graph it produces is different in kind. “most flame graphs show data from sampling and their cost is only an estimate based on a sample count. Processor Trace’s timeline flame graph is different: it shows the calls made over time”. WWDC25 308@16:59exact timeWWDC25 308@17:06exact time
• documentedIt sees compiler-generated code you didn’t write. The instrument “includes time that your app spends in all functions, including code that the compiler generates, such as automatic reference counting (ARC) memory management code in Swift, and synthesized constructors and destructors in C++.” DocsAnalyzing CPU usage with Processor Tracedoc
• statedYou don’t need to batch work for it. “Unlike sampling with CPU Profiler, you don’t need to batch up your work: even a single instance of the code you want to optimize can be enough.” WWDC25 308@14:55exact time
• statedBut keep it short. “For the best experience with Processor Trace, try to limit your tracing to only a few seconds”, and “Processor Trace has to deal with a lot of data, so capturing and analyzing it can take some time.” WWDC25 308@14:52exact timeWWDC25 308@15:31exact time
• demonstratedCPU Counters got preset modes. “This year, we’ve added preset modes for these counters to make them much easier to use. Instruments uses them in a guided, iterative methodology”, and the template offers “a guided configuration with curated modes to measure with”. Instruments “collect[s] CPU counter data for the threads used in our test and convert[s] them into bottleneck percentages”, with a description of a selected bottleneck shown in the extended detail. WWDC25 308@22:35exact timeWWDC25 308@23:11exact timeWWDC25 308@23:53exact timeWWDC25 308@24:17exact time
• statedCPU Counters samples, so it needs a repeatable workload: “The CPU Counters instrument relies on sampling the workload, so we need to return to the test harness we used with CPU Profiler to measure throughput again.” WWDC25 308@22:56exact time
• statedXcode 26’s overview frames Processor Trace the same way: “Unlike traditional sampling profilers that can miss critical code paths between sampling intervals, this tool reveals every branch taken and function called”. WWDC25 247@21:27exact time

1. Get a repeatable workload — a unit test is ideal — and wrap it in an os_signpost interval.
2. Profile it with CPU Profiler first to find where cycles go.
3. If you need exact call costs or suspect sampling is missing something, switch to the Processor Trace template — on qualifying hardware, for a few seconds at most.
4. Pin the thread, expand the per-thread flame graph, and select a specific call; set inspection range and zoom onto one iteration.
5. For microarchitectural tuning, record with the CPU Counters template, choose a preset mode, orient via Points of Interest, and read the bottleneck percentages.
6. Re-measure throughput the same way after each change.

• You can analyze a saved processor trace on any Mac, even one that cannot record it — so a colleague with an M4 can hand you the trace. DocsAnalyzing CPU usage with Processor Tracedoc
• Processor Trace needs only one instance of the code, not a batched loop. WWDC25 308@14:55exact time
• Launch from the test navigator’s per-test Profile item so the trace is almost all signal. WWDC25 308@10:51exact time

Both, but hardware-gated: Mac with M4 or later, iPad Pro with M4 or later, iPhone 16 / 16 Pro or later, on macOS 15.4 / iOS 18.4 / iPadOS 18.4 or later. Analysis of an existing trace works on any Mac. WWDC25 308@14:31exact timeDocsAnalyzing CPU usage with Processor Tracedoc

• This documentation page is the authoritative and more precise statement of the hardware/OS matrix — prefer it over the session’s spoken shorthand. DocsAnalyzing CPU usage with Processor Tracedoc

• demonstratedThe instruments exist and are taught. “The Swift Tasks and Swift Actors instruments provide a full suite of tools to help you visualize and optimize your concurrency code”, via “the new Swift Concurrency template in Instruments”. WWDC22 110350@4:58exact time
• statedThe problems they target: “thread pool exhaustion and continuation misuse”; “Continuation misuse causes leaks or crashes.” WWDC22 110350@0:48exact timeWWDC22 110350@3:13exact time
• statedWhy the main actor is special: “The main Actor is a special Actor which executes all of its work on the main thread… because the main thread is so important for UI, it needs to be available and can’t be occupied by a long-running unit of work.” WWDC22 110350@3:34exact timeWWDC22 110350@3:43exact time
• demonstratedReading it in the trace: start from “the top-level statistics provided to you by the Swift Tasks instrument”, beginning with Running Tasks; then “pin the Main Thread to the timeline” — “The Main Thread is being blocked by several long running Tasks.” WWDC22 110350@5:12exact timeWWDC22 110350@9:14exact time
• demonstratedThe Swift Concurrency Tasks instrument as a hang tool. “For issues like this, where Swift Concurrency tasks don’t execute the way you expect them to, we have another useful instrument: the Swift Concurrency Tasks instrument… The Swift Tasks instrument adds a summary track to the document”, but “what’s more interesting for our case is the data it contributes to each thread track” — the useful data is the new graph inside the main thread track. WWDC23 10248@30:14exact timeWWDC23 10248@30:28exact timeWWDC23 10248@30:40exact time
• statedThe root cause it exposes, stated as a rule: “Swift Concurrency Tasks, by default, inherit the actor isolation of the surrounding context.” WWDC23 10248@32:28exact time
• demonstratedWWDC26 shows the modern version of the same bug and fix. Diagnosis: Time Profiler showed main thread CPU “around a 100%… these tasks are just taking too long to run on the Main Actor”; cause: “because this code was called from SwiftUI, it inherited the Main Actor context. These tasks will compete with critical UI updates for the Main Actor”. Fix: “adding the @concurrent attribute to the task initializer… will move the thumbnail rendering task off the Main Actor, and onto the global executor”, and “The swift compiler will check that this code change does[n’]t introduce any race conditions.” WWDC26 268@17:32exact timeWWDC26 268@18:00exact timeWWDC26 268@18:29exact time
• demonstratedThe verification is visual and specific: “the Swift executors instrument shows that the thumbnail rendering tasks have moved from the Main Actor track to the global executor track”, and the fix “also allowed us to render these thumbnails in parallel.” WWDC26 268@18:47exact timeWWDC26 268@19:02exact time
• statedWWDC26’s one-line rule for this tool: “When the tasks fight for resources, use the Swift Concurrency instrument to identify actor congestion.” WWDC26 268@25:51exact time
• demonstratedChoosing the template up front: “Because my codebase utilizes Swift Concurrency, I will choose the Swift Concurrency template from the picker. Within this template, we still have access to the Time Profiler instrument.” WWDC26 268@3:43exact time

1. If the codebase uses Swift concurrency, start from the Swift Concurrency template — it still contains Time Profiler, so you lose nothing.
2. Narrow to the stutter, pin the main thread.
3. Read main-thread CPU: ~100% with async work on it is actor congestion, not blocking.
4. Look at the Swift Tasks graph inside the main thread track (not just the summary track) to see which tasks are running there.
5. Ask why they’re there — usually inherited actor isolation from a main-actor-isolated caller.
6. Move them off (@concurrent, or otherwise breaking the isolation inheritance) and let the compiler check for races.
7. Verify in the Swift executors track that the tasks moved from the Main Actor track to the global executor track — and check whether they now run in parallel.

• The interesting data is in the thread tracks, not the summary track — WWDC23 says this twice, once for Swift Concurrency and once for Thread States. WWDC23 10248@37:24exact time
• 100% main-thread CPU during a hang in an async codebase points at actor congestion, and the Time Profiler call tree alone won’t say so. WWDC26 268@17:32exact time
• The executor track is a before/after artifact: it visibly shows work relocating, which makes it an unusually clean way to prove a concurrency fix. WWDC26 268@18:47exact time

Swift concurrency and these instruments are platform-neutral; the demos are iOS/iPadOS apps. Nothing platform-gated is stated — the crew inferred applicability from the absence of any stated restriction, which is not an explicit Apple claim.

• WWDC22 110350 predates @concurrent and current isolation rules; WWDC26 268 is the current reference for this tool and for the fix idiom. Read 2022 for the instrument’s anatomy, 2026 for what to actually do.
• Improving app responsiveness. DocsImproving app responsivenessdoc

• demonstratedThe Allocations template contains two instruments, Allocations and VM Tracker: Allocations records heap and VM events live, VM Tracker periodically snapshots all virtual memory. WWDC24 10173@6:14exact time
• demonstratedReading a spike. Selecting a spike interval from its low point to its peak and sorting the statistics view by Persistent isolates what survived to the top of the spike; in the demo, @autoreleasepool content stood out with “hundreds” of entries. WWDC24 10173@8:18exact time
• demonstratedAttributing churn to code. Switching the Lifespan filter to Created & Destroyed across a wide range, then switching the detail view to a call tree, attributes transient churn to code. The demo’s trace showed 8 GB of temporary allocations traced to a makeThumbnail() path. 8 GB is that demo’s number, not a measurement of any app. WWDC24 10173@9:06exact time
• demonstratedMark Generation breaks persistent growth down by timespan: the first press groups all allocations created before that point that persisted to the end of the trace; each later press groups allocations made after the previous generation and before the new mark. WWDC24 10173@14:01exact timeWWDC24 1017313:57named section only
• demonstratedExpanding a generation and ordering by growth size names the responsible types; individual allocation addresses are readable in the extended detail view and can be pasted into the Memory Graph Debugger’s filter bar. WWDC24 10173@15:16exact time
• demonstratedAn imported memory graph populates the Allocations, Leaks and VM Tracker instruments in Instruments. WWDC24 10173@14:26exact time
• demonstratedAllocations marks short-lived allocations as transient; a near-million-allocation count plus “nearly all transient” is presented as the two indicators of unnecessary allocation. WWDC25 312@8:53exact timeWWDC25 3128:17named section only
• demonstratedThe detail-view filter field accepts a symbol substring (the demo typed QOI.init) to drop every call tree that does not contain it. WWDC25 312@13:53exact time
• documentedGenerations are also the documented way to scope allocations to one feature: mark, exercise the feature, mark again. DocsGathering information about memory use § Profile your app using the Allocations instrumentdoc

1. Turn on MallocStackLogging in the scheme’s Diagnostics tab, so every allocation carries a backtrace.
2. Product › Profile (release build, Instruments opens with the app as target), choose the Allocations template, Record.
3. Exercise the suspect feature several times so the pattern repeats, then Stop.
4. Spike shape → transient growth. Drag-select one spike low-to-high; sort statistics by Total Bytes, then by Persistent, to see both the bulk and the survivors.
5. Widen the selection across all spikes, set Lifespan = Created & Destroyed, switch the detail jump-bar to Call Tree, and read the Heaviest Stack Trace; your frames are emphasised. Double-click a frame to open its source.
6. Stair-step shape → persistent growth. Press Mark Generation at the quiet points between growth intervals; expand the generation that grew, order by growth size, and read the type.
7. Copy an offending allocation’s address from the extended detail view and continue in the Memory Graph Debugger to answer why is this still alive.

• For heap analysis specifically, the Simulator is acceptable — “for heap analysis, though, the Simulator environment is a lot closer in behavior, and it’s fine to use for memory profiling” — unlike timing work, which needs a release build on a real device. WWDC24 10173@12:24exact time
• Autorelease-pool content pages are themselves visible in Allocations, which makes them a useful tell for autorelease-driven spikes. WWDC24 10173@11:32exact time
• The fix for that pattern is a nested autoreleasepool scope inside the loop body, draining per iteration. WWDC24 10173@11:58exact time
• If the code is now too fast for Instruments to sample usefully, loop it (the demo looped parsing 50 times) to get a richer profile. WWDC25 312@16:42exact time
• A trace file is portable: save it and hand it to a colleague. WWDC24 10173@7:32exact time

The instrument and the whole workflow are cross-platform; the WWDC24 demo profiles an iOS app on device and on Simulator, and the WWDC25 Swift session profiles a command-line-style parser. Nothing in the Allocations workflow is iOS-only. The consequences of growth differ — see Memory footprint, where iOS/iPadOS enforce a footprint limit.

• Current description of the memory report, memory graph, Malloc Stack diagnostic, and the Allocations instrument’s statistics and Generations views. DocsGathering information about memory usedoc
• Apple’s written Instruments tutorials, which the WWDC26 lab names as the best starting guide. DocsInstruments tutorialsdocWWDC26 8003@15:16exact timeWWDC26 800315:18named section only

• statedThe Leaks instrument takes periodic snapshots of the app’s memory to detect leaks. WWDC24 10173@5:06exact time
• statedThe three-way model that makes leaks tractable: useful memory (reachable, will be used), abandoned memory (reachable, never used again — caches, singletons; counts against footprint and is pure waste), and leaked memory (unreachable). WWDC24 10173@20:26exact timeWWDC24 1017320:15named section only
• demonstratedIn the Memory Graph Debugger, leaked allocations carry a yellow triangle; the Show only leaked allocations filter-bar button plus the project-types filter narrows a noisy graph to your code. WWDC24 10173@21:14exact time
• demonstratedFixing one cycle cascaded: after breaking a three-node cycle, “the other leaks were resolved too” because those types were referenced by the leaked ones. WWDC24 10173@24:03exact time
• demonstratedleaks on a memgraph prints a ROOT CYCLE marker for retain cycles and, with malloc stack logging on, an allocation call stack per leak. WWDC21 10180@12:07exact time
• statedleaks was updated (as of WWDC18) to show not just leaked objects but the retain cycles they belong to, plus a backtrace for the root node when malloc stack logging was enabled. WWDC18 416@13:54exact time
• statedA leak defined: “the process allocates an object and loses all references to it without ever deallocating it”; in Swift the common route is a retain cycle between two objects with no external reference. WWDC21 10180@10:31exact time
• statedSwift closure contexts are the modern variant: when a closure captures values it allocates a heap block the Memory Graph Debugger labels closure context, and each closure context corresponds 1:1 with a live closure. Captures are strong by default. Closure metadata does not carry variable names, so every reference out of a closure context is simply labelled capture. WWDC24 10173@22:00exact timeWWDC24 1017321:54named section only
• demonstratedA particularly easy mistake: assigning a method as a closure (generator = defaultAction) implicitly captures self and creates a cycle; wrapping it in an explicit closure lets you apply a capture list. WWDC24 10173@29:14exact time
• demonstratedThe WWDC21 demo’s cycle is the textbook bidirectional-ownership bug — MealPlan.addItem stores the item and MenuItem.addPlan stores the plan, both strong — fixed by making one side weak. WWDC21 10180@13:48exact time

1. Reproduce the suspect flow, then pause in the Memory Graph Debugger from Xcode’s debug bar.
2. Click the leaked-allocations filter (triangle icon), then the project-types filter.
3. Select a leaked node; walk the reference edges in the Inspector and note the ownership qualifier Instruments reports on each edge (strong / weak / unowned / unmanaged / conservative).
4. For a closure context, use its allocation stack trace to jump to the code that created the closure, then add a capture list.
5. Re-run and re-pause to confirm the type disappears — and turn the type filter off, because downstream leaks often clear at the same time.
6. For batch / CI or Mac use, run leaks <memgraph> and look for ROOT CYCLE.

• A cascade is normal: fix the cycle at the root and the leaks that hung off it clear with it. Turn the type filter off before concluding a fix was partial. WWDC24 10173@24:03exact time
• When authoring a deliberate test leak, loop it — conservative scanning may not catch a single instance. WWDC24 10173@24:51exact time

Both. The leaks command-line tool “can analyze macOS and Simulator processes directly, or investigate issues using already-captured memory graphs”. WWDC22 recommends leaks directly for a Mac game as the alternative to capturing a graph in Xcode. Crew inference: on a live iOS device process you go via a captured memgraph rather than attaching leaks to the process, since the sessions only ever demonstrate direct attach for macOS and Simulator. WWDC24 10173@4:43exact timeWWDC22 10106@29:45exact time

• Leaks remains a standard Instruments template in current Xcode — confirmed by the memory crew’s own local xctrace check, not by an Apple page. See the local tool check panel in Coverage boundaries.

• statedA memory graph is “a snapshot of all allocations and the references between them”; with MallocStackLogging it also carries a backtrace per allocation, and it is reachable straight from Xcode’s debug bar. More precisely: “Memgraphs record the address and size of each virtual memory region and each allocated malloc block, as well as pointers between those regions and blocks”. WWDC24 10173@4:16exact timeWWDC21 10180@7:17exact time
• statedThe reference-type taxonomy that governs how much you can trust an edge: strong (definitely pointers, ARC-managed, explicit ownership), weak/unowned (definitely pointers, explicit non-ownership), unmanaged (pointers the runtime knows about but does not manage — “might be manual owning references, but then again, maybe not”), and uncertain/conservative (raw memory that merely looks like a pointer). WWDC24 10173@16:26exact timeWWDC24 1017316:00named section only
• statedType-information quality is language-dependent: Swift and Objective-C are well described; C and C++ carry no reference-ownership information, so you only see conservative references, and the best the tools can do is name C++ types that have virtual methods. Types without virtual methods fall back to stack-trace-derived labels such as malloc in PalmTree::growCoconut(). WWDC24 10173@17:14exact time
• demonstratedEnd-to-end demo: paste an address from Allocations into the Memory Graph Debugger filter bar, walk __DataStorage → PhotoThumbnail → dictionary → the static ThumbnailLoader.globalImageCache, then use the Inspector’s allocation backtrace to jump to the caching code and find a cache key built from Date() instead of the file’s creation date. WWDC24 10173@18:04exact timeWWDC24 10173@18:51exact time
• demonstratedEnabling MallocStackLogging: a checkbox in the scheme’s Diagnostics tab. WWDC18 adds the practical refinement to prefer the live allocations option when the log is destined for a memgraph. WWDC24 10173@3:28exact timeWWDC18 416@15:42exact time
• demonstratedExport for CLI use: File › Export Memgraph, then pass the memgraph to a command-line tool in place of the target process. WWDC18 416@10:53exact time
• statedvmmap --summary prints per-region size, dirty and swapped; the swapped column is the pre-compression size of the data, not what it compressed down to. WWDC21 restates the mapping explicitly: “In this tool, the term swapped means compressed.” WWDC18 416@11:36exact timeWWDC21 10180@15:46exact time
• demonstratedheap summarises heap objects by class with count, average and total size; it sorts by count by default, so --sortBySize is what you want when hunting a few enormous objects; heap --addresses <class> yields addresses to feed the next tool. WWDC18 416@14:59exact time
• demonstratedheap -diffFrom <pre> <post> shows objects present in the later graph but not the earlier — the regression-triage entry point. WWDC21 10180@16:35exact time
• demonstratedleaks --traceTree <address> gives the tree of objects referencing that address (useful without malloc stack logging); leaks --referenceTree gives a top-down tree of all memory with a best guess at roots, and --groupByType shrinks it. WWDC21 10180@17:50exact timeWWDC21 10180@18:44exact time
• demonstratedmalloc_history --fullStacks <memgraph> <address> returns the allocation call stack — the “smoking gun” step. WWDC21 10180@19:30exact timeWWDC18 416@38:31exact time
• statedfootprint recreates a high-level per-category breakdown from a memory graph; in that tool’s output the dirty size also includes swap and compressed, so read it as “total charged per category”. This is a different column convention from vmmap, which keeps dirty and swapped separate. WWDC22 10106@18:36exact timeWWDC22 10106@20:21exact timeWWDC22 10106@21:12exact time
• demonstratedComposability is an explicit selling point: vmmap --pages <memgraph> | grep dylib | awk … to total dirty pages attributable to linked libraries. WWDC18 416@12:43exact time

1. Capture: pause in the Memory Graph Debugger from Xcode’s debug bar, or File › Export Memory Graph for CLI work.
2. Start broad with vmmap --summary on the memgraph to see where the memory actually is (heap vs some other VM region).
3. If it is heap: heap -diffFrom between two graphs, or heap --sortBySize on one.
4. Get an address, then answer who holds it with leaks --traceTree and where it came from with malloc_history --fullStacks.
5. In the GUI, paste the address into the Memory Graph Debugger filter bar and walk the reference edges, reading the ownership qualifier on each.
6. Use the Inspector’s allocation backtrace to jump to the line that created it.

• Read the man pages. Explicitly recommended for the advanced functionality. WWDC24 10173@4:43exact time
• vmmap --verbose matters: by default vmmap collapses contiguous regions into one line, hiding per-region differences in dirty and compressed size. WWDC18 416@33:24exact time
• A heuristic from the same demo: later-created VM regions tend to correspond to later app lifecycle events, so when a memgraph was captured during a spike, start at the last region rather than the biggest. Presented as “not necessarily, but as a general rule”. WWDC18 416@34:07exact time
• Terminal output beats the graphical view for sharing: it can be searched, filtered, and pasted into a bug report. WWDC18 416@36:19exact time
• heap on an exported graph is a quick way to price a design choice: in the WWDC24 demo, one million ByteProducers with weak references produced one Swift weak reference storage allocation each, “almost as much memory as the ByteProducers themselves”. WWDC24 10173@30:02exact time

The CLI tools operate on exported memgraphs on your Mac for any platform, and can additionally attach directly to macOS and Simulator processes. The Memory Graph Debugger itself is an Xcode feature that works against a device or Simulator session. WWDC24 10173@4:43exact time

• Current naming: the checkbox is “Malloc Stack” in the Diagnostics area of the scheme’s Run settings; export via File › Export Memory Graph; and the doc still points readers at WWDC18 session 416 for the command-line tools. Note the naming drift: WWDC18 says “Export Memgraph”, current docs say “Export Memory Graph”. DocsGathering information about memory use § Inspect the debug memory graphdoc

• statedThe model. Memory splits into dirty (written by the app: heap/malloc, decoded image buffers, frameworks’ data-dirty sections), compressed (dirty pages not recently accessed, squeezed by the memory compressor, decompressed on access), and clean (never written / pageable — memory-mapped read-only files, frameworks’ DATA_CONST). WWDC21 10180@2:11exact time
• statedFootprint = dirty + compressed. Clean memory does not count. Stated independently by two sessions. WWDC21 10180@2:59exact timeWWDC18 416@7:40exact time
• statediOS has no traditional disk swap; it has a memory compressor, introduced in iOS 7. WWDC21 puts it as “we do not have the concept of swap on iOS, which is specific to macOS”. This is the single most important macOS/iOS divergence in the memory material. WWDC18 416@5:00exact timeWWDC21 10180@2:35exact time
• statedPages are 16 KB and indivisible: writing any part of a page dirties the whole page and you are charged for all of it. WWDC24 adds that only dirty and swapped count toward footprint and that “in most applications, the heap will be responsible for the majority of that footprint”. WWDC18 416@1:34exact timeWWDC21 10180@21:27exact timeWWDC24 10173@2:35exact time
• statedCompressed pages are still charged at their uncompressed size. WWDC22 10106@5:00exact time
• statedOn Apple silicon, accessed Metal resources count as dirty app memory, because CPU and GPU share unified memory. WWDC22 10106@4:30exact time
• statedLinked frameworks cost you dirty memory, unavoidably. If you own a framework, singletons and global initialisers are the lever, since a singleton stays resident once created and initialisers run at link/class-load time. Runtime swizzling can dirty an otherwise-clean DATA_CONST. WWDC18 416@4:35exact timeWWDC18 416@3:50exact time

1. Decide the question first: am I charged too much (footprint) or am I churning too much (Allocations)? They have different tools.
2. For footprint, read dirty + swapped — in VM Tracker, or in vmmap --summary on an exported memgraph.
3. If the heap is not the bulk, read the VM region names (CG image, IOSurface, mapped file) to find where it went.
4. If the heap total looks fine but footprint is high on a long-running process, check % FRAG per malloc zone.
5. For image-heavy screens, do the arithmetic before reaching for a tool: width × height × bytes-per-pixel.

• NSCache is offered as the better cache container: thread-safe and purgeable. WWDC18 416@7:16exact time
• For downsampling, use ImageIO’s CGImageSourceCreateThumbnailAtIndex rather than drawing a UIImage, to avoid decompressing the whole image and to skip the spike. WWDC18 416@22:35exact timeWWDC18 416@23:18exact time
• UIGraphicsImageRenderer picks the pixel format for you, whereas UIGraphicsBeginImageContextWithOptions is always 4-byte SRGB. Formats span 1 byte/pixel (Alpha 8) to 8 bytes/pixel (wide format). WWDC18 416@20:44exact timeWWDC18 416@21:28exact time

WWDC18 416 opens by saying that although it is focused on iOS, “a lot of what we’re covering will apply to other platforms as well”. Genuinely iOS-specific: no disk swap (compressor instead), the enforced footprint limit and EXC_RESOURCE, extension limits, and os_proc_available_memory. Genuinely cross-platform: dirty/clean accounting, 16 KB pages, fragmentation, proc_pid_rusage. macOS surfaces footprint in Activity Monitor. WWDC18 416@0:28exact timeWWDC22 10106@6:13exact time

• Which session supersedes which. WWDC18 416 is still the canonical model, and WWDC21 explicitly defers to it for depth; what is dated in it is the Xcode UI narration (“Xcode 10”, “Export Memgraph”) and the memory-gauge chrome. WWDC24 10173 is the current front door for heap work and explicitly scopes itself out of graphics memory and memory limits. WWDC21 10180@3:22exact timeWWDC24 10173@0:34exact time

• statedVM Tracker “provides separate tracks for dirty and swapped, which, in iOS, is compressed memory, and tells you some information about the resident size”. WWDC18 416@9:28exact time
• statedVirtual Memory Trace “provides a deep view into the virtual memory system’s performance with regards to your app”, and the recommended entry point is its By Operation tab, which surfaces things like page cache hits and page zero-fills. Note the presenter says “VM Memory Trace”; the instrument is Virtual Memory Trace. WWDC18 416@9:50exact time
• statedVM Tracker snapshots periodically rather than recording live, and is bundled in the Allocations template alongside Allocations. WWDC24 10173@6:14exact time
• statedThe Game Memory template is the richest packaging: Allocations and Metal Resource Events for allocations with history, VM Tracker to record memory footprint, Virtual Memory Trace to record virtual memory activity, plus Metal Application and GPU instruments. WWDC22 10106@9:10exact time
• demonstratedIn VM Tracker, Dirty Size is non-compressed dirty memory and Swapped Size is compressed-or-swapped; the Summary view lists VM regions, and memory-mapped assets show up under the mapped file region. WWDC22 10106@13:19exact timeWWDC22 10106@13:44exact time
• statedThe reason you need VM Tracker at all: “allocations don’t always translate to memory footprint”. WWDC22 10106@13:19exact time
• statedVM Tracker is also the tool that starts the WWDC18 dirty-memory investigation which then moves to vmmap on a memgraph. WWDC18 416@12:20exact time

1. Choose the Allocations template (VM Tracker included) or, for a Metal game, Game Memory.
2. Enable VM Tracker only when you need footprint rather than heap churn — the WWDC24 presenter deliberately leaves it off when focusing on the heap.
3. Record; read Dirty Size and Swapped Size as the footprint pair.
4. Use the Summary view to attribute footprint to VM regions (mapped file, IOSurface, CG image, MALLOC_*).
5. To go deeper than the trace allows, capture a memory graph and switch to footprint / vmmap.
6. For VM-system activity (faults, zero-fills) rather than sizes, add Virtual Memory Trace and start from By Operation.

• VM Tracker’s periodic snapshotting means it shares the snapshot observer cost: it suspends the target app, and can stutter or hang it briefly. WWDC24 10173@32:11exact time
• In a game, “All Anonymous VM” in the Allocations statistics view is where interesting possibly-dirty VM regions show up, distinct from “All Heap Allocations”. Allocations also “doesn’t include private Metal resources” — a real blind spot for graphics work. WWDC22 10106@10:23exact time

Both instruments exist for both platforms; the interpretation of the swapped column differs (compressed on iOS, genuine swap possible on macOS).

• Both VM Tracker and Virtual Memory Trace are still present in current Xcode under those exact names — from the memory crew’s own local xctrace check, not an Apple page. No developer.apple.com/documentation/… page dedicated to either instrument was found.

• statedPower Profiler “lets you profile your app and record a power trace which can then be visualized in Instruments”. WWDC25 226@1:54exact timeWWDC25 2261:52named section only
• demonstratedSetup shown: connect the iPhone wirelessly, Product › Profile, choose the Blank template, then add Power Profiler and CPU Profiler. WWDC25 226@3:11exact time
• demonstratedThe first lane is system power usage, expressed as a percentage per hour (the demo’s selection read 10.5%/hr); beneath it are per-app power impact lanes for CPU, GPU, display and networking. 10.5%/hr is that demo’s number. WWDC25 226@4:04exact timeWWDC25 226@4:27exact time
• statedPower impact is explicitly a score for prioritisation, not a physical unit: “This value is a score that lets you identify when unexpected power spikes occur, and prioritize debugging the highest impact subsystem.” WWDC25 226@5:20exact time
• demonstratedWorked demo 1 (reproducible at the desk): CPU power impact averaged 1 before and 21 during the spike; the CPU Profiler call tree with Hide System Libraries pointed at VideoCardView; the cause was an eager VStack building every thumbnail up front; switching to LazyVStack brought the average to 4.3. 1, 21 and 4.3 are that demo’s numbers. WWDC25 226@5:20exact timeWWDC25 226@8:28exact time
• demonstratedWorked demo 2 (not reproducible at a desk): an on-device trace from a colleague showed a periodic CPU-impact pattern; the Time Profiler named videoSuggestionsForLocation, which re-read and re-parsed a large JSON rules file on every location change — invisible at a stationary desk, obvious while commuting. Fix: load and parse lazily once, then cache. This is the best file-I/O-as-a-power-bug example in the corpus. WWDC25 226@12:59exact timeWWDC25 226@15:14exact time
• demonstratedOn-device collection (Performance Trace). Turn on Developer Mode, Settings › Developer › Performance Trace, enable Power Profiler, then select your app; only apps installed by Xcode, TestFlight, or via the enterprise program can be monitored. Start/stop from a Control Center control; the resulting file opens directly in Instruments. WWDC25 226@10:55exact timeWWDC25 226@11:19exact timeWWDC25 226@11:43exact timeWWDC25 226@12:07exact time
• statedIn on-device mode the Time Profiler runs at a lower sample rate to reduce the observer effect. WWDC25 226@12:31exact time
• statedComparing two implementations. Profile approach 1, profile approach 2, compare — but thermals, device state, system pressure, and your app’s own state (data volume, enabled features) all move the numbers, so capture multiple runs of each approach under varying conditions and average. WWDC25 226@17:44exact timeWWDC25 226@18:10exact timeWWDC25 22616:19named section only

1. Start from a symptom you can name: a high Energy Impact reading in the Debug navigator, an Organizer energy regression, or a user report.
2. Reproducible at your desk? Product › Profile over a wireless connection, Blank template, add Power Profiler + CPU Profiler, reproduce.
3. Read the system power lane for when, then the per-subsystem impact lanes for which: CPU, GPU, display, networking.
4. Route on the winner: CPU → CPU Profiler; GPU → Metal debugger; display → APL / dark appearance; networking → HTTP Traffic + Network Connections.
5. Not reproducible? Have someone who can reproduce it capture an on-device Performance Trace in Power Profiler mode and share the file.
6. Fix, then re-measure — several runs of each approach, averaged, not one.
7. For thermal defences, induce the thermal state with Xcode device conditions rather than warming the device.

• Connect wirelessly. A cabled or MagSafe-charging device reports system power usage as 0 — documented, not in the video. DocsMeasuring your app's power use with Po… § Record and analyze a power trace using Instrumentsdoc
• The cheapest energy check available needs no trace at all: watch the Energy Gauge while the app sits idle. It should be at or near zero. WWDC21 10181@4:30exact time
• When the desk cannot reproduce it, do not borrow the device — have the colleague capture and share an on-device trace, then close the loop by having the same colleague re-test after the fix. WWDC25 226@10:31exact timeWWDC25 226@16:06exact time

Power Profiler’s on-device Performance Trace mode is documented for iPhone (iOS 26+) and iPad (iPadOS 26+) only. The Energy Gauge, thermal-state API and device conditions are demonstrated on iOS. No session or doc in this cluster demonstrates macOS power profiling, and this guide does not imply one exists. DocsMeasuring your app's power use with Po… § Overviewdoc

• Measuring your app’s power use with Power Profiler — the source of every documented fact above. DocsMeasuring your app's power use with Po…doc
• Analyzing your app’s battery use — current Energy Impact display and its category list. DocsAnalyzing your app's battery usedoc
• The Energy Log instrument’s documented behaviour survives only on an archived Apple page describing an Energy Diagnostics template, an Energy Usage instrument reporting “a level from 0 to 20” that the page itself calls subjective, a Location Energy instrument, and on-device logging via Settings › Developer › Logging. Archived — label it as such. DocsEnergy Efficiency Guide for iOS Apps: … § Use the Energy Diagnostics Profiling Templatedoc

• statedThe HTTP Traffic instrument shipped in Instruments 13, inside the Network template, and inspects traffic through the Apple networking stack. WWDC21 10212@0:09exact time
• statedThe key architectural point: because it instruments the URL Loading System rather than sniffing packets, it covers HTTP/3 and VPN traffic, attributes traffic to processes, and reveals requests that hit the on-disk cache or that errored. A cache hit is invisible to a packet capture but visible here. WWDC21 10212@0:35exact time
• statedTrack hierarchy: HTTP Traffic (count of concurrent tasks) → process (including background traffic) → URLSession (one per URLSession you create) → domain. WWDC21 10212@2:12exact timeWWDC21 10212@2:36exact time
• statedTask vs transaction: a task is your API-level object — the interval starts when you call resume() and ends right before your completion block is called — and is made of one or more transactions, each a request/response pair. A redirect (apple.com → www.apple.com) is the canonical two-transaction task. WWDC21 10212@3:49exact timeWWDC21 10212@5:03exact time
• statedThe five transaction states, in order: cache lookup, blocked, sending request, waiting for response, receiving response. WWDC21 10212@7:08exact timeWWDC21 10212@7:56exact timeDocsAnalyzing HTTP traffic with Instruments § View tasks and transactionsdoc
• statedInterval labels are dense with information you would otherwise have to dig for: HTTP version, method, and whether an Authorization or Cookie header was sent; on the response side the status code, whether a cookie came back, and the content type. WWDC21 10212@6:20exact time
• demonstratedColour encodes outcome: orange for a non-success at the HTTP level (401), green for success (201), grey for a cancelled task. WWDC21 10212@18:50exact timeWWDC21 10212@19:44exact time
• demonstratedDemo 1 — head-of-line blocking. The initial screen took over 7 seconds; later tasks showed growing purple blocked states. Switching the domain track from “Tasks” to HTTP Transactions by Connection revealed six connections and a clear staircase: each transaction blocked until the previous one on the same connection finished. That is HTTP/1 head-of-line blocking; HTTP/2 multiplexes and needs no app change; the client picks the most modern version the server supports. After the server enabled HTTP/2: one connection, effectively no blocked time, under 3 seconds. 7 s, six connections and 3 s are that demo’s numbers. WWDC21 10212@12:18exact timeWWDC21 10212@16:50exact time
• demonstratedDemo 2 — an expired cookie. Re-prompted for login; the label showed no cookie icon on the request. Walking back to the earlier successful transaction showed the server had sent Set-Cookie — but the Transactions detail view’s extended detail (full request and response headers) showed an expiry date in the past, so URLSession correctly refused to send it. A server-side bug, found from the client. WWDC21 10212@20:33exact timeWWDC21 10212@21:49exact time
• demonstratedDemo 3 — a request that never left the device. A favourites refresh took “a couple of milliseconds”, too fast for a server round trip. In HTTP Transactions by Connection view the transaction was executed not on a connection but on Local Cache, and had no “waiting for response” state. Fix shown: set URLRequest.cachePolicy = .reloadRevalidatingCacheData so the server can answer 304. WWDC21 10212@23:56exact timeWWDC21 10212@26:10exact time
• demonstratedDemo 4 — auditing a third-party SDK. An integrated xcframework created its own URLSession and issued POSTs to an analytics endpoint before the user tapped anything; the backtrace implicated CoreLocation, and the transaction’s request body contained location coordinates. The trace itself became the bug report. This is the strongest “audit what your app really does” material in the corpus. WWDC21 10212@29:28exact timeWWDC21 10212@31:09exact time
• demonstratedBacktraces: selecting a task shows the backtrace of where resume() was called, which is how the demo navigated from a trace interval to the exact method in Xcode. WWDC21 10212@25:17exact timeDocsAnalyzing HTTP traffic with Instruments § View tasks and transactionsdoc
• demonstratedExport to HAR for people without Instruments, via xctrace export with a HAR flag. HAR is JSON, so it is scriptable, but it loses Instruments-specific detail such as URLSessions and backtraces. The precise flag spelling is unverified — check xctrace export --help before copying a command. WWDC21 10212@31:55exact timeWWDC21 10212@32:42exact time

1. Name your objects first — set URLSession.sessionDescription and URLSessionTask.taskDescription, because those strings become the track and interval labels.
2. Product › Profile → Network template (you get Network Connections and HTTP Traffic) → Record.
3. Accept the capture-risk dialog — and read the trap about what the trace now contains.
4. Option-click-drag to zoom to the traffic; expand the HTTP Traffic disclosure triangle; raise track height.
5. Read shapes in Tasks view: long purple blocked runs, orange failures, grey cancellations, suspiciously short intervals.
6. Switch the domain track to HTTP Transactions by Connection whenever the question is “why is this slow” or “did this actually go out” — it is the view that exposes both head-of-line blocking and Local Cache.
7. Use the bottom detail list plus its filter field to find requests by substring; selecting there moves the time cursor in the track view.
8. Select a transaction and read the extended detail (headers and bodies) for correctness and privacy questions; select a task and read the resume backtrace to get to code.
9. Export HAR to hand off.

• Profile builds a release configuration, so you are profiling what users run. WWDC21 10212@9:08exact time
• Click-dragging over a range shows a tooltip with the selected duration — a quick way to price a whole screen’s loading. WWDC21 10212@11:34exact time
• Hovering a task shows the duration of the task and of whichever child interval is under the cursor. WWDC21 10212@12:18exact time
• Closing advice: name sessions and tasks, adopt the latest protocols, and even with no bugs, audit how much data you send and delete what is unnecessary. WWDC21 10212@33:08exact time

The documentation scopes the HTTP Traffic instrument to “iOS, iPadOS, watchOS, tvOS, and macOS apps”; the session says it “just works on all Apple devices”. Network Link Conditioner is split: a separate downloadable preference pane on macOS, built into developer settings on iOS. DocsAnalyzing HTTP traffic with Instruments § OverviewdocWWDC21 10212@0:35exact timeWWDC19 422@11:12exact timeWWDC19 422@11:37exact time

• Current and maintained; it links back to session 10212 itself, which is a strong signal that the 2021 session is still the canonical teaching material. DocsAnalyzing HTTP traffic with Instrumentsdoc
• The Network template and both the HTTP Traffic and Network Connections instruments are present in current Xcode under those names — memory crew’s local xctrace check, not an Apple page.

• statedThe stakes, as Apple states them. “Writing to disk can wear out my users’ NAND, which will lead to poor device health. Writes also take a lot of time and can lead to poor user experience and slow performance if done frequently, so it’s important to batch these writes.” Unchecked disk writes are also “a common cause for annoying onscreen hangs and UI hitches” and “can eat up the battery life quickly”. WWDC21 10181@12:50exact timeWWDC21 10087@8:03exact time
• demonstratedThe headline demo. Reading a plist, updating one property and writing it back produces one read and three writes plus an fsync — not one write. The extra writes are file-system metadata. The fuller version: creating, reading and modifying a plist causes 12 separate I/O operations for what is roughly four lines of code, and every NSDictionary.write(toFile:atomically:) ends in an fsync. 1 / 3 / 12 are that session’s counts. WWDC19 419@5:29exact timeWWDC19 419@5:52exact timeWWDC19 419@14:23exact time
• statedWhat Instruments 11 changed in the File Activity instrument: support for all Apple devices; tracing the whole system, not just your process, so you can see interactions; an explicit logical vs physical I/O distinction; and automated reasoning covering (a) excessive physical writes, (b) failed I/O-related system calls — which matter for correctness, not just performance — and (c) suboptimal caching, i.e. code that is not making good use of the OS cache. WWDC19 419@25:51exact timeWWDC19 419@27:43exact time
• demonstratedThe tracks you get: a file system suggestions track (where the anti-pattern notifications live), a file system activity track broken into logical reads and logical writes with call counts and callers, and a disk usage track which is “where all the physical I/O information will live”. WWDC19 419@28:04exact timeWWDC19 419@29:09exact time
• demonstratedSuggestions count as a scalar progress metric. The demo’s SQLite workload went 12 → 3 → 0 suggestions as it moved from open/close-per-operation to better patterns to WAL-mode journalling, with the 12 being “excessive physical writes” notifications. With WAL mode, logical I/O no longer had a matching physical I/O and only a single fsync call remained versus delete-mode journalling. Those are that demo’s numbers. WWDC19 419@30:39exact timeWWDC19 419@31:44exact timeWWDC19 419@32:32exact timeWWDC19 419@33:16exact time
• demonstratedAttributing writes to code in the field. The Organizer’s disk writes reports are collected from consenting devices, contain the stack trace that led to the writes, and are broken into signatures with writes tracked per signature and sorted by total; in the demo the top signature accounted for 67% of writes. These reports are generated when an app writes more than 1 GB in a 24-hour period. 67% is that demo’s number. WWDC21 10087@8:50exact timeWWDC21 10087@9:13exact timeWWDC21 10181@14:50exact time
• demonstratedInsights (Xcode 13): Apple maintains a repository of known disk-write anti-patterns; matching reports are flagged with an optimisation suggestion and a documentation link. The demo’s suggestion was “add an index”. WWDC21 10087@10:26exact timeWWDC21 10087@10:50exact time
• demonstratedFile Activity as the validator. After adding the index, writes attributable to that function went from about 180 MB of writes to temporary files, carrying 780 ms of latency, to zero. The presenter calls File Activity “the perfect tool to validate my fix”. 180 MB and 780 ms are that demo’s numbers. WWDC21 10087@11:13exact timeWWDC21 10087@11:38exact time

1. Product › Profile → File Activity template → Record; exercise the write-heavy flow.
2. Read the file system suggestions track first — it is a count, and the detail view groups the notifications by kind (e.g. “excessive physical writes”). Treat the count as your score.
3. Read file system activity for logical reads/writes, call counts, and callers.
4. Read disk usage for the physical side, and compare: logical activity with no matching physical activity means the OS cache is absorbing it, which is the good case.
5. Change one thing, re-record, and watch the suggestion count move.
6. For shipped versions, go to the Organizer’s disk-writes reports, read the top signatures and any insight, fix, then validate with File Activity as in step 2.

• Record a deliberate baseline trace of the bad pattern before fixing anything, so the suggestion count and I/O counts have something to be compared against — the WWDC19 demo does this explicitly. WWDC19 419@29:09exact time
• The logical/physical gap is the signal, not either number alone. WWDC19 419@33:16exact time
• Full VACUUM versus incremental vacuum is measurably different in the instrument: the demo’s full vacuum produced 27 I/O operations totalling 168 KB per delete. That demo’s numbers. WWDC19 419@35:47exact time
• System-wide tracing is available, so you can see how your app interacts with the rest of the system rather than only its own calls. WWDC19 419@26:15exact time

The Instruments 11 rework explicitly added “support for all Apple devices… the same uniform profiling experience across your iOS device, Mac, Watch, TV, etcetera”. The NAND-wear framing and the Organizer disk-writes reports are presented in an iOS context. WWDC19 419@25:51exact time

• Naming has drifted. The template is still called File Activity, but the instruments inside it are now listed as Filesystem Activity, Filesystem Suggestions, Disk Usage and Disk I/O Latency — the session’s spoken “file system…” tracks map onto instruments whose current names use “Filesystem” as one word. From the memory crew’s local xctrace check, not an Apple page. No current documentation page dedicated to the File Activity instrument was found.

• demonstratedThe SwiftUI template ships with the SwiftUI instrument plus Time Profiler and the Hangs/Hitches instruments — so the handoff from “SwiftUI is busy” to “here is the code” happens in one trace. WWDC25 306@2:29exact time
• demonstratedFour lanes, in order: Update Groups (top-level “SwiftUI is doing work”), Long View Body Updates, Long Representable Updates, Other Long Updates. WWDC25 306@3:00exact timeWWDC25 306@3:22exact timeWWDC25 306@3:29exact timeWWDC25 306@3:36exact time
• statedLong updates are coloured orange and red by likelihood of causing a hitch or hang; the presenter says starting with red is typically a great starting point. WWDC25 306@3:48exact timeWWDC25 306@4:01exact time
• demonstratedExpanding the SwiftUI track reveals three subtracks: View Body Updates, Representable Updates, Other Updates. WWDC25 306@5:55exact time
• demonstratedThe full drill-down: select the lane → filter to the Long View Body Updates summary → “Show Updates” → right-click “Set Inspection Range and Zoom” → click the Time Profiler track → Command-F to search the call stack for the view type. WWDC25 306@6:30exact timeWWDC25 306@6:58exact timeWWDC25 306@7:10exact timeWWDC25 306@7:19exact timeWWDC25 306@8:05exact time
• demonstratedThe Cause & Effect graph records cause/effect relationships between gestures, state changes, environment writes and view-body runs; selecting a state-change node shows a backtrace of where the value was set. WWDC25 306@25:14exact timeWWDC25 306@25:54exact time
• statedWhy a backtrace alone is not enough: for declarative SwiftUI code you cannot use the backtrace to understand why a view is updating, because the frames are system frames whose names you would be guessing at. This is the session’s explicit argument for the graph. WWDC25 306@19:54exact timeWWDC25 306@20:15exact timeWWDC25 306@20:41exact time
• demonstratedDemo part 1 — the slow body. A distance computed property in LandmarkListItemView built a MeasurementFormatter and a NumberFormatter on every body run; Time Profiler showed those two formatter calls as the heaviest frames. Fix: hoist formatter creation into the location model and cache the formatted string per landmark. WWDC25 306@8:29exact timeWWDC25 306@8:31exact timeWWDC25 306@12:20exact timeWWDC25 306@13:04exact time
• demonstratedDemo part 2 — the update storm. Tapping two favourite buttons updated LandmarkListItemView far more than twice. The graph traced it to isFavorite reading the whole favoritesCollection.landmarks array, which made @Observable establish a dependency on the entire array for every row. WWDC25 306@18:56exact timeWWDC25 306@26:40exact timeWWDC25 306@27:34exact timeWWDC25 306@27:40exact time
• statedEnvironment reads create a dependency on the whole EnvironmentValues struct; every reader is notified when anything in it changes, and each must check whether its value changed — the check itself costs even when the body is skipped. WWDC25 306@31:35exact time