The parts that would matter if we were wrong.

Most security pages say "bank-level encryption" and stop. This one describes the iPhone and Apple Watch app, in enough detail that somebody who knows the field could tell if it were not true.

On your phone

Encrypted where it lives.

  • The system encrypts it, and the app asks it to. Your profile, allergies, readiness readings, training history, logged sets and the coach's notes live in one document in the app's private storage. It is written with iOS Data Protection, at the class Apple calls complete protection until first user authentication: encrypted at rest with a hardware-backed key, and unreadable after a restart until you unlock the phone once.
  • That is not the strongest class, and the reason is worth knowing. The strongest one seals the file again every time the screen goes off, which would silently drop the workouts arriving from Apple Health, from background refresh and from the Watch while the phone is in your pocket. The window traded away is the gap between a restart and your first unlock. Losing your training quietly is the worse failure.
  • Excluded from backup, at the folder. The directory is marked excluded, so neither iCloud backup nor a Finder backup captures it. Marked on the folder rather than on each file, because per-file is the version somebody forgets the second time they add one. Deleting the app removes this local copy.
  • No third-party SDKs. Not "none for tracking", none. No analytics, no crash reporting, no advertising, no attribution. The app links Apple's own frameworks and one Kotlin engine we wrote, and nothing else.
  • Device authentication in front of the app, described as what it is. Optional, using Face ID, Touch ID or the device passcode as available. It is useful when you hand somebody your unlocked phone. It is not encryption and is not sold as encryption.
  • Core training works offline. Planning, guidance and local records remain available signed out and without internet. Store purchases, manual iCloud actions and Sign in with Apple need Apple's services, while direct phone transfer needs the local network.

When you export

Sealed before it moves.

  • Your passphrase, not our key. The export is one file with everything in it, sealed on the phone: AES-256-GCM, with the key derived by PBKDF2-HMAC-SHA256 at 210,000 iterations over a salt generated fresh for every file. The primitives are Apple's CryptoKit and CommonCrypto, not something hand-rolled here.
  • Tampering is detectable, not just unlikely. GCM authenticates the file, so one that was edited or corrupted fails to open rather than restoring something subtly wrong. A wrong passphrase and an altered file report the same failure on purpose, because telling them apart would leak more than it helps.
  • We cannot open it. There is no copy of your passphrase anywhere, and a forgotten passphrase makes the file unrecoverable. Persto advises keeping the export off cloud drives and shared storage because it contains your complete record, even though the file is encrypted.
  • Restoring is always free. Export and restore are not part of Persto Plus, and they never will be.

Moving to a new iPhone

Handed over, with nothing left behind.

This is the one path where your health data leaves the phone, and it leaves because you started it, to a device you are holding.

  • Local network only. The payload goes straight from one iPhone to the other over the local link, held in memory on both sides. No server and no file, so there is nothing sitting in a cloud drive to be found in two years. Removing that durable artefact is the whole point of the feature.
  • Encrypted anyway, keyed by a one-time code. The same AES-256-GCM envelope goes over the wire, keyed by a 16-character code the sender reads out. A receiving phone without the code cannot open the payload.
  • Both ends request device authentication. Face ID, Touch ID or the device passcode is used as available on the sending and receiving phones. Sending is the dangerous direction, because that is the phone with the data on it.
  • Bound to your Apple ID. If you signed in with Apple, that app-scoped identifier travels inside the sealed payload, and a phone holding a different one refuses the data rather than applying it.
  • Torn down when it finishes. The receiver acknowledges, the connection closes and the payload is dropped on both sides. Local network permission is asked for when you start a transfer, not at launch.

iCloud

Your setup can be saved. Your body cannot.

Manual, free and performed only when you choose Save, Restore or Delete.

  • What crosses: only your display name and chosen coach voice. Persto seals one payload with AES-256-GCM before writing it to your iCloud key-value store. Its separate random key is kept in your synchronizable iCloud Keychain.
  • What never crosses: training setup, wake settings, Health readings, body measurements, goals, allergies, the readiness log, training history and every logged set. Those categories are named as excluded in the code and covered by tests.
  • Why the line is drawn there. App Review guideline 5.1.3(ii) says an app may not store personal health information in iCloud, and there is no carve-out for encryption. Encryption changes who can read data, not where it lives, and the key-value store is iCloud. Complete health and training data therefore stays out of Persto's iCloud store and moves only through an export or direct transfer the user explicitly starts.
  • No background synchronization. Every screen reads the local document. Setup is copied to iCloud only when you tap Save, and the local setup changes from iCloud only when you tap Restore. Delete removes the saved payload and key without changing local setup.

Where AI is not allowed

Some answers must not be a guess.

Readiness, progression, whether a session counts as completed, and the calorie floor are deterministic code in the engine both apps share, pinned by test vectors. The coach's reply is written on the phone by Apple's on-device model from the local context Persto provides. The model can be wrong, does not diagnose, and cannot override deterministic safety or completion rules. There is no cloud coach anywhere in the product.

The coach cannot write anything either. It can propose exactly four settings, all of which already exist on the settings screen, and you confirm before any of them change. Allergies and body measurements are not on that list. The coach memory uses local filters intended to reject allergies, medication, injuries and measurements, but generated text and filters can be wrong. Do not use coach memory to store safety-critical health information.

This website

A separate thing, kept small.

  • The app does not talk to this site. It links here, and that is the whole of the relationship. Nothing you do in the app reaches this domain.
  • HTTPS with HSTS for a year, and a content security policy that allows scripts only from this origin plus three pinned hashes. No third-party scripts, fonts or images, anywhere on the site.
  • Two forms, one destination. The early access form sends an email address and the bug report form sends what you typed, both to a single endpoint named in the policy. The policy permits no other destination, so a script that tried to send your input elsewhere would be blocked by the browser.

Tell me, and I will say what I fixed.

There is no security bounty program today. What we can promise is a real reply from the person who wrote the code and a straight answer about what was fixed.

Persto is a young app and a separate Android build is in closed testing. Please keep your own encrypted export if the record matters to you, and do not include health records or other sensitive information in a security report.

Report an issue Read the privacy policy