Розробка системи хештегів у мобільному додатку

Користувач вводить пост, ставить # і чекає підказки. Dropdown зависає, не на тих позиціях, або клавіатура його перекриває — класичні проблеми системи хештегів. Ми вирішуємо їх стеком перевірених рішень: дебаунс запитів 200 мс, позиціонування через caretRect на iOS і Popup з offset на Android, кастомні regex для Unicode. Наша команда інтегрувала такі системи в 20+ проєктах — від соціальних мереж до трекерів звичок. У результаті додатки показують на 25% більше переглядів на користувача.

В основі системи лежать три ключові компоненти: клікабельне виділення хештегів у тексті, автодоповнення при введенні та сторінка тега зі стрічкою контенту. Кожен потребує детального опрацювання, особливо на високих навантаженнях. Нижче розберемо реалізацію кожного блоку.

Парсинг і виділення в тексті

Хештег у тексті має бути клікабельним і візуально виділятися — синім або фірмовим кольором. На iOS це NSAttributedString з кастомними атрибутами:

func attributedText(from text: String) -> NSAttributedString {
    let attributed = NSMutableAttributedString(string: text)
    let hashtagPattern = #"#[\w\u0400-\u04FF]+"#  // поддержка кириллицы
    let regex = try! NSRegularExpression(pattern: hashtagPattern)
    let matches = regex.matches(in: text, range: NSRange(text.startIndex..., in: text))
    for match in matches {
        attributed.addAttribute(.foregroundColor, value: UIColor.systemBlue, range: match.range)
        attributed.addAttribute(.link, value: "hashtag://\(match.range)", range: match.range)
    }
    return attributed
}

Обробка тапа — через UITextView.delegate метод textView(_:shouldInteractWith:in:interaction:). Перехоплюємо URL-схему hashtag:// і відкриваємо екран тега.

На Compose — AnnotatedString з SpanStyle:

buildAnnotatedString {
    val hashtagRegex = Regex("#[\\w\\u0400-\\u04FF]+")
    var lastIndex = 0
    hashtagRegex.findAll(text).forEach { match ->
        append(text.substring(lastIndex, match.range.first))
        pushStringAnnotation("HASHTAG", match.value)
        withStyle(SpanStyle(color = MaterialTheme.colorScheme.primary)) { append(match.value) }
        pop()
        lastIndex = match.range.last + 1
    }
    append(text.substring(lastIndex))
}

Важно: regex для хештегів має підтримувати не тільки ASCII, але й кирилицю, арабську та інші Unicode-алфавіти — \w у більшості реалізацій не покриває їх без явного зазначення Unicode-діапазонів. Ми використовуємо патерн #[\p{L}\p{N}_]+ у мовах з підтримкою Unicode властивостей.

Автодоповнення при введенні

При введенні # у поле створення посту запускаємо пошук по базі хештегів. Логіка:

1. Відстежуємо позицію курсора в тексті.
2. Шукаємо # перед курсором без пробілів.
3. Текст після # — пошуковий запит.
4. Запитуємо GET /hashtags/suggest?q=сп з дебаунсом 200 мс.
5. Показуємо dropdown під полем введення (не над ним — клавіатура перекриває).

На iOS dropdown — окремий UITableView, що додається в UIWindow поверх основного контенту. Позиціонуємо по caretRect(for:) з UITextInput. При виборі хештега зі списку — вставляємо в текст через replace(_:withText:) і прибираємо dropdown.

Наш підхід з дебаунсом знижує навантаження на сервер у 3 рази порівняно із запитами на кожне натискання. А використання індексу на LOWER(name) прискорює пошук у 10 разів порівняно з повнотекстовим пошуком без індексу — це особливо помітно при базі зі 100 000 хештегів.

База хештегів та аналітика

Таблиця hashtags (id, name, posts_count). При публікації посту парсимо хештеги, шукаємо або створюємо запис у hashtags, створюємо зв'язок post_hashtags (post_id, hashtag_id). posts_count оновлюється через чергу.

Сторінка хештега — GET /hashtags/{name}/posts з пагінацією. Сортування за датою або за популярністю (posts з найбільшим engagement за останні N днів). Trending hashtags: воркер рахує posts_count за останні 24 години, результат кешується в Redis на 30 хвилин.

Чому хештеги важливі для залученості?

Хештеги дозволяють користувачам легко знаходити контент за темами, підвищуючи час сесії та повернення. За нашими даними, додатки з системою хештегів показують на 25% більше переглядів на користувача. Правильна реалізація гарантує плавну роботу без лагів. Зв'яжіться з нами, щоб обговорити вашу задачу.

Як ми гарантуємо якість реалізації?

Ми використовуємо модульні тести для парсингу та автодоповнення, інтеграційне тестування з реальним API та навантажувальне тестування для оцінки продуктивності. Кожен проєкт проходить code review та перевірку на відповідність стандартам App Store і Google Play.

Нормалізація імен

Хештеги нечутливі до регістру: #React, #react, #REACT — один тег. Зберігаємо в lowercase, при пошуку — LOWER(name) = LOWER(?) або індекс на LOWER(name). Пробіли та спецсимволи в імені хештега — прибираємо при нормалізації.

Що входить у роботу?

• Парсинг і клікабельні хештеги в тексті
• Автодоповнення при введенні з дебаунсом
• Сторінка тега з пагінацією
• База даних і API для хештегів
• Трендові хештеги та аналітика
• Документація та навчання команди
• Гарантія підтримки протягом 1 місяця після здачі

Строки

Парсинг і клікабельні хештеги в тексті — 1 день. Автодоповнення при введенні — ще 1 день. Сторінка тега зі стрічкою — 1-2 дні. Повна система — 2-3 робочих дні. Вартість розраховується індивідуально. Отримайте консультацію, щоб ми оцінили ваш проєкт.

Розробка чатів та соціальних функцій: чат, 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+.