Монетизація мобільних додатків: IAP, підписки та рекламна медіація
Додаток з погано реалізованими покупками втрачає гроші не тому що користувачі не хочуть платити, а тому що StoreKit транзакція зависає, Receipt Validation падає з помилкою або restore purchases не працює — і користувач пише в підтримку або залишає 1 зірку.
In-App Purchases та StoreKit 2
StoreKit 2 (iOS 15+) — сучасний API з async/await та перевіреними транзакціями на стороні пристрою без сервера. Transaction.currentEntitlements повертає всі активні покупки. Ключова зміна порівняно зі StoreKit 1: верифікація JWS-підпису на пристрої через VerificationResult<Transaction> — не потрібно відправляти receipt на сервер для базової перевірки.
Але серверна валідація все одно потрібна для consumable покупок та захисту від fraud. App Store Server API замінює старий /verifyReceipt endpoint. Webhooks через App Store Server Notifications v2 дають real-time события: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без polling.
Типова помилка: не обробляють paymentQueue(_:updatedTransactions:) у фоні для незавершених транзакцій. Користувач купив consumable, додаток упав до finishTransaction — покупка висить в черзі, при наступному запуску відновлюється та вимагає повторної обробки на сервері. Без ідемпотентності сервера — подвійне нараховування.
Підписки: управління життєвим циклом
Підписочна модель вимагає відстеження станів: trial → active → grace period → expired → refunded. RevenueCat — фактичний стандарт для управління підписками в продакшні. Абстрагує StoreKit та Google Play Billing, дає unified API, webhooks, аналітику когорт та A/B тести paywall.
Альтернатива RevenueCat — власна реалізація з Adapty або Qonversion. Повністю кастомна — тільки якщо є причини (дані не повинні покидати інфраструктуру, нестандартна логіка).
Google Play Billing Library 6+ вимагає обробки PurchasesUpdatedListener та явного виклику acknowledgePurchase() або consumePurchase() протягом 3 днів — інакше Google автоматично скасовує покупку та повертає гроші.
Рекламна медіація
Показувати рекламу через один джерело — означає втрачати дохід. Медіація (waterfall або bidding) запитує рекламу у кількох мереж та показує найкращу ставку.
Google AdMob — основа: banner, interstitial, rewarded. Медіація через AdMob Mediation або MAX (AppLovin) — другий de facto стандарт. MAX використовує In-App Bidding — real-time аукціон без водопаду. На практиці MAX дає CPM на 15-30% вище за класичний waterfall (залежить від географії та аудиторії).
ironSource (Unity Ads) — сильна позиція в ігровому сегменті, особливо rewarded video. Mintegral — добре покриває азіатську аудиторію.
Налаштування медіації вимагає ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламний CPM падає в 3-5 разів для користувачів, які не дали дозвіл. SKAdNetwork та Privacy Manifest (iOS 17) — обов'язкові вимоги, без яких ревю падає.
Freemium: проектування моделі
Freemium працює коли межа між безплатним та платним проведена правильно. Занадто жорсткий paywall на старті — користувач видаляє. Занадто щедрий безплатний тир — немає стимулу платити.
Паттерн, який працює технічно: feature flags з сервера (Remote Config у Firebase або LaunchDarkly) управляють доступом до фіч. Це дозволяє A/B тестувати paywall без релізу, змінювати умови trial, проводити акції.
Реалізація на рівні коду: EntitlementManager — єдина точка перевірки доступу до фіч, яка знає про статус підписки, флаги та промо. Без розкиданих по коду перевірок isPremium.
Строки: базова IAP інтеграція зі StoreKit 2 або Google Play Billing — 1-2 тижні. Повнофункціональна система підписок з RevenueCat, paywall екранами, аналітикою та webhooks — 3-5 тижнів. Рекламна медіація з MAX та 3-4 мережами — 1-2 тижні.