[Feature] iOS 26.1 Background Photo Sync Support

[jthoward64]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Implement support for the new iOS 26.1 background photo sync API

https://developer.apple.com/documentation/photokit/uploading-asset-resources-in-the-background#Create-and-configure-the-extension-target

Platform

• Server
• Web
• Mobile

[bo0tzz]

This isn't really something to track as a feature request, nor is it something we're likely to add anytime soon. Once it's available on the majority of devices it'll likely make it in as part of the usual improvements to the app.

[joydashy]

Sad to see this closed, the majority of users is on IOS 26, and in any case, any user that cares about Immich uploads would certainly upgrade their OS! To me the unreliable background upload is the most important feature Immich is missing. So happy that Apple finally opened this up, now hope it gets the attention it deserves.

Hup Holland!

[fabb]

Yes, the constant upload push notifications are not wife-approved and don’t help my case of leaving google photos

[subtleslander]

Adding to this, given we're now on the eve of iOS 27.

[grishio]

Adding to this, given we're now on the eve of iOS 27.

I think there are some technical limitations to this as explained in this comment below.

[stammy]

Would love to have this as well.

[fingon]

For the record I think majority of iOS users are already in 26 train ( at least for our app - about 2/3 are iOS 26 right now ). So when is this being reopened?

[muccitod]

New immich user here. Excellent service. Anything to improve the background upload of iOS/iPhone photos is a welcome addition. Thanks.

[coughlanio]

Also expressing my interest, I think it would be a great feature for Immich!

[johannesvogel]

I tried implementing my own "Photo Uploader for Immich" iOS app using the PhotoKit Background Resource Upload extension. Sadly there are two limitations that currently make it impossible to use this feature with Immich:

1. Apple forces developers to hardcode the URL that the photos will be uploaded to "for network access validation" (BackgroundUploadURLBase has to be added to the Info.plist file). This means it's impossible to use the PhotoKit upload with a User-configurable URL which would be necessary for using it with Immich (since every Immich instance has their own URL).
2. I then tried implementing this just for my own instance, but the Immich API for uploading assets has some required fields like deviceAssetId, deviceId, etc. which have to be sent to Immich as multipart/form-data fields. This is currently not supported by the PhotoKit upload, as the body of the HTTP request can only contain the asset data itself.

For reference, my proof-of-concept implementation is available here: https://github.com/johannesvogel/photo-uploader-for-immich This is of course not working (due to the limitations mentioned above) but I thought it might be of interest anyway.

Especially for "Limitation 1" someone at Apple would have to adapt the design of the Background Resource Upload extension, which I am not very hopeful for. If someone knows someone at Apple though, this might be something to bring up, since this basically makes it impossible to use for any self-hosted photo sync software.

[johannesvogel]

When it comes to privacy, the request body could just be encrypted.

I feel like encryption would add too much complexity, but I hadn't thought about this actually:

The intermediary server doesn't necessarily need to even parse the body, it can send a response as soon as it sees the redirect url param or some custom header.

I have adapted the config of my nginx "redirector" service (see here). Nginx now sends the HTTP 307 response once it has read the headers:

