Classic Chat vs. Messaging: Mobile Browser Lifecycle (iOS Tab-Switching) and Queue Retention Behavior

Hi everyone,

I am looking for some architectural clarity from the community and the Zendesk product team regarding how Zendesk Classic Chat compares to Zendesk Messaging when handling mobile browser lifecycles - specifically on iOS Safari.

Our Context & Problem

We run a virtual healthcare platform where maintaining a stable virtual waiting room/routing queue is critical to patient care. Currently, we are using the Zendesk Classic Web Widget.

We are facing a severe issue with mobile users (specifically on iOS). When a user enters the chat queue, looks away to check another app, or switches tabs in Safari, iOS aggressively freezes the JavaScript execution context to save battery.

• In Classic Chat, this causes the live WebSocket connection to drop.

• Within 20 seconds to a couple of minutes, the Zendesk server flags the user as offline, removes their session, and drops them entirely from the active routing queue.

• When the user switches back to our tab, the widget attempts to reconnect, but their queue position has been completely reset, causing a terrible user experience.

We are looking to solve this natively and are considering a migration to Zendesk Messaging. Before we pull the trigger on architectural changes, we need to confirm exactly how Messaging handles this backgrounding behavior differently under the hood.

Our Questions for the Community / Zendesk Team:

1. Server-Side Presence Tracking: In Classic Chat, the queue position is tied strictly to the active, synchronous WebSocket session. In Zendesk Messaging, is the user's queue position decoupled from the active frontend WebSocket? If an iOS user backgrounds Safari and the socket drops, does Messaging hold their place in the routing queue server-side?

2. Capacity Release Settings: We understand that Zendesk Messaging features a "Capacity Release" setting in the Admin Center ("Mark messaging sessions as inactive when end-users leave"). If we turn this OFF, does it explicitly prevent iOS backgrounded/tab-switched users from being kicked out of the active queue? What is the grace period before the system considers them truly gone?

3. End-User Presence Detection & Web Push: Zendesk documentation mentions that if Web Push Notifications are enabled, an end-user's presence is considered "always detected" even if the WebSocket terminates. Does this functionality require the mobile website to be installed as a Progressive Web App (PWA) on iOS to keep the queue spot active, or does the server-side architecture hold the spot regardless of the client-side push status?

4. Session Resumption: When a user returns to a frozen Safari tab after 5–10 minutes, how does the modern Messaging Web Widget handle synchronization compared to Classic? Does it seamlessly download the missed conversation history and resume the active queue state without forcing a session reset?

We want to avoid fragile frontend workarounds (like silent audio keep-alive loops) or building a heavy custom backend API proxy server. We are hoping to confirm that a native upgrade to Zendesk Messaging completely modernizes this backgrounding behavior.

Any insights into the engineering differences between how Classic and Messaging manage mobile browser sleep cycles would be highly appreciated!

Thanks in advance.