I've discovered what appears to be a system-level memory leak when pressing any key in Swift UI projects. This issue occurs even in a completely empty SwiftUI project with no custom code or event handlers. When monitoring with Instruments' Leaks tool, I observe multiple memory leaks each time any key is pressed. These leaks consist primarily of: NSExtraData objects (240 bytes each) NSMenuItem objects (112 bytes each) Other AppKit and Foundation objects Has anyone else encountered this issue? How can I fix this behavior? While the leaks are small (about 5-6KB per keypress), they could potentially accumulate in applications where keyboard input is frequent.

I want to check the disassembly code of vImage function by Instrument. But when I double click the stack of time profiler, I can see nothing. My Mac is intel chip and iPhone is 14 pro max Xcode version is 16.3. How can I fix this(maybe no .dSYM in iOS device support?)

I kept CoreLocation’s startUpdatingLocation running for a full day and used Performance trace - PowerProfiler to track the power usage during that time. The trace file was successfully generated on the iOS device, and I later transferred it to my MacBook. However, when I tried to open the .atrc file, I received the following warning: The document cannot be imported because of an error: File ‘/Users/jun/Downloads/PowerProfiler_25-06-16_181049_to_25-06-17_091037_001.atrc’ doesn’t contain any events. Why is this happening? Is there a known issue with PowerProfiler in iOS 26, or am I missing something in the tracing setup? Note: The .aar file and the extracted .atrc file are not attached here, as forum uploads do not support these formats.

Hello, I wanted to try new Bottleneck analysis mode showcased in recent Apple's video, however when I select CPU Counters template in Instruments, there's no such option - just the same old "sample by Time/Events". I have the latest XCode 16.4 and OS Sonoma 15.5, the system is M4 Max. While Instruments shows version 16.0 in About dialog for some reason (a bug?), it definitely comes from the Xcode 16.4 package and the build id is the same (16F6) as for XCode 16.4. I also checked just in case on another M1 system (all updated as well) and it's all the same. Any clues why Bottleneck analysis is missing? Regards, Maxim

Hello, I have recently been using the new Power Profiler tool introduced in Xcode 26 to analyze the power consumption of my app. My app primarily operates in the background. During a profiling session of 5 hours and 30 minutes, I observed that the app was active in the background for 2 hours and 30 minutes, while it remained in a suspended state for the remaining 3 hours. While the Power Profiler allows me to identify spikes in CPU, networking, and other resource usage at specific points, it is difficult to determine whether these values are objectively considered high. For example, in my case, the total QoS Execution Time of CPU Impact recorded during the 5 hours and 30 minutes was 12.18 seconds. I am wondering whether this is considered a good metric. Could you please advise on the following points? 1. Is there a commonly accepted or recommended ratio between app active time and CPU time that developers should aim for? 2. Are there any guidelines or reference materials on how to interpret CPU usage and other resource metrics for apps that primarily run in the background? Any insights or advice would be greatly appreciated. Thank you.

Is there an xctrace instrument capable of capturing the complete control flow of a process? So far the best I can find is high-frequency sampling, but what I need is a trace of all machine instructions executed. This is easily done on Linux/Intel using the perf tool, which provides access to Intel's hardware-assisted tracing module (ptrace). According to the arm specification, my mac mini M1 (armv8.4-a) and M4 (armv9.2-a) both have hardware support in the CoreSight ETM (embedded trace macrocell) for full instruction tracing (i.e., no sampling, no gaps, no statistics--capturing the complete execution path). But it's not clear how I can access these features, if they are supported by the macos XNU kernel at all. After hours of searching online, it's nothing but dead ends. Any suggestions for documentation or Xcode tools or open-source tools or built-in macos tools would be much appreciated!

Updated Xcode from 16.2 to 16.4, running Time Profile in Instruments, it launches the trace, but does not install or load on connected device, breaks the functionality. I am unable to debug... ERROR: Connection with the remote side was unexpectedly closed : <dictionary: 0x1f3c8b6d0> { count = 1, transaction: 0, voucher = 0x0, contents = "XPCErrorDescription" => <string: 0x1f3c8b850> { length = 22, contents = "Connection interrupted" } } Domain: IXRemoteErrorDomain Code: 6 User Info: { DVTErrorCreationDateKey = "2025-08-09 00:47:53 +0000"; } -- Connection with the remote side was unexpectedly closed : <dictionary: 0x1f3c8b6d0> { count = 1, transaction: 0, voucher = 0x0, contents = "XPCErrorDescription" => <string: 0x1f3c8b850> { length = 22, contents = "Connection interrupted" } } Domain: IXRemoteErrorDomain Code: 6 IOS 18.5

