QuickBlox integration for chat, video and push in mobile and web apps

QuickBlox suits products that need communication features without building them from scratch:

• You need chat, video and push notifications from one backend and one SDK family across iOS, Android, web, React Native and Flutter.
• One QuickBlox application can be shared by all your platforms.
• Your calls are one-to-one or small groups, or you can use the separate video conference module for larger ones.
• You need a hosting choice. QuickBlox lists a managed cloud, a private cloud on your own provider, and on-premise.

Check these before you commit:

• Large group video. QuickBlox advises its standard calling module for groups of four or fewer, because every participant connects to every other. Larger calls use the video conference module, which its documentation marks as an Enterprise-plan feature.
• Push as the main way to deliver messages. Push goes to a device when it is fully offline, and the app is expected to stay connected to chat.
• A platform that a module does not list. Not every module is on every SDK, so confirm coverage first.
• Self-hosting without talking to the vendor. Details of the on-premise package come from QuickBlox sales.

QuickBlox's documentation describes modules for users, chat, video, push notifications, content storage, custom objects and an address book. Chat covers private, group and public conversations with message history, presence, delivery and read receipts, typing indicators, attachments, offline messages and user blocking. Video calling uses WebRTC for one-to-one calls and small groups, with screen sharing, and a separate video conference module serves larger groups. Push notifications can be instant, scheduled, recurring or aimed at tagged users, through the Apple and Google push services. Users can sign in with standard, social, phone-number or custom identity provider logins. SDKs cover iOS, Android, JavaScript, React Native and Flutter, plus a server API.

• Sessions: session tokens expire after a period of inactivity, and there are separate application sessions (read-only) and user sessions (read and write). We build token refresh.
• Secrets: QuickBlox recommends its authorization key and secret for client code during development and API keys for server-side code. We keep secrets out of shipped apps.
• Clock and replay checks: session creation uses a timestamp that must be close to real time and a nonce that cannot repeat, so a wrong device clock or reused request is rejected.
• Push per platform: iOS needs an Apple push certificate uploaded in the dashboard, and VoIP push uses a separate subscription. Android needs the Firebase Cloud Messaging key set for development and production. A user can have several subscriptions and must re-subscribe when a device token changes.
• Video connections: signalling for calls runs through the chat connection, so chat must be connected first, and STUN or TURN servers help find a route between devices.
• SDK updates: we pin versions and read the changelog before upgrading.

1. Decide which modules you need: chat, video, push and storage have different limits and plans
2. Prototype the hardest call first: a real group call or a push to a closed app, on real devices
3. Set up push per platform early: certificates and keys are the usual cause of late surprises
4. Hand over properly: the QuickBlox application settings documented, the SDK versions pinned, and notes on session and push handling

Technology facts on this page are taken from the official documentation:

• QuickBlox documentation: introduction
• QuickBlox documentation: key concepts
• QuickBlox API reference: create session
• QuickBlox: hosting options