Mobile Sports Betting App Development
Betting applications process thousands of odds updates per second. A 3–5 second delay turns into financial losses: clients place bets on outdated data, and arbitrageurs cash out. The core challenge is data freshness. Our stack and architecture solve this at the protocol and UI level. In one project with 5,000+ concurrent connections, we achieved odds update latency under 100 ms. This allowed the operator to reduce losses from arbitrage bets by 30% and decrease server load by 10x compared to traditional polling.
Why WebSocket, Not REST?
REST polling every 3 seconds with 500 active matches creates load incompatible with real-time. We use WebSocket: one connection, subscriptions to events (SUBSCRIBE {market_ids: [123, 456]}), the server sends diffs ({market_id: 123, outcomes: [{id: 1, odds: 2.45}]}). The client applies changes to local state without reloading.
- iOS:
URLSessionWebSocketTask+Combinepublisher distributes updates to ViewModels. - Android:
OkHttp WebSocket+StateFlow/SharedFlowthroughBettingRepository. - On disconnect — automatic reconnect with exponential backoff and re-subscription.
- Visual: micro-animations when odds change (green/red flash via
animate()in Compose orUIView.animatein UIKit).
Suspended markets. Before a major event, a match goes into suspend — bets are blocked. The app receives {market_id: 123, status: "suspended"} and immediately deactivates the "Place Bet" button. If a coupon is already open — show an inline warning.
How Does Idempotency_key Work in Bet Placement?
idempotency_key (client UUID) is mandatory — it prevents duplicate bets due to network failures. It is sent in POST /bets. The server checks uniqueness within a time window, eliminating double debiting.
Betslip — Architecture and Pitfalls
The betslip is a technically complex UI component. A user adds selections, the app calculates accumulator odds: total_odds = outcome_1_odds × outcome_2_odds × ... × outcome_n_odds. When any odds change while the betslip is open — update with animation and offer to accept new terms.
Bet placement flow:
- Tap "Place Bet" → local validation (balance, min/max stake).
- POST
/betswith{selections, stake, idempotency_key}→ server reserves the amount. - Response:
{bet_id, status: "accepted"/"pending"/"rejected", actual_odds}. - If
actual_oddschanged — dialog "Odds changed. Accept?"
How Do We Ensure Geolocation Control?
Licensing requirements prohibit bets outside permitted territory. We request CLLocationManager (iOS) or FusedLocationProviderClient (Android) on start. Coordinates are sent to the server, which cross-checks with GeoIP + device location. VPN detection: compare IP geolocation with GPS — a significant discrepancy triggers a flag for review, not an outright ban.
Payments and Withdrawals: Security First
Deposits and withdrawals via Stripe, Adyen, PayOp, or local PSPs. Card data never passes through our server — we use Stripe iOS SDK (STPPaymentCardTextField) / Stripe Android SDK. For withdrawals — mandatory verification (KYC) via Sumsub. Apple Pay / Google Pay for fast deposits: integration takes 1–2 days with a ready backend.
Approach and SDK Comparison
| Criterion | WebSocket | Long polling |
|---|---|---|
| Update latency | 50–100 ms | 3–5 sec |
| Server load | Low | High |
| Implementation complexity | Medium | Low |
| Suspend event support | Native | Requires workarounds |
| Scalability (1000+ connections) | Excellent | Poor |
| Platform | Library | Combine/Flow support |
|---|---|---|
| iOS | URLSessionWebSocketTask | Yes (Combine) |
| Android | OkHttp | Yes (Flow via callback) |
| iOS/Android (alternative) | Starscream (iOS) / okhttp3 (Android) | Depends on implementation |
WebSocket is better for live odds: reduces load by 10x compared to polling and ensures data freshness. In load testing, we simulated 2000+ concurrent connections and achieved 99.99% successful updates.
What Stack and Architecture Are Used?
- iOS: Swift 5.9+, SwiftUI, Combine, async/await
- Android: Kotlin, Jetpack Compose, Hilt DI, Room, Coroutines + Flow
- Cross-platform: Flutter 3.x (Dart) or React Native (TypeScript) — but for live odds, native development is preferred
- Backend: GraphQL (Apollo) + REST + Codable, Firebase / Supabase
- Storage: local DB (Room / Core Data) with migrations for bet history
Architecture: Clean Architecture — BettingRepository (WebSocket + REST), BetSlipViewModel (accumulator, validation), PaymentRepository, GeoLocationService.
Work Process: From Audit to Publication
- Audit licensing requirements and select jurisdiction
- Design API and WebSocket contract
- Develop real-time odds and betslip
- Integrate payments + KYC
- Geolocation control
- Load testing (1000+ concurrent updates)
- Publish to stores (App Store: gambling entitlement + license; Google Play: Gambling policy)
What Is Included in the Result
- Source code for iOS and/or Android app
- WebSocket contract and API documentation
- Configured CI/CD (TestFlight, Firebase App Distribution)
- Publication and maintenance instructions
- 30-day support after delivery
Experience and Timelines
We have 8+ years in mobile development. Our portfolio includes 20+ projects, including high-load sportsbook platforms. Average MVP delivery time is 10 weeks. Development cost varies based on functionality and real-time requirements.
- MVP (live and pre-match odds, singles and accumulators, basic payments): 8–12 weeks.
- Full platform (live streaming, cash out, multi-currency, both platforms): 3–5 months.
To discuss details, contact us — we'll send a commercial proposal with a preliminary estimate within two days. Get a consultation for your project right now.