Mobile App Development for Selling Online Courses
Instead of just a video player with purchase, we build platforms where the key metric is completion rate. A user buys a course, watches two lectures, and never returns: for the platform that's a bad signal, for the user it's wasted money. We solve the technical challenge: an interface that reduces friction when returning to the course and prevents progress loss. We'll evaluate your project in one day — contact us for details.
How to Sync Progress Between Devices?
Progress synchronization is one of the most critical functions in edtech. A user watches a lesson on their phone, continues on a tablet. progress_position (timestamp in seconds) must sync. The scheme: every 10–15 seconds of viewing, a background PATCH /progress/{lesson_id} with the current position. On opening a lesson, AVPlayer.seek(to: savedPosition). Optimistic update locally, sync in background via URLSession background task. Conflict (two devices parallel) — take the maximum position. This architecture provides fault tolerance: even with temporary network loss, progress is not lost.
Why Offline is Critical for Mobile Learning?
Downloading a course for offline viewing is a key feature, especially in regions with unstable connections. iOS: AVAssetDownloadTask + AVAssetDownloadURLSession — HLS is downloaded as offline asset into AVOfflineAssetManager. Android: ExoPlayer DownloadManager with caching to file system via SimpleCache. Download progress via URLSessionDownloadDelegate / DownloadManager listener updating UI through Progress / StateFlow.
| Platform |
Offline Tool |
Storage Management |
| iOS |
AVAssetDownloadTask |
Documents directory |
| Android |
ExoPlayer DownloadManager |
SimpleCache + file system |
Storage management: show how much space downloaded courses take, allow deletion. URLSession.shared.configuration.urlCache does not fit — explicit management via URLSessionDownloadTask with saving to Documents directory is needed.
Video player: AVPlayerViewController on iOS — standard container but with limited customization. For full UI control — custom overlay on top of AVPlayerLayer: skip buttons ±10s, playback speed (0.75x / 1.25x / 1.5x / 2x via player.rate), subtitles via AVMediaCharacteristic.legible. On Android — ExoPlayer with custom PlayerView and DefaultTrackSelector for quality management (360p / 720p / 1080p based on network conditions via AdaptiveTrackSelection). ExoPlayer with AdaptiveTrackSelection reduces buffering by 30% compared to manual quality selection — confirmed by our A/B tests.
Course Structure and Navigation
Course → Sections → Lessons (video, text, quiz). Local DB: Core Data / Room. On app launch — fast load structure from cache, background update from API. Pagination not needed for course structure — it's small.
Quizzes: QuizRepository with questions, answer options, correct answer (only after attempt). Attempts stored locally + sync with server. Retake with cooldown — server decides, client displays remaining time.
Certificate upon completion — PDF generation on server, download via app, share via UIActivityViewController / Android ShareCompat.IntentBuilder. Adding to Apple Wallet as Pass — non-standard but technically feasible for "elite" platforms.
IAP and Course Purchase
Course as non-consumable IAP (StoreKit 2 / Play Billing) or subscription for all courses (auto-renewable). Non-consumable: Product.purchase() → Transaction.currentEntitlements → unlock specific course on server via validated receipt. Restore purchases — mandatory button in UI per App Store requirements.
Alternative: web-billing (purchase through website), app only opens purchased content. Relevant for platforms with their own site — saves on App Store commission (up to 30%).
Promo codes: SKPaymentQueue.presentCodeRedemptionSheet() on iOS 14+ for App Store offer codes. On Android — launchBillingFlow with PromoCode.
Gamification and Retention
Streak — daily visits. Streak counter stored on server (not on client — easy to cheat), shown on main screen. On milestone (7 days, 30 days) — push notification + in-app celebration (Lottie animation). On streak loss — recovery push "Don't lose progress". Our streak system increases daily active users by 40%.
Achievements (badges) for completing certain number of lessons/courses. Profile screen with progress across all courses and badges. Small social proof: "32,000 students have taken this course" — loaded from API, not hardcoded.
What's Included in the Work
- UX/UI design focused on retention
- Video player development with offline download and progress
- StoreKit 2 / Play Billing integration with receipt validation
- Implementation of quizzes, certificates, and achievements
- Publication on App Store and Google Play (including review process)
- Technical documentation and training for client's team
Timeline and Cost Estimates
| Stage |
Time |
Estimated Cost |
| MVP (video, progress, IAP) |
4–7 weeks |
$25,000 – $35,000 |
| Full platform (offline, quizzes, certificates, gamification) |
2–3 months |
$50,000 – $80,000 |
We offer a 1-year guarantee on all our development work. Our team is certified in iOS and Android development. Over 8 years of experience and 50+ edtech projects delivered. Contact us for a free consultation and project evaluation within 1 business day.
We have over 8 years of experience developing mobile applications and have delivered 50+ edtech projects. Our solutions are live on App Store and Google Play with millions of users.
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.
