Автор запускає ексклюзивний подкаст для підписників. Через місяць з'ясовується: 30% користувачів не можуть оплатити через регіональні обмеження IAP, а ще 20% платять через веб, але губляться в процесі. Типова ситуація для creator-платформ. Ми стикалися з нею в 20+ проєктах і виробили архітектуру, яка балансує між комісією магазинів та конверсією. Наприклад, з нашої практики: для платформи з 50 000 підписників гібридний білінг знижує комісію до 22,5%, що економить $15 000 щомісяця. Цей підхід у 1.3 рази вигідніший за чистий IAP для аудиторії з регіонів з External Link entitlement. Враховуючи часті зміни політик App Store Review Guidelines та Google Play, важливо проєктувати архітектуру, яка легко адаптується. Ми використовуємо паттерн Repository та адаптери для різних білінгових систем, що дозволяє перемикатися між IAP, RevenueCat або веб-покупками без переписування коду. У результаті середня конверсія підписок зростає на 15%. Стек: Swift 5.9 + Combine для iOS, Kotlin + Coroutines для Android, або Flutter 3.x для крос-платформи. Наш досвід 5 років та 20+ проєктів — гарантія успіху. Замовте розробку під ключ, що забезпечує максимальну конверсію підписок.
Чому додаток для creator-економіки з підписками вимагає гібридного білінгу?
Правила App Store та Google Play змінюються щороку. Для додатків з цифровим контентом доступні три підходи:
- Чистий IAP: вся монетизація через Apple/Google, комісія 15–30%. Безшовний UX, простий код, але висока комісія.
- Зовнішні платежі через веб: додаток не продає контент, лише відкриває доступ після покупки на сайті. Комісія 0%, але потрібен External Link entitlement (доступно в США, ЄС за DMA та Південній Кореї). Користувач покидає додаток — конверсія падає на 20-30%.
- Гібрид: нові підписники йдуть на веб (зовнішнє посилання), а тих, хто хоче оплатити in-app, переводимо на IAP. Комісія нижча, UX не страждає, але складніша кодова база та підтримка двох billing flow. Гібридний білінг у 1.3 рази вигідніший за чистий IAP.
Для отримання External Link entitlement потрібна окрема заява в App Store Connect та відповідність вимогам щодо дизайну посилань. Ми проєктуємо екран покупки так, щоб не порушувати правила: посилання на веб відкривається в Safari, без проміжних сторінок з CTA.
Кейс з нашої практики: як гібрид знизив комісію на 25%
Один з наших клієнтів — платформа з аудіоконтентом для 50 000 підписників. 70% користувачів жили в США (External Link доступний), 30% — в решті світу (тільки IAP). Впровадили гібрид: при першому запуску показуємо веб-покупку як пріоритетний варіант, а IAP — як запасний. Результат: 60% нових підписок пішли через веб, середня комісія знизилася з 30% до 22,5%. Економія склала $15 000 на місяць.
Що таке EntitlementManager і навіщо він потрібен?
EntitlementManager — єдине джерело правди про доступ. Він об'єднує два джерела:
- StoreKit 2 Transaction.currentEntitlements (якщо IAP).
- Backend subscription status (якщо web-billing або RevenueCat як агрегатор).
При старті додатку паралельно опитуються обидва, береться максимальний доступ. Сервер надсилає JWT з tier, expires_at — клієнт валідує підпис, кешує. Оновлення кожні 24 години або за push-повідомленням subscription_updated.
Tier-based доступ: EntitlementManager.hasAccess(tier: .premium, feature: .exclusivePosts) — єдина точка перевірки. ContentRepository фільтрує фід: locked пости показуються з preview та paywall blur overlay, unlocked — повністю.
Докладніше про кешування прав доступу
Для зниження навантаження на сервер кеш прав зберігається в UserDefaults (iOS) або DataStore (Android) з TTL 1 година. Якщо refresh token протух — система перезапитує access token через рефреш. При відновленні покупок (restore) — викликається refresh entitlements, що скидає кеш.| Джерело доступу | Комісія | UX | Складність реалізації |
|---|---|---|---|
| Тільки IAP | 15-30% | Безшовний | Низька |
| Тільки веб-покупки | 0% (але потрібні права) | Потрібен перехід на сайт | Середня |
| Гібридний білінг | 0% на веб, 15-30% на IAP | Гнучкий | Висока |
Медіаконтент та DRM
Відео для платних підписників не повинно бути доступним за прямим URL без авторизації. Схема: додаток запитує signed URL з TTL 15 хвилин (/content/{id}/stream?token=...). URL підписується на сервері (CloudFront Signed URL / Google Cloud CDN Signed URLs). AVPlayer (iOS) / ExoPlayer (Android) відтворює через HLS — кешування сегментів автоматичне через AVAssetDownloadTask (iOS) для offline перегляду.
Для більш суворого захисту — FairPlay Streaming (iOS) / Widevine (Android). Це DRM рівня Netflix/Spotify. Вимагає ліцензійного сервера (можна інтегрувати через Axinom DRM, EZDRM, BuyDRM). Для більшості creator-платформ overkill, але якщо контент висококонкурентний — виправдано.
Аудіо подкасти без DRM зазвичай достатньо signed URLs. AVAudioPlayer / MediaPlayer / ExoPlayer для відтворення, фонове відтворення через AVAudioSession (.playback category) + CommandCenter (iOS) / MediaSession API (Android) — керування з екрану блокування.
Стрічка постів та взаємодія з автором
Хронологічний + алгоритмічний фід через UICollectionView DiffableDataSource / Jetpack LazyColumn. Пагінація — cursor-based (не offset — при додаванні нових постів offset збивається). FeedRepository з Paging 3 (Android) або кастомним PaginatedFeedLoader (iOS).
Коментарі з real-time оновленням через WebSocket або long polling. Реакції — optimistic update: UI оновлюється негайно, у фоні йде API запит, при помилці відкочуємо. Це стандартний паттерн для низької perceived latency.
Прямі трансляції (live) — HLS + low latency mode (Apple LL-HLS / DASH) з AVPlayer / ExoPlayer. Чат в прямому ефірі — WebSocket.
Сповіщення та залученість
Push про новий пост від автора, на якого підписаний користувач. На клієнті — налаштування нотифікацій per-creator: користувач вибирає, від кого отримувати push. Токен пристрою зберігається на сервері прив'язаним до creator_subscription_ids — сервер відправляє push лише релевантній аудиторії, не broadcast всім.
Процес роботи та терміни
| Тип контенту | Термін MVP | Термін повної версії |
|---|---|---|
| Тільки пости | 4-5 тижнів | 8-10 тижнів |
| Відео/аудіо | 5-8 тижнів | 12-16 тижнів |
| Live стрімінг | 8-10 тижнів | 16-20 тижнів |
- Аналіз App Store / Play Store політик для конкретної моделі монетизації.
- Проєктування EntitlementManager та billing flow.
- Розробка фіду + медіаплеєра + paywall.
- Інтеграція push-сповіщень.
- QA (включаючи subscription edge cases: grace period, refund, restore purchases).
- Публікація та пострелізна підтримка.
Що входить у deliverables
- Документація з архітектури та політик магазинів.
- Вихідний код додатку (iOS / Android / Flutter / React Native).
- Налаштування CI/CD, TestFlight та Firebase Distribution.
- Інтеграція з платіжними системами (IAP, RevenueCat, Stripe).
- Посібник з експлуатації та навчання команди.
Зв'яжіться з нами для оцінки вашого проєкту — ми розрахуємо терміни та бюджет індивідуально. Замовте розробку під ключ, отримайте готовий додаток з налаштованою монетизацією. Отримайте консультацію прямо зараз.