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.

This is a screenshot from the Swift Task track in Xcode. I made these tasks with public actor ResourceManager { func foo() { for observer in observers { Task(name: "ResourceManager notify observers") { await notification(observer) } } } } I am confused why each of the task is showing as a separate task in the task lifetime summary. Is there a way to queue the trace in Instruments into the fact that these are indeed the same task?

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.

I am profiling a simple SwiftUI test app on my new iPhone through my new MacBook Pro and everything is version 26.2 (iOS, macOS, Xcode). I run Instruments with the SwiftUI template using all of the default settings and get absolutely zero data after interacting with the app for about 20 seconds. Using the Time Profiler template yields trace data. Trying the SwiftUI template again with the sample Landmarks app has the same issue as my app.

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?