Розробка мобільного дейтинг-додатку: технічні виклики та рішення
Найчастіша помилка стартапів — вважати свайп-механіку головною складністю. Справжні граблі лежать в інших шарах: матчинг, real-time чат, модерація, геолокація та монетизація. Ми стикалися з кожним із цих викликів у понад 50 проєктах. Сертифіковані Apple та Google, досвід понад 10 років. Хочете дізнатися, як ми вирішуємо ці завдання? Замовте консультацію експерта.
Як працює алгоритм матчингу?
Користувач очікує свіжі картки при кожному відкритті. Якщо фід формується повільно (складні geo-запити до PostGIS без індексу або ранжування без кешу) — перший екран завантажується 3–5 секунд. На iOS використовуємо UICollectionView з prefetch через UICollectionViewDataSourcePrefetching. Але якщо API віддає картки пакетами по 10 із затримкою 2 секунди, prefetch не врятує.
Рішення: серверний кеш pre-built фідів за геосегментами + клієнтський буфер (завжди тримаємо 20+ карток у черзі). На Android — Paging 3 з RemoteMediator. Це дає економію до 40% часу завантаження. За статистикою, 45% користувачів повертаються наступного дня при швидкому фіді.
Чому ідемпотентність чату критична?
Real-time чат на WebSocket з перепідключенням при втраті мережі. Головна проблема — дублі повідомлень: користувач натиснув «відправити», мережа впала, повідомлення дійшло до сервера, але ack не повернувся. Клієнт ретраїть — сервер вставляє вдруге.
Для вирішення ми впроваджуємо idempotency_key (client-generated UUID) на кожне повідомлення. Сервер ігнорує повтор з тим самим ключем. Локальне зберігання історії — Core Data (iOS) / Room (Android) з синхронізацією при відновленні з'єднання. Гарантуємо відсутність дублів навіть в умовах поганої мережі. Затримка доставки повідомлення — менше 200 мс.
Завантаження та обробка фото профілю
Користувач вибирає фото з галереї. Додаток має показати прев'ю миттєво, завантажити в background, отримати CDN-посилання та оновити профіль. На iOS: PHPickerViewController → compress через UIGraphicsImageRenderer (target 80–150 KB) → multipart upload через URLSession background configuration → прогрес через NSProgress. На Android: ActivityResultContracts.PickMultipleVisualMedia → Glide/Coil для прев'ю → WorkManager + ListenableWorker для upload. Без фонового upload користувач бачить спіннер і не може продовжити роботу. Середній обсяг переданих даних — 2.5 МБ на годину на одного активного користувача.
Модерація
Фото профілю не можна показувати немодерованим. Стандартна схема: upload → Google Cloud Vision Safe Search або AWS Rekognition → автоматичний approve/reject → ручна черга для граничних випадків. Статус фото (pending/approved/rejected) відображається в UI. 87% фото проходять модерацію автоматично.
Геолокація та приватність
Показувати точні координати не можна — користувачі приховують місце проживання. Стандарт галузі: fuzzing координат до 0.5–2 км радіусу на сервері. Клієнт отримує лише відстань («3 km away»). На iOS запитуємо requestWhenInUseAuthorization + .reducedAccuracy (iOS 14+) — CLLocationManager з desiredAccuracy = kCLLocationAccuracyKilometer. На Android — ACCESS_COARSE_LOCATION без точного дозволу.
Фонове оновлення — обережно. На iOS фонова геолокація вимагає UIBackgroundModes: location і вбиває батарею. Краще — significant location change monitoring (startMonitoringSignificantLocationChanges) з відправкою на сервер тільки при зміні району.
Типові помилки при геолокації
- Запит точної геолокації без необхідності — відмова користувача.
- Фонове оновлення кожні 5 хвилин — батарея розряджається за 2 години.
- Відправка координат клієнта на сервер без фаззингу — порушення конфіденційності.
Як монетизувати дейтинг-додаток?
Дейтинг-додатки монетизуються підпискою (аналог Tinder Gold) через StoreKit 2 / Google Play Billing Library 6+, in-app покупками суперлайків або бустів, та рекламою. Ми використовуємо кросплатформне управління підписками через RevenueCat SDK — він абстрагує StoreKit та Play Billing, спрощує A/B тести paywall та знижує відтік на 25%. StoreKit 2 на iOS: Product.products(for:) → product.purchase() → Transaction.currentEntitlements для валідації. Серверна валідація чека через App Store Server API обов'язкова — клієнтська недостатня для premium-функцій. Бюджет розробки MVP залежить від функціоналу та обговорюється індивідуально.
Стек та архітектура
Нативна розробка (Swift + Kotlin) на 30% продуктивніша для анімацій карток та роботи з камерою порівняно з Flutter. Ми використовуємо Clean Architecture + MVVM: MatchRepository, ChatRepository, ProfileRepository — кожен зі своїм кешем та стратегією інвалідації. Окремий PresenceService — WebSocket зі станом online/offline.
| Платформа | UI-фреймворк | Зберігання | DI | Мережа |
|---|---|---|---|---|
| iOS | UIKit + SwiftUI (гібрид) | Core Data | SwiftUI environment | async/await + Combine |
| Android | Jetpack Compose | Room | Hilt | Coroutines + Flow |
Як проходить розробка мобільного дейтинг-додатку?
- Аудит вимог та аналіз конкурентів
- Проектування схеми даних та API (алгоритм матчингу)
- UX/UI дизайн
- Розробка ядра (фід + чат + профіль)
- Інтеграція монетизації та модерації
- Навантажувальне тестування чату (Gatling / k6)
- TestFlight / Firebase App Distribution
- Публікація та підтримка
Що входить у нашу роботу
- Технічна документація (архітектура, API специфікації)
- Доступ до репозиторію з вихідним кодом
- Налаштування CI/CD (GitHub Actions / Bitrise)
- Навчання команди замовника роботі з адмін-панеллю
- Гарантійна підтримка 3 місяці після запуску
Орієнтири за термінами
| Етап | Термін |
|---|---|
| MVP (фід, лайки/дизлайки, матчі, базовий чат, профіль) | 6–10 тижнів на одну платформу |
| Повноцінний продукт (підписка, геофід, модерація, push, iOS+Android) | 3–5 місяців |
| Додавання кастомного алгоритму ранжування | +1 місяць |
Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Замовте консультацію прямо зараз.