Hello Apple Team, I’ll be attending the Battery and Performance Optimization Lab this Thursday, and I’d like to prepare as thoroughly as possible to get the most value from the session. I’m particularly interested in understanding what I can do beforehand to identify optimization opportunities in my app and arrive with useful performance measurements and actionable questions. I would appreciate your guidance on a few areas: Xcode configuration: Are there specific build settings, diagnostic options, profiling configurations, or performance-related settings I should enable or review before the lab? Performance measurement: Which Instruments templates, metrics, or profiling workflows would you recommend using beforehand to establish a meaningful baseline for CPU usage, memory, energy consumption, and battery efficiency? Preparation: What measurements, diagnostic reports, or reproducible test scenarios would be most useful to bring so we can spend more time investigating optimization opportunities rather than establishing a baseline? Technical resources: Are there specific WWDC sessions, documentation, or technical concepts you recommend reviewing to better understand how iOS manages energy consumption, background execution, and performance? Prioritization: What are the most important things developers should understand before attending this lab, particularly when optimizing an application that performs continuous on-device processing and audio playback? iPhone Duo testing: Will the engineering team have iPhone Duo demonstration or development units available during the lab for testing and profiling applications on actual hardware? My app includes Duo-specific multitasking and display adaptations, and I’d particularly value the opportunity to evaluate performance, battery efficiency, and resource usage on the device. My goal is to arrive with a well-profiled application, a clear understanding of its current performance characteristics, and enough preparation to make the session as technically productive as possible. Thank you for your guidance. I’m looking forward to learning from the team on Thursday!

I am seeking advice about supported macOS performance tracing, NOT reporting a confirmed APFS bug. This is a real application failure. AI assisted with organizing this report, and the measurements were reviewed against existing records. Environment Apple Silicon Mac Studio, 32 GB RAM, macOS 15.7.9 (24G830). CPython 3.11.15, linked SQLite 3.50.4. SQLite database: 3,224,576,000 bytes on an internal APFS volume, journal_mode=DELETE. The application runs PRAGMA quick_check before starting worker processes. A progress handler cancels the operation after 30 seconds, producing SQLITE_INTERRUPT. This is application-triggered, not proof of corruption. Observed results Original database: 30.008 s wall / 5.220 s CPU; a separate run took 30.192 s wall / 5.420 s CPU. Both were interrupted. A two-second sample showed 95/96 samples on SQLite's checkTreePage → readDbPage → unixRead → pread path. Individual pread latency was not measured. A transaction-consistent SQLite Backup API snapshot on a different APFS volume completed quick_check in 2.412 s and integrity_check in 8.797 s, both returning "ok". The snapshot and original were checked at different times with uncontrolled cache and system-load conditions. Additional mmap experiment On the same offline snapshot: A: mmap_size=0, executed first, quick_check took 31.070 s and was interrupted. B: reported mmap limit approximately 2 GiB, executed second, quick_check returned "ok" after 22.146 s. Cache conditions and host load were not equivalent, so these observations do NOT establish an mmap performance improvement. A separate deliberate mapped-I/O error test ended with SIGBUS in an isolated child process. This does not establish an ordinary APFS defect. Questions Which supported macOS Instruments templates or APIs can correlate pread offsets, sizes and timings with physical disk latency, filesystem cache activity, memory pressure and thread scheduling, without disabling system security protections? What minimum set of simultaneous observations could distinguish cache misses, APFS metadata/layout overhead, physical device delays and CPU scheduling contention? How should process read-byte counts be interpreted against physical disk I/O? How should I safely compare read-only SQLite mmap against normal pread access on disposable copies, without mistaking a warmer second run for a performance gain? What SIGBUS containment and recovery checks would be appropriate? I am primarily looking for a reliable instrumentation plan and interpretation criteria before conducting further tests. I do not want to modify the original database, weaken integrity checks or bypass security controls.

I'm developing an iOS app that includes the following Network Extension providers: NEPacketTunnelProvider NEFilterDataProvider NEFilterControlProvider I want to analyze CPU usage, memory footprint, and battery/energy impact for these extensions after release, using data collected from production devices. I've been looking into MetricKit, including MXMetricManager and MXMetricPayload, and would appreciate clarification on its support for app extensions. Specifically: API support: Can MetricKit be initialized and registered as a subscriber from within a Network Extension provider's process? Are there any restrictions specific to these extension types? Metric availability: If registration is supported, do the resulting metric payloads contain CPU, memory, and energy metrics attributable to the extension itself, or do they cover only the containing app? Production reliability: Can I rely on MetricKit to collect these metrics consistently across production devices and app versions? Are reports generated for extensions independently, and are there known limitations in report delivery or coverage? Memory and CPU: Is there a supported way to obtain the extension's peak memory footprint and CPU consumption through MetricKit? If these metrics aren't available through MetricKit, what APIs or reporting mechanisms does Apple recommend? Energy and battery: Can MetricKit provide energy-impact metrics specifically attributable to a Network Extension provider, rather than aggregated metrics for the containing app? Recommended approach: For post-release analysis of these extensions, should I use MetricKit, Xcode Organizer's Energy reports, custom telemetry within the extension, or a combination of these? My goal is to monitor resource consumption and identify regressions in production without relying on Instruments profiling on individual devices. I'd appreciate clarification on which of these capabilities are officially supported for Network Extension providers and which approach Apple recommends for reliable production monitoring. Thanks!

