Power & Performance Q&A

My app's crash numbers in App Store Connect's analytics are higher than I'd like, but I'm having trouble figuring out where they're coming from. In Xcode's Organizer, I see very low numbers of foreground crashes, and 95% of my background terminations are "System Pressure." So I have some questions about what's included in App Store Connect's numbers and correlating them with other signals: Do they include background terminations, or only foreground terminations? If they do include background terminations, do they include "File Lock" terminations (which I think largely means 0xdead10cc)? If they do include background terminations, do they include System Pressure terminations? Are all the crashes included in App Store Connect's numbers also delivered to MetricKit as crash diagnostics? Is there documentation on what "System Pressure" terminations are? My understanding is that it's when the system kills my app to free up resources.

The new MetricKit and StateReporting APIs look great. The names of the Swift-first API conflicts with a lot of what I’ve written to do custom decoding (CrashDiagnostic —> MetricKit.CrashDiagnsotic and MetricKitModels.CrashDiagnostic). Job well done. Very clean API and reminds me of enum cases generated from Swift OpenAPI Generator, good stuff. Since there were no 1:1 labs this year for power and performance, I thought I’d send over my feedback for open discussion on the forums. This post is mostly centered around documentation and clarification. FB23019810 - Multiple metric and diagnostic pipeline design. What is the recommended implementation if I have two destinations that want the exact same domain scope. Two managers? A single manager with multiple async streams? Some API like HealthKit recommend a single HKHealthStore, is there any downside to creating many managers, or conversely, creating many async streams for metrics and diagnostics? FB23019316 - The new sample code shows mxSignpost. Is there any reason why we should not be using OSSignposter backed with a MetricKit OSLog handle? The API is more expressive and can handle wrapping closures P.S. see FB22413384 to hopefully enhance OSSignposter with an async func variant FB23020182 - MetricKit deprecations seem off and availability of the new API is missing from macOS and visionOS too. Can you clarify what the docs should show for deprecation? Can you clarify what the docs should show for availability of the new API? FB23051890 - Regarding StateReporting, I understand there is a sanity limit for how one would slice up the metrics per the video commentary. Too many dimensions the data becomes hard to associate with actual improvements to be made. Is there a limit developers should stay clear of? When using the StateReporting API, what are the practical limits to the number of domains and metadata key/value pairs we can have? FB23051980 - I’m excited and ready to implement StateReporting, in all the places. Is it supported in extensions? Will the resulting state changes be included in MetricReport? Last I asked, MXMetricPayload didn’t capture extension data. Will the resulting state changes be included in DiagnosticReport? I do see MXDiagnosticPayload come through containing extension data, so hopefully yes. FB23051678 - I didn’t catch any session or documentation material about the usage around the volatile metadata in the StateReporting API. The docs state it is a fatalError to change the domain and stable metadata keys, that makes sense if that is how the composite key for uniqueness is being created. By the name volatile I assume it can, well change. What is the usage of the volatile metadata? What limitations exist around it if any? The ReportedState API doesn’t have any properties for volatile, is it meant to be received in reports? FB23051738 - There isn’t a StateReporting area path in Feedback Assistant. For now sending feedbacks to MetricKit team, but it is a different framework. I assume other new frameworks are also missing I haven’t confirmed yet. FB13904761, FB13819435, FB13221143, FB22362800 - I have a handful of feedbacks that were reporting anomalous data with payloads. The routine with most bug feedbacks is to capture a sysdiagnose. Any tips on doing that when the reports are coming in from the field or not being actively monitored on dev and test devices? I know this is unlikely to happen but putting it out there FB9931474 - MetricKit: Add API to trigger sysdiagnose programmatically FB23047674 - Add docs for StateReporting and the Xcode simulate MetricKit menu. What domains should be added to the managers to populate data in the simulated reports? FB23020088 - I dig the new memory diagnostic, I’m hoping to close out this feedback that requested it FB9972410. Based on the language in the session, I am leaning towards it is only for memory limit, not jetsam memory pressure. Can you clarify in the documentation which memory exits it is for? Thanks for making it all the way to the end. If better to split this up in different posts I can try to do that but overlapped with other conference calls at the moment.

