How Kyra stores, syncs, and locks your data

Data flow at a glance

Your device Trade entry and SwiftData database Stored inside Kyra's local app container. iCloud sync off: data stays here.

Apple iCloud Private CloudKit database Bound to your Apple ID, not a Kyra account.

Your next device Another iPhone running Kyra Restored through the same iCloud account.

No Kyra-operated server is in this path. iCloud sync is optional; when it is off, trade history remains on the device where it was logged.

Protected locally

SwiftData persists entries inside the iOS app container. Privacy Lock can require device authentication before trade content is shown.

Optional off-device copy

When iCloud sync is enabled, CloudKit stores a private database under the user's Apple ID. Kyra does not operate a trade-history server.

Verify the boundary

Network

Use App Privacy Report or a proxy to inspect destinations while logging, syncing, and viewing patterns.

Disclosure

Compare Kyra's App Privacy label with the data path and analytics description on this page.

Threats

Local protection does not replace Apple ID security or device security; those boundaries are listed below.

Storage layer

Kyra uses SwiftData for local persistence. The database file lives in the app's container on the device. Standard iOS protections apply:

File is encrypted at rest using the device's Data Protection class
File is not readable by other apps on the device (iOS sandboxing)
File is included in iCloud Backup unless the user disables it (on by default)
File is included in encrypted computer (Finder) backups

Kyra's data model covers your trades, your settings, and checklist sessions. Schema migrations happen on app version updates. SwiftData handles the migration; no data is sent off-device during the migration.

Sync layer

When iCloud sync is on, SwiftData replicates the database through CloudKit's .automatic mode. CloudKit is Apple's user-data storage layer; in .automatic mode, the data lives in the user's private database in their iCloud account.

What this means concretely:

The data is bound to the user's Apple ID, not to a Kyra account
The data is encrypted in transit and at rest under Apple's iCloud security model; users who want Apple itself locked out can enable Advanced Data Protection, which end-to-end encrypts CloudKit data
Kyra cannot read the data through any developer-accessible API — CloudKit .automatic user-private data is not surfaced to the developer
A subpoena to Apple would receive whatever data Apple has access to under their disclosure policies; a subpoena to Kyra returns nothing about your trades, because Kyra has nothing

If iCloud sync is off (toggle in Settings), trades remain on the single device they were logged on. No sync, no network traffic, no off-device copy.

Privacy Lock

Privacy Lock is the in-app authentication layer that gates trade visibility. When enabled:

Opening Kyra prompts for Face ID, Touch ID, or the device passcode
Returning to Kyra from the background re-prompts after a configurable timeout
The app switcher blurs Kyra's preview thumbnail so trade information is not visible during a swipe-up gesture
A direct deep link into a trade detail still requires authentication

The implementation uses Apple's LocalAuthentication framework. Kyra never sees the biometric data; the authentication result is a boolean response from iOS, not a credential the app stores.

Privacy Lock is a per-device setting — not synced through iCloud — so a trader can enable it on the iPhone and leave it off on the iPad if their threat model differs by device.

For the setup walkthrough, see FAQ ("How do I lock the app?").

Crash reporting

Kyra uses TelemetryDeck for anonymous analytics and Apple's MetricKit for crash diagnostics. Exactly what does and does not leave the device:

Data	Leaves the device?	Detail
Anonymous device ID	Sent	Generated by TelemetryDeck. Not the IDFA, IDFV, or anything Apple's ad system uses.
Product interaction	Sent	Which features get tapped, e.g. "trade entered via Quick P&L mode."
Crash diagnostics	Sent	Function names and call stack. No user content.
Trade content	Never	Ticker, P&L, emotion, reflection text, every field on the trade model.
User identity	Never	Apple ID, email, name.
Location	Never	Not collected.
Device serial, IDFA, IDFV	Never	Not collected.
IP address	Never	Stripped or truncated by TelemetryDeck per their policy.

