Subject: [SDK / Instruments] Clarification on Runnable & Blocked Time Semantics — Customers Misinterpreting as CPU Usage
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