I have been working on battery consumption analysis for my application, and as part of this effort, I wanted to understand how competitor apps behave under similar usage conditions. To do this, I downloaded competitor apps from the App Store and attached them to Instruments via Xcode. I then executed a defined set of manual test scenarios to simulate real user behavior. During these tests, the iPhone was connected to a Mac and charging continuously, which meant that System Power Usage logs were not generated in Instruments. However, I was able to capture detailed metrics such as: Network usage CPU load GPU activity Display and brightness impact Other runtime performance characteristics Since direct battery drain data was unavailable, I used derived analysis (with AI assistance) to estimate approximate power consumption based on the above metrics, assuming real-device (battery-powered) conditions. According to Apple documentation, System Power Usage in Instruments is not directly tied to the device’s battery percentage. Instead, it appears to be computed using contributing factors such as CPU, network, display, and other subsystem activity. This raises a few important questions about data reliability and methodology. Key questions: How reliable are Instruments-based metrics (CPU, network, display, GPU) for estimating real-world battery consumption when the device is charging? Can these metrics be safely used as a comparative baseline between competitor applications, even if absolute battery drain values are unavailable? Is the System Power Usage instrument essentially a derived model based on subsystem activity, and if so, does it remain accurate when the device is not discharging? From Apple’s perspective, is this a valid approach for relative power comparison, provided that: The same device is used OS version is identical Test scenarios are consistent and repeatable Based on these findings, would it be reasonable to proceed with instrumenting our own application, run the same scenarios, and draw conclusions using relative comparisons rather than absolute battery percentages? The intent is not to claim exact battery drain numbers, but to establish a directionally correct and repeatable comparison that can guide performance optimizations in our own application. I would like to understand whether this methodology aligns with Apple’s recommended practices, or if there are limitations or inaccuracies I should be aware of before relying on these results for decision-making.

what is the diff between INST_ALL and Instructions(FIXED_INSTRUCTIONS)? also CORE_ACTIVE_CYCLE VS Cycles(FIXED_CYCLES)

Hi everyone, I’m developing a cross-platform mobile app (React Native) but I don’t currently own a Mac. What is the most reliable and professional way to: Build the iOS version Test it properly (real device / TestFlight) Upload it to the App Store Are cloud Mac services (like MacinCloud, AWS Mac, etc.) considered stable for production release workflows? Is there any fully supported workflow without direct access to a physical Mac? Would appreciate real-world experience from developers who faced the same situation. Thanks in advance.

When I try to run dtruss on a command line program (freshclam) I see: $ sudo dtruss -a /usr/local/bin/freshclam 2>&1 | tee ~/tmp/dtruss.out dtrace: system integrity protection is on, some features will not be available dtrace: failed to execute /usr/local/bin/freshclam: DTrace cannot instrument translated processes I did some research and found advice on how to enable dtrace use via running: csrutil enable --without dtrace in a terminal running in macOS recovery mode. When I do that I see a warning saying this is an unsupported configuration and that it will allow unsigned kernel modules to be loaded. This is not what I want, I just want to run dtruss on a program while keeping all the other SIP protections in place. Why can't I just use sudo to grant the privileges for dtrace to work? All of this has me wondering if Apple intends for developers to use dtruss/dtrace in the current macOS?

Hi everyone, I am developing a benchmarking tool to measure memory latency (L1/L2/DRAM) on Apple Silicon. I am currently using Xcode Instruments (CPU Counters) to validate my results. In my latest run for a 128 MB buffer with random access, Instruments shows: Latency (cycles): ~259 cycles (derived from LDST_UNIT_OLD_L1D_CACHE_MISS / L1D_CACHE_MISS_LD). Manual Timer Result: ~80 ns. To correlate these two values, I need the exact CPU Frequency (GHz) at the time of the sample. My Questions: Is there a recommended way to programmatically fetch the current frequency of the Performance cores (p-cores) during a benchmark run? Does Apple provide a "nominal" frequency value for M-series chips that we should use for cycle-to-nanosecond conversions? In Instruments, is there a hidden counter or "Average Frequency" metric that I can enable to avoid manual math? Hardware/Software Environment: Tool: Instruments 26.3+ (CPU Counters Template). Chip: A19, iPhone 17 pro. OS: 26.3.

