Mobile Sports Betting App Development

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 + Combine publisher distributes updates to ViewModels.
• Android: OkHttp WebSocket + StateFlow / SharedFlow through BettingRepository.
• On disconnect — automatic reconnect with exponential backoff and re-subscription.
• Visual: micro-animations when odds change (green/red flash via animate() in Compose or UIView.animate in 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:

1. Tap "Place Bet" → local validation (balance, min/max stake).
2. POST /bets with {selections, stake, idempotency_key} → server reserves the amount.
3. Response: {bet_id, status: "accepted"/"pending"/"rejected", actual_odds}.
4. If actual_odds changed — 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

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

1. Audit licensing requirements and select jurisdiction
2. Design API and WebSocket contract
3. Develop real-time odds and betslip
4. Integrate payments + KYC
5. Geolocation control
6. Load testing (1000+ concurrent updates)
7. 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.

Mobile App Monetization: IAP, Subscriptions, and Ad Mediation

An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.

Why StoreKit 2 is the Best Choice for IAP?

StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.

But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.

A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.

How Not to Lose Revenue on Subscriptions?

The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.

Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.

Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).

Ad Mediation: Boosting CPM via Bidding

Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.

ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.

Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.

How We Implement Monetization: Step-by-Step Process

1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
6. A/B testing of paywall — use Remote Config for experiments without a release.
7. Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.

How to Design a Freemium Model and Paywall?

Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.

A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.

Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).

Scope of Monetization Work

• Current model audit — analysis of funnel, paywall, price tiers.
• IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
• Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
• Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
• Documentation — description of entitlements, restoration procedure, review checklist.
• Team training — analysis of typical mistakes, support recommendations.
• Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.

Estimated Timelines

Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.