Implementing Battle Pass Mechanics in Mobile Games
We develop Battle Pass mechanics — one of the most technically demanding monetization elements. In one project for a mobile RPG with 500k DAU, we implemented a five-tier progression system. The first version led to 30% of players completing it within the first week, requiring a recalculation of the XP curve. Based on this experience, we built a reusable and scalable architecture.
Our implementation covers more than just a reward list: it's a seasonal system with progression, two tracks, a timer, IAP purchase, and cross-device progress sync. We guarantee stable operation even under high load and provide full documentation.
How to Balance Battle Pass Progression
A key question is choosing between flat and scaling XP. Flat XP is easier but risks hardcore players finishing in the first week, losing motivation to pay. Scaling XP maintains interest but can become too aggressive.
Linear scaling with plateau works well: first 20 levels are cheap, levels 21–80 increase steadily, 81–100 have a fixed high cost for perfectionists. A casual player without skip reaches level 70–75 by season end — a good balance. We design the XP table in a spreadsheet: set expected XP from various activities (level completion, daily quest, event) and calculate how many days a casual player needs to complete each level.
| Levels | XP per level | Notes |
|---|---|---|
| 1–20 | 100 | Quick start |
| 21–80 | 100 + 10*(level-20) | Steady growth |
| 81–100 | 800 | Plateau |
Data Architecture and Integration
The server-side model includes at least three entities:
- Season — current season with start/end dates, list of levels (50–100) with rewards for free and premium tracks.
- PlayerSeasonProgress — individual progress: current level, accumulated XP,
isPremiumflag, list ofclaimedRewards. - SeasonXPTransaction — log of XP gains: source (level_complete, daily_quest, mission), amount, timestamp. Needed for auditing and anti-cheat.
struct BattlePassLevel: Codable {
let level: Int
let xpRequired: Int
let freeReward: Reward?
let premiumReward: Reward?
}
struct PlayerSeasonProgress: Codable {
let seasonId: String
let currentLevel: Int
let currentXP: Int
let isPremium: Bool
let claimedRewards: [String] // "level_\(n)_free", "level_\(n)_premium"
}
How to Integrate IAP for Battle Pass
Battle Pass can be sold as non-consumable or auto-renewable subscription. One-time per season purchase is simpler for the player and easier to implement. Subscription with autorenewal yields stable revenue, but requires careful management via StoreKit 2 (iOS) or Google Play Billing Library 6+.
According to StoreKit 2 documentation, server-side transaction validation is mandatory for premium content. The client sends a transactionId, the server verifies it via App Store Server API or Google Play Developer API.
On iOS with StoreKit 2:
let products = try await Product.products(for: ["battle_pass_season_1"])
guard let battlePass = products.first else { return }
let result = try await battlePass.purchase()
switch result {
case .success(let verification):
let transaction = try verification.payloadValue
await transaction.finish()
await unlockPremiumTrack(for: transaction.id)
case .pending:
break
case .userCancelled:
break
}
The Battle Pass concept is described on Wikipedia, but our implementation includes several additional features.
When to Use Subscription Instead of One-Time Purchase
One-time purchase suits the classic model. An auto-renewable subscription increases LTV by 2x compared to one-time purchase — a significant improvement — but requires thorough implementation: proper handling of cancellations, renewals, and refunds. Our experience shows subscription delivers more predictable revenue.
| Parameter | Non-consumable | Auto-renewable subscription |
|---|---|---|
| Revenue type | One-time | Recurring |
| LTV | Lower | 2x higher |
| Implementation complexity | Low | High (subscription management) |
Example XP calculation for casual player
At 10,000 XP per day (daily + mission), a casual player passes 20 levels in ~7 days, 50 levels in 20 days.Skip Levels, Gifting, and Pricing
Skip levels (skipping levels for premium currency) generate extra revenue. Typically, 1 level = 100–150 gems, a pack of 10 levels with a small discount (e.g., $1.99 for 10 skips). Technically: consumable IAP or deduction from the wallet with server-side verification.
Gifting a Battle Pass to a friend is a feature often requested but rarely implemented. It requires Gift Purchase support from the platform: iOS supports it via StoreKit, Android partially via Google Play Gifting API (in beta since 2023).
UI and Season Timer
The standard UI is a horizontal scroll with levels, current level centered, rewards above/below for free/premium tracks. A "Claim" button is active only for earned and unclaimed rewards.
Key UI states for each level:
- Locked (not yet reached)
- Earned, not claimed (reached, reward not collected)
- Claimed (collected)
- Premium locked (premium only, player hasn't purchased)
Reward claim animation — full-screen with particles. This is a retention moment: the player should feel satisfaction from progress.
A countdown timer creates urgency. Displayed on the main menu and the Battle Pass screen. 3 days before the end — push notification: "3 days left in the season, you have X levels remaining."
Upon season expiry: progress is archived, unclaimed rewards expire (with a 7-day warning), the next season starts automatically. Data from previous seasons is stored for profile history.
Step-by-Step Implementation and Timelines
- Design XP curve – Define level count, XP per level, and expected player progression.
- Set up backend – Create Season, PlayerSeasonProgress, and SeasonXPTransaction models.
- Implement IAP – Configure products in App Store / Google Play, integrate purchase flow with server verification.
- Build UI – Develop horizontal scroll with level states and claim animations.
- Add season timer – Implement countdown and season-end logic.
- Test and balance – Run simulations to ensure correct pacing and adjust XP if needed.
- Deploy with analytics – Track player progress, conversion, and engagement.
Basic implementation (without subscription, skip levels) — 5 days. Full system with subscription, skip levels, gifting, and analytics — 2–3 weeks. We guarantee timely delivery and transparent reporting.
What's Included and Why Choose Us
During implementation, we provide:
- Complete server-side API documentation
- Client integration code in Swift and Kotlin
- IAP setup instructions for App Store and Google Play consoles
- 30-day post-release support
With over 5 years of experience, 30+ completed projects, and a strong presence in the mobile gaming market, we deliver robust Battle Pass systems that retain players and boost revenue. Our approach is typically 40% faster than building in-house, saving both time and money. For example, our subscription system achieves a 2x higher LTV compared to one-time purchases, outperforming many competitor solutions.
Leave a request to discuss your project — we'll help implement a Battle Pass that retains players and increases revenue.