Розробка мобільного додатку для онлайн-казино

Ми розробляємо мобільні додатки для онлайн-казино під ключ: від вибору стратегії дистрибуції до публікації в сторах та інтеграції з платіжними провайдерами. Казино-додаток в App Store — рідкість: Apple видає gambling entitlement лише операторам із дійсною ліцензією в ~15 країнах. Google Play також має регіональні обмеження. Для більшості ринків обирають PWA або пряму дистрибуцію APK. Який шлях підходить вашому проєкту — оцінимо на консультації.

Як вибрати стратегію дистрибуції?

PWA обходить store-обмеження, але на iOS обмежений: немає фонових push-сповіщень, біометрії, а Safari має WebGL-обмеження для 3D-слотів. Нативний додаток дає максимальний UX, але потребує ліцензії та проходить суворий рев'ю. Гібридний підхід (нативна оболонка + WebView) — компроміс: ігрове лобі та слоти рендеряться у WebView (провайдери дають iframe/JS SDK), нативний шар обробляє авторизацію, платежі, push. Міст через WKScriptMessageHandler (iOS) / addJavascriptInterface (Android).

Нативний додаток має в 2 рази вищу конверсію push-сповіщень, ніж PWA, що критично для утримання гравців. Згідно з Apple App Store Review Guidelines, публікація додатка з азартними іграми потребує спеціального entitlement.

Чому PWA не завжди підходить для iOS?

На iOS Safari не підтримує фонові push-сповіщення, що критично для утримання гравців. Біометрія недоступна — важливо для безпечного входу та підтвердження платежів. WebGL-обмеження знижують якість 3D-слотів. Для live dealer мобільного додатку потрібна низька latency відеопотоку — HLS через AVPlayer (не WebRTC), що в PWA реалізувати складно. Тому багато операторів обирають гібрид.

Інтеграція ігрового провайдера

Великі провайдери (Pragmatic Play, Evolution, NetEnt, Playtech) надають game launch URL виду https://provider.com/game?token=SESSION_TOKEN&demo=false. Мобільний додаток:

1. Запитує у свого сервера session_token для конкретної гри (сервер отримує його від провайдера за B2B API).
2. Відкриває game URL у WKWebView / WebView з fullscreen presentation.
3. Отримує callback від провайдера через postMessage при закритті гри.

Проблема: ігрові iframes часто блокують viewport meta tag і потребують landscape orientation. На iOS: WKWebView з allowsInlineMediaPlayback = true, mediaTypesRequiringUserActionForPlayback = [] (автовідтворення звуку без tap). Live dealer (Evolution) вимагає відеопотік із буфером 2–4 секунди — норма.

Платіжна інфраструктура

Платіжна інтеграція казино включає обробку через спеціалізовані PSP: Payvision, Skrill, Neteller, PaySafe. Стандартний card flow: Apple Pay / Google Pay для швидкого депозиту, credit card через PCI-DSS compliant hosted fields. 3DS2 — обов'язково для європейських карток. Більшість PSP надають SDK із embedded 3DS challenge screen. 95% успішних транзакцій — середній показник після оптимізації. Ліміти депозиту (від $10 до $10000) та responsible gambling інструменти (self-exclusion, deposit limits) — регуляторна вимога. Інтерфейс керування лімітами — обов'язковий екран у налаштуваннях.

KYC та безпека

KYC — обов'язково за ліцензійними вимогами. Використовуємо Sumsub SDK або Onfido: document upload + selfie + liveness check. Верифікація займає в середньому 2 хвилини. Рівні верифікації: базовий (email+телефон) → розширений (ID) → повний (proof of address) з різними лімітами. Біометрична аутентифікація для входу та підтвердження виведення — LocalAuthentication (iOS) / BiometricPrompt (Android). Зберігання токенів — iOS Keychain, Android EncryptedSharedPreferences.

Бонусна система

Welcome bonus, free spins, cashback — стандартний набір. На клієнті: BonusRepository з поточними активними бонусами, wagering progress (скільки потрібно проставити), expiration timer. Фріспіни застосовуються автоматично при запуску гри — логіка на сервері, клієнт отримує {free_spins_available: 10, game_id: "starburst"} і показує badge.

Покроковий процес розробки

1. Аналіз ліцензійних вимог та вибір стратегії дистрибуції
2. Інтеграція з ігровим провайдером (API, game launch, callbacks)
3. Платіжна інтеграція (PSP, Apple Pay, 3DS2)
4. Впровадження KYC (Sumsub/Onfido) та біометрії
5. Реалізація бонусної системи та responsible gambling
6. QA та тестування (включаючи real device)
7. Публікація/деплой (App Store, Google Play, PWA)

Що входить у роботу

• Документація: архітектурна схема, API-специфікація, інструкція з експлуатації
• Вихідний код із коментарями на Swift/Kotlin/Dart
• Інтеграція з обраними ігровими провайдерами та PSP
• Налаштування KYC та біометрії
• Реалізація бонусної системи та responsible gambling
• Допомога з проходженням store review (при необхідності)
• Підтримка після запуску: 1 місяць інцидент-менеджменту

Маємо 7+ років досвіду та сертифікацію PCI DSS. Гарантуємо відповідність вимогам сторів.

Орієнтири за термінами та бюджетом

• Базова версія (WebView-лобі, один провайдер, платежі, KYC): 8–12 тижнів, орієнтовний бюджет від $40,000.
• Повноцінна платформа (кілька провайдерів, live dealer, бонуси, обидві платформи): 3–5 місяців, бюджет від $100,000 до $150,000.

Ми — команда з 7+ років досвіду в мобільній розробці, виконали 30+ проєктів для iGaming. Зв'яжіться з нами для оцінки вашого проєкту — підготуємо технічну пропозицію та roadmap.

Монетизація мобільних додатків: 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.