[Feature] Mobile app QUIC support

[jpds]

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

• Yes

The feature

The Immich mobile apps should use https://pub.dev/packages/rhttp to leverage HTTP2 and HTTP3 connection support for quicker data connection establishment and data transfer speeds. Currently on my frontend webserver I only see requests using HTTP/1.1 from the app (as, of course, it's using dart:io).

Platform

• Server
• Web
• Mobile

[mmomjian]

Would love to see this. Definitely would improve the timeline experience to parallelize these requests.

[shenlong-tanwen]

We are planning to migrate to using cronet / cupertino http libraries in #21459 which brings automatic support for HTTP/2 and HTTP/3

[xrzlddl]

I'd love to see Immich support HTTP/2 and HTTP/3 natively. The head-of-line blocking in HTTP/1.1 can be a real bottleneck when scrolling through large photo timelines, especially when loading hundreds of thumbnails simultaneously. Adding QUIC (HTTP/3) support would be a game-changer for remote access over unstable mobile connections.

We are heading into 2026, and these protocols should really be the baseline for any modern, high-performance media application. Staying on older standards feels a bit outdated for a cutting-edge project like Immich.

It would be great to see this prioritized in the roadmap to ensure a snappier, more robust user experience.

[fabianbees]

@xrzlddl You can check out this PR, it makes use of the native clients for each device type and also has QUIC support as a side effect.
I remember testing the .apk of said branch a while ago, and I could confirm using QUIC resulted in massive performance gains for loading the thumbnails in the main timeline compared to the stable version without QUIC support.

Maybe the author of PR #21459 @mertalev can give us a quick update, wether this PR is still planned to be merged or considered stale?

[mertalev]

Part of the motivation of the PR was to handle client certs, which we learned wouldn't be fully resolved with cronet. That and an issue with using the libraries with different Flutter engines (which might be fixed upstream by now?) made me deprioritize it. rhttp as mentioned in that PR seems worth trying as well as a possible alternative.