Synchronous Code

Thu, 19 Feb 2026 00:00:00 +0000

A Guide to Handling Heavy Synchronous Code in Swift Concurrency

This post explains why CPU-intensive synchronous code (such as image decoding via ImageIO) must be dispatched off the Swift Concurrency thread pool, and shows the correct patterns RawCull uses to do so.

`DispatchQueue.global(qos:)` — QoS Levels Compared

The key difference is priority and resource allocation by the system.

`.userInitiated`

Priority: High (just below .userInteractive)
Use case: Work the user directly triggered and is actively waiting for — e.g., loading a document they tapped, parsing data to display a screen
Expected duration: Near-instantaneous to a few seconds
System behavior: Gets more CPU time and higher thread priority — the system treats this as urgent
Energy impact: Higher

`.utility`

Priority: Low-medium
Use case: Long-running work the user is aware of but not blocked by — e.g., downloading files, importing data, periodic syncs, progress-bar tasks
Expected duration: Seconds to minutes
System behavior: Balanced CPU/energy trade-off; the system throttles this more aggressively under load or low battery
Energy impact: Lower (system may apply energy efficiency optimizations)

Quick Comparison

	`.userInitiated`	`.utility`
Priority	High	Low-medium
User waiting?	Yes, directly	Aware but not blocked
Duration	< a few seconds	Seconds to minutes
CPU allocation	Aggressive	Conservative
Battery impact	Higher	Lower
Thread pool	Higher-priority threads	Lower-priority threads

Rule of thumb

// User tapped "Load" and is staring at a spinner → userInitiated
DispatchQueue.global(qos: .userInitiated).async {
 let data = loadCriticalData()
}

// Background sync / download with a progress bar → utility
DispatchQueue.global(qos: .utility).async {
 downloadLargeFile()
}

If you use .userInitiated for everything, you waste battery and CPU on non-urgent work. If you use .utility for user-blocking tasks, the UI will feel sluggish because the system may deprioritize the work.

Heavy on RawCull