What a "Heartbeat" Actually Is
A heartbeat, in the monitoring app world, is just a small automatic message a phone sends out on a schedule. No user interaction required. Every 10 minutes, every 30 minutes, every hour — the app wakes up, posts a few lines of data to a server (battery level, last screen unlock, GPS coordinates, whatever the app tracks), and goes back to sleep. The caregiver's dashboard refreshes. The dot stays green. Everything is fine.
The value isn't in any single ping. It's in the absence of one. If the phone goes quiet for three hours when it's usually chatty every 30 minutes, something changed. Maybe the battery died. Maybe the person fell. Maybe they drove into a dead zone. The gap is the signal. That only works if the heartbeats were actually running in the first place.
What Android Lets You Do
On Android, a third-party developer can register what's called a foreground service — a persistent background process that keeps running even when the app isn't open. The catch is transparency: Android requires it to show an ongoing notification in the status bar so the user always knows something is running. It's a reasonable tradeoff. The app runs, the user sees it running, and the heartbeats go out like clockwork.
A caregiver monitoring app built for Android can reliably post a check-in every 30 minutes, every hour, whatever the developer sets. The schedule is the schedule. If the phone has signal and battery, the ping goes out. You can set your watch to it — which is exactly the point when you're watching for gaps.
What Apple Lets You Do (And the Catch)
iOS has a feature called Background App Refresh, and it sounds like it does the same thing. It mostly doesn't — at least not for this use case. Apple's system decides when to wake a third-party app in the background based on usage patterns, battery state, network conditions, and factors Apple hasn't fully documented. A developer can request background time. iOS decides whether to grant it, and when.
In practice this means a third-party monitoring app on iOS might check in every 30 minutes — or it might not check in for two hours. There's no reliable schedule. The system defers, batches, and skips background tasks based on its own judgment. If the phone is in Low Power Mode, background refresh for most third-party apps stops entirely. If the phone hasn't been used recently, iOS may decide the app doesn't need to run. The developer has no override.
Apple's Own Apps Play by Different Rules
Here's the part that tends to surprise people. Apple's own location-sharing tools — Find My, Family Sharing, the Crash Detection and Emergency SOS features built into iPhone and Apple Watch — don't go through the same Background App Refresh queue that third-party apps use. They operate at the system level, with privileged access that Apple doesn't extend to outside developers.
Find My can show you where an iPhone is right now with reasonable accuracy because it has hooks into the OS that no app from the App Store can touch. An independent developer building a caregiver app can't replicate that, no matter how well the app is written. They're working with the tools Apple gives them, which are intentionally limited. Whether that's a reasonable privacy and battery tradeoff or a competitive moat dressed up as policy is a debate worth having — but the technical reality is the same either way.
The Hiker in the Crevice
Imagine someone solo hiking. They've got a safety app installed that's supposed to ping their emergency contact every 30 minutes. They slip, injure an ankle, and can't move. The phone has signal and 60% battery.
On Android, the app keeps running. Pings go out at 30-minute intervals. After 90 minutes of no movement and no screen activity, the caregiver's dashboard flags the gap and fires an alert. Someone knows to call for help.
On iPhone, the same app is subject to iOS's background scheduling. The phone hasn't been touched in an hour, so iOS deprioritizes background tasks for apps the system deems "inactive." The pings slow down or stop. The caregiver's dashboard sees a gap — but gaps happen on iOS all the time, for completely mundane reasons, so the threshold for an alert is set high to avoid false alarms. The hiker waits.
This isn't a hypothetical designed to make Apple look bad. It's a real architectural constraint that anyone building a safety or monitoring app for iOS has to design around, usually by relying on push notifications from a server (which require the server to already know something is wrong) or by asking users to open the app regularly to refresh it manually — which rather defeats the purpose.
Where Pixel Fits In
Google's Pixel phones run stock Android, which makes them the cleanest version of the Android story above. The foreground service model works as documented. No extra battery optimization layers, no manufacturer-added process killers, no surprises. If you're building or choosing a monitoring app, a Pixel running stock Android is about as predictable as it gets on the background-process question.
Samsung, on the other hand, runs its own Android flavor (One UI) with its own aggressive battery management on top of Google's. Older Samsung devices were notorious for killing background processes more aggressively than the Android spec intended, which caused third-party apps to miss their heartbeat windows even on Android. Samsung has improved this significantly in recent years, but it's worth knowing that "Android" isn't a single consistent behavior — stock Android and manufacturer-skinned Android can behave differently enough to matter.
The Workaround Apple Developers Actually Use
Since a reliable scheduled heartbeat isn't available, iOS developers building safety apps have to flip the model: instead of the phone pushing data out, the server pushes a silent notification in to wake the app. Apple provides this — it's called a "content-available" push notification, and it can wake a sleeping app briefly to let it report in. The server sends a ping to the phone; the phone wakes, checks in, goes back to sleep.
It works, but it introduces a dependency: the server has to be the one initiating contact, on a schedule, for every monitored device. It also means the app's check-in frequency is limited by how aggressively Apple allows silent pushes (which it rate-limits), and the whole thing falls apart if the phone is in Do Not Disturb, has notifications disabled for the app, or is in a poor signal state when the push arrives. It's a workable architecture, but it's more fragile than a straightforward scheduled heartbeat, and the developer has to build and maintain the server-side push infrastructure to make it run.
What This Means If You're Choosing a Phone for Safety Reasons
If the specific use case is passive monitoring — a phone that reports in on its own, without the user doing anything — Android (especially stock Android or a recent Pixel) is the more reliable platform today. The architecture supports it. A well-built Android monitoring app can maintain a consistent heartbeat schedule that the caregiver's side can trust.
On iPhone, the same category of app is working around platform limitations by design. That doesn't make the apps bad — some are well-engineered and the workarounds are solid. But the floor of reliability is lower, and the behavior is less predictable. If Find My and Apple's own ecosystem tools meet your needs, they work well. If you need a third-party app to run background checks on its own schedule, iOS is the harder platform to build that on — and to depend on.
The gap between what Apple's own apps can do and what third-party apps can do is real, documented, and not an accident. It's worth understanding before you hand someone a phone and tell them it'll check in every 30 minutes.