$ curl -v --location-trusted [...]
> POST /api/assets?redirectURL=immich.mydomain.com HTTP/2
> Host: redirect.example.com
> User-Agent: curl/8.7.1
> Accept: */*
> Content-Length: 2147483648
>
< HTTP/2 307
< server: nginx
< date: Sun, 28 Dec 2025 12:37:53 GMT
< content-type: text/html
< content-length: 164
* Need to rewind upload for next request
* close instead of sending 2147418271 more bytes
< location: https://immich.mydomain.com/api/assets
<
* Keep sending data to get tossed away
* Ignoring the response-body
* we are done reading and this is set to close, stop send
* [...]

This makes this viable option in my opinion, but this remains an issue of course:

I think this would be solvable with an alternative API endpoint that accepts the fields as headers

[Jip-Hop]

Perhaps another approach is to go with BGContinuedProcessingTask

A task that starts in the foreground and can continue running in the background as needed.

Not as elegant as a Background Photo Sync, but if it doesn’t have the plist hardcode and fixed body requirement it could be good.

Perhaps the app could check in the background if there are some new photos to sync, display a notification and once user clicks notification a new BGContinuedProcessingTask would start which would even continue if there are many and/or large files to sync.

[jthoward64]

When it comes to privacy, the request body could just be encrypted.

I feel like encryption would add too much complexity, but I hadn't thought about this actually:

I really doubt it would be too bad, the server could either have a single shared secret across all devices or have every session in the db have an 'upload secret' or something and expose an api route they gets the upload secret for the active login session. Considering we would need a new endpoint no matter what, making it so the body is parsed as an encrypted blob shouldn't impact anything else, and AES-256 is fast enough even without hardware acceleration that compared to how long the network and disk transactions take it should be relatively minimal overhead, but testing would be needed to know more.

[FawenYo]

Hi, I just found this discussion thread. In my PoC, I found that BackgroundUploadURLBase doesn't strictly need to match the actual Immich server endpoint. It is only used to verify the device's network connectivity to trigger the background upload process. (Check https://developer.apple.com/documentation/photokit/uploading-asset-resources-in-the-background#Create-and-configure-the-extension-target)

Add a new top-level key to the Info.plist file, named BackgroundUploadURLBase of type String. Set its value to the base URL for your upload server, such as https://api.example.com. The system requires this key for network access validation.

Although this isn't an elegant way (e.g. It might still attempt an upload even if the Immich server is offline), we can still use this as a temp solution

[grishio]

Question. How does Synology's Photo's iOS accomplish this? I use it via my own URL (not quick connect). As long as I have the app open in the background, through the course of the day all the photos get uploaded. They are not using ios26.1 background photo sync. Seems to work good, as long as you've opened the app before.

[fabb]

Background Photo Sync sounds awesome to get rid of the non-wife-approved immich push notifications.

Sounds like it is not compatible with chunked uploads though, or is there a way?
#25183

[FawenYo]

Hi @idolize , sorry I didn't see the notification.
Yes, you can just leave it alone, and it will continuously upload your photos/videos to the Immich server. The main difference with the official app is that mine uses the official SDK new introduced in iOS 26.1+ (https://developer.apple.com/documentation/photokit/uploading-asset-resources-in-the-background).

[menn0]

I am using Immich probably a bit different than most here, I use Immich with external libraries only.

1. A ext library for phone pictures
2. One ext library for camera pictures
3. One ext library for the spouse

The backup- mechanisms in my case are solved in different ways, some phone syncs via Onedrive to a Nas external library location, for the other the SD-card gets removed from the camera and photos are moved to the NAS folder.

Now for the spouse's iOS device I run into the issue that background syncing is made hard by Apple. I see this solution but also see the proxy. (read: extra complexity)

I wonder, if I use external libraries only, and just want to use this app YAIIU as a sync app (not a front-end to actually flick through the photos), dos this app suit my needs??

[cipri-tom]

@menn0 for your wife, just let the iPhone turned on over the night until the initial sync is done (sometimes it gets stuck and you need to restart the app and to resume). But after the initial sync, I find it works not too bad, except you have a notification every now and then .

[LuNeder]

@menn0 for your wife, just let the iPhone turned on over the night until the initial sync is done (sometimes it gets stuck and you need to restart the app and to resume). But after the initial sync, I find it works not too bad, except you have a notification every now and then .

The whole point of background sync is not having to do these awful workarounds.

I’ve been leaving my iPad with Immich open overnight for 4 nights in a row by now and it’s still at 1286 files out of 220791. If I go to sleep around 11pm, it’s often already frozen by 3am. This is not a good workaround and is what kept me from using 3rd party cloud services ever since I have an iCloud, but now that background sync is officially a thing this could get way better. Not because it would be fast, but because you could just leave it alone and eventually they’d finish.

Also, menn0 mentions using external libraries only so your advice doesn’t really work for them (I was also planning to do so initially, but apparently external libraries have some drawbacks in immich unfortunately - such as the app not letting you set your upload path to them)

[cipri-tom]

yep, I agree, quite frequent restarts are necessary initially :( . I wasn't trying to diminish this request, just giving Menn0 visibility into how we all did it so far, until better options exist.

Yes, not applicable to external libs. He said it's just for wife's iOS .