According to the ARM documentation for the CPU models available in Apple Silicon, the CoreSight implementation includes an Embedded Trace Macrocell which can perform a complete "Instruction Trace" (https://developer.arm.com/documentation/102119/0200/What-is-trace-). Although other operating systems such as Linux make this easy, we have not been able to find any tools or even a system-level API for accessing this feature of the ETM. In the "Instruments" window of Xcode 16+, there is a "Processor Trace" instrument, but this performs sampling and is totally unrelated to the Instruction Trace we need for debugging and analysis purposes. Because it produces a complete, contiguous sequence of branch instructions, the Instruction Trace is essential for identifying precise execution behaviors that are otherwise invisible to the developer. On other platforms, an alternative is debugger scripting, but we have found far too many bugs and reliability issues with the macOS implementation of lldb. Any suggestions would be greatly appreciated!

Hello, I am trying to investigate my apps memory usage using the instruments tool. Whenever I attach instruments my app crashes, when I have it connected to xcode as well I can see that the crash occurs in liboainject: ___lldb_unamed_symbol117 with SIGBUS. Here's what the stack looks like. Is this a known issue? Are there any workarounds or things I can do to figure out what is causing the crash?

Does the new HTTP Traffic instrument require iOS15 running on the device? I am attempting to profile my app and I get an error saying 'This device is lacking a required capability'?

I'm trying to run the Instrument "Animation Hitches", but it fails immediately after starting on the iPhone. This happens on multiple projects, including a brand new project. I get the following errors: Timestamp | Message (Before Run Started) | Unexpected failure: Couriers have returned unexpectedly. (Before Run Started) | Failed to start the recording: Failed starting ktrace session. The issue also happens with the instruments App Launch, but not with any other that I tested. Is this a bug? Using Xcode Version 16.1, Mac Mini M1 Sequoia 15.1. Running project on iPhone 14 Pro iOS 18.1.

I am running Xcode 16.1, macOS 15.1 , iOS 18.1, and I see the error when trying to run the Instruments Network Profile

Our customers are large enterprises and we need to be able to collect traces on our customers' endpoints in support cases. Especially critical are performance problems. So far we've instructed our customers to use ktrace: sudo ktrace artrace -p appname --type=profile We would then open this trace in Instruments with the CPU profile and load our own symbols. The problem is, that symbols for system libraries are missing. In one instance we see that all of the high load is coming from a syscall made by libpcap. But all symbols other than our own are missing. How can we collect traces which include those symbols? I tried to use ktrace symbolicate in tests where I recorded a trace and then used ktrace symbolicate to collect system lib symbols, but it fails for most libraries, including libpcap and the syscalls. This is somewhat surprising, because dyld_info -exports /usr/lib/libpcap.A.dylib is able to print the symbols including offsets. So what is the recommended workflow for this scenario? Installing Xcode is of course not an option on a customer machine, especially not in an enterprise scenario.

Hi everyone, (I am running on an M2 MacBook Pro 14 inch with 96 GB of memory) I've been profiling with Instruments to find out why program suddenly goes from full CPU usage (all of my threads active and all cores working) to about 33% CPU usage. An Instruments system trace is showing me a massive performance cliff where I suddenly get taken off the performance cores and only run on efficiency cores. The performance cores are then occupied by "kernel.release.t6020". What is this thing? I have kernel callstacks enabled but I only get the instruction pointer and have no symbols for any of those callstacks. I'm accustomed to Windows development where kernel symbols are available so you can see deeply into the kernel to know why you're spending time there (for example, semaphore wait or thread scheduling). Is there a way for me to get a similar level of information or kernel symbols so I can see what the kernel is doing? Around the time I observe the performance cliff, I also noticed in the narrative view some of the preemptions are done "because thread was balanced off CPU i (P Core) to optimize the system's CPU performance". What does this mean? Have I begun to hit some sort of thermal limit? Here are some example screenshots of what I am seeing in Instruments:

I'm developing a library and using XCTest for unit tests. While trying to profile the test suite, I noticed that Instruments seems to report a leak every single time the async throwing setup function is called, no matter what. For example, This will report a leak: final class LeakTests: XCTestCase { override func setUp() async throws { try await super.setUp() } func testLeak() async throws { try await Task.sleep(nanoseconds: 5_000_000_000) } } This will not report a leak: final class LeakTests: XCTestCase { // override func setUp() async throws { // try await super.setUp() // } func testLeak() async throws { try await Task.sleep(nanoseconds: 5_000_000_000) } } Any ideas on why this might be happening, or should I just file a bug report? It makes it quite difficult to use the leak detection for unit tests, as it shows hundreds of leaks when the whole suite is ran.

I am currently reviewing the tutorial documentation for the instruments. (Instruments Tutorials: https://developer.apple.com/tutorials/instruments/identifying-a-hang) It seems very useful, so I want to follow the tutorials step by step. However, I am having trouble downloading the sample project files; it appears that the 7z file is broken. (https://developer.apple.com/instruments/tutorials/downloads/InitialVersion.7z) Can anyone help me with how to download the project files properly?

Context I created a short script to CPU profile a program from the command line. I am able to record via the Instruments app, but when I try from the command line I get the following error shown below. This example is just profiling the grep command. Error: % cpu_profile /usr/bin/grep \ --recursive "Brendan Gregg" \ "$(xcode-select --print-path)/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" Profiling /usr/bin/grep into /tmp/cpu_profile_grep.trace Starting recording with the CPU Profiler template. Launching process: grep. Ctrl-C to stop the recording Run issues were detected (trace is still ready to be viewed): * [Error] Failed to start the recording: Failed to force all hardware CPU counters: 13. Recording failed with errors. Saving output file... Script: #!/bin/sh set -o errexit set -o nounset if [ "$#" -lt 1 ] then echo "Usage $0 <program> [arguments...]" 1>&2 exit 1 fi PROGRAM="$(realpath "$1")" shift OUTPUT="/tmp/cpu_profile_$(basename "$PROGRAM").trace" echo "Profiling $PROGRAM into $OUTPUT" 1>&2 # Delete potential previous traces rm -rf "$OUTPUT" xcrun xctrace record \ --template 'CPU Profiler' \ --no-prompt \ --output "$OUTPUT" \ --target-stdout - \ --launch -- "$PROGRAM" "$@" open "$OUTPUT" I think the error has to do with xctrace based on this post, but according to this post it should have been resolved in MacOS version 15.4. System Chip: Apple M3 Pro macOS: Sequoia 15.4.1 xctrace version: 16.0 (16E140) xcrun version: 70. Xcode version: 16.3 (16E140) Working Screenshots from Instruments App:

When running instruments or when debug memory in Xcode, I am getting same error as An unknown error occurred launching the helper task Xcode: Xcode16.3 OS: 15.5 Beta (24F5068b) Mac mini: Apple M2 Pro

Hi :wave: I am not sure that I use it right, I was not able to profile using these events: I am on a M1 Pro machine using macOS 15.5. I just wonder if these events are support on Apple Sillicon.

I’m seeing inconsistent call stacks and usage percentages in the Time Profiler between two Instruments builds: • Xcode 16.0’s Instruments Version 16.0 (16A242d) • Xcode 16.3’s Instruments Version 16.0 (16E140) When I open an old .trace file recorded with the 16A242d profiler in the newer 16E140 Instruments, the call trees and percentage breakdowns no longer match. It looks like the latest Instruments now exposes or collapses different frames (e.g. system libraries, inline code) by default. I rely on these call stacks as a baseline to track performance regressions and verify optimizations over time. Unfortunately, every Xcode/Instruments update changes what I see, making it impossible to compare profiles across versions. My questions: Is there a way in Instruments 16.0 (16E140) to restore the exact call-tree view and percentage calculations that 16A242d produced? Failing that, is there a recommended workflow or tool for capturing CPU profiles in a way that remains stable and comparable, regardless of Xcode or Instruments version? Any guidance on achieving consistent, version-independent performance measurements would be greatly appreciated!