I am trying to run the SwiftUI instruments tool for an iOS app and every time I run it, it either switches from giving me the "Time Profiler: Time Profiler does not support the iOS platform" error, or I end up with no data at all; however, when I run just the Time Profiler by itself it works fine. I am running this on a physical device

Is it possible to change the order of Cards in a Trends/Units screen like that (in a such order): Free In-App Paid Free iOS/watchOS/tvOS Free macOS In-App iOS/tvOS In-App macOS Paid iOS/watchOS/tvOS Paid macOS

Enabled processor trace on my mac and other types of profiler work fine. However, Processor Trace keeps showing nothing and I see the error "Failed to stop recording session. Failed stoping ktrace session" How to solve this?

Subject: [SDK / Instruments] Clarification on Runnable & Blocked Time Semantics — Customers Misinterpreting as CPU Usage Hi Apple Developer Technical Support Team, I hope this message finds you well. I am writing to seek urgent clarification on a profiling question that is directly impacting our SDK customers. Context We provide an iOS SDK that is integrated into third-party applications. Our SDK includes a background monitoring thread created via: -[NSObject performSelectorInBackground:withObject:] As documented, threads created through this API carry a default (relatively low) scheduling priority. Inside the thread, we call sleep(1) once per second for periodic idle intervals, and we collect CPU usage metrics using kernel APIs: • task_threads() • thread_info() Both calls involve kernel-level operations and are known to trigger context switches internally. The Core Issue — Customer Misinterpretation When our customers profile their apps using Instruments with "Context Switch Sampling" enabled, they observe that our SDK thread shows a large proportion of time labeled as "Runnable" and "Blocked". A representative example: • Total (wall clock): 4.30 s — 100% • Runnable: 3.06 s — 71.4% ← customers flag this as high CPU usage • Blocked: 1.05 s — 24.5% • Running: 176 ms — 4.1% ⚠️ Our customers are interpreting the "Runnable" time (71.4%) as CPU consumption by our SDK, and are raising concerns that our SDK is degrading their app's performance. We strongly believe this interpretation is incorrect — a thread in the "Runnable" state is merely waiting in the scheduler's ready queue and has NOT been assigned to any CPU core, therefore it should NOT consume any CPU resources. However, we need an official confirmation from Apple to address our customers' concerns definitively. Our Questions Do the time values shown next to "Runnable" and "Blocked" in the Time Profiler call tree represent wall-clock waiting time (i.e., time spent in that state), or actual CPU consumption time? Does a thread in the "Runnable" state consume any CPU resources on the device? We want to confirm clearly: does Runnable time contribute to CPU load or battery drain in any way? Is it correct that the high Runnable time observed is caused by the combination of: a. The low thread scheduling priority assigned by performSelectorInBackground:withObject:, and b. Context switch overhead introduced by the task_threads() and thread_info() kernel calls? Is there any official Apple documentation that explicitly describes the semantics of "Runnable" and "Blocked" time in Instruments, which we could reference when communicating with our customers? An authoritative answer from Apple would allow us to accurately explain the profiling data to our customers and clarify that the high "Runnable" time does NOT represent CPU consumption by our SDK. Thank you very much for your time and support. Best regards

