Privacy Policy

Effective date: 31 August 2026

In short

This policy covers the pre-release version of BearingKind Baby Sleep Tracker. The iPhone version is distributed through Apple's TestFlight for testing. The Android version is not distributed yet, and this policy describes it in advance, so that what it does with your data is written down before anyone can install it. Before general release, the app will gain cross-platform accounts and household sharing backed by BearingKind-operated services, and we will publish a revised policy describing that service before it holds anyone's data.

The pre-release app works like this. Your records live on your device. If you turn on iCloud sync on iPhone, they are mirrored to your own iCloud, which we cannot read. If you turn on the backup to Google Drive on Android, they are encrypted on your phone before they are uploaded to your own Drive, and we cannot read those either. There is no BearingKind account. The app contains no advertising, attribution, product analytics, or third-party crash-reporting code. Outside TestFlight feedback and things you choose to send us yourself, the app sends us nothing.

1. Who this policy is from

Ivan Kuindzhi
Box 69, Nalbandjan 28, 0010 Yerevan
support@bearingkind.com
+374 55 843957

"We" and "us" below mean the publisher named above. "The app" means BearingKind Baby Sleep Tracker on iPhone and Apple Watch, together with its widgets and Live Activities, and the Android version of the same app.

The Android version is not distributed yet. Where a section below describes Android behavior, it describes what that version does with your data once you install it. None of it applies to you before then. TestFlight is distributing the iPhone version today.

2. What the app records

The app records:

• About a child you add: the name you give them, their date of birth, the hours you consider night, and any reference ranges you adjust yourself.
• Sleep records: when sleep started and ended, how the record was made (by hand, from the watch, or imported), the time zone it happened in, and corrections you make later.
• Notes: free text you write, with a time and optionally an end time. The app does not restrict what you put in a note, so a note holds exactly what you choose to put in it. Nothing prompts or requires you to record anything health-related.
• Data you import from a backup file or from another app you export from.
• If you share a household: who is in it. For each person in a shared household, the app keeps the name and email address Apple's sharing system provides for them, their Apple sharing identity, their role, and whether they have accepted the invitation. Section 6 explains where this comes from and who can see it.
• Subscription status. If you buy the sharing subscription, the app keeps the record StoreKit gives it — the product, its current state, and its expiry, grace-period, and revocation dates — so it can decide whether paid sharing is on. It never holds your card details.
• Technical records the app keeps for itself: an identifier for each of your own devices so records made in two places can be merged in the right order, and a local diagnostics log of sync outcomes used to explain errors to you.

The pre-release app has no BearingKind account and does not ask you for your name, phone number, contacts, location, or photos. Turning on the Android backup connects a Google account you already have, and section 3 says what the app can and cannot see through it. It asks Google for permission to use one hidden folder and for nothing else, so it does not learn the name or the email address on that account. The names and email addresses it does handle are those of household sharing: the address you type to invite a caregiver, and the name and address Apple's sharing system provides for each participant (section 6). The general release will introduce a BearingKind account, and the revised policy will list the exact account fields before that version ships.

3. Where it is stored

On your iPhone. The app's records live in a database in the app's own storage, which the app asks iOS to keep under file protection. iOS encrypts it and keeps it encrypted while your device is locked. One technical exception is worth stating: a file the app already had open when you locked the phone can remain readable to the app until it is closed, which is what allows a running sleep timer to keep recording in your pocket. Deleting the app removes the database.

On your Android phone. The records live in the app's own private storage, which Android's app sandbox keeps unreadable to other apps on an ordinary, unrooted phone. Most Android phones also encrypt their storage, but that is the phone's doing and not something the app can promise for every device, so treat your screen lock as the protection that is actually yours to set. That directory is left out of Google's automatic cloud backup and out of device-to-device transfer, so a new phone set up from your old one does not arrive holding your child's records. The encryption key for the Drive backup is the one deliberate exception, and the paragraphs below say what happens to it. Deleting the app removes the database.

In your own iCloud, if you turn sync on. The app can mirror records to a private CloudKit database tied to your Apple Account. We cannot read that private database. Turning sync off stops the mirroring; it does not delete what is already there, which you can remove through the iOS Settings app under your Apple Account.

