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.

ArchitecturePrimary copyDeveloper can read recordsAccount required
Device onlyOn the deviceNoNo
Device plus private sync (CloudKit)On the device, copied to your iCloudNoApple Account only
Server-backedCompany databaseYes, subject to their policyYes

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.

  1. Does it require an account? A required account means a server-side identity, which means a database with your records tied to an identifier.
  2. Does it work fully offline? Full offline function is strong evidence that the primary copy is local.
  3. 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.
  4. 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.

CopyCreated byExposure if breached
App container on the deviceNormal useNeeds physical access and your passcode
iCloud private databaseSync turned onTied to your Apple Account security
Device backupiCloud or computer backupDepends on backup encryption settings
Developer's serverServer-backed appsEveryone in that database
Analytics providerEmbedded SDKsUsage 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

Records are created and stored on your device as the primary copy, and any sync goes through your own account rather than a company database. The practical test is whether the app works fully with no account and no network connection.

Usually not. HIPAA applies to covered entities such as clinicians, health plans, and clearinghouses, and to their business associates. An app you download and fill in yourself typically falls outside it, which is why HHS publishes guidance on when health apps are and are not covered.

No. CloudKit sync stores records in your own iCloud account, so the developer does not receive a copy the way a server-side database would. It is still a network service with its own security model.

Whether the app requires an account, whether it works offline, whether you can export everything in a readable format, and whether you can delete everything including any server copies. Then check for analytics or advertising SDKs.

Lose the device with no backup and the data is gone. Using a second device needs a working sync path. Sharing with a clinician needs an explicit export. And features that need server computation are harder to build.

With a local-first app, the records stay on your device and any export you made stays valid. With a server-based app, access depends on the company, which is why a working export matters before you need it.

Sources

About the author. Max Grev is the founder of Vitadel, the company behind Vitadel Run and Vitadel Protocol.

Related guides

Start logging without an account

Vitadel Protocol is local by default: your protocol stays on your iPhone unless you turn on backup.