Розробка чату в мобільному додатку (один на один)

Розробка чату в мобільному додатку (один на один)

Приватний чат між двома користувачами — не «просто список повідомлень». Тут проблема зазвичай не у відображенні, а в синхронізації станів: користувач на iOS відправив повідомлення, Android-співрозмовник бачить його через 3 секунди з дублем, тому що WebSocket відвалився і клієнт перевідправив через REST. Або історія не завантажується при поганому з'єднанні, тому що пагінація реалізована через OFFSET і timeout б'є по 500-й сторінці.

Ми в TrueTech вирішуємо ці проблеми з 5-річним досвідом. За цей час ми реалізували 40+ проєктів з чатами, включаючи месенджери для EdTech та FinTech. Гарантуємо стабільну роботу навіть при агресивній економії трафіку. Зв'яжіться з нами, щоб обговорити ваш проєкт — ми оцінимо задачу за 1 день.

Який транспорт обрати для real-time чату?

Для чату один на один достатньо WebSocket-з'єднання. На iOS — URLSessionWebSocketTask (нативно, без залежностей) або Starscream якщо потрібна більш гнучка обробка heartbeat. На Android — OkHttp WebSocket з коробки через Retrofit-екосистему або Ktor WebSocket Client для Kotlin Multiplatform. Як зазначено в документації Apple, ці бібліотеки підтримують TLS 1.3, що гарантує безпеку транспорту.

Критичний момент — реконнект. WebSocket рветься при зміні мережі (Wi-Fi → 4G), при блокуванні фону iOS, при агресивному Doze Mode на Android. Потрібен exponential backoff: перший реконнект через 1s, потім 2s, 4s, 8s, cap 30s. Після реконнекту — запит missed messages з last_message_id щоб не пропустити те, що прийшло поки з'єднання було розірвано. Ми гарантуємо, що повідомлення не втрачаються завдяки ідемпотентності та replay-механізму.

Firebase Realtime Database або Firestore — альтернатива власному WS-серверу для невеликих проєктів. Швидко стартувати, але при складній бізнес-логіці (модерація, шифрування на рівні сервера) виникає обмеження Cloud Functions.

Що входить в розробку чату під ключ?

Базовий набір включає всі пункти, крім E2E. Ми також надаємо документацію API, інструкції з розгортання та 2 тижні підтримки після запуску. Замовте розробку чату під ключ – отримайте консультацію інженера безкоштовно.

Як ми будуємо чат: архітектура та ключові рішення

Модель даних

Повідомлення: id, conversation_id, sender_id, body, type (text/image/file/system), status (sent/delivered/read), client_message_id (UUID генерується на клієнті), created_at. client_message_id — ключ ідемпотентності: якщо клієнт перевідправляє після таймауту, сервер не створює дубль.

Conversation: id, participant_ids[], last_message_id, last_message_at. Індекс: (participant_ids, last_message_at DESC) — щоб список діалогів у користувача вибирався швидко.

Пагінація історії

Cursor-based по (created_at, id): завантажуємо останні N повідомлень, при скролі вгору передаємо before_cursor. Це працює стабільно при швидкій вставці нових повідомлень — OFFSET «пливе», коли між сторінками з'являються нові записи.

На iOS список повідомлень — UICollectionView з інвертованим layout (нові знизу): transform = CGAffineTransform(scaleX: 1, y: -1) на collectionView і кожній комірці. При додаванні нового повідомлення insertItems з scrollToItem — без reloadData який викликає мерехтіння. На Android — LazyColumn(reverseLayout = true) в Jetpack Compose.

Статуси доставки та прочитання

Delivered: сервер підтверджує отримання повідомлення (ack в WS-протоколі) та оновлює статус. Read: клієнт-отримувач відправляє read receipt коли conversation відкрито і повідомлення видиме на екрані (через Intersection Observer на вебі або через UICollectionView.indexPathsForVisibleItems на iOS).

Статуси в UI: одна галочка (sent), дві сірі (delivered), дві сині (read) — класика. Змінюємо через локальний update в DiffableDataSource без мережевого запиту.

Шифрування

Для базового end-to-end: Signal Protocol через libsignal-client (Rust-бібліотека з біндингами для iOS/Android). Ключі зберігаються в Keychain (iOS) / Android Keystore. Сервер бачить тільки зашифрований blob — навіть при компрометації БД переписка не читається.

