Skip to content

feat(mobile): use shared native client#25942

Open
mertalev wants to merge 31 commits intomainfrom
feat/use-native-clients
Open

feat(mobile): use shared native client#25942
mertalev wants to merge 31 commits intomainfrom
feat/use-native-clients

Conversation

@mertalev
Copy link
Member

@mertalev mertalev commented Feb 5, 2026

Description

The app currently has fragmented auth and networking behavior, with configuration scattered across the app in the form of setting headers for individual API calls and websockets, creating clients per request and configuring each one, widgets having their own auth mechanism, each isolate needing to do all of this, and so on. This leads to a large surface area for these features with some things working and others being broken.

This PR moves API requests from a Dart client to a shared native client that is instantiated at startup. The overall goal is to consolidate configuration into a pre-configured client that handles everything, including mTLS, self-signed certificates, basic auth and custom headers. This client is then shared across the app, making these features more reliable and have lower maintenance burden as they work transparently.

An additional benefit to this is that the client leverages HTTP2/HTTP3, caching and multiplexing for improved performance, including for foreground upload. Moreover, these benefits extend across the app, meaning app extensions like widgets can get the same configuration for free.

The main remaining exceptions to this are asset downloading, background uploads and widgets, which don't use the same session yet. This can be addressed separately from this PR.

How Has This Been Tested?

Tested login, browsing, asset upload and websocket events on both platforms with and without mTLS, self-signed certificates and custom headers.

@jfly

This comment was marked as resolved.

@mertalev
Copy link
Member Author

mertalev commented Feb 7, 2026

Hmm, it might not be setting headers correctly on Android. I think I only tested upload on iOS.

@jfly
Copy link
Contributor

jfly commented Feb 11, 2026

@mertalev, just let me know when I should try testing android again!

@mertalev
Copy link
Member Author

@jfly Foreground backup is working on Android now for me, so it should be good for another round of testing.

@mertalev mertalev force-pushed the feat/use-native-clients branch 3 times, most recently from 755e5ac to 6be2052 Compare February 16, 2026 20:36
@mertalev
Copy link
Member Author

I also tried changing the client cert import to pick the cert from the OS store instead of importing a .p12 file directly. It should still work for certs that are already imported to the app, but any new imports will need to be added to the OS store first. Let me know how that feels to use!

@philipmw
Copy link

@mertalev , re:

It should still work for certs that are already imported to the app, but any new imports will need to be added to the OS store first.

Do you mean that adding to the OS store becomes the only supported way, or is it still an option to add the p12 file to the app manually?

@mertalev
Copy link
Member Author

@mertalev , re:

It should still work for certs that are already imported to the app, but any new imports will need to be added to the OS store first.

Do you mean that adding to the OS store becomes the only supported way, or is it still an option to add the p12 file to the app manually?

It becomes the only supported way. I'd rather avoid having two import flows for this.

@jfly
Copy link
Contributor

jfly commented Feb 17, 2026

@jfly Foreground backup is working on Android now for me, so it should be good for another round of testing.

@mertalev, foreground backup works for me now! I haven't tested background backup (honestly not entirely sure how to). I am now daily driving this PR, and will report back with any issues.

@mertalev mertalev force-pushed the feat/use-native-clients branch from 1a6242d to c943d12 Compare February 17, 2026 21:19
@jfly

This comment was marked as resolved.

@mertalev
Copy link
Member Author

mertalev commented Feb 18, 2026

Hmm, it looks like there's a bug with how the headers are handled when the background tasks run. I have a hunch for what's causing that.

@jfly

This comment was marked as resolved.

@mertalev
Copy link
Member Author

@jfly I think both issues should be fixed as of the latest commits.

@jfly
Copy link
Contributor

jfly commented Feb 18, 2026

Ok, I'm now running 68ace2b, will holler if I get logged out again, or run into any other issues!

platform-side headers

update comment

consistent platform check

tweak websocket handling

support streaming
@mertalev mertalev force-pushed the feat/use-native-clients branch from 5318e5b to c2ba1a7 Compare February 21, 2026 04:15
@mertalev mertalev force-pushed the feat/use-native-clients branch from c2ba1a7 to 58203eb Compare February 21, 2026 04:20
@mertalev
Copy link
Member Author

Ok, I'm now running 68ace2b, will holler if I get logged out again, or run into any other issues!

So far so good?

@jfly
Copy link
Contributor

jfly commented Feb 24, 2026

@mertalev, things have been stable for me on 5318e5b. Just deployed 42d5cb7 to my phone, will report back if I have any issues.

@philipmw
Copy link

Tangential— is there a TestFlight? As an mTLS user, this issue concerns me and I want to contribute testing.

@mertalev
Copy link
Member Author

Tangential— is there a TestFlight? As an mTLS user, this issue concerns me and I want to contribute testing.

There's no TestFlight for this PR unfortunately. To test it, you would need to build and install the app locally with Xcode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants