3CX apps: production, beta and PBX-version boundaries

Pin every client and PBX to its release lane

The 3CX client family does not share one version number or one release state. At the October 6, 2026 review, 3CX presented Windows Softphone 5.7 as a production release, while its Windows build history listed 5.8 as beta. Its Android build history listed 5.6 as production and 5.8 as beta; 3CX likewise published iOS 5.6 as production and iOS 5.8 as beta. Keep Windows, Android, iOS, Web Client and PWA rows separate.

PBX features can add another gate. 3CX's Android and iOS 5.8 beta articles say their outbound-number and queue controls require V20 Update 10, while the release index still described Update 10 as beta at review. A client visible in a beta channel is not a production recommendation, and a client installation does not prove that its connected PBX exposes the feature.

Keep the current app family bound to a 3CX system

3CX states that its current apps work with a 3CX system. The supported family includes Windows, iOS and Android clients plus the browser Web Client and Chrome or Edge PWA. Keep those paths separate from the legacy Electron Desktop App and from generic SIP clients: user identity, presence, messaging, routing and permissions come from the connected PBX.

Record the PBX edition, version and update, hosting model, user extension, exact client build, installation channel, operating system and access path. A feature documented for the Web Client or an Update 10 beta does not establish the same interface or behavior on a production Windows or mobile client.

Treat Windows migration as credential-bearing provisioning

Windows Softphone 5.7 can detect a legacy Desktop App configuration, check whether the stored PBX is reachable and offer to migrate the server and extension. It also documents an administrator flag for silent migration. This is a provisioning path, not proof that every account, policy, audio device or call setting moved correctly.

Inventory the source Desktop App, destination Softphone, PBX identity and authorized user before migration. Confirm which data is read, which process owns the action and how the old client is retired. Do not run production and beta clients together merely to compare them; 3CX's release guidance warns against parallel production and beta installations. Preserve a supported re-enrollment path instead of copying configuration material by hand.

Separate login, QR enrollment, SSO and fleet installation

The user manual starts from a system-issued account path. The Web Client can use PBX credentials and administrator-enabled identity controls; mobile setup uses a QR code. Treat the QR code, account email, migration source and any command-line provisioning arguments as credential-bearing material rather than ordinary documentation.

Installation, enrollment, authentication and authorization are separate states. Record who can issue and revoke each path, how a lost device is removed and whether older sessions remain active. Beta features such as one-click SSO still require their stated client and PBX versions and must not be backported into the production capability record by assumption.

Version the mobile push-expiry statement

3CX says mobile apps use push notifications to wake the device for incoming calls and messages. Its September 18, 2026 article states that V20 Update 10 changes the push-subscription expiry from seven to fourteen days. Because Update 10 remained beta in the reviewed release index, the fourteen-day value is an Update 10 behavior, not an unqualified promise for every deployed PBX.

Preserve PBX version, client build, platform push service, notification permission, background or battery policy, last app connection and subscription state separately. Opening the app can refresh state, but one successful notification does not establish locked-screen delivery over a shift, an extended absence, Wi-Fi and cellular transitions or a restored device.

Pilot each platform and the complete calling policy

Use separate matrices for production and beta lanes on Windows, iOS, Android, Web Client and PWA: sign-in, enrollment, inbound and outbound calls, selected caller identity, audio devices, DTMF, hold, transfer, voicemail, presence, queue state, notification, reconnect, upgrade, sign-out and revocation. Confirm which device rings when several clients are active and how answering or declining on one affects the others.

Emergency routing, callback and location remain properties of the user, PBX, trunk, number and jurisdiction path. Use an approved test procedure and retain a fallback for critical users. No client, beta, browser, PBX, account, QR code, SSO path, migration, tunnel, certificate, media protection, push service, device, emergency route, compatibility, availability, price, audio result or live call was tested for this guide.

Diagnose a mobile subscription that crossed its versioned lifetime

When a 3CX mobile app stops receiving calls after an extended offline period, use the push-subscription expiry diagnostic. It preserves the installed PBX update lane, last app connection, seven- or fourteen-day boundary, PBX push record, device permission state and fresh-QR re-enrollment as separate evidence.