Private Health Tracking on iPhone: Local-First vs Cloud Peptide Apps
By Max Grev, Founder of Vitadel · 7 min read · Published · Updated
Local-first apps keep the primary copy of your records on the device and sync, if at all, through your own iCloud account. Cloud apps keep them in a company's database under that company's terms. That choice decides who has to be breached for your log to leak, whether an account is required, and how deletion and export work.
For peptide and GLP-1 logs, which hold medication details most people do not want in a marketing database, the architecture matters more than any feature list.
What local-first means
Local-first means the authoritative copy of your data lives on your device. Sync, when present, copies that data to your other devices through infrastructure you control, such as CloudKit inside your own iCloud account, rather than to a server the developer runs.
There is a simple test that cuts through marketing language. Put the phone in airplane mode and try to create and read a record. If the app needs an account to open and cannot work without a network, the primary copy is not on your device, however the privacy page is worded.
Three architectures cover nearly everything on the App Store.
| Architecture | Primary copy | Developer can read records | Account required |
|---|---|---|---|
| Device only | On the device | No | No |
| Device plus private sync (CloudKit) | On the device, copied to your iCloud | No | Apple Account only |
| Server-backed | Company database | Yes, subject to their policy | Yes |
None of these is automatically right. They fail in different ways, and the point is knowing which one you chose.
HIPAA probably does not cover your app
HIPAA applies to covered entities, meaning clinicians, health plans, and clearinghouses, plus their business associates. A consumer app you download and fill in yourself is generally not one, which is why the HHS Office for Civil Rights publishes dedicated guidance on when health apps fall inside or outside the rule.
What applies instead is a patchwork. The FTC's Health Breach Notification Rule requires certain non-HIPAA health apps to notify users about unauthorized disclosures, and the FTC has brought enforcement actions over health data sharing. State privacy laws add requirements that vary by where you live. Apple's App Store rules restrict some uses of health data by developers.
Your protection therefore depends mostly on the app's own architecture and policy, not on a health-specific legal shield you might assume exists.
Four questions before you log anything sensitive
Ask these in order, because the first answer often settles the rest.
- Does it require an account? A required account means a server-side identity, which means a database with your records tied to an identifier.
- Does it work fully offline? Full offline function is strong evidence that the primary copy is local.
- Can I export everything? A complete export in a portable format, such as CSV or PDF, is your exit and your route to sharing with a clinician.
- Can I delete everything, and where does deletion apply? Local deletion is easy. Whether it reaches server copies and backups needs an explicit answer.
Two follow-ups are worth the extra minute. Does the app embed analytics or advertising SDKs, which send usage data to third parties even when your log content stays local? And does it ask for Health app permissions broader than the feature needs?
Where the copies live
Data location determines exposure, so it helps to list the copies that can exist.
| Copy | Created by | Exposure if breached |
|---|---|---|
| App container on the device | Normal use | Needs physical access and your passcode |
| iCloud private database | Sync turned on | Tied to your Apple Account security |
| Device backup | iCloud or computer backup | Depends on backup encryption settings |
| Developer's server | Server-backed apps | Everyone in that database |
| Analytics provider | Embedded SDKs | Usage patterns, sometimes more |
iOS encrypts device storage with keys tied to your passcode, so a locked device with a strong passcode is a real barrier, as Apple's Platform Security Guide describes. That protection assumes a passcode nobody else has and backups that are themselves encrypted.
The iCloud middle ground
CloudKit private sync differs in kind from a developer-run server. Records go into your iCloud account, so the developer never receives them, while you still get access from a second device and a recovery path if the phone is lost.
iCloud is still a network service with its own account-recovery process. If you use it, two settings do most of the work: a strong, unique Apple Account password with two-factor authentication, and knowing which categories your backup includes. Advanced Data Protection changes the encryption posture for many iCloud categories. Read Apple's documentation on what it covers rather than assuming.
A device-only app with no sync has the smallest exposure and the largest data-loss risk. Decide which you would rather manage instead of leaving it to a default.
Export and deletion are the rights that matter
Export lets you leave, share with a clinician, and keep a copy independent of any company. Deletion is how you end the relationship.
Test both while you are still deciding, not after months of entries. Generate an export and open it. Confirm it holds your real data with dates, doses, concentrations, and notes rather than a summary. Then read what the app says happens on deletion, including retention windows for server copies and whether backups are covered.
If an app cannot produce a full export, the data is effectively hostage. If it cannot describe deletion clearly, assume copies persist.
Reading an App Store privacy label
App Store privacy labels are developer-declared summaries of what an app collects and whether that data is linked to your identity or used for tracking. They are a screening tool, not an audit.
"Data Not Collected" is a strong claim. Check it against whether an account is required. "Data Linked to You" that includes health or fitness categories means records are tied to an identity somewhere. "Data Used to Track You" means an advertising or cross-app identity graph is involved, which rules the app out for most people logging medications.
Then check the two things labels never tell you: whether the app works offline, and whether an export exists.
Trade-offs of local-first, stated plainly
Local-first buys a smaller attack surface and costs convenience in specific places.
- Device loss. With no sync and no backup, the record is gone. Pick a backup posture on purpose.
- A second device. Reading your log on an iPad needs a sync path.
- Sharing. A clinician gets a file you generate, not a portal login.
- Server-side features. Anything that needs central computation is harder to build.
- Web access. Usually there is none, by design.
Vitadel Protocol stores records on the iPhone by default, needs no account to start, and offers sync as an opt-in through your own iCloud account rather than through Vitadel's servers. Export produces PDF, CSV, or JSON files you can hand to a clinician or keep as a backup. Hold it to the four questions above, the same as any other app.
FAQ
Sources
About the author. Max Grev is the founder of Vitadel, the company behind Vitadel Run and Vitadel Protocol.
Related guides
- How to Log a Peptide or GLP-1 Dose So You Can Trust the Record
Six fields, written down at the moment of injection, turn a pile of entries into a record you can hand to a clinician.
- How to Read Peptide Research: A Five-Minute Source Check
Species, sample size, endpoint, publication status, and funding: five questions that resolve most peptide claims in five minutes.
- Vial Inventory: How to Track Reconstituted Peptides
Four fields per vial replace the spreadsheet, and remaining doses become arithmetic instead of a guess.
Start logging without an account
Vitadel Protocol is local by default: your protocol stays on your iPhone unless you turn on backup.