[Feature]: Use neutral status copy while reconnecting after mobile app resume

[goggi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/mobile

Problem or use case

After backgrounding the iOS app and reopening it, the composer status briefly shows:

Failed to connect. Retrying <environment>...

It then changes to:

Syncing messages...

The connection normally recovers without any action from the user. Because this happens as part of a routine app resume, the initial message makes an expected reconnect look like a genuine connection failure.

This makes it difficult to distinguish between normal recovery after reopening the app and a connection problem that actually requires attention.

To reproduce:

1. Open a thread in the iOS app while connected to an environment.
2. Background the app for a few seconds.
3. Reopen it.
4. Observe Failed to connect. Retrying <environment>..., followed by Syncing messages... once the connection recovers.

Proposed solution

Use neutral progress messaging during the normal reconnect that follows an app resume.

For example, the app could show the existing Syncing messages... status while reconnecting, rather than immediately showing Failed to connect.

Reserve Failed to connect for cases where the environment has not reconnected after a meaningful timeout. This would preserve a clear failure state without presenting a routine, transient reconnect as an error.

Why this matters

Backgrounding and reopening an app is a frequent and expected mobile workflow. Showing a failure message during normal recovery makes the app appear less reliable and may cause users to force-quit the app, retry manually, or check their remote environment unnecessarily.

Using neutral progress messaging for routine recovery would also make genuine connection failures more meaningful when they do appear.

Smallest useful scope

Change only the mobile status presentation following an app resume:

• Show neutral progress messaging during the initial reconnect.
• Show Failed to connect only if reconnecting continues beyond a reasonable timeout.
• Leave the existing connection and retry behavior unchanged.

Alternatives considered

• Always show Reconnecting...: Better than failure-flavoured wording, but Syncing messages... may provide a simpler and more consistent resume experience.
• Show no status during a brief reconnect: Avoids unnecessary messaging but removes useful feedback that recovery is in progress.
• Keep the current behavior: The connection usually recovers, but the status continues to suggest that something has gone wrong.

Risks or tradeoffs

Delaying the failure message means a genuine connection problem may take slightly longer to become visible. The timeout should therefore be long enough to avoid warning about routine reconnects, but short enough to communicate a sustained failure promptly.

The wording should also remain consistent across the composer and other mobile connection-status surfaces.

Examples or references

• fix(web): delay transient reconnect warnings #5670 delays transient reconnect warnings in the web client so brief reconnects do not immediately appear as sustained failures.
• perf(mobile): reconnect environments immediately on resume #4878 introduced the current immediate reconnect behavior when the mobile app resumes.
• [Bug]: iOS app fails to open a thread on slow links ("syncing → failed to connect") after an image Read — server inlines full base64 images into thread activity payloads #4595 reports a related iOS connection-status experience, but with a different trigger.
• [Bug]: Local desktop environment enters reconnecting after foreground health check timeout #3553 concerns similar connection-health messaging on desktop rather than this mobile resume experience.

Contribution

• I would be open to helping implement this.