Розробка мобільного дейтинг-додатку: технічні виклики та рішення

Розробка мобільного дейтинг-додатку: технічні виклики та рішення

Найчастіша помилка стартапів — вважати свайп-механіку головною складністю. Справжні граблі лежать в інших шарах: матчинг, 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) з відправкою на сервер тільки при зміні району.

Як монетизувати дейтинг-додаток?

Дейтинг-додатки монетизуються підпискою (аналог 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.

Як проходить розробка мобільного дейтинг-додатку?

1. Аудит вимог та аналіз конкурентів
2. Проектування схеми даних та API (алгоритм матчингу)
3. UX/UI дизайн
4. Розробка ядра (фід + чат + профіль)
5. Інтеграція монетизації та модерації
6. Навантажувальне тестування чату (Gatling / k6)
7. TestFlight / Firebase App Distribution
8. Публікація та підтримка

Що входить у нашу роботу

• Технічна документація (архітектура, API специфікації)
• Доступ до репозиторію з вихідним кодом
• Налаштування CI/CD (GitHub Actions / Bitrise)
• Навчання команди замовника роботі з адмін-панеллю
• Гарантійна підтримка 3 місяці після запуску

Орієнтири за термінами

Зв'яжіться з нами для безкоштовної оцінки вашого проєкту. Замовте консультацію прямо зараз.

Монетизація мобільних додатків: IAP, підписки та рекламна медіація

Додаток з погано реалізованими покупками втрачає гроші не тому що користувачі не хочуть платити, а тому що StoreKit транзакція зависає, Receipt Validation падає з помилкою або restore purchases не працює — і користувач пише в підтримку або залишає 1 зірку. Наш досвід (більше 7 років у мобільній розробці) показує, що грамотна монетизація збільшує LTV на 30–60% вже в перші три місяці після впровадження. Отримайте консультацію з монетизації вашого додатка — проаналізуємо поточну модель і знайдемо точки зростання.

Чому StoreKit 2 — найкращий вибір для IAP?

StoreKit 2 (iOS 15+) — сучасний API з async/await та верифікованими транзакціями на стороні пристрою без сервера. Transaction.currentEntitlements повертає всі активні покупки. Ключова зміна порівняно з StoreKit 1: верифікація JWS-підпису на пристрої через VerificationResult<Transaction> — не потрібно надсилати receipt на сервер для базової перевірки.

Але сервер-сайд валідація все одно потрібна для consumable покупок та проти fraud. App Store Server API замінює старий /verifyReceipt endpoint. Вебхуки через App Store Server Notifications v2 дають real-time події: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без поллінгу.

Типова помилка: не обробляють paymentQueue(_:updatedTransactions:) у фоні для незавершених транзакцій. Користувач купив consumable, додаток впав до finishTransaction — покупка висить у черзі, при наступному запуску відновлюється та вимагає повторної обробки на сервері. Без ідемпотентності сервера — подвійне нарахування.

Як не втратити дохід на підписках?

Підписочна модель вимагає відстеження станів: тріал → активна → grace period → expired → refunded. RevenueCat — фактичний стандарт для керування підписками в продакшні. Абстрагує StoreKit та Google Play Billing, дає unified API, webhooks, аналітику когорт та A/B тести paywall.

Альтернатива RevenueCat — власна реалізація з Adapty або Qonversion. Повністю кастомна — тільки якщо дані не повинні залишати інфраструктуру або є нестандартна логіка. Ми гарантуємо, що налаштування webhooks та обробка подій життя підписки виконується без втрат — перевірено на проектах з аудиторією понад 500 тис. DAU.

Google Play Billing Library 6+ вимагає обробки PurchasesUpdatedListener та явного виклику acknowledgePurchase() або consumePurchase() протягом 3 днів — інакше Google автоматично скасовує покупку та повертає гроші. Середня вартість такої помилки — втрата значної суми на користувача на місяць (за даними наших проектів).

Рекламна медіація: підвищення CPM через bidding

Показувати рекламу через одне джерело — означає втрачати дохід. Медіація (waterfall або bidding) запитує рекламу у декількох мереж і показує найкращу ставку. Google AdMob — основа для banner, interstitial, rewarded. Медіація через AdMob Mediation або MAX (AppLovin) — другий де-факто стандарт. MAX використовує In-App Bidding — real-time аукціон без водоспаду. На практиці MAX дає CPM на 15-30% вище класичного waterfall (залежить від гео та аудиторії). У США для rewarded відео CPM може перевищувати певну суму. При 100 000 показів rewarded відео на день перехід з waterfall на In-App Bidding може приносити додатково значну суму щоденно.

ironSource (Unity Ads) — сильна позиція в ігровому сегменті, особливо rewarded video. Mintegral — добре закриває азійську аудиторію.

Налаштування медіації вимагає ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламний CPM падає в 3-5 разів для користувачів, які не погодилися. SKAdNetwork та Privacy Manifest (iOS 17) — обов'язкові вимоги, без яких рев'ю падає.

Як вибрати рекламні мережі для медіації?

Як ми впроваджуємо монетизацію: покроковий процес

1. Аудит поточної моделі — аналіз воронки, paywall, цінових тирів та виявлення вузьких місць.
2. Проектування моделі — вибір типу (subscription, consumable, non-consumable) та оптимізація цінових точок.
3. Інтеграція IAP — налаштування StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
4. Рекламна медіація — підключення 3-6 мереж, налаштування waterfall або In-App Bidding, тестування fill rate.
5. Аналітика та когорти — інтеграція RevenueCat, Amplitude або Firebase для відстеження LTV.
6. A/B тестування paywall — використання Remote Config для експериментів без релізу.
7. Запуск та моніторинг — 2 тижні безкоштовної підтримки після запуску, фікс багів по SLA 24 години.

Freemium: проектування моделі та paywall

Freemium працює коли межа між безкоштовним та платним проведена правильно. Занадто жорсткий paywall на старті — користувач видаляє. Занадто щедрий безкоштовний тир — немає стимулу платити.

Як проєктувати paywall для freemium?

Паттерн, який працює технічно: feature flags з сервера (Remote Config у Firebase або LaunchDarkly) керують доступом до фіч. Це дозволяє A/B тестувати paywall без релізу, змінювати умови тріалу, проводити акції.

Реалізація на рівні коду: EntitlementManager — єдина точка перевірки доступу до фіч, яка знає про статус підписки, флаги та промо. Жодних перевірок isPremium розкиданих по всьому коду. Досвід показує: такий підхід знижує кількість багів з paywall на 80% (підтверджено на 30+ проектах).

Обсяг робіт з монетизації

• Аудит поточної моделі — аналіз воронки, paywall, цінових тирів.
• Інтеграція IAP — StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
• Рекламна медіація — налаштування MAX / AdMob, підключення 3-6 мереж, тестування fill rate.
• Налаштування аналітики — RevenueCat, Amplitude / Firebase, когортний аналіз.
• Документація — опис ентайтлментів, процедура відновлення, чек-лист рев'ю.
• Навчання команди — розбір типових помилок, рекомендації з підтримки.
• Гарантія — безкоштовна підтримка 2 тижні після запуску, фікс багів по SLA 24 години.

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

Вартість розраховується індивідуально. Ми працюємо в цій сфері більше 8 років і реалізували більше 40 проектів з монетизацією — багато з них пройшли App Store Review без жодного блокування. Зв'яжіться з нами для аудиту або замовте консультацію — розповімо, які точки зростання є у вашому додатку.

Джерела: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.