Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

Performance wise what are trade-offs when running an MLX-backed model on-device compared to using the system's AFM Core model? Also semiconnected: How do I use the 'model judge evaluator' to compare the accuracy of a custom LoRA adapter against the system's private cloud compute models?

I wrote a python script called MXSymbolicate (https://github.com/OliveTreeBible/MXSymbolicate) to symbolicate the crash reports produced by the old version of MetricKit. The new MetricKit in the '27 releases appears to be basically the same data but in type-safe form, with the addition of state tracking. Notably, the new CrashReportExtension API seems to include the ability to symbolicate a crash stack on-device, but it looks like the CallStackTree type is still just binary names and frame offsets and such - no symbol names. Should I keep symbolicating crash reports from the new MetricKit APIs the same way I did the old ones? Or is the expectation that I should use the CrashReportExtension system for symbolicated crashes, and use the MetricKit crash reports for other purposes, like state tracking?

Hi team: I recently update to Xcode 26.4, and I encountered crash when running to < iOS 26.4 both for physical device and Simulator with this log: dyld[1257]: Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A> /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A>x /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib but iOS 26.4 works well. Env: Xcode: 26.4 Simulator/Physical Device: < 26.4 macOS: 26.3 Thanks for giving any help.

Hi, We are trying to integrate Metric Kit into our MacOS Application. Our application is a background process. We are interested in getting CPU and Memory metrics for our process. MXMetricPayload is the one we are looking at. We tried to integrate metric Kit and left the background app for 24 hours, we did not get any callback. So, does metric kit work for background app in MacOS? Also does it for Network Extension?

I'm unexpectedly getting 403 status codes when calling the perfPowerMetrics APIs for any arbitrary app on my account. This worked last week, it is not working now. I have since revoked keys and recreated admin and developer keys--no luck, still getting 403. I've been working with the analytics APIs lately so I don't know exactly when the power and performance API stopped working. I've narrowed it down to something related to the token scope. When I have a scope on this endpoint of "GET /v1/apps/1234567890/perfPowerMetrics" it is rejected -- but the docs say I can create a token and reduce its scope like this. When I remove the scope and let the token be unbounded, the API call returns a valid response. FB22313063 - App Store Connect API: Fetching xcode metrics with an admin key generated token results in a 403 unexpectedly

I have a bunch of Audio Unit v3 plugins that are approaching release, and I was considering using subscription-model pricing, as I have done in a soon to be released iOS app. However, whether this is possible or not is not at all obvious. Specifically: The plugin can, depending on the host app, be loaded in-process or out-of-process - yes, I know, Logic Pro and Garage Band will not load a plug-in in-process anymore, but I am not going to rule that out for other audio apps and force on them the overhead of IPC (I spent two solid weeks deciphering the process to actually make it possible for an AUv3 to run in-process - see this - https://github.com/timboudreau/audio_unit_rust_demo - example with notes) Depending on how it is loaded, the value of Bundle.main.bundleIdentifier will vary. If I use the StoreKit API, will that return product results for my bundle identifier when being called as a library from a foreign application? I would expect it would be a major security hole if random apps could query about purchases of other random apps, so I assume not. Even if I restricted the plugins to running out-of-process, I have to set up the in-app purchases on the app store for the App container's ID, not the extension's ID, and the extension is what run - the outer app that is what you purchase is just a toy demo that exists solely to register the audio unit. I have similar questions with regard to MetricKit, which I would similarly like to use, but which may be running inside some random app. If there were some sort of signed token, or similar mechanism, that could be bundled or acquired by the running plugin extension that could be used to ensure both StoreKit and MetricKit operate under the assumption that purchases and metrics should be accessed as if called from the container app, that would be very helpful. This is the difference between having a one-and-done sales model and something that provides ongoing revenue to maintain these products - I am a one-person shop - if I price these products where they would need to be to pay the bills assuming a single sale per customer ever, the price will be too high for anyone to want to try products from a small vendor they've never heard of. So, being able to do a free trial period and then subscription is the difference between this being a viable business or not.

App out of memory and killed by Jetsam event seems not report to MetricKit diagnostic, it only contains crash or watch dog kill (scene create or scene update). So I want to ask to report these issues to MetricKit

In MetricKit, a metric payload comes in with a time range which usually means it contains multiple launches/sessions. How can we relate things that will change between launches or sessions such as pid and lowPowerModeEnabled from the metadata. Will there be multiple payloads for each unique value or is there some other way to use this?

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

In recent versions, the increase in background abnormal exits is significant. According to monitoring data, it is closely related to the iOS 26 system. Could you please look into the reasons or provide some suggestions for troubleshooting the issue?

Can you confirm that if you launch an app in the U.S. (in the iOS store) that is you cannot select a specific state (i.e. Rhode Island, North Carolina etc.) to roll out your app? In other words when you launch your app in the U.S. it has to be for the entire country right? Can someone please confirm that this is the case and has always been the case in any app store (i.e. Google Play and IOS)? Thanks. - Erik

I'm adding a few custom signposts with mxSignpost(.begin,...) and mxSignpost(.end,...). Is there a way to force delivery of the MXMetricPayload so I don't need to wait for the daily aggregation to be pushed?

Hi Apple Developer Community, I'm implementing MetricKit launch performance tracking in our iOS app and need clarification on two properties: histogrammedTimeToFirstDraw histogrammedOptimizedTimeToFirstDraw The Documentation Problem: The official MetricKit documentation provides minimal explanation of these properties beyond their names. Based on naming conventions, I initially assumed: histogrammedTimeToFirstDraw = cold launches histogrammedOptimizedTimeToFirstDraw = warm/optimized launches Based on our measurements: The “optimized” metric appears only in a small fraction of launches The "optimized" metric is actually slower The naming suggests the opposite behavior Questions: What specific launch conditions does each metric measure? Why would "optimized" launches be slower and less frequent? Is histogrammedOptimizedTimeToFirstDraw related to iOS app pre-warming or prediction features? If these metrics don’t correspond to cold vs. warm launch times, is there an alternative way to measure them accurately? Any clarification from Apple or insights from developers who've tracked these metrics would be greatly appreciated.

I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!

I use CI/CD dsym, downloaded into local directories, but there seems no direct way using it in Xcode

The MXCrashDiagnostic and MXHangDiagnostic reports are not being returned via MXMetricManager on the next app launch in iOS 17.2, 17.3, 17.4, and 17.5. This issue prevents collection of crash and hang diagnostics through the MetricKit framework, which worked as expected on earlier and later (18, 26) iOS versions. Steps to Reproduce:- Integrate MetricKit in an iOS app using: MXMetricManager.shared.add(self) and implement: func didReceive(_ payloads: [MXDiagnosticPayload]) Install and run the app on a device running iOS 17.2 or later. Cause a crash or hang scenario (e.g., dereference a null pointer or block the main thread). Relaunch the app after the system terminates it. Observe the callback for diagnostic payloads. Expected Behavior MXMetricManager.shared.didReceive(_:) should be invoked on the next launch, returning diagnostic payloads that include MXCrashDiagnostic or MXHangDiagnostic objects. Actual Behavior: No diagnostics are returned on subsequent launches. didReceive(_:) is not triggered, or the diagnostic payloads array is empty. This behavior is reproducible across multiple devices and iOS versions (17.2–17.5). iOS Versions: 17.2, 17.3, 17.4, 17.5 Devices Tested: iPhone 14, iPhone 15 Pro Xcode Version: 15.2 / 15.3 Framework: MetricKit Diagnostic Type: Crash and Hang

I'm working on adding MetricKit to our iPad application that we distribute internally via Enterprise distribution. I've set up the didReceive functions for both MXMetricPayload and MXDiagnosticPayload. When I build onto a device via Xcode and use the Simulate MetricKit Payloads command, everything works as expected. The issue I'm having is when testing on a device via our enterprise distribution. When I simulate a crash, I am receiving the MXDiagnosticPayload so that part is working correctly. However, I am never receiving a MXMetricPayload. I've been using the app and waiting up to 3 days in some tests and not receiving any payload over that time frame. Some information I found suggested the issue might be MetricKit not working fully on enterprise apps but I haven't been able to find a definitive source on that question. Hoping someone here can guide me on that. Thanks!

Hallo all, I did a test integration of MetricKit into one of our apps...I'am on macOS Ventura 13.3.1 (a). The app is not distributed via the App Store. I subscribed to the MXMetricManager and implemented the didReceiveDiagnosticPayloads function. So far everything seems to work, when I use in Xcode: Debug -> Simulate MetricKit Payload I get a callback and the payload. So I did some further testing. When I build the app debug version with a test crash and then run the Debug Version (without Xcode) and let it crash the next time I start the app I get a callback to didReceiveDiagnosticPayloads with all the information about the crash. But I'am not able to get a hang report. I tested it by adding a sleep (60) and adding some intensive computation work on the main thread so that it is busy for several seconds, I get no hang reports :-( I'am using the Debug version and run it without Xcode. Are hang reports expected to be reported immediately? I also get after 24 hours no hang reports. Can someone help me? Thanks and have a nice day!

Two month back we published 28.11.0 version a app. for both foreground and background terminations are not properly showing by Xcode matrix Foreground Termination: I was able to see the termination bar chart for one release, but after that, the chart stopped showing real-time crash progress. However, crashes are still being reported directly by users. Why is Xcode Organizer unable to capture these events? Please help us track them effectively. Background Termination: The termination bar chart has not appeared in Xcode Organizer for the last two releases, which span nearly two months. As a result, we are unable to monitor app terminations for background scenarios.