Hi, I’m encountering an issue when profiling an application with xctrace and Instruments on macOS. When I try to record a trace using either the CPU Profiler or CPU Counters template, the recording fails with the following error: Failed to start the recording: configureHardwareCounters: Failed set kpc configuration: Operation not permitted. The issue was also present in the previous macOS 27.0 build (26A428) and remains after updating to macOS 27.0.1 (26A434) System: Apple M6 Mac mini macOS 27.0.1, build 26A434 Xcode 27.0, build 27A266a

Hello! I was recently trying out XCTHitchMetric with my MTKView and it doesn't seem to record anything. But if I use the Animation Hitches instrument then I do see the hitches get recorded when a frame is presented on screen later than expected. I'm curious if there is a reason for this or maybe I am missing something?

i've been struggling to get the SwiftUI instrument to work during the betas. It never produces any results on simulator, while on device it throws an error which prevents any results from other instruments from appearing. the error is: Failed to stop recording session: Data Providers emitted errors: Required I've tried on my iPad Pro 11-inch (M4) (iPadOS27 beta 3), and iPhone 17 Pro Max (iPadOS27 beta 2). And I get the same result running from my mac studio & MacBook air. Is this a known thing? cheers, Mike

Hi all, I've hit a reproducible issue where the presence of the SwiftUI instrument in a template prevents any data from being recorded, including from the other instruments in the same template. Removing the SwiftUI instrument immediately restores normal recording. Environment Host: macOS 26.4.1 (25E253), Mac mini Xcode / Instruments 26.4.1 (17E202) Device: iPhone 17, iOS 26.4.2 (23E261) (physical device, USB-attached) Symptom Recording the same app, same device, same session, only varying the template contents: SwiftUI template (as-is) => All lanes empty across the entire recording Same template with the SwiftUI instrument removed => Data collected normally (Time Profiler samples, Hangs, etc.) So it seems not an issue with the SwiftUI lanes specifically being empty — including the SwiftUI instrument appears to silence the entire recording. Steps to reproduce Open Instruments → pick the SwiftUI template (or build a custom template that includes the SwiftUI instrument alongside, e.g., Time Profiler). Target the device, attach to the running app. Record for ~10s, interact with the app. Stop. Result: every lane is empty. Edit the template, remove the SwiftUI instrument, re-record with no other changes. Result: normal data appears in the remaining instruments. Questions Is this a known regression in Instruments 26.4.1 on iOS 26.4.x? Is there a workaround to use the SwiftUI instrument on this OS combo (different Xcode build, runtime flag, entitlement)? Does it work for anyone on iOS 26.4.x + Xcode 26.4.1, or is everyone seeing this? I can file a Feedback if confirmed as a bug — wanted to check here first in case I'm missing a setup step. Thanks!

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.

using Version 26.2 (17C52) I often get "Trace file had no SwiftUI data" why so?

