DEV Community: SleepTrace

Overnight mobile sensing without murdering the battery: field-tested tactics

SleepTrace — Mon, 06 Jul 2026 16:35:53 +0000

Battery is the silent killer of always-on mobile sensing. If your app records or samples through the whole night, you are one bad release away from a 40% overnight drain and a one-star review that just says "killed my battery." Some hard-won tactics.

The budget mindset

Treat energy like a memory budget. Every wakeup, every sensor poll, every network call has a cost. The goal is not zero cost - it is predictable, disclosed cost. Users forgive "uses ~8% overnight" if you tell them; they do not forgive a surprise.

Concrete tactics

Batch, do not stream. Buffer samples and process in chunks instead of waking the CPU continuously. Coalesced work is far cheaper than the same work sprinkled across the night.
Downsample aggressively. Full-resolution capture is rarely needed end to end. Capture high, immediately reduce to the features you actually use, discard the rest.
On-device beats network. Classify locally and upload summaries, not raw data. Radios are among the most expensive things you can touch; a nightly sync of small summaries costs a fraction of streaming.
Respect thermal and low-power state. Back off when the OS signals low-power mode. Fighting it drains battery and gets you throttled anyway.
Measure on real devices. Simulators lie about energy. Profile an actual older phone across a full night before shipping.

Why it is worth the effort

Overnight sensing only delivers value if users leave it on, and they only leave it on if it does not cost them their morning charge. For sleep specifically, the payoff is capturing events other sensors miss - the acoustic ones like snoring and breathing pauses covered in this overview of snoring vs. sleep apnea.

What is your worst overnight-battery war story?

The sleep score is the least honest number in your health app

SleepTrace — Mon, 06 Jul 2026 16:35:30 +0000

Consumer sleep apps love a single number: 82, 78, "your sleep score." As someone building in this space, I want to make the case that the score is often the least honest thing on the screen.

Why one number is seductive and wrong

A score compresses a messy, multi-dimensional night - duration, continuity, stage distribution, disturbances - into a scalar you can feel good or bad about. That is great for engagement and terrible for truth. Two very different nights can produce the same 78, and a small model change can move the number without anything about your sleep changing.

What the number hides

Continuity vs. duration: eight fragmented hours and seven solid ones can score similarly, yet feel nothing alike.
Confidence: the app rarely tells you how sure it is. A stage estimate from wrist motion is a guess with wide error bars, presented as a fact.
Events: the actually-actionable stuff - a snoring cluster at 2 a.m., a long awakening - gets averaged away into the score.

A more honest UI

Show the timeline, not the trophy. "Here is when you were restless, here is a disturbance at 03:14" beats "your score is 78" because it is falsifiable and useful. Users can act on an event; nobody can act on a decimal.

The clinical reason the audible events matter - especially for apnea screening - is summarized in this overview of snoring vs. sleep apnea.

How does your product handle the tension between a friendly single metric and honest uncertainty?

Sleep-stage detection is mostly inference. Be honest about it.

SleepTrace — Mon, 06 Jul 2026 14:04:22 +0000

Sleep-stage classification is where a lot of consumer sleep tech quietly cheats. A quick tour of the honest-vs-hand-wavy spectrum, from someone who has stared at too many hypnograms.

The ground truth nobody ships

The clinical gold standard is polysomnography: EEG, EOG, EMG, scored in 30-second epochs by a human. No wrist wearable or phone reproduces that. Anything claiming "REM detected" from a single accelerometer is estimating, and the honest ones say so.

What each signal can and cannot do

Actigraphy (motion): decent at sleep-vs-wake, weak at staging. It infers deep sleep from stillness, which fails for anyone who lies still while awake.
Heart rate / HRV: adds real signal - autonomic tone shifts across stages - but the mapping is probabilistic, not deterministic.
Audio: the underused one. It cannot stage sleep on its own, but it directly captures events other sensors only infer: snoring intensity, breathing pauses, movement, environmental disturbance. Events, not stages.