Trade fields — ticker, direction, prices, P/L, emotion, execution rating, setup tag, reflections — are excluded from analytics payloads, log statements, and error messages by design. A quarterly egress audit verifies the exclusion across the codebase.

Analytics can be turned off in Kyra: Settings → Privacy & Security → Analytics. With analytics off, zero outbound data is sent from Kyra except CloudKit sync traffic (if iCloud is on).

Network behavior

Kyra is built to function fully offline. The only outbound network activity is:

CloudKit sync (only when iCloud sync is on; handled by Apple's framework, not by Kyra's networking code)
TelemetryDeck signal (only when analytics is on; one HTTPS POST per session-bounded event)
App Store software updates (handled by iOS; Kyra does not call out for update checks)

There is no third-party API call. There is no analytics SDK with its own outbound traffic. There is no ad-network beacon. There is no crash reporter that ships full device fingerprints. The list above is exhaustive.

A trader who wants to verify this can use Apple's built-in App Privacy Report (Settings → Privacy & Security → App Privacy Report on iOS 15.2+) to see Kyra's actual network destinations. The report will show Apple's CloudKit domains (gateway.icloud.com, etc.) and TelemetryDeck's ingestion endpoint if analytics is on. Nothing else.

Threat model

Kyra defends against

A malicious app on the same device. iOS sandboxing prevents other apps from reading Kyra's database.

Physical device access without your biometric. Privacy Lock gates the data behind Face ID, Touch ID, or passcode.

A shoulder-surfer in the app switcher. App-switcher blur hides the trade content.

A subpoena to Kyra. Kyra has no trade content to surrender.

A breach of a Kyra server. Kyra has no server to breach.

An ad network wanting trader-targeting data. Kyra ships no advertising SDKs.

Outside Kyra's control

A compromised Apple ID. If your iCloud is breached, synced data is at risk. The defense is your iCloud password and two-factor authentication.

A device with biometric already defeated. If someone has your unlocked iPhone, at-rest encryption cannot help. The defense is iOS-level: remote wipe, Find My.

A subpoena to Apple. Apple's policy for CloudKit user-private data governs what they release. Kyra is not in the chain of disclosure.

A malicious iCloud backup restored elsewhere. Restore your backup to a device a third party controls and they get the database. The defense is iCloud account integrity.

The threat model is honest about its boundaries. Kyra does not claim to defend against threats outside its layer.

What you can verify independently

Five things any technically curious user can check without taking Kyra's word:

The App Privacy nutrition label. Visible on Kyra's App Store listing. Compare to any competitor's label.
The App Privacy Report. Settings → Privacy & Security → App Privacy Report on iOS 15.2+. Shows Kyra's actual network destinations over the last 7 days.
Network traffic with a proxy. Use Charles Proxy or Little Snitch on a Mac to intercept Kyra's outbound traffic. Confirm: no third-party domains, no analytics beacons beyond TelemetryDeck.
The CloudKit storage class. Apple's documentation explains that .automatic mode places data in the user's private database. Kyra's mode is verifiable from the schema definitions (publicly described in /why-on-device.html).
The TelemetryDeck mode. TelemetryDeck publishes an official guide for its default privacy configuration. Kyra uses the default mode with no custom user identifier.

If any of the architecture stopped matching the description above, the App Privacy label would have to change, the App Privacy Report would expose the discrepancy, the network traffic would tell on Kyra. The story is auditable through five independent checks.

Updates to this page

When the security model changes — Privacy Lock gets a new authentication path, TelemetryDeck adds a new signal class, the threat model gains or loses a defense — this page gets updated. The version history is captured in the public changelog at Changelog.

If a vulnerability is reported, the disclosure timeline and the fix description land here. Email security disclosures to privacy@neontigerlabs.com.

The security model is small because the architecture is small. There is no backend, no account system, no ad SDK, no analytics SDK with its own outbound traffic. Each absence is a defense; together they form the privacy model explained in Why on-device. The implementation details on this page make that model auditable, not just claimed.