Разработка мобильного приложения для лотереи
Лотерейное приложение выглядит проще букмекерского — нет real-time котировок, нет live dealer. Но у него своя специфика: розыгрыши со строгим временны́м окном, верификация билетов, мгновенные розыгрыши (scratch cards) с demand на анимацию, и пиковые нагрузки перед дедлайном продаж билетов.
Основные технические сценарии
Продажа билетов с дедлайном. Лотерея закрывает продажи билетов в момент розыгрыша (или за N минут до). Приложение должно точно отображать countdown и заблокировать покупку ровно в момент дедлайна. Проблема: Date() на устройстве можно перевести — сервер должен быть источником правды времени. Получаем server time при открытии приложения, вычисляем смещение от Date(), используем скорректированное время для countdown (serverNow + (Date() - syncedAt)). Дедлайн проверяется и на сервере при каждой попытке покупки.
Номера билета. Пользователь выбирает числа (как в 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. Результат определяется сервером при покупке билета и передаётся зашифрованным — клиент расшифровывает только после полного стирания, предотвращая просмотр результата до анимации.
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, оффлайн сценарии) → публикация.
Ориентиры по срокам
Приложение с продажей числовых лотерей, историей билетов, push о результатах и платежами: 4–8 недель. С мгновенными scratch card лотереями, физическим сканером и responsible gambling инструментами: 2–3 месяца.