In your own Google Drive, if you turn the Android backup on. The Android version can copy your records to your own Google Drive, so that they survive losing the phone and so that a second Android phone on the same Google account can catch up. It is off until you turn it on, and you pick the Google account it uses.

The records themselves are encrypted on the phone before they leave. The app generates a key on the device, seals each batch of records with it, and uploads the sealed files. Google holds those files and can no more read what is in them than we can. The wrapping around them is not sealed, and the paragraph below says what that leaves visible. The phone talks to Google directly, and no BearingKind server is involved at any point.

What Google sees is what it needs to store a file. Each file has a name saying which of your devices wrote it and which stretch of records it covers, a short label the app uses to recognize it again, a size, and a time. None of that holds a child's name, a note, or a sleep record. Everything about your child is inside the sealed part.

The files go in the hidden folder Google gives each app, not into your visible Drive, and they count against your Google storage. Drive's settings list the apps that have stored data this way, and you can delete everything the app holds there from that list.

The key matters more than the files. It is never uploaded on its own and we never receive it, so a lost key means an unreadable backup that nobody, including us, can recover. Two things keep that from happening. The app shows you a recovery code when you turn the backup on and will show it again later from settings, and you keep that code somewhere safe. Android's own backup can carry the key as well, but only on Android versions where the app can insist that the backup is encrypted in a way Google cannot read. Where it cannot insist on that, the app does not put the key in the backup, and your recovery code is the way back. Transferring to a new phone from your old one deliberately does not carry the key across either: a second phone joins by scanning a code shown by the first, or by taking the recovery code you saved.

Turning the backup off stops new uploads. It does not delete what is already in your Drive, which you remove from the same settings list.

Not on our servers. The pre-release app stores nothing on BearingKind-operated services; none exist for it to use. That changes at general release, when cross-platform accounts arrive, and the revised policy will name the data categories, providers, processing locations, retention periods, and deletion and recovery behavior before any of it holds your data.

In backup files you create. The app can export everything it holds as a file, so that your records are yours to keep and to move. That file is ordinary, unencrypted JSON. Anything that opens text can read it. That is deliberate: a backup you cannot open is not a backup. It also means the file deserves the same care as any other document holding your child's information. Where it goes after the export is entirely in your hands.

4. Analytics, advertising, and diagnostics

The app has these limits:

• No analytics or product measurement. The app contains no code that records which screens you open, what you tap, or whether you come back.
• No advertising and no tracking. There are no ad networks, no attribution SDKs, no advertising identifiers, and nothing that follows you across other apps or websites.
• No third-party client crash reporter. The app does not send a stack trace or diagnostics file to a crash-reporting vendor.

The general release will add BearingKind-operated services, which will receive data from the app and may produce operational and security logs. The revised policy will define those flows, and each platform's privacy disclosures will be recalculated against the release build, before that version ships.

Apple diagnostics that are separate from the app

Everything above is about what the app does. Separately, and whatever any app contains, iOS itself may send Apple crash reports and usage statistics. Apple shows some of that information to developers, including us. Two things come from Apple's own measurement, not from any code of ours:

• Aggregate statistics in App Store Connect: roughly how many devices installed the app, how often it is opened, and how many people keep using it. These are totals and averages. They do not identify you and we cannot use them to look up a person.
• Crash reports, which describe what the app was doing when it stopped working. They contain technical state, not your records. They do not contain a child's name, notes, or sleep history.

This only happens if you have left Share with App Developers switched on, under Settings → Privacy & Security → Analytics & Improvements on your iPhone. It is Apple's switch, it applies to every app on your device, and you can turn it off there at any time. We would not know if you did.

We are telling you this because "we collect nothing" is the sort of claim that quietly stops being true at the edges, and an edge you find yourself later is worse than one we point out now.

Google's own measurement on Android

The same holds on Android, with Google in Apple's place. Google Play shows developers aggregate figures such as how many devices installed the app and how it is rated, and Android vitals reports crashes and freezes from phones whose owners have left Usage and diagnostics switched on. A crash report describes what the app was doing when it stopped working. It does not contain a child's name, notes, or sleep history, and the aggregate figures are totals that cannot be used to look up a person. The switch is Google's, it covers your whole phone, and it sits in the Android Settings app under Google, where the exact wording varies between phone makers.

