Розробка мобільного додатку для лотереї під ключ

Лотерейний додаток виглядає простіше букмекерського — немає real-time котирувань, немає live dealer. Але у нього своя специфіка: розіграші зі строгим часовим вікном, верифікація квитків, миттєві розіграші (scratch cards) з вимогою плавної анімації та пікові навантаження перед дедлайном продажів. 5 років досвіду та понад 10 реалізованих проєктів дозволяють нам передбачати ці складнощі. Нижче розберемо ключові проблеми та їх вирішення.

Ключові проблеми мобільного додатку для лотереї

Як забезпечити чесний час при розіграші?

Лотерея закриває продажі квитків у момент розіграшу (або за N хвилин до). Додаток має точно відображати countdown та заблокувати покупку рівно в момент дедлайну. Проблема: Date() на пристрої можна перевести — сервер має бути джерелом правди часу. Отримуємо server time при відкритті додатку, обчислюємо зміщення від Date(), використовуємо скоригований час для countdown (serverNow + (Date() - syncedAt)). Дедлайн перевіряється і на сервері при кожній спробі покупки. Це виключає маніпуляції з таймером.

Вибір номерів та Quick Pick

Користувач вибирає числа (як у Keno або Powerball аналозі) або отримує Quick Pick (випадковий набір). Quick Pick на клієнті — CSPRNG (SecRandomCopyBytes на iOS, SecureRandom на Android), але фінальний вибір валідується та зберігається на сервері. Інтерфейс вибору чисел — grid з N комірок з multi-select, анімація вибору через withAnimation (SwiftUI) / animateContentChange (Compose).

Миттєві лотереї (scratch cards)

Візуально — шар срібла поверх зображення, який стирається жестом. Реалізація: Metal або SpriteKit на iOS, Canvas з PorterDuff.Mode.DST_OUT на Android. Поріг стирання — 70% площі (налаштовується) — відкриває весь приарт через SKTexture mask або Path coverage calculation. Результат визначається сервером при покупці квитка і передається зашифрованим: клієнт розшифровує тільки після повного стирання, запобігаючи перегляду результату до анімації.

Як реалізувати scratch card анімацію?

Процес створення скретч-карти:

1. Підготувати маску стирання: шар срібла (сірий колір) над призовим зображенням.
2. Обробити жести стирання: на iOS — Metal з текстурою маски, на Android — Canvas з PorterDuff.Mode.DST_OUT.
3. Розрахувати відсоток стертої області: mask coverage > 70% → відкрити призове зображення.
4. Результат (виграш/програш) зашифровано на сервері і дешифрується локально тільки після стирання.

Як організувати push-сповіщення про результати?

Сповіщення «Ви виграли!» або «Результати розіграшу» має приходити одразу після розіграшу. Схема: сервер проводить розіграш → перевіряє winning квитки → надсилає персоналізовані push через FCM/APNS. UNNotificationServiceExtension на iOS дозволяє додати rich notification — зображення виграшних чисел прямо у сповіщенні. Deep link зі сповіщення → екран результатів конкретного квитка.

Проблема пікових пушів: якщо 1 мільйон користувачів отримують push одночасно після великого розіграшу — FCM batch sending. Сервер надсилає не одним запитом, а через Firebase Admin SDK sendEach() батчами по 500 токенів, обробляючи InvalidRegistration (застарілі токени) для чищення бази.

Верифікація фізичних квитків

Якщо оператор має і роздрібні точки — потрібен QR/barcode scanning для верифікації паперових квитків через додаток. AVFoundation (AVCaptureSession + AVMetadataObjectTypeQRCode) на iOS, ML Kit Barcode Scanning на Android — швидше та надійніше ніж ZXing. Сканований код → API запит → відображення статусу квитка (winner/loser, prize amount).

Платежі

Купівля квитків: Apple Pay (PKPaymentRequest) та Google Pay для UX без friction. Card через Stripe/Braintree hosted fields. У ряді юрисдикцій лотерейні квитки — предмет державного регулювання, додаток зобов'язаний показувати responsible gambling warnings і дозволяти встановити ліміти на витрати.

Стек

Flutter або React Native — виправдані тут, оскільки немає жорстких вимог до real-time WebSocket продуктивності. Scratch card анімація — нативний модуль (Platform Channel / Native Module) для Metal/Canvas операцій. Core Data / Room для історії квитків та локального кешу результатів. Firebase для push.

Процес роботи

Аналіз лотерейної механіки та регуляторних вимог → дизайн білетного flow → розробка (купівля, scratch cards, результати, історія) → платіжна інтеграція → push-сповіщення → QA (включаючи deadline edge cases, офлайн сценарії) → публікація.

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

Чому обирають нас?

Більше 5 років досвіду в мобільній розробці. Сертифіковані спеціалісти (Apple, Google). Гарантуємо дотримання App Store Review Guidelines (Section 4.2, 5.1) та вимог Google Play. Отримайте консультацію щодо вашого лотерейного проєкту — напишіть нам. Оцінимо ваш проєкт безкоштовно, зв'яжіться для консультації.

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