Разработка мобильного приложения для ставок на спорт

Разработка мобильного приложения для ставок на спорт

Букмекерские приложения обрабатывают тысячи обновлений котировок в секунду. Задержка в 3–5 секунд превращается в финансовые потери: клиенты ставят по устаревшим данным, а арбитражники выводят деньги. Центральная задача — актуальность данных. Наш стек и архитектура решают её на уровне протокола и UI. В одном из проектов с 5000+ одновременных подключений мы добились задержки обновления коэффициентов менее 100 мс. Это позволило оператору сократить потери от арбитражных ставок на 30% и снизить нагрузку на сервер в 10 раз по сравнению с традиционным polling.

Почему WebSocket, а не REST?

REST polling каждые 3 секунды при 500 активных матчах создаёт нагрузку, несовместимую с real-time. Мы используем WebSocket: одно соединение, подписки на события (SUBSCRIBE {market_ids: [123, 456]}), сервер присылает дифф ({market_id: 123, outcomes: [{id: 1, odds: 2.45}]}). Клиент применяет изменения к локальному state без перезагрузки.

• iOS: URLSessionWebSocketTask + Combine publisher дистрибьютит обновления по ViewModel'ам.
• Android: OkHttp WebSocket + StateFlow / SharedFlow через BettingRepository.
• При разрыве — автоматический reconnect с экспоненциальным backoff и повторной подпиской.
• Визуально — микроанимация при изменении коэффициента (зелёный/красный flash через animate() в Compose или UIView.animate в UIKit).

Suspended markets. Перед крупным событием матч уходит в suspend — ставки блокируются. Приложение получает {market_id: 123, status: "suspended"} и немедленно деактивирует кнопку «Поставить». Если купон уже открыт — показываем inline предупреждение.

Как работает idempotency_key в размещении ставок?

idempotency_key (UUID клиента) обязателен — предотвращает дублирование ставок при сетевых сбоях. Он передаётся в POST /bets. Сервер проверяет уникальность ключа за определённый промежуток времени, что исключает повторное списание средств.

Купон ставки (betslip) — архитектура и подводные камни

Betslip — технически сложный UI-компонент. Пользователь добавляет исходы, приложение считает accumulator odds: total_odds = outcome_1_odds × outcome_2_odds × ... × outcome_n_odds. При изменении любого коэффициента во время открытого betslip — обновление с анимацией и предложением принять новые условия.

Flow размещения ставки:

1. Нажатие «Поставить» → локальная валидация (баланс, мин/макс ставка).
2. POST /bets с {selections, stake, idempotency_key} → сервер резервирует сумму.
3. Ответ: {bet_id, status: "accepted"/"pending"/"rejected", actual_odds}.
4. Если actual_odds изменились — диалог «Коэффициент изменился. Принять?».

Как мы обеспечиваем геолокационный контроль?

Лицензионные требования запрещают ставки за пределами разрешённой территории. Запрашиваем CLLocationManager (iOS) или FusedLocationProviderClient (Android) при старте. Координаты уходят на сервер, сервер сверяет с GeoIP + device location. VPN detection: сравниваем IP-геолокацию с GPS — существенное расхождение только флаг для проверки, а не бан.

Платежи и вывод: безопасность прежде всего

Пополнение и вывод через Stripe, Adyen, PayOp или локальные PSP. Карточные данные не проходят через наш сервер — используем Stripe iOS SDK (STPPaymentCardTextField) / Stripe Android SDK. Для вывода — обязательная верификация (KYC) через Sumsub. Apple Pay / Google Pay для быстрого депозита: интеграция занимает 1–2 дня при готовом бэкенде.

Сравнение подходов и SDK

WebSocket лучше подходит для live-котировок: снижает нагрузку в 10 раз по сравнению с polling и обеспечивает актуальность данных. При нагрузочном тестировании мы эмулировали 2000+ одновременных подключений и достигли 99.99% успешных обновлений.

Какой стек и архитектура используются?

• iOS: Swift 5.9+, SwiftUI, Combine, async/await
• Android: Kotlin, Jetpack Compose, Hilt DI, Room, Coroutines + Flow
• Cross-platform: Flutter 3.x (Dart) или React Native (TypeScript) — но для live-котировок предпочтительна нативная разработка
• Backend: GraphQL (Apollo) + REST + Codable, Firebase / Supabase
• Хранилище: локальная БД (Room / Core Data) с миграциями для истории ставок

Архитектура: Clean Architecture — BettingRepository (WebSocket + REST), BetSlipViewModel (accumulator, validation), PaymentRepository, GeoLocationService.

Процесс работы: от аудита до публикации

1. Аудит лицензионных требований и выбор юрисдикции
2. Проектирование API и WebSocket-контракта
3. Разработка real-time котировок и betslip
4. Интеграция платежей + KYC
5. Геолокационный контроль
6. Нагрузочное тестирование (1000+ одновременных обновлений)
7. Публикация в магазинах (App Store: gambling entitlement + лицензия; Google Play: Gambling policy)

Что входит в результат

• Исходный код приложения для iOS и/или Android
• WebSocket-контракт и документация API
• Настроенные CI/CD (TestFlight, Firebase App Distribution)
• Инструкция по публикации и сопровождению
• Поддержка в течение 30 дней после сдачи

Опыт и сроки

Мы занимаемся мобильной разработкой 8+ лет. В портфолио более 20 проектов, включая high-load букмекерские платформы. Среднее время вывода MVP — 10 недель. Стоимость разработки варьируется в зависимости от функционала и требований к real-time.

• MVP (live и prematch котировки, одиночные и экспресс-ставки, базовые платежи): 8–12 недель.
• Полноценная платформа (live streaming, cash out, многовалютность, обе платформы): 3–5 месяцев.

Чтобы обсудить детали, свяжитесь с нами — пришлём коммерческое предложение с примерной оценкой в течение двух дней. Получите консультацию по вашему проекту прямо сейчас.

Монетизация мобильных приложений: 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 автоматически отменяет покупку и возвращает деньги. Средняя стоимость такой ошибки — потеря $0.3–0.8 на пользователя в месяц (по данным наших проектов).

Рекламная медиация: повышение 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 может превышать $20. При 100 000 показов rewarded видео в день переход с waterfall на In-App Bidding может приносить дополнительно $50-100 ежедневно.

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, receip-валидация, 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 на старте — пользователь удаляет. Слишком щедрый бесплатный тир — нет стимула платить.

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

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

Объём работ по монетизации

• Аудит текущей модели — анализ воронки, paywall, ценовых тиров.
• Интеграция IAP — StoreKit 2 / Google Billing 6, receip-валидация, 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.