Environment: macOS 27.0 beta (26A5368g) Xcode 27 beta — Instruments 27.0 (64578.226), build 27A5209h MacBook Pro (M1, 2020), 16 GB — MacBookPro17,1 Target: physical iPhone running an iOS app (on-device LLM inference benchmarking) Summary: Instruments crashes reproducibly with EXC_BREAKPOINT (SIGTRAP) shortly after I stop a recording. Recording itself works — the crash occurs during the post-stop analysis phase, while the trace is being processed. This has happened multiple times today with different templates (Time Profiler, and a custom document with Power Profiler / os_signpost / Thermal State). Steps to reproduce: Open Instruments 27.0 beta, choose Time Profiler (or a document containing Power Profiler + os_signpost) Target a physical iPhone and an installed app Record for a short period, then press Stop Instruments crashes while analyzing/importing the trace Crash details: The crashing thread is always on the dispatch queue com.apple.dt.frame.activity, inside InstrumentsPlugIn transformer/modeler code. In one report the crashing frame is: Thread 10 Crashed:: Dispatch queue: com.apple.dt.frame.activity 0 InstrumentsPlugIn NetworkConnectionStatsModeling.__receiveRow(cursor:writer:referenceManager:) + 920 1 InstrumentsPlugIn TransformerExecutionUnit.run(yieldBlock:) + 92 2 InstrumentsPlugIn specialized TransformerHostingModeler.populateOutputTables(_:usingObserverations:parameters:checkToYieldBlock:) + 2344 Exception Type: EXC_BREAKPOINT (SIGTRAP), esr 0xf2000001 (Breakpoint) brk 1 At crash time, sibling worker threads on the same queue were executing SystemPowerImpactModeling and ProcessSubsystemImpactModeling transformers, so the failure appears to be in the modeling pipeline that runs when the recording is finalized. Incident identifiers from two occurrences today: D6D2467F-8553-487C-A291-EC30C0D2846F (14:13 IST) 55017CAB-5345-4865-9695-36228B B80AA4A (18:20 IST) Filed via Feedback Assistant as FBXXXXXXXX with full crash logs and sysdiagnose attached. Questions: Is this a known issue in the current Instruments 27.0 beta? Is there a recommended workaround to record and analyze traces until a fix ships — e.g., recording headlessly with xctrace and opening the .trace in a late r build? Happy to provide the .trace files or additional diagnostics. Thanks!

Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel: jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process. The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated. A similar slowdown did not occur on ext4. Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/. My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph: (The most thorough writeup is the discussion on this pull request.) I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?

I’m profiling a SwiftData app in Instruments. Most frames are symbolicated correctly but SwiftData frames appear only as addresses. 0x21ff2abd4 SwiftData 0x21ffb06c8 SwiftData 0x21ffb3064 SwiftData while surrounding frames are symbolicated, for example: __CFRunLoopDoObservers CoreFoundation stepTransactionFlush AppKit Attribute.syncMainIfReferences<A>(do:) SwiftUICore Is this expected, or should SwiftData symbols normally be visible here?

I'm joining the Ads iOS SDK team — our SDK is embedded in thousands of host apps. I want to understand the recommended approach for two performance challenges specific to embedded SDKs: what's the Instruments workflow for isolating our SDK's CPU and memory contribution from the host app's footprint, when we don't control or have access to the host app's source? are there any new APIs in iOS 27 that allow a third-party framework to declare or report its own performance budget to the host app, so developers can see SDK-level impact without custom instrumentation?

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

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?

I’m reporting a severe reproducible issue in Instruments, specifically when using the SwiftUI instrument and opening Show Cause & Effect Graph. What happens: • Instruments becomes extremely laggy/unresponsive • The graph/detail area can turn solid magenta/pink • Memory usage rapidly increases (I observed around 18 GB, 25 GB, and up to 34 GB) • My Mac has crashed/restarted during this, or in other terms, had a kernel panic, where my Mac froze, and everything unresponsive. The Trackpad wouldn't even click. Important detail: • I could not find a generated kernel panic log after the crash/restart. Repro context: • SwiftUI iOS app profiled from Xcode • Trigger is specifically entering Show Cause & Effect Graph • Recordings can be short and still trigger it • Issue is much less severe or absent if I avoid that view What I already tried: • Rebooting • Short captures / fewer instruments • Clearing Xcode/Instruments caches/preferences • Retesting after cleanup • Reinstalling Xcode Is this a known Instruments regression? Is there a workaround besides avoiding Show Cause & Effect Graph? What exact diagnostics should I collect when no kernel panic file is generated? Specs: Xcode Version 26.3 (17C529) Instruments Version 26.3 (17C529) macOS Version 26.4 Beta (25E5223i) MacBook Pro 13-inch, M1, 2020, 16 GB RAM

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

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.

In Instruments, I'm seeing "Zero Time Stamp" events in the "Audio Server" lane. What does that mean?

Background: During daily usage of iOS devices, devices experience noticeable thermal issues. This heating not only affects user experience, but may also lead to device performance throttling, shortened battery life, and other problems. We need better understanding and monitoring of device thermal states to optimize application performance and user experience. Issues Encountered: Insufficient thermal monitoring capabilities: Unable to obtain real-time accurate temperature data from devices Difficult power consumption analysis: Hard to determine which specific modules or threads cause high power consumption and heating Requested Solutions: Temperature Monitoring API: Provide accessible device temperature reading interfaces Thermal Attribution Analysis Capability: During heating events, we expect to receive more detailed power consumption monitoring data, such as CPU, GPU, network, location services, display, high power consumption thread stacks and other information to help developers identify high energy consumption operations