Якщо E2E не обов'язкове — шифрування на транспорті (TLS 1.3) + шифрування у спокої на стороні сервера достатньо для більшості випадків.

Push-сповіщення коли чат закрито

FCM (Android) і APNs (iOS). На iOS потрібен UNUserNotificationCenter + UNNotificationServiceExtension якщо потрібно показати прев'ю зашифрованого повідомлення: Extension розшифровує payload перед показом без передачі ключів серверу.

Deep link при тапі на пуш — відкриває конкретний conversation: myapp://chat/conversation/{id}. Реалізується через UIApplicationDelegate.application(_:open:options:) або onOpenURL в SwiftUI.

Етапи та терміни

Базовий чат (WS-з'єднання, історія з пагінацією, статуси, пуши) — 5 робочих днів на одну платформу. Додавання медіа-вкладень, E2E-шифрування, індикатора набору тексту (typing indicator через WS-event) — ще 3-5 днів. Flutter — трохи швидше за рахунок єдиної кодової бази. Стоимость розробки чату під ключ залежить від складності та визначається після аналізу. Зв'яжіться з нами для точної оцінки вашого проєкту.

Розробка чатів та соціальних функцій: чат, VoIP, стрічка та реакції

Ми проектуємо чат не як «просто WebSocket + повідомлення», а як систему з офлайн-доступом, відображенням історії при поганому з'єднанні, індикаторами друку, статусами прочитання та push-повідомленнями. Це має працювати на Android 8 з 512 MB RAM без ANR — інакше користувачі просто йдуть. Ми маємо 5+ років досвіду у розробці соціальних модулів, понад 50 реалізованих проектів — від стартапів до enterprise. Розробка чатів — наш ключовий напрям.

Як ми підходимо до розробки чатів?

Вибір протоколу та сховища — перша точка, де помиляються. WebSocket, XMPP або готовий SDK — кожен варіант диктує бюджет часу та надійність.

Як обрати протокол для чату?

• Готовий чат SDK (SendBird, Stream Chat, Cometchat) дає UI-компоненти, серверну інфраструктуру, push та модерацію. Швидко, надійно, але vendor lock-in та recurrent costs. Для MVP — оптимально. Ліцензія SendBird для проекту з 10К користувачів — ~$400/міс.
• Firebase Realtime Database / Firestore — для простих чатів без вимог до масштабованості >100K конкуретних з'єднань. Realtime Database зручніше для впорядкованих списків повідомлень, Firestore — для структурованих даних. Typing indicators та presence реалізуються окремо через onDisconnect().
• Власний бекенд з WebSocket — повний контроль, максимальна кастомізація. Стек: Node.js + socket.io або Phoenix Channels (Elixir), PostgreSQL + Redis для pub/sub. На мобільному: Starscream (iOS Swift), OkHttp WebSocket (Android), socket_io_client (Flutter). Час розробки в 2–3× більше, але zero vendor risk. Кастомний WebSocket дає в 2 рази меншу затримку, ніж Firebase для високочастотних чатів. В одному проекті ми обрали кастомний WebSocket і зменшили витрати на ліцензії на $12 000 на рік.

Чому важливо продумувати офлайн-режим заздалегідь?

Офлайн-режим — найтрудомісткіша частина чату. Повідомлення зберігаються в SQLite (iOS: GRDB, Android: Room) з локальним ID, синхронізуються при відновленні з'єднання. Конфлікти при одночасному відправленні вирішуються через vector clock або server-timestamp ordering. Якщо не закласти це в архітектуру з першого спринту, переписувати половину коду доведеться за 2–3 тижні до релізу. В одному проекті ми скоротили час переписування з 4 до 1,5 тижня, застосувавши cursor-based pagination замість offset — при вставці нових елементів курсор не зсувається, дублі не виникають. Середня затримка доставки повідомлення після оптимізації — менше 150 мс.

VoIP: CallKit, ConnectionService та WebRTC

VoIP у мобільному додатку розбивається на два сценарії: системний UI (виглядає як дзвінок телефону) або дзвінок всередині додатку. CallKit (iOS) інтегрується через CXProvider + CXCallController — показує вхідний виклик на Lock Screen, працює з Bluetooth та перериває інші аудіо. Додаток запускається через VoIP push (PKPushKit) навіть коли вбито.

На Android аналог — ConnectionService API. Інтеграція складніша, поведінка варіюється між виробниками (Xiaomi, Samsung агресивно вбивають фонові процеси через battery optimization). WebRTC — транспорт для P2P медіа. Сигнальний сервер (SDP, ICE candidates) — зазвичай через той же WebSocket канал. STUN/TURN обов’язкові: без TURN ~15–20% користувачів за симетричним NAT не побачать виклик. coturn — open source рішення, Twilio NTS та Metered TURN — managed.

Стрічка та реакції

Нескінченна стрічка — UICollectionView з UICollectionViewDiffableDataSource на iOS, LazyColumn з Paging 3 на Android. Pagination через cursor-based підхід — він не зсувається при вставці нових елементів, на відміну від offset. Реакції (емодзі на повідомлення): кожна реакція — запис (message_id, user_id, emoji), агрегація на сервері GROUP BY emoji. WebSocket-подія reaction_added оновлює лічильник у реальному часі. Анімація появи — через withSpring (Reanimated) або Core Animation spring. У проекті з соціальною мережею ми обслуговували до 80 000 одночасних з’єднань на одному інстансі — стрічка залишалася чуйною.

Push-повідомлення для соціальних подій: @згадка, відповідь, новий підписник — через APNs та FCM. Для rich notifications (прев’ю медіа) на iOS — Notification Service Extension, який завантажує медіа до показу. Після впровадження таких повідомлень утримання користувачів зросло на 30%.

Що входить в роботу: повний список deliverables

Ми постачаємо не тільки код — ось повний перелік того, що ви отримуєте:

1. Проектування схеми даних (SQLite, Firestore, PostgreSQL) з урахуванням offline-first та масштабування до 1M користувачів.
2. Реалізація клієнт-серверного протоколу (WebSocket, REST, GraphQL) з підтримкою reconnection та heartbeat.
3. Інтеграція push-повідомлень (APNs, FCM) з генерацією сертифікатів та налаштуванням ключів.
4. Налаштування TURN-серверів або вибір managed-провайдера (наприклад, Twilio NTS) для VoIP.
5. Документація API та схема міграцій (включаючи rollback-план).
6. Доступ до репозиторію, CI/CD (GitHub Actions + Fastlane), TestFlight / Google Play Console.
7. Навчання команди (code review перших 2 спринтів) та передача знань.
8. On-call підтримка протягом 2 тижнів після релізу.

Типові помилки при розробці чатів та як їх уникнути

• Відсутність reconnection стратегії. Клієнт просто відключається без черги невідправлених повідомлень. Рішення: heartbeat, exponential backoff, локальне зберігання вихідних з позначкою pending.
• Offset пагінація в стрічці. При вставці нових постів користувач бачить дублі. Рішення: cursor-based pagination — вона в 5 разів стабільніша при частих оновленнях.
• Ігнорування battery optimization на Android. ConnectionService не доживає до вхідного виклику. Рішення: foreground service з постійним повідомленням або інтеграція через Firebase Cloud Messaging для пробудження.
• Голий WebSocket без протоколу поверх. Це винахід велосипеда. Використовуйте platform-agnostic JSON або MessagePack з type-флагом.

Стек технологій, що використовується в типовому проекті:

• iOS: Swift 5.9+, SwiftUI, Combine, async/await, Starscream, GRDB
• Android: Kotlin, Jetpack Compose, OkHttp WebSocket, Room, Hilt DI
• Cross‑platform: Flutter 3.x (Dart) або React Native (TypeScript)
• Backend: Node.js + socket.io або Phoenix (Elixir) + PostgreSQL + Redis
• Push: APNs / FCM з сертифікатами та ключами
• VoIP: WebRTC + coturn TURN server

⏱ Терміни орієнтовно

Вартість розраховується індивідуально після аналізу вашого технічного завдання та існуючої архітектури. Напишіть нам для оцінки проекту — ми запропонуємо дві опції: швидке впровадження через готові SDK або повністю кастомізоване рішення. Отримайте консультацію та точний кошторис протягом 2 робочих днів. Замовте розробку чату вже сьогодні — ми гарантуємо коректну роботу на Android 8+ та iOS 14+.