I'm trying to benchmark a Core Image filter chains memory footprint and notice a weird quirk in instruments. On a real device, even with a simple Core Image chain, the memory balloons each time I ran the filter. See attached screen shots. Running on iPhone 17 Pro: Running on simulator (M2 Macbook Pro) As you can see there's a huge build up of 4MB "VM: IOSurface" memory on the real device, but the simulator seems to clean it up correctly. Here's my basic code: func processImage() { guard let inputImage = ContentViewModel.loadImageFromBundle(name: "kitty.HEIC") else { print("Failed to load sample_image from bundle") return } var outputImage = inputImage outputImage = outputImage.applyingFilter("CIBloom", parameters: [ kCIInputRadiusKey: 20, kCIInputIntensityKey: 0.8 ]) DispatchQueue.global(qos: .userInitiated).async { let data = self.context.jpegRepresentation(of: outputImage, colorSpace: CGColorSpace(name: CGColorSpace.sRGB)!) if let data = data, let uiImage = UIImage(data: data) { DispatchQueue.main.async { self.displayImage = Image(uiImage: uiImage) } } } } Why is this happening? Seems like a bug to me or I need to release an object. At the very least makes it challenging to measure memory usage. Any help is greatly appreciated. Alex

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?

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

I’m trying to understand how SwiftUI List handles row lifecycle and reuse during scrolling. I have a list with around 60 card views; on initial load, only about 7 rows are created, but after scrolling to the bottom all rows appear to be created, and when scrolling back to the top I again observe multiple updates and apparent re-creation of rows. I confirmed this behavior using Instruments by profiling my app. Even though each row has a stable identifier, the row views still seem to be destroyed and recreated, which doesn’t resemble UIKit’s cell reuse model. I’d like clarity on how List uses identifiers internally, what actually gets reused versus recreated, and how developers should reason about performance and view lifetime in this case.

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.

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

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

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

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?

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 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'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?

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?