Testing through TestFlight

The pre-release app is distributed through Apple's TestFlight, which is governed by Apple's own TestFlight terms and gives us more visibility than the App Store version will:

• Tester information. App Store Connect shows us the email address or name a tester was invited with (a tester who joined through a public link shows less), together with device model, OS version, and app build.
• Beta usage and crash data. Apple collects crash logs and usage statistics from TestFlight builds and shares them with us as part of the test program. TestFlight has its own data handling, described in its terms, separate from the Analytics & Improvements switch above.
• Feedback you send. TestFlight feedback — your comments and any screenshot you attach — reaches us through App Store Connect. A screenshot contains whatever is on it, so look before sending, the same as with anything in section 8.

We use all of this only to run the test program. Apple collects it as its own service, under its TestFlight terms. Where the GDPR or UK GDPR applies, we process what Apple shows us on our legitimate interest in running the test program and fixing what testers find. Tester information and beta statistics stay in App Store Connect; feedback we take out of it is treated the way section 8 treats support material: deleted once the issue it raises is closed, and no later than 12 months after we receive it. This section describes TestFlight distribution and will be removed from the policy when that distribution ends.

5. Health information about your child

Infant sleep, and anything you choose to write in a note, can be sensitive information about a child. Laws in many countries treat it as a special category needing extra protection.

In the pre-release app, no information about your child reaches us unless you choose to send it to us yourself (section 8). It stays on your device, in your own iCloud if you turn sync on, in your own Google Drive as sealed files if you turn the Android backup on, and with the caregivers you invite.

The general release will process some information about a child on BearingKind-operated services so a household can sync across platforms. That makes data minimization, access control, encryption, retention, deletion, incident response, and legal review requirements of that release, and the revised policy will set them out before the service holds anyone's records.

Two consequences worth stating plainly:

• Protect your own access. Use a device passcode, protect your Apple Account, and take care with exported backup files.
• Your own copies are the recovery path. We hold no copy of your records and cannot restore them. What can be restored is what is on your device, in your own iCloud, and in the backup files you export. The Google Drive backup restores too, but only while you still hold its key, through a phone that is already enrolled, an encrypted Android backup that carried the key, or the recovery code you saved.

6. Sharing a household with another caregiver

If you invite another caregiver, such as a partner, grandparent, or nanny, this section applies. If you never do, it does not.

Sharing is an iPhone feature today. The Android version has no household sharing in it and does not show the feature at all. Bringing sharing to Android is what the BearingKind-operated service described below is for.

How sharing works in the pre-release app. Sharing runs on Apple's CloudKit sharing. The shared records live in your own iCloud, and the caregivers you invite read and write them there. We operate no server in between and cannot read the shared database.

What sharing adds to the data. To invite someone, you enter their email address. For each participant, Apple's sharing system gives the app a name, an email address, a sharing identity, a role, and an acceptance status. Everyone in the household can see who else is in it. This is the app handling a second person's identity data — the invited caregiver's, not just yours — and it is visible to the household, not to us.

Removal and what others keep. You can remove a caregiver, and a caregiver can leave. That cuts their access to the shared records in your iCloud. Copies that left the shared database before that — an export they made, a screenshot, records still on their device — are outside anyone's technical control, so invite people you trust. If sharing ends while some records were made but not yet delivered, the app keeps those records on the device that made them for 30 days so they can be exported rather than silently lost.

What changes at general release. Household sharing will move to BearingKind accounts and BearingKind-operated services so caregivers on different platforms can share a household. The revised policy will define that contract — invitations, roles, visibility, removal, retention, export, deletion, and recovery — before the service is used.

7. Purchases

If you buy a subscription, Apple is the seller. The purchase happens through the App Store using your Apple Account. Apple handles payment, receipts, renewals, refunds, and any statutory right of withdrawal.

We do not receive your card details, and no BearingKind server receives your transaction data. The subscription-status record described in section 2 stays on your device and in your private iCloud.

In the pre-release TestFlight build, purchases run in Apple's sandbox: testers are not charged, renewals are accelerated for testing, and a test subscription does not create a paid subscription in the App Store version.

The Android version has nothing to buy in it. The subscription pays for household sharing, which the Android version does not have.

Apple's handling of the transaction is governed by Apple's own privacy policy, not by this one.

