PHBackgroundResourceUploadExtension is never scheduled when iCloud Photos is enabled

Question

willis ling OP

Created Apr ’26

Replies 1

Boosts 0

Participants 2

Feedback: PHBackgroundResourceUploadExtension is never scheduled when iCloud Photos is enabled

Summary

PHBackgroundResourceUploadExtension's init() and process() methods are never called by the system when iCloud Photos is enabled on the device, even though setUploadJobExtensionEnabled(true) succeeds and uploadJobExtensionEnabled returns true.

Environment

iOS 26.4 (both devices)
Xcode 26.x
Tested on iPhone 17 Pro (primary device, 10,000+ photos) and an older iPhone (development device, 200+ photos)
Same build deployed to both devices
Full photo library access (.authorized) on both devices

Steps to Reproduce

Create an app with a PHBackgroundResourceUploadExtension (ExtensionKit, extension point com.apple.photos.background-upload)
Enable iCloud Photos on the device (Settings > Photos > iCloud Photos)
In the host app, request .readWrite photo library authorization and receive .authorized
Call PHPhotoLibrary.shared().setUploadJobExtensionEnabled(true) — succeeds without error
Verify PHPhotoLibrary.shared().uploadJobExtensionEnabled == true
Wait for the system to schedule the extension (tested overnight, with device on charger + WiFi)

Expected Behavior

The system should call the extension's init() and process() methods to allow the app to create upload jobs, as documented in "Uploading asset resources in the background."

Actual Behavior

The extension's init() and process() are never called. The extension process is never launched.

Investigation via Console.app

Using Console.app to monitor system logs on both devices revealed the root cause:

When iCloud Photos is DISABLED (extension works correctly):

assetsd    Checked all submitted library bundles. Result: YES

dasd    SUBMITTING: com.apple.assetsd.backgroundjobservice.assetresourceuploadextensionrunner:35E7B5
dasd    Submitted: ...assetresourceuploadextensionrunner at priority 5
dasd    submitTaskRequestWithIdentifier: Submitted BGSystemTask com.apple.assetsd.backgroundjobservice.assetresourceuploadextensionrunner

The extension is subsequently launched and init() / process() are called as expected.

When iCloud Photos is ENABLED (extension never works):

assetsd    Checked all submitted library bundles. Result: NO

No assetresourceuploadextensionrunner background task is ever submitted to dasd. The extension is never launched.

Reproducibility

100% reproducible across two different devices
Toggling iCloud Photos off (and waiting for sync to complete) immediately resolves the issue
Toggling iCloud Photos on immediately causes the issue to reappear
Reinstalling the app does not help
The same build works on the same device when iCloud Photos is disabled

Impact

This effectively makes PHBackgroundResourceUploadExtension unusable for the vast majority of users, as most iPhone users have iCloud Photos enabled. Third-party photo backup apps (Google Photos, Dropbox, OneDrive, etc.) would all be affected by this limitation.

The documentation for "Uploading asset resources in the background" does not mention any incompatibility with iCloud Photos being enabled.

Requested Resolution

Please either:

Allow PHBackgroundResourceUploadExtension to be scheduled regardless of iCloud Photos status, or
Document this limitation clearly in the API documentation if it is intentional behavior

Answered by DTS Engineer in 887992022

Thanks for the thorough investigation — using Console.app to pinpoint the gating decision at assetsd ("Checked all submitted library bundles. Result: NO" with iCloud Photos on, versus YES with it off) is exactly the diagnostic level engineering needs.

Based on the public API documentation, the observed behavior doesn't match the framework's documented design. The "Uploading asset resources in the background" article and the documentation for setUploadJobExtensionEnabled(_:) enumerate two preconditions for the extension to run: full photo library authorization, and registration of the extension point com.apple.photos.background-upload. Neither mentions iCloud Photos.

The stronger signal comes from the documented description of PHAssetResourceUploadJob.Type.upload: "An upload job type (will download the resource from iCloud if required, then upload)." That description is only meaningful if iCloud Photos can be enabled — the framework is explicitly designed to handle the case where photo assets are stored in iCloud and need to be fetched before upload. If iCloud Photos enabled was meant to gate the extension entirely, the design of that job type wouldn't make sense.

So this looks like a bug rather than intentional behavior. Have you filed a Feedback for this? The post is structured like a Feedback report but I don't see an FB number — if you've filed, posting the number here lets others reference it; if you haven't, the body of your post is essentially ready to file as-is.

If you'd like direct engagement with engineering on this — for example, to ask about workarounds while the issue is being investigated — opening a Code-Level Support request is a good path. I can look at your project directly and follow up with the Photos team.

Answer 1

DTS Engineer OP

Apple

2w

Recommended

Thanks for the thorough investigation — using Console.app to pinpoint the gating decision at assetsd ("Checked all submitted library bundles. Result: NO" with iCloud Photos on, versus YES with it off) is exactly the diagnostic level engineering needs.

Based on the public API documentation, the observed behavior doesn't match the framework's documented design. The "Uploading asset resources in the background" article and the documentation for setUploadJobExtensionEnabled(_:) enumerate two preconditions for the extension to run: full photo library authorization, and registration of the extension point com.apple.photos.background-upload. Neither mentions iCloud Photos.

The stronger signal comes from the documented description of PHAssetResourceUploadJob.Type.upload: "An upload job type (will download the resource from iCloud if required, then upload)." That description is only meaningful if iCloud Photos can be enabled — the framework is explicitly designed to handle the case where photo assets are stored in iCloud and need to be fetched before upload. If iCloud Photos enabled was meant to gate the extension entirely, the design of that job type wouldn't make sense.

So this looks like a bug rather than intentional behavior. Have you filed a Feedback for this? The post is structured like a Feedback report but I don't see an FB number — if you've filed, posting the number here lets others reference it; if you haven't, the body of your post is essentially ready to file as-is.

If you'd like direct engagement with engineering on this — for example, to ask about workarounds while the issue is being investigated — opening a Code-Level Support request is a good path. I can look at your project directly and follow up with the Photos team.