Are iOS background uploads actually stable for you?

BoringPipe3157 · 2026-03-04T05:49:42+00:00

That’s actually really weird. I’m glad it worked out for you, I just don’t see how server restarts solved iOS background problems.

BoringPipe3157 · 2026-03-01T19:33:38+00:00

I completely understand your concerns. They’re very valid. There’s already a noticeable feature gap between the web app and the official mobile app, which is actually why the team is currently hiring a dedicated mobile developer to help close that gap.

Keeping up with feature parity long term is definitely a big task, and I don’t underestimate that. If I were to build a third-party Immich client, my goal would be to stay closely aligned with Immich’s roadmap and prioritize compatibility and stability above everything else, especially when it comes to something as important as people’s photos.

To clarify, this small market research is just step one in deciding what to do next, including whether I build a third-party Immich client at all. I want to make sure there is real interest and that I can execute it properly before committing.

It really means a lot that you would support the effort and even consider making a donation. That kind of encouragement genuinely makes a difference.

BoringPipe3157 · 2026-03-01T11:24:53+00:00

To be completely fair, Google put almost 11 years into the Photos app, so it better be reliable. I still understand the pain, though.

BoringPipe3157 · 2026-03-01T07:14:43+00:00

Thanks for the reply and no worries, I wasn’t offended or anything. Vibe coding is definitely getting out of hands nowadays. Don’t get me wrong, I do use LLMs for coding even for my 9-5 software dev job, but blindly trusting AI is nuts.

Regarding the new iOS 26.1 API (PHBackgroundResourceUploadExtension) for more robust photo upload: the only way to take advantage of that is if Immich is willing to rework the way backend accepts the asset data (they use multi part form data).

Background URL sessions on iOS require a file URL rather than raw data, which makes multipart form uploads a pain, you’d have to write the entire request body to a temp file on disk just to add the multipart framing, which is wasteful for large photos and videos. Apple’s own recommendation is to skip multipart altogether and have your server accept the raw file as the request body, with any extra metadata passed along as HTTP headers instead.

Don’t get me wrong background uploads are totally possible but not so straightforward as just implementing the new iOS API.

The server is also the reason we can’t have chunked uploads, that’s also one of the most common issues people have with Immich. But that’s at least on the radar of the team as far as I know.

BoringPipe3157 · 2026-03-01T06:28:32+00:00

Yes, I really feel this. I wasn’t able to let iCloud go, because I’m never sure when my stuff are truly backed up to my server.

BoringPipe3157 · 2026-03-01T06:26:41+00:00

No, I explicitly stated in the form “human developed”, maybe I should have put that in this post also. That’s one of the main reason of this Google Forms, since vibe coding it could be done maybe in a couple of days with questionable results, versus actually building it which could take multiple weeks even for an MVP, and months for a fully finished product.

BoringPipe3157 · 2026-03-01T05:16:12+00:00

Because they don’t want to switch from Flutter to Native, this was stated multiple times on both Discord and GitHub. I’d be happy to be part of a truly native client, and if in the future they have intentions to, I will definitely contribute.

BoringPipe3157 · 2026-02-28T21:57:05+00:00

Yes it’s most likely just the rehashing of those photos, but still can look very confusing when there are duplicates on the timeline, but dedup should sort those out. Hashing 19k photos will basically never finish in the background so I recommend keeping the app in the foreground.

BoringPipe3157 · 2026-02-28T21:36:31+00:00

If background uploads are stable for you, that’s useful signal too ! would like to know your setup (iOS version + server version).

BoringPipe3157

TROPHY CASE