Hi! I have a couple of questions around measuring SDK performance in production, especially battery impact (and related to this, Disk Read/Writes). For an SDK running in the wild, what resources or APIs would you recommend using to evaluate performance impact once the SDK is already deployed to real users? I understand that Instruments and local profiling are the right tools during development, but production introduces a much wider range of devices, OS versions, app behaviors, network conditions, and user patterns (in particular, because SDK goes into different types of apps) In particular, are there recommended ways to understand battery usage attributable to an SDK in production? How can we reason about whether a battery-related issue is actually caused by our SDK rather than by the host app, system behavior, networking conditions, or other third-party SDKs? Any guidance on recommended signals, best practices, or things to avoid when trying to attribute battery impact in production would be very helpful.

I shared a handful of feedbacks regarding MetricKit and StateReporting documentation here: https://developer.apple.com/forums/thread/833079, this post focuses on API design feedback and enhancements. While you’re breaking the interface and the json schema version, there are a few more quality of life improvements that could be made. I’m sharing my feature request feedbacks for the new API here to encourage other devs to write similar feedbacks and share theirs too. So, what would you say is the best way to inspire and ask for new features in MetricKit? #filefeedback FB23023840 - MetricKit: Add 'id' or 'identifier' (UUID string) to the MetricReport and DiagnosticReport Just like an IPS crash file, I’d like each report to have a unique identifier. This will help when performing mass imports of payloads into analysis and visualization tools. FB23023481 - MetricKit: Update environment osVersion.platform to use the same string name values as App Store Connect API --> iPhone OS should be simply 'iOS' This is just a small QOL to keep naming consistent in related fields. One could even share code! FB23024453 - MetricKit: Make MetricReport and DiagnosticReport types conform to Equatable for convenience of comparing decoded reports against each other This is similar to the unique ID concept, but if you don’t want to add an ID or conformance to identifiable, this can be a very useful quick check for all of the type properties being the same or not for report uniqueness. FB23019500 - MetricKit: Update API of MetricReport to not allow a nil environment I know the metadata in the metrics is nullable, and if this is just a wrapper or conversion of that I get it, but, is it possible to make the environment for the MetricReport required? I think it is reasonable for all of the properties except the multiple app versions to detect in the MetricReporter type or what ever internals. The rest of the API change eliminated a whole cohort of nullable types and properties, I think this is the last one! FB23023396 - MetricKit / Xcode: Simulate MetricKit payloads with encodingKeyFormat set to default produces an empty string bundle identifier My first few simulated payloads had an empty string for the bundle identifier. I know that the metadata didn’t expose this property in the old API but the jsonRepresentation did. I don’t know if it is related to how it is computed in that legacy type or just a bug in the Xcode utility. FB23052965 - MetricKit: Create OpenAPI Spec for the JSON encoding representations of MetricReport and DiagnosticReport I will have to update the code in my dev tools app that analyzes and visualizes MetricKit payloads to support the new json format(s). It would be nice if all of this code could be generated using a tool like the Swift OpenAPI Generator. One major advantage is that anyone could create their decoding types fairly easily, and, updating to new versions with new metrics or diagnostic constructs would be a simple code generation effort. FB23019260 - MetricKit / Developer Documentation: Update the new MetricKit sample code to use swift lang version 6 and fix compile errors The days of @preconcurrency import MetricKit are gone! At least for the new types. The sample code still uses Swift 5. Small tweak but good to illustrate the API is fully sendable and ready for structured concurrency. FB19499083 - Add API to designate the ‘source’ of the install —> App Store, TestFlight, Xcode (ad-hoc, mdm, etc.) I use the ‘source’ to determine a priority and routing of metric payloads (soon to be metric/diagnostic reports). I’d like to see as part of the environment property, a designation to where the app came from. Now that the report types are fully codable I could just wrap to enrich it, and that is probably going to be a common workflow, but it would be great if the original type had it from the start. I don’t have a reliable way to distinguish MDM device-enrolled vs MDM user-enrolled, Xcode is easy —> #if DEBUG source = Xcode. FB23053458 - MetricKit / Developer Documentation: Update sample code to capture the async sequences and demonstrate cancellation under a user privacy switch showing privacy-by-design I have always found MetricKit to be an incredibly useful privacy-by-default and private-by-design developer instrumentation tool. The sample code could be updated to show developers they can and should cancel their report tasks if the user wants to not have their data collected. MetricKit is rather incompatible with Open Telemetry, but signposts do easily transfer to spans and traces. Apple’s swift-log, swift-metrics, and swift-distributed-tracing would make for some really interesting integrations with MetricKit as the backing store. No FB numbers yet, I need to think about this one more. Betas are installed, apps updated with reporter sequences, save to files app and hunting for bugs. Evident from the group lab, MetricKit and StateReporting are a significant milestone for app performance and observability. Looking forward to future updates and betas!

