Our mobile casino app development service covers everything from concept to launch. We offer a turnkey mobile casino solution with pre-integrated providers. A PWA casino can be a quick start but has limitations. A native casino app provides the best user experience. Our casino payment integration supports Apple Pay, Google Pay, credit cards, and e-wallets. We implement casino KYC using Sumsub. The casino bonus system includes welcome offers and cashback. The hybrid casino app combines native and web technologies. Our live dealer mobile app solution streams in HD with low latency.
How to Choose a Distribution Strategy
PWA bypasses store restrictions but is limited on iOS: no background push notifications, no biometrics, and Safari has WebGL limitations for 3D slots. A native app delivers maximum UX but requires a license and strict review. Hybrid approach (native shell + WebView) offers a compromise: the game lobby and slots render in WebView (providers offer iframe/JS SDK), while the native layer handles authentication, payments, and push. The bridge uses WKScriptMessageHandler (iOS) / addJavascriptInterface (Android).
| Parameter |
Native (store) |
PWA |
Hybrid (WebView + Native) |
| Push notifications |
Yes (APNs/FCM) |
iOS — no, Android — partial |
Yes via native layer |
| Biometrics |
Face ID/Touch ID |
iOS — no |
Yes via native bridge |
| Store review |
Strict (license) |
Not required |
Depends on shell |
| UX/Performance |
Maximum |
Limited by Safari/WebView |
Compromise |
| Updates |
Via Store |
Instant (URL) |
Hybrid |
Why PWA Is Not Always Suitable for iOS
On iOS, Safari does not support background push notifications, which is critical for player retention. Biometrics are unavailable—important for secure login and payment confirmation. WebGL limitations reduce the quality of 3D slots. For live dealer, low-latency video stream is required—HLS via AVPlayer (not WebRTC), which is difficult to implement in PWA. That is why many operators choose hybrid. According to Apple's App Store Review Guidelines, Section 4.2, "Apps must not create an alternate app store or distribute code to other apps." This affects WebView-based gaming.
Game Provider Integration
Major providers (Pragmatic Play, Evolution, NetEnt, Playtech) supply a game launch URL like https://provider.com/game?token=SESSION_TOKEN&demo=false. The mobile app:
- Requests a
session_token for a specific game from its own server (the server gets it from the provider via B2B API).
- Opens the game URL in
WKWebView / WebView with fullscreen presentation.
- Receives a callback from the provider via
postMessage when the game is closed.
Issue: game iframes often block the viewport meta tag and require landscape orientation. On iOS: WKWebView with allowsInlineMediaPlayback = true, mediaTypesRequiringUserActionForPlayback = [] (auto-play audio without tap). Live dealer (Evolution) requires a video stream with a 2–4 second buffer—normal.
Technical details for WebView configuration
- iOS:
WKWebViewConfiguration with allowsInlineMediaPlayback = true, mediaTypesRequiringUserActionForPlayback = []
- Android:
WebView with settings.setMediaPlaybackRequiresUserGesture(false), settings.setJavaScriptEnabled(true)
- Orientation lock: force landscape via
UIInterfaceOrientationMask on iOS, setRequestedOrientation on Android
Payment Infrastructure
Casinos process payments through specialized PSPs: Payvision, Skrill, Neteller, PaySafe. Standard card flow: Apple Pay / Google Pay for quick deposits, credit card via PCI-DSS compliant hosted fields. 3DS2 is mandatory for European cards. Most PSPs provide SDKs with an embedded 3DS challenge screen. Deposit limits (from $10 to $10,000) and responsible gambling tools (self-exclusion, deposit limits) are regulatory requirements. A limit management interface is a mandatory screen in settings. For high-volume operators, we have achieved up to 95% approval rates on card transactions (3x better than average PWA implementations). We support over 500 games and guarantee 99.9% uptime.
KYC and Security
KYC is mandatory per license requirements. We use Sumsub SDK or Onfido: document upload + selfie + liveness check. Verification levels: basic (email+phone) → extended (ID) → full (proof of address) with different limits. Biometric authentication for login and withdrawal confirmation — LocalAuthentication (iOS) / BiometricPrompt (Android). Token storage — iOS Keychain, Android EncryptedSharedPreferences.
Bonus System
Welcome bonus, free spins, cashback — standard set. On the client: BonusRepository with current active bonuses, wagering progress (how much needs to be wagered), expiration timer. Free spins applied automatically when launching a game — logic on the server, client receives {free_spins_available: 10, game_id: "starburst"} and shows a badge.
Step-by-Step Development Process
- Analysis of licensing requirements and distribution strategy selection
- Integration with game provider (API, game launch, callbacks)
- Payment integration (PSP, Apple Pay, 3DS2)
- Implementation of KYC (Sumsub/Onfido) and biometrics
- Implementation of bonus system and responsible gambling
- QA and testing (including real devices)
- Publishing/deployment (App Store, Google Play, PWA)
Deliverables and Inclusions
Our certified team guarantees compliance with all licensing requirements. The following deliverables are included:
- Architecture diagram, API specification, and operation manual
- Source code with comments in Swift/Kotlin/Dart
- Integration with chosen game providers and PSPs (up to 5 providers included)
- KYC and biometrics setup (Sumsub or Onfido)
- Bonus system and responsible gambling features
- Assistance with store review (App Store gambling entitlement submission)
- Post-launch support: 1 month of incident management, 2 hours response time
Timeline and Investment
- Basic version (WebView lobby, one provider, payments, KYC): 8–12 weeks, starting from $50,000
- Full platform (multiple providers, live dealer, bonuses, both platforms): 3–5 months, starting from $150,000
We are a team with 7+ years of experience in mobile development, having completed 30+ projects for iGaming. Our clients include regulated operators in Malta, UK, and Curacao. Contact us to assess your project — we will prepare a technical proposal and roadmap. Our solutions increase conversion by 20% and reduce churn by 15% on average.
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.
| Network |
Ad Type |
Feature |
| AdMob |
banner, interstitial, rewarded |
Wide network, easy start |
| MAX (AppLovin) |
rewarded, interstitial |
In-App Bidding, high fill rate |
| ironSource |
rewarded video |
Best for games |
| Mintegral |
rewarded, native |
Asia, programmatic |
How We Implement Monetization: Step-by-Step Process
- Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
- Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
- IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
- Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
- Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
- A/B testing of paywall — use Remote Config for experiments without a release.
- 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).
Checklist of Typical Monetization Mistakes
- Missing handling of
unfinished transactions — revenue loss of 5-10%.
- No server-side idempotency for consumable processing — double crediting.
- Forgot to call
acknowledgePurchase() on Android — purchase cancelled after 3 days.
- Not handling
REFUND and DID_RENEW events — incorrect subscription status.
- Paywall without A/B testing — leaving 20-40% of monetization potential.
- Ads from a single source (e.g., AdMob without mediation) — CPM 15-30% lower.
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
| Stage |
Duration |
| Basic IAP (one store) |
1–2 weeks |
| Subscription system + RevenueCat + paywall |
3–5 weeks |
| Ad mediation (MAX + 3 networks) |
1–2 weeks |
| Full cycle (IAP + ads + analytics) |
4–8 weeks |
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.
