The one-star review that kills meditation apps reads: "stopped playing when I locked my phone." Second place: "downloaded sessions won't play on the plane." Both are background-audio and caching problems, both are entirely preventable, and both are routinely discovered after launch because the spec said "plays audio" and everyone assumed that was one line of work.
Meditation and mindfulness apps look like the simplest category in wellness. A list of sessions, a play button, a timer. The build is genuinely cheaper than a fitness app with wearable sync — a wellness MVP starts at $12,000 — but the difficulty is concentrated in four places nobody puts on a feature list: background playback, offline caching, streaming economics, and whether your content needs protecting. This page covers those four.
Background playback is a platform contract, not a feature
Your user starts a 20-minute body scan, locks their phone, and puts it face-down. If your app has not explicitly told the operating system it intends to keep playing, the OS will stop it. This is not a bug you fix later; it is a set of declarations and lifecycle handling you build in from the start.
On iOS, that means configuring an AVAudioSession with the playback category and activating it, declaring the audio background mode in your app's capabilities, and populating the now-playing info center so the lock screen and Control Center show the session title, artwork and elapsed time. Then you handle the events that actually happen in the field: an incoming phone call interrupts and later ends, the user unplugs headphones mid-session (route change), another app takes the audio session, or the session ends while the screen is off and your next-session logic has to run without a foreground app.
On Android, background audio lives in a foreground service with a media playback service type, paired with a media session so system UI, Bluetooth controls and Android Auto know what is playing. Modern builds use Media3 and ExoPlayer rather than the legacy MediaPlayer stack. Then you fight the real enemy: aggressive battery management. Several Android OEMs kill background services far more eagerly than stock Android does, and a service that survives on a Pixel can die on other devices in ways that only appear in customer support tickets.
The engineering work is not exotic. It is just genuinely more than an afternoon, and it needs testing on real devices across manufacturers, which is exactly what a QA and release readiness cycle is for.
The interruption cases that generate reviews:
- A call arrives at minute 14 of a 20-minute session. Does it resume? From where?
- Headphones disconnect. Correct behavior is pause, not blast the session through the speaker in a quiet office.
- The user backgrounds the app and opens Spotify. Your session should stop cleanly, not fight for the audio session.
- A sleep session runs 45 minutes with the screen off, and your streak logic has to register completion afterward.
- The user sets the app down mid-session and the phone goes into deep idle. Timers you built on foreground assumptions will drift.
Offline caching: decide the model before you record anything
Meditation is used on planes, in basements, on subways, and in bedrooms with terrible Wi-Fi. Offline is not an advanced feature in this category; it is table stakes. But the way you deliver audio determines how hard offline is, and that decision is made when you encode your catalog — not when you build the download button.
Two delivery models:
Progressive files (a plain AAC or MP3 file over HTTPS) are simple. Downloading for offline is downloading a file. Playback is trivial on both platforms. The trade-off is no adaptive bitrate, weaker protection, and one quality for every network condition. For audio-only content this is a much more defensible choice than the streaming-video world would suggest.
HLS (adaptive segmented streaming) gives you bitrate switching, cleaner support for very long files, and a natural path to encryption. Offline is more work: iOS uses a dedicated asset download API to persist an HLS stream, and Android's ExoPlayer has its own download manager for the same job. This is the right model if you have long sessions, variable-quality content, or a protection requirement.
What a good offline implementation actually handles:
- Download queue with pause, resume, and recovery after the app is killed mid-download
- Storage budget the user can see and control, plus graceful behavior when the device runs out of space
- Cache eviction — a least-recently-used policy so a user who downloads 90 sessions does not consume 4 GB forever
- Content updates: if you re-record a session, the stale local copy must be invalidated
- Entitlement checks that work offline, so a subscriber on a plane is not locked out of content they downloaded, and an expired subscriber is not entitled forever
- Partial-download detection, so a half-downloaded file does not present itself as ready to play
That entitlement point is the one that bites. Naive implementations check subscription status against the server at play time, which means offline playback fails for paying users. Over-corrected implementations cache entitlement forever, which means cancelled users keep the library. The correct answer is a cached entitlement with a bounded grace window and a re-check on next connectivity — and RevenueCat gives you most of the machinery for it.
What audio streaming actually costs
This is the section that changes budgets, and almost nobody writes it.
Audio bandwidth is arithmetic. A 96 kbps AAC stream is 12 KB per second, which is about 43 MB per hour of listening. A 15-minute guided session is roughly 11 MB. At 128 kbps, an hour is about 58 MB.
Now scale it. If 10,000 monthly active users each stream 20 sessions of 15 minutes and nothing is cached, that is 10,000 × 20 × 11 MB ≈ 2.2 TB per month of CDN egress. At 100,000 users on the same behavior, 22 TB.
CDN egress is priced per gigabyte and varies substantially by provider, region and committed volume, so plug your own provider's rate into that arithmetic rather than trusting a number in a blog post.
Three levers control that bill, and all three are architecture decisions:
- Encode sensibly. Guided meditation is speech over ambient sound. It does not need 320 kbps. Dropping from 128 to 96 kbps cuts egress by a quarter with no perceptible loss for this content. Encode once, correctly, at catalog creation — re-encoding a library later is a project.
- Cache aggressively. Every downloaded session is bandwidth you pay for once instead of every time. An app that encourages downloads has a structurally cheaper bill than one that streams by default. This is the rare case where the better user experience is also the cheaper one.
- Serve from a CDN, not your origin. Obvious, and still the most common mistake in early builds. Origin egress plus no edge caching is how a modest audience produces an alarming invoice.
Two more cost lines people forget: storage for the master files and every encoded variant, and transcoding on ingest if you are accepting uploads rather than a fixed catalog.
Does a guided session need DRM?
Usually not. Here is the honest hierarchy, cheapest first.
Signed, short-lived URLs. Content sits behind a CDN that only serves it when presented with a token your backend issued to an authenticated, entitled user. Links expire in minutes. This stops casual sharing and hotlinking, which is the overwhelming majority of the actual risk for a meditation catalog. It is inexpensive and adds no playback complexity.
AES-encrypted HLS. Segments are encrypted; the key is fetched over an authenticated channel. Meaningfully harder to casually rip. Still no DRM licensing infrastructure, and it works with standard players.
Full DRM — FairPlay on Apple platforms, Widevine on Android — requires a license server, certificate provisioning with Apple, per-platform integration, and either a DRM vendor's recurring fee or your own infrastructure. It is what you use when a content partner's contract requires it.
For a catalog you produced yourself, DRM is usually the wrong purchase. It adds engineering cost, adds failure modes (nothing generates support tickets like license acquisition failing offline), and protects content whose commercial value is in the app experience and the catalog's breadth rather than in any one file being unshareable.
When DRM is genuinely required: you have licensed content from a partner whose agreement mandates it, you have exclusive celebrity-narrated content with real piracy exposure, or you are distributing video courses where the economics are different. If a contract mandates DRM, that is a scoping fact, and it belongs in your planning sprint rather than being discovered in week eight.
What else a meditation app needs in version one
Beyond audio, the features that determine retention:
- A streak and progress model that survives timezone changes and offline sessions. This is the same class of bug that breaks fitness streaks, and it is covered in depth in the habit and mood tracking guide.
- Reminder notifications with a real strategy behind them. One well-timed reminder beats four that get muted.
- A sleep-content mode — long-form audio, screen-off, fade-out, and a volume profile that does not jolt someone awake. Overlaps with sleep tracking features if you go further.
- A subscription paywall with a free tier that gives away enough to build the habit. Trial length and paywall placement move revenue more than almost any code you write.
- Apple Watch or wearable session logging if your audience wears one — $3,500 per platform, and worth it only if mindful-minutes logging is something your users ask for.
The honest budget
A meditation app without wearable sync, live sessions or AI features is one of the cheaper builds in wellness. A bounded version one — catalog, player with proper background handling, offline downloads, streaks, notifications, paywall — fits the $12,000+ MVP band for a single platform. Two platforms, a content-management admin surface, or DRM push it toward $25,000.
What we would tell you to cut: live sessions (run them on an existing video tool until demand is proven), a community feed (an existing community platform, same reasoning), and a custom CMS (use an off-the-shelf headless CMS; your content team will be happier and you will save four figures).
What we would tell you not to cut: offline, background playback correctness, and real-device QA across Android manufacturers. Those three are what the reviews are about.
If you want the scope written down before you spend build money, the MVP Planning Sprint is $1,500 over five days and is credited toward the build. If you already know what you are building, tell us and we will price it. More on the category as a whole on the wellness app development page, and if your content moves toward therapy or clinical territory, read the mental health app development page first — intended-use boundaries change what you are allowed to say and what you have to build.
Frequently asked questions
How much does it cost to develop a meditation app?
A bounded version one with a session catalog, proper background playback, offline downloads, streaks and a subscription paywall fits the $12,000+ MVP band for one platform. Adding a second platform, a content-management admin surface, live sessions or DRM moves it toward $25,000 and up. Content production and CDN costs sit on top of the build price.
Why do meditation apps stop playing when the screen locks?
Because background audio must be explicitly declared and correctly implemented on both platforms — an audio session category and background mode on iOS, a media-playback foreground service and media session on Android — plus handling for calls, headphone disconnects and audio focus loss. Apps that treat "plays audio" as a single task ship this broken.
How do I make meditation sessions available offline?
Choose your delivery format first: progressive audio files make offline simple, while HLS needs each platform's dedicated download API. Then build the parts people forget — a resumable download queue, a storage budget the user can control, cache eviction, invalidation when content is re-recorded, and entitlement checks that still work with no network.
How much does audio streaming cost at scale?
Do the arithmetic with your own CDN's rates: 96 kbps AAC is roughly 43 MB per hour of listening, so a 15-minute session is about 11 MB. Ten thousand users streaming twenty sessions a month is roughly 2.2 TB of egress. Encoding at a sensible bitrate and encouraging offline downloads are the two levers that cut it most.
Do I need DRM on guided meditation audio?
Usually not. Signed short-lived URLs behind a CDN stop the realistic threat — casual sharing and hotlinking — at a fraction of the cost. Full DRM with FairPlay and Widevine is worth it when a content licensing agreement requires it or you have genuinely high-value exclusive content, not by default.
Should I build for iOS or Android first?
For consumer meditation apps in the US market, iOS-first is the common default because subscription revenue per user tends to be higher there and the device matrix is far smaller. Android's background-audio behavior varies more across manufacturers, which makes it the more expensive platform to QA properly, not the cheaper one.