Hi Apple Developer Technical Support Team, I hope this message finds you well. I am writing to seek urgent clarification on a profiling question that is directly impacting our SDK customers. Context We provide an iOS SDK that is integrated into third-party applications. Our SDK includes a background monitoring thread created via: -[NSObject performSelectorInBackground:withObject:] As documented, threads created through this API carry a default (relatively low) scheduling priority. Inside the thread, we call sleep(1) once per second for periodic idle intervals, and we collect CPU usage metrics using kernel APIs: • task_threads() • thread_info() Both calls involve kernel-level operations and are known to trigger context switches internally. The Core Issue — Customer Misinterpretation When our customers profile their apps using Instruments with "Context Switch Sampling" enabled, they observe that our SDK thread shows a large proportion of time labeled as "Runnable" and "Blocked". A representative example: • Total (wall clock): 4.30 s — 100% • Runnable: 3.06 s — 71.4% ← customers flag this as high CPU usage • Blocked: 1.05 s — 24.5% • Running: 176 ms — 4.1% ⚠️ Our customers are interpreting the "Runnable" time (71.4%) as CPU consumption by our SDK, and are raising concerns that our SDK is degrading their app's performance. We strongly believe this interpretation is incorrect — a thread in the "Runnable" state is merely waiting in the scheduler's ready queue and has NOT been assigned to any CPU core, therefore it should NOT consume any CPU resources. However, we need an official confirmation from Apple to address our customers' concerns definitively. Our Questions Do the time values shown next to "Runnable" and "Blocked" in the Time Profiler call tree represent wall-clock waiting time (i.e., time spent in that state), or actual CPU consumption time? Does a thread in the "Runnable" state consume any CPU resources on the device? We want to confirm clearly: does Runnable time contribute to CPU load or battery drain in any way? Is it correct that the high Runnable time observed is caused by the combination of: a. The low thread scheduling priority assigned by performSelectorInBackground:withObject:, and b. Context switch overhead introduced by the task_threads() and thread_info() kernel calls? Is there any official Apple documentation that explicitly describes the semantics of "Runnable" and "Blocked" time in Instruments, which we could reference when communicating with our customers? An authoritative answer from Apple would allow us to accurately explain the profiling data to our customers and clarify that the high "Runnable" time does NOT represent CPU consumption by our SDK. Thank you very much for your time and support. Best regards

Hi Apple Developer Technical Support Team, I hope this message finds you well. I am writing to seek urgent clarification on a profiling question that is directly impacting our SDK customers. Context We provide an iOS SDK that is integrated into third-party applications. Our SDK includes a background monitoring thread created via: -[NSObject performSelectorInBackground:withObject:] As documented, threads created through this API carry a default (relatively low) scheduling priority. Inside the thread, we call sleep(1) once per second for periodic idle intervals, and we collect CPU usage metrics using kernel APIs: • task_threads() • thread_info() Both calls involve kernel-level operations and are known to trigger context switches internally. The Core Issue — Customer Misinterpretation When our customers profile their apps using Instruments with "Context Switch Sampling" enabled, they observe that our SDK thread shows a large proportion of time labeled as "Runnable" and "Blocked". A representative example: • Total (wall clock): 4.30 s — 100% • Runnable: 3.06 s — 71.4% ← customers flag this as high CPU usage • Blocked: 1.05 s — 24.5% • Running: 176 ms — 4.1% ⚠️ Our customers are interpreting the "Runnable" time (71.4%) as CPU consumption by our SDK, and are raising concerns that our SDK is degrading their app's performance. We strongly believe this interpretation is incorrect — a thread in the "Runnable" state is merely waiting in the scheduler's ready queue and has NOT been assigned to any CPU core, therefore it should NOT consume any CPU resources. However, we need an official confirmation from Apple to address our customers' concerns definitively. Our Questions Do the time values shown next to "Runnable" and "Blocked" in the Time Profiler call tree represent wall-clock waiting time (i.e., time spent in that state), or actual CPU consumption time? Does a thread in the "Runnable" state consume any CPU resources on the device? We want to confirm clearly: does Runnable time contribute to CPU load or battery drain in any way? Is it correct that the high Runnable time observed is caused by the combination of: a. The low thread scheduling priority assigned by performSelectorInBackground:withObject:, and b. Context switch overhead introduced by the task_threads() and thread_info() kernel calls? Is there any official Apple documentation that explicitly describes the semantics of "Runnable" and "Blocked" time in Instruments, which we could reference when communicating with our customers? An authoritative answer from Apple would allow us to accurately explain the profiling data to our customers and clarify that the high "Runnable" time does NOT represent CPU consumption by our SDK. Thank you very much for your time and support. Best regards

