Metal GPU work aborts and crashes app during backgrounding without BG GPU access (iOS 26.2)

[JulianPscheid]

Summary

On iOS 26.2 (tested on iPhone 12) with whisper.cpp v1.8.2 + Metal backend, backgrounding the app while a GPU workload is in-flight now not only revokes the GPU work (expected) but also crashes the app via ggml/Metal abort. Prior to iOS 26, backgrounding would terminate the job without killing the process. We’re looking for a safe way to avoid the crash when the system hasn’t granted a BG GPU assertion.

Environment

• whisper.cpp: v1.8.2 release (and with more recent commit 999a7e0)
• Device: iPhone 12 running iOS 26.2
• Backend: Metal (default configuration)
• Model: ggml-small-q8_0.bin
• BGContinuedProcessingTask: either not submitted or still pending when the app backgrounds

Steps to reproduce

1. Initialize whisper.cpp with Metal and start a short transcription chunk.
2. Immediately background the app (press Home) before a continued-processing task with .gpu resources is active.
3. Metal logs MTLCommandBufferErrorDomain Code=8 "accessRevoked"; ggml/whisper.cpp aborts; the host app crashes.

Observed behavior

• Any in-flight Metal command buffer is aborted if the BG GPU resource isn’t already asserted.
• whisper.cpp treats the Metal error as fatal, so the process exits rather than falling back to CPU or canceling the chunk.
• Even when devices report support for BG GPU (via BGTaskScheduler.supportedResources), the handler isn’t always delivered before the background transition, leading to the same crash.

Expected behavior

• Backgrounding without a BG GPU assertion should terminate the work but leave the app/process running, just as it did on earlier iOS versions.
• Ideally there would be hooks or guidance to pause/flush whisper.cpp’s Metal state before background transitions so we can avoid the crash window.

Additional context

• In testing, very few devices actually report BG GPU support via BGTaskScheduler.supportedResources, so we still need a robust fallback for devices that don’t support the continued-processing task at all.
• Current workaround is to force CPU contexts whenever we can’t guarantee BG GPU access, but that forfeits Metal acceleration.

Any pointers or recommended patterns from the community on handling Metal revocation (or detecting unsupported devices cleanly) would be greatly appreciated.