8. When you send us something

Support is a separate route by which your data can reach us.

To help with a problem, we may ask you to send a diagnostics summary or a backup file. If you send one, we receive whatever is in it. A backup file contains your child's name, date of birth, and every record and note you have written.

So:

• Sending anything is your choice. We will explain what we are asking for and why. You can decline and we will still try to help.
• Consider removing what is not needed. The backup file is plain text; a note you would rather not share can be taken out before you send it.
• We keep it only while we are working on your problem. We delete attachments and the correspondence containing them once the issue is closed, and no later than 12 months. We use support material only to answer and investigate your request.
• Legal basis, where the GDPR or UK GDPR applies. We handle an ordinary support message because it is necessary to answer the request you made of us, and because we have a legitimate interest in supporting the people who use the app. If you attach a diagnostics summary or a backup file containing health-related information about your child, that is special-category data, and we process it only with your explicit consent, given by choosing to send it, and only for the purpose of resolving your support request. You can withdraw that consent at any time by writing to support@bearingkind.com and asking us to delete it; withdrawing does not undo processing already carried out before you did.
• Where your message goes. We are based in Armenia and read support mail there. The mailbox is hosted by Apple, through iCloud+ Custom Email Domain, which handles the message in the course of delivering it to us. We do not route it anywhere else, and no other company receives it.

9. Service providers

Apple processes information for the App Store, TestFlight, purchases, and iCloud features under its own privacy policy and its agreement with you. We do not choose Apple's terms and cannot vary them on your behalf. See apple.com/legal/privacy. On iPhone, Apple is the only provider involved in running the app itself.

Google processes information for two purposes on Android, both under its own privacy policy: it holds the encrypted backup described in section 3 in your Drive, and it distributes the app through Google Play. See policies.google.com/privacy.

What we ask Google for, and what we promise about it. The app asks for one permission, to use the hidden folder Drive gives each app inside your own Drive. It asks for nothing else, so it never learns your Google name or email address. It uses that access only to store and read the backup you turned on. We use what we receive through Google's APIs only to provide the backup you turned on. We pass it to nobody, we serve no advertising with it, we run no analytics on it, and no person at BearingKind reads it, which we could not do in any case, because it is encrypted with a key we never receive. Those are the Limited Use commitments in the Google API Services User Data Policy, and they are what we hold ourselves to here.

These policy pages are a separate, smaller matter. They are static pages with no cookies, no analytics, and no advertising, delivered by Amazon Web Services (S3 and CloudFront), which processes request details such as your IP address in the course of serving a page, under its own terms. We keep no access logs of these pages, and none of those request details reach us.

The general release will add hosting and possibly other operational providers for the account service. The revised policy will name each provider, its purpose, the data it receives, its processing locations, and any international transfer mechanism.

10. Your rights

If you are in the EU, the UK, or another place with similar law, you have rights to access, correct, delete, restrict, object to, and port your personal data.

In the pre-release app, your records are under your direct control:

For support material sent under section 8, and for TestFlight feedback, write to support@bearingkind.com.

No sale or targeted-advertising feature exists or is planned. The general release will hold account data on BearingKind-operated services, and the revised policy will give service-side instructions for access, correction, export, deletion, restriction, objection, and consent withdrawal, and will complete each region's disclosures from the release data inventory.

If you think we have got any of this wrong, tell us first. You also have the right to complain to your national data protection authority.

11. Children

The app is designed for parents and caregivers to use. It is not directed at children and children are not its users.

It does hold information about a child, entered by you. This policy treats that information as sensitive throughout, even though the person using the app is an adult. The app is rated 4+ and is not published in the Kids Category.

12. Changes to this policy

If we change this policy, we will publish the new version at https://bearingkind.com/baby-sleep-tracker/privacy with a new effective date. The revision for the general release, covering the account service, will be published before that service holds anyone's data.

We will describe material changes to account storage, household sharing, analytics, advertising, or crash reporting before they take effect when the law or platform rules require notice or consent. We will not rely on a quiet policy edit to introduce a materially different use of child or household data.

13. Contact

Questions about this policy, or about anything in it:

support@bearingkind.com
Ivan Kuindzhi
Box 69, Nalbandjan 28, 0010 Yerevan\