The design lesson

Do not oversell staging. Report what you actually measured (an audio event at 03:14, a long quiet stretch, a cluster of arousals) and be honest about what you inferred. Users trust "here is what happened" more than "your REM was 18%" - especially when the second number is a model's guess.

The clinical background on why the audible events matter, particularly for apnea screening, is in this overview of snoring vs. sleep apnea.

Curious how others handle the honesty-vs-simplicity tradeoff in sleep UIs - what does your app claim vs. measure?

Field notes: all-night audio recording on iOS without dying in the background

SleepTrace — Mon, 06 Jul 2026 13:46:42 +0000

Keeping a microphone alive all night on iOS sounds trivial and is not. Some field notes from building an audio-first sleep tracker, for anyone fighting the same OS behaviors.

The problem

iOS suspends backgrounded apps aggressively. An AVAudioSession with the playAndRecord category keeps you alive - until the user locks the phone, another app grabs the session, or the system decides you are idle. Result: silent gaps in the night you only discover in the morning.

What actually works

A keep-alive audio node. A muted output node on the audio graph signals "actively doing audio" to the OS. Without it, recording-only sessions get reaped on lock on some OS versions.
Interruption handling as a state machine. Calls, alarms, Siri, CarPlay handoffs - each fires AVAudioSession.interruptionNotification with slightly different resume semantics. Treat resume as maybe: re-activate, verify input, and log the gap if re-activation fails.
Watchdog timestamps. Write a heartbeat every N seconds. Morning-after, the gaps between heartbeats tell you exactly when and how long recording was dead - which is also honest UX: show the user the gap instead of pretending the night was complete.
Battery discipline. Process in chunks, classify on-device, discard raw audio you do not need. A full night of raw PCM is storage and battery poison.

Why bother

Because the acoustic events - snoring patterns, breathing pauses, sleep talking - are the part of the night that motion sensors cannot see. The clinical background on why those sounds matter is summarized in this overview of snoring vs. sleep apnea.

Questions about the audio session details welcome - happy to share more specifics in the comments.

Why we built an audio-first sleep tracker (and what it taught us about on-device ML)

SleepTrace — Mon, 06 Jul 2026 11:54:14 +0000

Most sleep apps work like this: a motion sensor or heart-rate curve feeds a model, the model guesses your sleep stages, and you get a score in the morning. The score might say 78. What it can't tell you is why.

We build SleepTrace, an audio-first sleep tracker, and this post is about the engineering reasons we bet on sound instead of another wearable.

The signal nobody records

The events that actually destroy sleep quality are acoustic:

snoring (intensity, patterns, position-dependence)
gasping / breathing pauses that may warrant a doctor visit
sleep talking and grinding
environmental noise: partner, street, pets

A phone microphone on the nightstand captures all of these. A wrist wearable captures none of them directly — it infers downstream effects (movement, heart rate) and guesses at the cause.

Evidence beats scores

The product insight: people act when they hear a 20-second clip of their own 3 a.m. snoring. Nobody changes their behavior because a number dropped from 82 to 78. So instead of leading with a score, the app leads with an audio timeline of the night — the moments worth hearing, classified on-device.

The hard constraints

All-night recording on iOS/Android without draining the battery. Background audio sessions, watchdog timers, and OS-specific keep-alive quirks are half the codebase's gray hair.
On-device classification. Recording a bedroom is the most privacy-sensitive thing an app can do. Clips are processed locally; nothing leaves the phone without explicit opt-in. Privacy has to be structural, not a checkbox.
Storage discipline. A full night of audio is large. We keep event clips, not raw nights.

What the literature says

Acoustic analysis is a legitimate screening signal — snoring characteristics and audible breathing pauses correlate with apnea-hypopnea severity. We collect the relevant studies with citations on the SleepTrace sleep science blog if you want to dig into the research side.

Happy to answer questions about background audio sessions, on-device audio ML, or the privacy architecture in the comments.