Developing a Mobile App for Lottery
Lottery app looks simpler than sportsbook—no live odds, no live dealer. But has own specifics: draws with strict time window, ticket verification, instant lotteries (scratch cards) with animation demand, peak loads before ticket sales deadline.
Main Technical Scenarios
Ticket sales with deadline. Lottery closes sales at draw moment (or N minutes before). App must display countdown precisely and block purchase exactly at deadline. Problem: device Date() can be changed—server is truth source. Get server time on app open, calculate offset from Date(), use corrected time for countdown (serverNow + (Date() - syncedAt)). Deadline checked on server per purchase attempt.
Ticket numbers. User selects numbers (like Keno or Powerball) or gets Quick Pick (random). Quick Pick on client—CSPRNG (SecRandomCopyBytes on iOS, SecureRandom on Android), but final choice validated and saved on server. Number selection UI—grid of N cells with multi-select, selection animation via withAnimation (SwiftUI) / animateContentChange (Compose).
Instant lotteries (scratch cards). Visually—silver layer over image, wiped away by gesture. Implementation: Metal or SpriteKit on iOS, Canvas with PorterDuff.Mode.DST_OUT on Android. Erase threshold (70% area = reveal all art) with SKTexture mask or Path coverage calculation. Result determined by server at purchase, transmitted encrypted—client decrypts only after full erase, prevents result peeking before animation.
Push Notifications on Results
"You won!" or "Draw results" notification should arrive right after draw. Scheme: server conducts draw → checks winning tickets → sends personalized push via FCM/APNS. UNNotificationServiceExtension on iOS allows rich notification—draw numbers image right in notification. Deep link from notification → results screen for specific ticket.
Peak push problem: if 1 million users get push post-major draw—FCM batch sending. Server sends not single request, but via Firebase Admin SDK sendEach() in 500-token batches, handling InvalidRegistration (stale tokens) for cleanup.
Physical Ticket Verification
If operator has retail outlets—need QR/barcode scanning for paper ticket verification via app. AVFoundation (AVCaptureSession + AVMetadataObjectTypeQRCode) on iOS, ML Kit Barcode Scanning on Android—faster and more reliable than ZXing. Scanned code → API request → display ticket status (winner/loser, prize amount).
Payments
Ticket purchase: Apple Pay (PKPaymentRequest) and Google Pay for frictionless UX. Card via Stripe/Braintree hosted fields. In some jurisdictions, lottery tickets—state-regulated, app must show responsible gambling warnings and allow spending limits.
Stack
Flutter or React Native—justified here, no hard real-time WebSocket performance needs. Scratch card animation—native module (Platform Channel / Native Module) for Metal/Canvas ops. Core Data / Room for ticket history and local results cache. Firebase for push.
Process
Lottery mechanic analysis and regulatory requirements → ticket flow design → development (purchase, scratch cards, results, history) → payment integration → push notifications → QA (deadline edge cases, offline scenarios) → publication.
Timeline Estimates
App with number lottery sales, ticket history, result push, payments: 4–8 weeks. With instant scratch card lotteries, physical scanner, responsible gambling tools: 2–3 months.