Розробка мобільного застосунку для дейтінгу
Дейтинг-застосунок — один з найбільш технічно перегромаджених типів мобільних продуктів. Не тому що «складно», а тому що в ньому одночасно сходяться: real-time чат, геолокація, медіа-обробка, агресивна монетизація, модерація контенту та вимоги до приватності. Провалити будь-який з цих шарів — потерять користувачів.
Свайп-механіка — не проблема. Проблеми в іншому
Swipe-карточки реалізуються за день. Настоящі грабли починаються дальше.
Алгоритм матчінгу та фід. Користувач очікує свіжі карточки при кожному відкритті. Якщо фід формується повільно (складні geo-запити до PostGIS без індексу, або ранжування без кеша) — перший екран грузиться 3–5 секунд. На iOS це UICollectionView з prefetch через UICollectionViewDataSourcePrefetching, але якщо API відає карточки пакетами по 10 з затримкою 2 секунди, prefetch не спасає. Рішення — серверний кеш pre-built фідів по геосегментам + клієнтський буфер (завжди тримаємо 20+ карточок у черзі).
Real-time чат. WebSocket (Socket.IO або нативний URLSessionWebSocketTask / OkHttp WebSocket) з переподключенням при втраті мережі. Головна проблема — дублі сообщений: користувач натиснув «відправити», мережа упала, сообщение дійшло до сервера, але ack не повернувся. Клієнт ретрайт — сервер вставляет другий раз. Вирішується через idempotency_key (client-generated UUID) на кожне сообщение: сервер ігнорує повтор з тим же ключем. Локальне зберіганння історії — Core Data (iOS) / Room (Android) з синхронізацією при восстановленню соединення.
Завантаження та обробка фото профілю. Користувач вибирает фото з галереї — застосунок повинен показати превью миттєво, завантажити у 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 користувач видит спиннер та не може продовжити користування застосунком.
Модерація. Фото профілю неможна показувати немодерованим. Стандартна схема: upload → Google Cloud Vision Safe Search або AWS Rekognition → автоматичний approve/reject → ручна очередь для пограничних випадків. Статус фото (pending / approved / rejected) відображається у UI — користувач видит, що фото на перевірці.
Геолокація та приватність
Показувати точні координати неможна — користувачи скривають місце проживання. Стандарт галузі: 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) з відправкою на сервер тільки при смені району, не кожні N хвилин.
Монетизація
Дейтинг-застосунки монетизуються кількома шарами: підписка (Tinder Gold аналог) через StoreKit 2 / Google Play Billing Library 6+, in-app покупки разових «суперлайків» або «бустів», та іноді рекламна модель для безплатних користувачів.
SK2 subscription на iOS: Product.products(for:) → product.purchase() → Transaction.currentEntitlements для валідації. Серверна валідація чека через App Store Server API (JWT-авторизація, /inApps/v1/subscriptions/{transactionId}) обов'язкова — клієнтська валідація недостатня для premium-функцій.
Для кросс-платформенного управління підписками (iOS + Android) RevenueCat SDK зручен — він абстрагує StoreKit та Play Billing, зберігает entitlements на своєму сервері та спрощує A/B тести paywall.
Стек та архітектура
Нативна розробка (Swift + Kotlin) дає максимум по продуктивності анімацій карточок та роботи з камерою. Flutter оправданий при жорсткому обмеженню бюджету на одну команду.
На iOS: UIKit + SwiftUI гібрід (карточки — UIKit для точного контролю жестів, решта — SwiftUI), Combine/async-await, Core Data. На Android: Jetpack Compose, Coroutines + Flow, Room, Hilt.
Архітектура: Clean Architecture + MVVM. MatchRepository, ChatRepository, ProfileRepository — кожен зі своїм кешем та стратегією інвалідації. Окремий PresenceService — WebSocket соединение зі станом online/offline собеседника.
Процес роботи
Аудит вимог та аналіз конкурентів → проектування схеми даних та API (включаючи алгоритм матчінгу) → UX/UI дизайн → розробка ядра (фід + чат + профіль) → інтеграція монетизації та модерації → нагрузкове тестування чата (Gatling / k6) → TestFlight/Firebase App Distribution → публікація → підтримка.
Ориентири по терміних
MVP (фід карточок, лайки/дизлайки, матчи, базовий чат, профіль з фото): 6–10 тижнів на один платформ. Полнофункціональний продукт з підпискою, геолокаційним фідом, модерацією, push-сповіщеннями та підтримкою iOS + Android: 3–5 місяців. Кастомний алгоритм ранжування на основі поведінки користувачів добавляет ще місяц.