I'm having trouble knowing whether my app is in good shape for battery usage by looking at the Battery Usage pane in Xcode's Organizer. I have some questions: At the top under "On-Screen Battery Usage", it says "Normalized to the usage of the most recent version when unplugged (x minutes / day)". Is the number there represented by "x" how long users tend to have my app open per day? When looking at the colored segments of the usage, I'm showing "Display" as 85% or more of the area. Is that just the cost of keeping the display turned on? Does it go up or down based on things like animations, displaying complex images, etc? It would be great to have an example of some apps of different types that are good "battery usage" citizens and what their battery usage looks like on this screen.

The documentation suggests that you can transfer files out of the crash reporting extension but it doesn’t outline if there are any gotchas to watch out for. Are there any limitations to this? Does it have full network access? Are app groups and keychain groups fully supported? Does the extension have a memory footprint limit we should watch out for? What is the lifecycle of the callback, what Is a reasonable amount of time to plan our implementation to do its work and be done within? 10 seconds? 30? And so on.

I wrote a python script MXSymbolicate to symbolicate crash reports produced by MetricKit. To symbolicate a given frame, it needs the symbol file for that frame's library. For system libraries, my system only has the requisite files on disk if I've plugged an iOS device of that type at that iOS version into my computer at some point (I assume these symbol files from the device are generated by Xcode when it's preparing to debug on a new device). All these different versions of the symbol files take up a fair bit of space on my machine over time, and it means the symbolication process isn't very portable. Is there a better way to get ahold of symbol files for system libraries? Or is the expectation that we (as third party developers) only symbolicate the frames from our own apps?

Hi! I have a few questions about the lifecycle and capabilities of the Crash Reporter Extension. Besides using the corpsePort to inspect the crashed process through Mach APIs, is it safe/supported/recommended for the extension to access files in a shared App Group container? Are there any caveats or exceptions we should be aware of, for example around memory-mapped files, file coordination, or filesystem access after the host app has crashed? Shall we use some particular APIs for this kind of shared resource or not? While debugging the extension, I noticed that when I trigger a crash in the app I am debugging, LLDB does not stop inside the extension (it also ends up stopping the debugging session). However, I can observe that the extension does run, because it writes data into a shared App Group directory related to the crash. Is this expected behavior? Is there a recommended way to debug the Crash Reporter Extension reliably (with lldb, or other way)? More generally, I would like to better understand the extension lifecycle: When exactly does the extension start running? How long can it live after the app crashes? Is there a time limit for operating on the corpse process? Is the extension subject to resource limits similar to other app extensions, such as memory, disk, CPU, watchdog, or jetsam constraints? If the Crash Reporter Extension itself crashes, how can we detect that? Would those crashes appear in Xcode Organizer, or is there another recommended way to observe them? Any clarification around the supported lifecycle, debugging model, and resource limits would be very useful.

Xcode26.2, xcode26.3: with each Xcode version upgrading from xcode26.0 to Xcode 26.2, xcode26.3, we saw size increased with same code running on different Xcode versions, freeze happened when run app on simulator, also our same XCtest cases randomly failure on Mac Mini, but successfuly on Mac book with same OS and xcode version

My app has a meaningful number of 0xdead10cc terminations because it deals with sqlite files in a shared app container. Are there any tips to diagnose them or track down which files are most often held open? Are they delivered to MetricKit as crash diagnostics? They're hard to identify in the Xcode organizer - I have to right-click on a suspect, Show in Finder, Show Package Contents, navigate into the proper sub-folder for my filter, then into the Logs subfolder, and look through the raw crash reports. And these crash reports don't identify the file that the lock is held open to, and they don't identify the correct culprit thread. Not all of them even show any of my code doing file IO. FB12292887