Attributing SDK performance/battery impact in production

Question

Created 1d

Replies 2

Boosts 0

Participants 2

This post is from the WWDC26 Power & Performance Q&A.

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.

Answer 1

Systems Engineer OP

Apple

1d

Hi Okengroth, thanks for the great question!

The best ways to understand the power and performance impact of a given framework is through Xcode Organizer and metrickit.

If the framework shows up in a lot of energy reports in Xcode Organizer, it is causing significant power impact
You can also use the metrickit CPU exception and again if the associated call stack contains the framework it is likely causing performance issues. Additionally, if you're able to conditionally disable the framework for some users you can use the new state reporting api to A/B test the framework's impact.

Answer 2

Okengroth OP

1d

( @Systems Engineer answering here as I cannot do it with the "Add Comment").

I agree with you that MetricKit will probably help here (and also state reporting api)

As far as I know Xcode Organizer is only accessible to the app developer. So we (the SDK), cannot get that information directly (we know it's useful, we just cannot get it)

Regarding lower-level APIs, is there anything similar to extracting ri_billed_energy from rusage_info_current, or anything along those lines, that could help narrow the attribution down to my SDK or to specific functions in my code?