Hello All,
I’m a mobile-app developer working with iOS 26+ and I’m using BGContinuedProcessingTask to perform background work. My app’s workflow includes the following business logic:
- Loading images via PHImageRequest.
- Using a CLIP model to extract image embeddings.
- Using an .mlmodel-based model to further process those embeddings.
For both model inferences I set computeUnits = .cpuAndNeuralEngine.
When the app is moved to the background, I observe that the same workload(all three workload) becomes on average 4-5× slower than when the app is in the foreground.
In an attempt to diagnose the slowdown, I tried to profile with Xcode Instruments, but since a debugger was attached, the performance in background appeared nearly identical to foreground. Even when I detached the debugger, the measured system resource metrics (process CPU usage, system CPU usage, memory, QoS class, thermal state) showed no meaningful difference.
Below are some of the metrics I captured:
- Process CPU: 177% (Foreground) → 153% (Background) → ~-24.1%
- Still >1.5 cores of work.
- System CPU: 56.1% → 38.4% → ~-17.7%
- Process Memory: 244.8 MB → 218.1 MB
- QoS Class: userInitiated in both cases
- Thermal State: nominal in both cases
Given these results, I’m finding it hard to pinpoint why the overall latency is so much worse when the app is backgrounded, even though the obvious metrics show little variation.
I suspect the cause may involve P-core vs E-core scheduling, or internal hardware throttling/limit of Neural Engine usage, but I cannot find clear documentation or logging to confirm this.
My question is: Does anyone know why a CPU (and Neural Engine)-intensive job like this would slow down so dramatically when using BGContinuedProcessingTask in the background on iOS 26+, despite apparent similar resource-usage metrics?
Are there internal iOS scheduling/hardware-allocation behaviors (e.g., falling back to lower-performing cores when backgrounded) that might explain this? Any pointers to Apple technical notes, system logs, or instrumentation I might use to detect which cores or compute units are being used would be greatly appreciated.
Thank you for your time and any guidance you can provide.
Best regards,
Does anyone know why a CPU (and Neural Engine)-intensive job like this would slow down so dramatically when using BGContinuedProcessingTask in the background on iOS 26+, despite apparent similar resource-usage metrics?
I'm not entirely certain of this, but if I had to guess, it could be happening because you lost GPU access when you entered the background. Try testing with the "Metal System Trace", as I suspect that will show you a resource "shift" that wouldn't necessarily be visible in Activity Monitor.
Are there internal iOS scheduling/hardware-allocation behaviors (e.g., falling back to lower-performing cores when backgrounded) that might explain this?
Priority certainly does shift when you enter the background; however, the shift you’re describing is larger than I'd expect from that, especially since BGContinuedProcessingTask is involved. I'll also note that in your list here:
...the measured system resource metrics (process CPU usage, system CPU usage, memory, QoS class, thermal state) showed no meaningful difference.
...Metal/GPU usage is the one resource that ISN'T in that list. Unfortunately, if this is Metal, then there isn't a lot you can do about that. You can (and probably should) enable background GPU access, but that won't help on the iPhone (it's not available there). However, if you have an iPad that supports it, I'd also test there with and without background GPU enabled. If the performance loss disappears or substantially reduces when you enable background GPU, then that basically proves what the issue is.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