As stated in the title. I am running the following code. Each time I perform an API call, I create a new instance of URLSession and use a background-configured session to allow background API calls. ` Code being executed: import Foundation // Model definitions struct RandomUserResponse: Codable { let results: [RandomUser] } struct RandomUser: Codable { let name: Name let email: String } struct Name: Codable { let first: String let last: String } // Fetcher class class RandomUserFetcher: NSObject, URLSessionDataDelegate { private var receivedData = Data() private var completion: ((RandomUser?) -> Void)? private var session: URLSession! func fetchRandomUserInBackground(completion: @escaping (RandomUser?) -> Void) { self.completion = completion let configuration = URLSessionConfiguration.background(withIdentifier: "com.example.randomuser.bg") session = URLSession(configuration: configuration, delegate: self, delegateQueue: nil) let url = URL(string: "https://randomuser.me/api/" )! let task = session.dataTask(with: url) task.resume() } // Data received func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) { receivedData.append(data) } // Completion func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) { defer { self.session.finishTasksAndInvalidate() } guard error == nil else { print("Error: \(error!)") completion?(nil) return } do { let response = try JSONDecoder().decode(RandomUserResponse.self, from: receivedData) completion?(response.results.first) } catch { print("Decoding error: \(error)") completion?(nil) } } }` Called in viewDidLoad, etc.: let fetcher = RandomUserFetcher() fetcher.fetchRandomUserInBackground { user in if let user = user { print("Name: \(user.name.first) \(user.name.last), Email: \(user.email)") } else { print("Failed to fetch random user.") } } In Instruments' Network instrument, I focus on my app's process, use 'Command + 3', and switch to 'List: URLSessionTasks'. Even though didCompleteWithError is called and the API call fully completes, the Duration keeps increasing, and the Success column remains '-' (neither 'Yes' nor 'No'). For non-background URLSessions, the session shows up as 'unnamed session', but for background URLSessions, it appears as 'unnamed background session 1 (XXXXXX-XXXXXX-XXXXX)'. Does this mean the session is not actually being completed? I've checked Debug Memory Graph and confirmed there is no NSURLSession memory leak, but is it possible that the app is somehow still retaining session information internally? I also suspect that Instruments may not be able to fully track background URLSession tasks.

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!

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

I'm currently exploring Instruments for profiling and tracing on macOS 15.6.1. I know there is the "network connections" instrument which records TCP/UDP information, however it seems to not include the "lo0" (loopback) interface. Is there a way to configure it so that localhost traffic is included in the recording? as the application I'm tracing uses that and I want that information to be included in traces. The documentation for network-interface-detection schema makes no mention of how it detects interfaces. Thanks in advance.

I was reading through this documentation about instruments command line tool https://help.apple.com/instruments/mac/current/#/devb14ffaa5 and how it can be launched from the command line. However, unlike what the documentation states, there's no such instruments command anywhere on my macos M1 (OS version 15.6). That command gives: $> instruments zsh: command not found: instruments I do have XCode installed which has the Instruments.App (GUI app) but not the command line utility: $> ls Xcode.app/Contents/Applications/ ... Instruments.app Is that linked documentation up-to-date (it does say "latest" in the URL)? Is there some other way to install this command line utility?

Hi everyone, I’m currently integrating AlarmKit into an app and would like to offer users the same selection of built-in iOS alarm sounds that the native Clock app provides. So far, I haven’t found any API in AlarmKit (or elsewhere in the SDK) that exposes the system’s default alarm tones. Before implementing a custom sound library, I wanted to check: Is there any way to access or present the iOS system alarm sounds when creating alarms with AlarmKit? Or are developers limited to custom audio files that we provide ourselves? If anyone has experience with AlarmKit or knows whether this is technically possible (or explicitly restricted), I’d really appreciate your insights. Thanks!

Instruments is crashing when the swiftui instrument is stopped (the session is finished) and the transfer begins from device to device: Crashed Thread: 11 Dispatch queue: com.apple.swiftuitracingsupport.reading Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [1633] I've tried removing derived data, reinstalling xcode, updating xcode (I originally thought this might be the issue -- I needed to update to 26.2 from the 26 RC -- the update didn't fix crash or change the crash report), and restarting both devices. I'm running Instruments/Xcode 26.2 on a MacBook Pro 15" (2018) running Mac OS 15.7.2 (24G325) with an iPhone 16 Pro Max running 26.2. Hoping someone else might have seen this or could help me troubleshoot. I find the swiftui instrument be helpful and like to use it :) I can post a complete crash report as well.

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 could use the Metal System Trace before the most recent update, but now whenever I try to profile using the Metal Counter instrument, I get the [Warning] GPU Service reported error: Selected counter profile is not supported on target device. What is the issue here?