Розробка мобільного застосунку для коучингу під ключ

Розробка мобільного застосунку для коучингу

Уявіть: коуч витрачає 20% часу на ручне узгодження часу з клієнтами через месенджери. Кожна сесія — листування, нагадування, перенесення. Клієнти забувають оплатити, а коуч втрачає дохід. Коучинговий застосунок вирішує ці проблеми автоматизацією: бронювання, оплата, щоденник, трекер звичок — усе в одному місці. Але реалізація складніша, ніж здається: потрібно врахувати безпеку даних, часові пояси, гнучкі сценарії оплати. Ми розробили десятки коучингових застосунків за 5+ років і знаємо, як уникнути типових помилок. У цій статті розберемо ключові модулі: від колеса балансу до push-сповіщень. Покажемо, як реалізувати гнучке бронювання з урахуванням тайм-зон, і чому Stripe часто вигідніше вбудованих покупок Apple — економія на комісіях досягає 27%.

Бронювання сесій: гнучкий редактор доступності

Інтеграція з Calendly або власний booking flow. Власна реалізація — time_slots таблиця, аналогічно менторингу. Різниця: коучі часто працюють за строгим розкладом (наприклад, лише по вівторках 10:00–18:00), і потрібен гнучкий редактор доступності.

Редактор доступності коуча — шаблон по днях тижня + виключення. RecurringSchedule модель: dayOfWeek, startTime, endTime. Виключення (відпустка, свята) — blocked_dates. При бронюванні — обчислюємо доступні слоти на найближчі N тижнів з урахуванням зайнятих і заблокованих.

Часові пояси — обов'язково. Коуч у Москві, клієнт у Лондоні. Усі слоти зберігаються в UTC, конвертуються в локальний час на клієнті. TimeZone.current (iOS) / ZoneId.systemDefault() (Android) для визначення зони пристрою. DateComponentsFormatter для людиночитаного відображення "через 2 години".

Вибір між Calendly і власною розробкою: Calendly дає швидкий старт і готовий UI, але обмежує кастомізацію та вимагає оплати API. Власний booking flow потребує 1–2 тижнів розробки backend, але дає повний контроль над дизайном і логікою — наприклад, можна додати кастомні правила доступності або інтеграцію з CRM. Для проектів з унікальними вимогами другий варіант окупається гнучкістю.

Інструменти коучингу в застосунку

Колесо балансу — кругова діаграма по 8–12 сферах життя (кар'єра, здоров'я, стосунки, фінанси тощо). Клієнт оцінює кожну сферу за шкалою 1–10. Малюємо через Core Graphics / Canvas в Compose: UIBezierPath для секторів на iOS, Path в Compose на Android. Анімація при зміні оцінок — withAnimation (SwiftUI) / animateFloatAsState (Compose).

Історія коліс балансу — показуємо зміни за місяць/квартал. Два накладені колеса (поточне і минуле) — прозорість через UIColor.withAlphaComponent().

Щоденник прогресу — щоденні/щотижневі записи клієнта. Markdown або rich text через UITextView з кастомним тулбаром для жирного/курсиву. Зберігаємо локально (Core Data / Room) + синхронізація з сервером. Коуч бачить записи лише якщо клієнт явно поділився — через toggle в налаштуваннях.

Рефлексивні запитання — коуч створює шаблони запитань для домашніх завдань. Клієнт відповідає в застосунку. Запитання + форматований текстовий відповідь + можливість прикріпити голосову нотатку (через AVAudioRecorder).

Трекер звичок — простий чеклист звичок на день. UITableView з UISwitch або Compose Checkbox. Streak — серія днів поспіль, мотивуючий елемент. Calendar.current.dateComponents([.day], from:to:) для підрахунку стріка.

Як реалізувати безпечне зберігання згоди на запис сесії?

Відеосесія — вбудована (100ms, Daily.co) або зовнішнє посилання. Після сесії — поле для конспекту від коуча (основні інсайти, наступні кроки). Клієнт отримує сповіщення, що конспект додано.

Аудіозапис сесії (з згоди клієнта) — AVCaptureSession з AVCaptureAudioDataOutput. Записуємо в M4A, завантажуємо на сервер. Зберігання згоди на запис — окремий consent флаг з timestamp у базі.

Транскрипція аудіо — SFSpeechRecognizer (iOS, offline на пристрої для підтримуваних мов) або OpenAI Whisper API через сервер для точності та багатомовності.

Чому для коучингових застосунків частіше обирають Stripe, а не App Store?

Stripe PaymentSheet для одноразових сесій і Stripe Billing для пакетів. iOS App Store підписки (StoreKit 2) тільки якщо коучинг продається як "контент всередині застосунку" — але більшість коучингових застосунків працюють через Stripe (веб-форма оплати) без IAP. Пакет 10 сесій — Product з type: .nonConsumable у StoreKit (використано 1 раз, не відновлюється при видаленні застосунку). Або пакет як підписка з обмеженим терміном використання.

Порівняння підходів до платежів:

Stripe обходиться дешевше в 5–10 разів при типових обсягах продажів сесій.

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

• Технічне завдання та прототип UI/UX
• Розробка backend (REST/GraphQL) + клієнт (iOS/Android)
• Інтеграція платежів (Stripe / StoreKit)
• Публікація в App Store і Google Play
• Документація по API та адмініструванню (Swift Package Manager для залежностей, Fastlane для CI/CD)
• Передача доступів і навчання команди
• Гарантійна підтримка 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+.