HealthKit is free. It ships with iOS, it reads the phone's health store, and Apple charges nothing for it. So the $299 to $499 a month that cloud health-data APIs publish is not paying for Apple Health data. It is paying for someone else's pipe, storage, and per-user metering on data the phone already holds.
I read the vendor pricing pages and wrote up the arithmetic. Three things stood out.
1. The entry tier is not the price. Published entry tiers are the floor. The per-user caps and overage meters are where a small product's bill actually lands, and they scale with the thing you most want to grow.
2. The seat matters more than the rate. A cloud API puts a processor between the phone and your server. Every read crosses a meter. The same read, done on-device, crosses nothing.
3. On-device is not anti-cloud. For some products a cloud pipeline is still the right call: multi-tenant analytics, web dashboards, batch ML. The question is whether your core loop needs a server in the path at all.
The full breakdown, with the vendor tiers quoted and the cases where cloud still wins, is here: https://www.healthexport.dev/blog/apple-health-api-pricing
I maintain MetricBridge, an open-source MCP server that reads 190 Apple Health metrics locally and hands them to any agent, so I have a stake in this. The arithmetic stands on its own though. Read the pricing pages.
Top comments (0)