BGContinuedProcessingTask GPU access — no iPhone support?

Question

Created 21h

Replies 2

Boosts 0

Participants 2

We are developing a video processing app that applies CIFilter chains to video frames. To not force the user to keep the app foregrounded, we were happy to see the introduction of BGContinuedProcessingTask to continue processing when backgrounded.

With iOS 26, I was excited to see the com.apple.developer.background-tasks.continued-processing.gpu entitlement, which should allow GPU access in the background. Even the article in the documentation provides "exporting video in a film-editing app" or "applying visual filters (HDR, etc) or compressing images for social media posts" as use cases. However, when I check BGTaskScheduler.shared.supportedResources.contains(.gpu) at runtime, it returns false on every iPhone I've tested (including iPhone 15 Pro and iPhone 16 Pro).

From forum responses I've seen, it sounds like background GPU access is currently limited to iPad only. If that's the case, I have a few questions:

Is this an intentional, permanent limitation — or is iPhone support planned for a future iOS release?
What is the recommended approach for GPU-dependent background work on iPhone? My custom CIKernels are written in Metal (as Apple recommends since CIKL is deprecated), but Metal CIKernels cannot fall back to CPU rendering. This creates a situation where Apple's own deprecation guidance (migrate to Metal) conflicts with background processing realities (no GPU on iPhone).
Should developers maintain deprecated CIKL kernel versions alongside Metal kernels purely as a CPU fallback for background execution? That feels like it defeats the purpose of the migration.

It seems like a gap in the platform: the API exists, the entitlement exists, but the hardware support isn't there for the most common device category. Any clarity on Apple's direction here would be very helpful.

Boost

Answer 1

FrankSchlegel OP

12h

Good question!

I haven't seen the new GPU background entitlements. Good to know!

My guess is that they don't want to support iPhone here because they prioritize battery over expensive processing on the mobile devices. The iPads on the other hand are more targeted towards pro use cases (and have a bigger battery).

What we are currently doing in our apps is to prevent the screen from locking during video export (using UIApplication.shared.isIdleTimerDisabled = true). We also pause the processing when the app is backgrounded and resume when it's active again.

0

Answer 2

trisign OP

8h

@FrankSchlegel for some reason the forum doesn't let me reply directly to your input:

Yes, we work with the same work arounds at the moment. We are just confused regarding the communication, as Apple strongly suggests support for iOS. Not only in their documentation, but also their WWDC talks:

"In iPadOS and iOS 26, your continued processing tasks can also benefit from background GPU access on supported devices."

Which is confusing because there just are no supported devices on iOS 26.

Trying to keep the user on the app during a video export task always felt hacky and suspending and restarting comes with its own issues. Especially since Apple deprecated CIKL a while ago and I don't know another way to have a Filter with CPU fallback. We were just happy to see a well implemented path for this use case.

I am also happy to accept if this is technically not feasible at the moment or Apple is moving in a different direction. I would just appreciate clarity, as their documentation and WWDC inputs are confusing/misleading.

0