Oratide — Privacy Policy

Effective 31 October 2026 (2026-10-31), for the Google Play build and the iPhone app on the App Store, each of which sells Oratide's one-time $9.99 unlock. Sixth version — see the change log.

Oratide is a Catholic fixed-hours prayer app: a bell at the hours you set, and the prayer for that hour. This document says what the app does with information, in plain words. Every statement in it is a statement about the code as it exists on the date above, and each one can be checked against that code.

Made by chibu. Questions go to support@chibuapps.com. A person reads them.

The short version

Oratide has no account and no server. Everything you put into it — your hours, the names you pray for, the record of days if you choose to keep one — is written to the app's own storage on your device, and it stays there. Nothing is uploaded, because there is nowhere for it to go. There are no analytics, no advertising and no crash reporter. The one piece of third-party code in the Android app that can speak to anyone is Google's Play Billing Library, which talks only to Google Play, when you buy or restore the $9.99 unlock and when the app checks it (§9). In the iPhone app, buying goes through Apple's StoreKit, between your phone and the App Store, and nothing about it is sent to us (§9). You can export all of it as a plain file whenever you like, and you can erase it.

In the Android app, if you turn bells on as system notifications, the times of your hours are handed to Android on the same phone, so that a bell can sound with the app closed. That needs no server and sends nothing anywhere (§6). In the iPhone app, turning them on hands iOS the times of your next bells, at most 58 at a time, on the same phone; that sends nothing anywhere either. Push from a server is a different thing, and Oratide has none (§7).

That is the whole policy. The rest is detail, for anyone who wants to check it.

1. What this covers

• The Android app on Google Play, package com.chibuapps.oratide. Inside it is a web app in a thin shell (Capacitor), and the shell carries three Capacitor plugins: one that hands your hours to Android so that a bell can sound with the app closed, one that tells the app when it comes back to the screen, and one for buying the unlock through Google Play (§2, §9). Nothing else is added.
• A web version, if one is ever published. None is published today: the page at https://chibuapps.com/oratide describes the app and is not the app. §12 says what would change if a web version were published.
• The iPhone app on the App Store, bundle ID com.chibuapps.oratide (added 2026-10-31). It is the same web app in the same shell (@capacitor/ios in place of @capacitor/android), with the same three plugins. It too has no account, no server and no analytics, and collects nothing. Buying the unlock goes through Apple's StoreKit, between your phone and the App Store, and nothing about it is sent to us (§9). Where a section below says "the Android app", it describes the Android app only.

2. What Oratide does not do

Each line here is a fact about the code, not a policy that could be quietly changed.

• No account. Nothing asks who you are. There is no sign-up, no email address, no name, no age, and no question about your religion.
• No server of ours. There is no backend. The app has no address to send anything to.
• No analytics. No usage events, no session recording, no crash reporting, no attribution or advertising identifiers, no experiments run on you.
• No advertising, and no slot in the interface that an advertisement could be put into.
• No analytics, advertising or tracking SDKs. The shipped web app has exactly two runtime dependencies, React and React DOM — open-source libraries that draw the screens and make no network requests. The Android app adds the Capacitor shell (@capacitor/core, @capacitor/android), an open-source container that carries the web app; it is not a service.
• Three Capacitor plugins are compiled into the Google Play build, and each is named here with what it does. @capacitor/local-notifications hands the times of your hours to Android so that Android can post each bell (§6). @capacitor/app tells the app when it comes back to the screen, so that the bells Android is holding can be checked against the hours you have set. Those two talk to Android on the phone and to nothing else. capacitor-plugin-cdv-purchase is the billing plugin (§9); it brings with it Google's Play Billing Library, the standard way an Android app asks Google Play to sell something, which talks to the Google Play Store app on the phone and through it to Google. The app calls the billing plugin to sell, restore and check the one-time unlock, and the library connects only to Google Play (§9). The About screen lists the two web libraries, the shell and the three plugins, and a test fails the build if that list drifts from the real dependency manifests.
• No third-party network requests. The app's Content-Security-Policy lets the page connect only to the host it is served from, and in the web version its service worker answers any GET request bound for another host locally with a 403 rather than letting it reach the network. The app has no code path that wants such a request; the refusal is there so that one could never slip in unnoticed. The three plugins make no network request of their own in this build.
• No access to your location, contacts, camera, microphone, photos, calendar, or files — except a single file you yourself choose when you import an Oratide export.
• No selling, sharing, or brokering of anything, because nothing is collected.

3. What is kept on your device

Everything below lives on the device you are using. None of it is sent anywhere.

Where it is. All of it is one document in the browser's local storage, under the key horarium.state. Before a migration, an import, or an erase, a copy of the previous document is written to horarium.backup. If the app ever finds a document it cannot read, it moves it to horarium.quarantine and starts clean, rather than deleting it. The app's own files are also kept in the browser's cache so that it opens with no network. In the Android app, "the browser" is the app's private WebView, whose storage belongs to the app alone.

The bells Android holds. In the Android app, while bells are on as system notifications (§6), the notifications plugin keeps its own copy of each bell it has handed to Android — the name of the hour, the time, the sound, the three buttons, and which hour it belongs to — in the app's private storage, so that it can hand them back to Android after the phone restarts; Android's alarm service holds the times. That copy is never sent anywhere. Turning the bells off cancels them and deletes it, and uninstalling the app removes it.

How it is protected. By your device: its lock screen, its app sandbox, and its disk encryption if it has it. Oratide does not add a cipher of its own on top of that. Anyone who can get past your lock screen and open the app can read what is in it, the way anyone who opens your missal can read the card inside. If a name is sensitive, treat the note field accordingly and use the device lock.

How it could be lost. Browsers can discard a site's storage: when you clear browsing data, and in some browsers after a long stretch without opening the site. An installed app is far less exposed to this than a browser tab, but the only copy we can promise you is the one you export (§10).

Android backup. The Android app allows Android's own backup. If you have backup to your Google account switched on for the device, Android may include Oratide's data in that backup. That copy is made by Android, under Google's terms and Google's encryption, not by Oratide, and you control it in your device's Settings under Google → Backup.

iPhone backup. In the iPhone app, if iCloud Backup is on for the iPhone, iOS may include Oratide's data in that backup. That copy is made by iOS, under Apple's terms and Apple's encryption, not by Oratide, and you control it in the iPhone's Settings.

4. Intentions — the names you carry

The names you pray for never leave the device. There is no code in the intentions feature that touches a network, and no network for it to touch.

They are yours to take with you, always. From the Intentions screen and from Settings you can export them as plain text (readable on any machine, printable, fit for a missal) or as JSON (which comes back in whole). There is no entitlement check anywhere in the export code, and there is deliberately no place to put one. The free tier limits only how many names you carry at the same time; reading, editing, giving thanks, and exporting are never limited, for anyone.

The whole-app export from Settings (§10) carries a line of its own: "This file is yours. It never left your device to be made." That line is true. The intentions-only files carry no such line.

5. The record of days

The record is off until you turn it on, and the switch sits next to the words "Missing a day is not a failure." While it is off, nothing is written — not hidden, not deferred. When it is on, it keeps a calendar of the days you prayed, a monthly count, and a lifetime total. None of those can go down. It is kept on the device with everything else and is included in the whole-app export.

6. Notifications

Oratide can deliver a bell in three ways. Reminder Health, in Settings, shows which of them you are actually getting on your device.

1. In the app. A timer in the page, worked out from your Rule and the clock, sixty days ahead, with no network and no server. This is the one that always works, while the app is open.
2. As a system notification. This needs your permission and is off by default. In the Android app, turning it on hands Android the times of your hours, up to sixty days ahead and at most 360 bells at once, and Android posts each bell as a notification at its hour — whether Oratide is open, in the background, or closed. The app hands them over again each time it opens or comes back to the screen, so the sixty days run from the last time you opened it. The schedule is worked out on the phone and handed to Android on the phone; nothing is sent anywhere. In the iPhone app, turning it on hands iOS the times of your next bells, at most 58 at a time (iOS keeps at most 64 waiting notifications for an app), and the app hands over more each time it opens or comes back to the screen; nothing is sent anywhere. If Oratide is ever run in a web browser (§12), the app's own service worker posts the bell instead, and only while the app is running.
3. While the app is closed. In the Android app, these are the bells of item 2: Android holds them, and after the phone restarts the notifications plugin hands them back to Android. Two limits are Android's rules, not ours. Force-stopping Oratide from the system settings cancels everything it holds until you open the app again. And on Android 12 and later a bell rings at its exact minute only if the setting Alarms & reminders allows it for Oratide; otherwise Android rings it near the hour, at a moment Android chooses. Oratide reads that setting and never opens it on its own; Reminder Health says which you have and offers the button that opens it. In a web browser there is no way to ring with the app closed; see §7.

Permission is only ever asked when you press a button that says so — on the bell step of first run, or on the Bells or Reminder Health screens. It is never asked on launch.

What a notification contains. The name of the block you set (for example "Lauds"), the time, and the name of the bell sound; for a bell you put off, the words "It is time" and the time; for a test bell, a line saying it is a test. In the Android app a bell is set to show in full on the lock screen, so someone looking at your phone could see that you keep an hour. Name your blocks with that in mind. Nothing from your intentions or your record is ever placed in a notification.

What tapping does. "Pray now", or the bell itself, opens the block it named. "In 15 minutes" rings the bell again fifteen minutes later. "Skip today" does nothing else; the skip is remembered only until the day turns, and then it is forgotten. (On Android, Android brings the app forward for any of the three; only "Pray now" and the bell itself open a prayer.)

Announcements. There is a second class of notification for anything that is not one of your hours. It is off by default, capped at one a week; the cap is shown on the Settings screen, and the cap and the count for the last seven days on the Bells screen. With no server, an announcement can only come from the app itself.

Reminder Health sends a real test bell through the same path a real bell takes — in the Android app, a notification handed to Android two seconds ahead — and then tells you the actual state of things on your device — permission, whether exact alarms are allowed, how many bells Android is holding and until what date, whether the last bells were delivered — in the words your own phone's settings use. Where the limit is the platform's rather than yours, it says so instead of letting you blame your phone.

7. Push — the honest account

Push is how a server wakes a phone: the server sends a message through a push service run by the phone's or browser's maker, and the phone shows it. It is not how the Android app's bells work. Those are held by Android on the phone itself (§6), and need no server.

The web is different: a web page has no way to ring a bell at a set time with the app closed. The only mechanism that could is web push, and web push needs a server.

Oratide has no server, so this build does not offer push. In the code, the delivery key that push would require is declared and set to nothing, and no push subscription is ever created. The service worker does contain the receiving end — the few lines that would show a bell if a push message ever arrived — but there is no sending end, and no message can arrive.

If a later version adds it, here is what it would involve, so that you can weigh it when you see the switch:

• You would turn it on. It would be off by default, on its own switch, with the cost stated beside it, and it would never be required to use the app.
• Your browser or operating system would create a push subscription. That is a unique address (an "endpoint") at a push service run by the maker of your browser or phone — Google for Chrome and Android, Apple for Safari and iPhone, Mozilla for Firefox — together with a pair of keys that let only our server send to it, and only your device read what is sent.
• That endpoint, and the times to ring, would be sent to a server of ours and kept there, so that it could ask the push service to wake your device at your hours. That would be the first piece of information about you to leave the device, and this document would say so.
• The push service would see that a message went to your device, and when. It would not see what the message said, because push payloads are encrypted to your device.
• Turning it off would tell our server to forget the endpoint. Uninstalling the app, or clearing site data, revokes the subscription at the browser's end as well.

This document will be revised, dated, and logged below before any of that goes live.

8. What the app reads from your device, and keeps to itself

To do its job the app reads a few things about the device it is running on. None of them are stored beyond what §3 lists, and none of them leave the device.

• The clock and time zone, to ring at the right hour and to recompute the schedule when you travel or the clocks change.
• The browser's identification string, to tell an iPhone from an Android phone from a desktop, so that Reminder Health can give the right instructions in the right words, and to know whether the app is installed or running in a tab.
• Whether notification permission is granted, and whether the app is running in its own window.
• In the Android app, what Android is holding: whether exact alarms are allowed, which bells Android still holds and until what date, and which it has posted — so that Reminder Health can report them and the delivery log in §3 can be kept.
• Your system preferences for dark mode and reduced motion, which the app honours.
• Vibration, for one soft tap when a bell comes due or is put off, and — if you leave haptics on in the prayer controls — one when a block begins and one when it ends.

9. Buying Oratide, and what the store sees

Oratide is free to use, in full, without paying: every prayer text, every reminder, the calendar, offline use, and accessibility are covered by the Free Core Covenant shown in the app. Paying is a one-time purchase of $9.99, made in Google Play, or in the App Store in the iPhone app. There is no subscription, no renewal and no trial — a fact worth stating in a privacy policy, because there is therefore no recurring billing relationship to keep any record of. The only thing paying would change in this version is the limit of seven carried intentions. The Support screen also names seasonal companions as what the money pays for; those are not written yet, and nothing in the app is gated on them.

Exactly what leaves your phone when you buy or restore the unlock, and who receives it. Oratide's own code sends nothing to anyone: there is no server of ours, no billing service such as RevenueCat, and no receipt-validation server. Everything goes to Google Play, through the Google Play Store app on your phone:

• the purchase itself, made on Google Play's own screens: your Google account, the payment method, the item (horarium_full), the price in your currency, the date and the order;
• the acknowledgement Google requires after a purchase, quoting the purchase token Google Play issued (below);
• the app's question "what has this store account bought?", asked when the app checks your unlock and when you tap Restore, which the Google Play Store app answers;
• and, from Google's Play Billing Library inside the app, technical information Google's own library may send Google about the purchase flow.

All of that is governed by Google's privacy policy, not this one. Oratide never sees your name, email address or payment details. The development version run from source uses a sandbox store with a mock ledger on the device instead.

In the iPhone app, everything goes to Apple instead, through Apple's StoreKit, which is part of iOS. The purchase goes between your phone and the App Store, and nothing about it is sent to us:

• the purchase itself, made on Apple's own purchase sheet: your Apple Account, its payment method, the item (horarium_full), the price in your currency and the date;
• the app's question "what has this Apple Account bought?", asked when the app checks your unlock and when you tap Restore purchases, which StoreKit answers;
• and the app telling StoreKit that it has received the purchase (it marks the transaction finished).

All of that is governed by Apple's privacy policy, not this one.

How buying works (Google Play in the Android app, the App Store in the iPhone app), and it follows from the fact that Oratide has no server:

• The purchase is made by the store, on the store's own screens, with your store account and the payment method the store has on file. Oratide never sees your name, your email address, your card, or your billing address.
• The app asks the store through a billing plugin compiled into it (capacitor-plugin-cdv-purchase, open source): on Android it uses Google's Play Billing Library, which talks to the Google Play Store app on your phone; on iPhone it uses Apple's StoreKit. That plugin can be set up to send receipts to a validation server; Oratide does not set that up, and does not include the part of the plugin that would. So a purchase goes between your phone and Google Play or the App Store, and to nobody else — not to us, not to a billing service, not to any server of anyone's.
• Google Play requires every purchase to be acknowledged by the app, and refunds one that is not. So after you buy, the app tells Google Play, through the same library, that it has received the purchase, quoting the purchase token Google Play gave it. That acknowledgement is the one purchase record the app sends, and it goes to Google Play, which already holds the purchase. On iPhone the app marks the transaction finished with Apple in the same way.
• What the app receives from the store is the fact of an entitlement — that this device's store account has bought Oratide, and on what day — with the store's order or transaction number. It keeps those on the device, so the purchase can be shown back to you, and it has nowhere to send them. There is no expiry date in it, because a purchase does not expire. If the store's answer is missing or cannot be understood, the app grants full access rather than showing a paywall.
• The store sees what it always sees for any purchase: the item, the price, the date, and your store account. That is governed by Google's privacy policy or Apple's, not by this one.
• Refunds are handled by the store under its own rules: a refund is issued by Google Play, or by Apple for a purchase in the iPhone app, back to the payment method that was charged. The app will point you there; no ticket or email to us is involved. (The app has no refund button: the store handles refunds.) There is nothing to cancel, so there is no cancellation flow of any kind, in the app or at the store.
• Emails about a trial ending or a subscription renewing will never arrive, from us or from the store, because there is no trial and no renewal. Any receipt the store sends goes from the store to the address it holds for you. It cannot come from us, because we do not have your address.

10. Taking your data with you, and erasing it

• Export everything. In Settings, one tap saves the whole document — Rule, intentions, record, and preferences — as a JSON file. The intentions can also be exported alone, as text or JSON. In the Android app, saving these files has not yet been confirmed on a real device: the app hands each file to its web view as a download, and the Capacitor shell registers nothing to receive downloads, so on Android it may save nothing.
• Import. The same screen reads an export back in, after first backing up what is there.
• Erase everything on this device. In Settings, behind one confirmation. It clears the document and keeps one backup copy of what was erased in the same storage, in case it was a mistake. That copy stays until the next import, erase or data migration replaces it; ordinary use does not remove it. To remove it, erase a second time (the copy is then replaced by what was there after the first erase), clear the site's data in your browser, or uninstall the Android app.
• Nothing to delete anywhere else. Because nothing was ever sent anywhere, there is no copy on a server to ask us to remove.
• How long it is kept. On your device, until you erase it or uninstall the app (the erase above keeps one backup copy until the next import, erase or data migration). Nowhere else: the only copy outside the app's own storage is an Android backup or, in the iPhone app, an iCloud backup, if you have backup switched on (§3), and that is kept under Google's or Apple's rules, not ours.

11. The Android app in particular

• The app's files are inside the package. The shell serves them to its own WebView from a local address. Opening the app makes no request to the internet.
• Permissions. The app and its plugins declare eight, each for one job. INTERNET, which the Capacitor shell template declares; the app makes no request to the internet of its own; Google's Play Billing Library uses the Google Play Store app on the phone to buy, restore and check the unlock (§9). POST_NOTIFICATIONS, so that a bell can appear as a notification; on Android 13 and later Android asks you for it, and Oratide lets it ask only when you press the button that turns bells on or sends a test bell (§6). SCHEDULE_EXACT_ALARM, so that a bell can ring at its minute rather than near it; you allow or refuse it in Android's settings under Alarms & reminders, and Oratide only reads it. RECEIVE_BOOT_COMPLETED, so that after the phone restarts the notifications plugin can hand the bells back to Android. WAKE_LOCK, which the notifications plugin declares in its own manifest and which comes into the app with it; nothing in Oratide's own code uses it. VIBRATE, for the soft tap described in §8. And com.android.vending.BILLING, which the billing plugin declares so that the app can open Google Play's own purchase screen. ACCESS_NETWORK_STATE, which Google's Play Billing Library brings in through Google's own logging component (com.google.android.datatransport 3.1.8): it lets that component check whether the phone is online before it sends Google the technical information about the purchase flow described in §9. It reads no network contents, and Android does not ask you about it. Beyond those eight, the build carries only a permission that the AndroidX support library defines for the app's own internal use. There is no permission for location, the camera, the microphone, contacts, your files, or an advertising identifier.
• Notifications. The bells do not use the WebView's own notification interface. In the Android app they go through the notifications plugin to Android (§6).
• Android backup. See §3.
• What Google sees. Installing from Google Play records the install against your Google account, and Android reports crashes and unresponsive-app events to the developer's Play Console in aggregate if you have "usage and diagnostics" sharing on for the device. That is Google's collection under Google's policy. The same setting lets Android System WebView, which draws Oratide's screens, send Google its own usage statistics and crash reports, under Google's policy. Oratide does not currently opt out of the WebView's usage statistics. Oratide adds no crash reporter of its own and receives nothing beyond that aggregate.

12. A web version, if one is published

No web version of Oratide is published today; the app is the Android app and the iPhone app. If a web version is published, this is what it will mean, and this document will name its host and that host's log retention on the same day.

• Loading the app. The first time you open it in a browser, and whenever it checks for an update, your browser fetches the app's files from its host. Like any web request, the host sees your IP address, the file requested, the time, and the identification string your browser sends with every request. Oratide adds nothing to that: no cookie, no identifier, no query string, and the app sets no cookies.
• After that, the service worker serves the app from its cache, so a launch is answered without the network. A few seconds after load, when the device is online, the app asks that same host once whether a newer build exists, and if so fetches only the app's own files.
• Any request to another host is refused by the service worker before it reaches the network (§2).

13. Children

Oratide is not directed at children under 13 and has no feature that asks anyone's age. Since it collects nothing from anyone, it collects nothing from children.

14. Your rights

Laws such as the GDPR and the CCPA give you rights to see, correct, delete, and take away the data an organisation holds about you. The app gives us none, so there is nothing of the app's for us to act on; the tools to do all of those things with the data on your device are in Settings (§10). The one thing we can hold is a message you choose to send. If you write to support@chibuapps.com, we then have your address and what you wrote, because you sent them; the message reaches us through Cloudflare's email forwarding (Email Routing) and is kept in a Gmail inbox, so Cloudflare and Google handle it under their own policies. It is used only to answer you, never added to a list and never shared. Ask, and we delete the conversation. A person will answer. If you are in the European Union or the United Kingdom, you also have the right to complain to your data protection authority.

15. Changes to this document

The effective date at the top changes whenever this document does, and each change is summarised in the log at the end. If a future version begins to send anything off the device — push (§7) is the one we can foresee — that version will say so in the app, ask before it does so, and this document will be revised the same day.

16. Contact

chibu — support@chibuapps.com

By post: chibu, 2112 Broadway St NE Ste 225 #535, Minneapolis, MN 55413, United States

Change log

• 2026-10-31 — The iPhone app on the App Store is added. §1 covers it, and §9 (with the short version and §3's Purchase row) says that in the iPhone app the purchase goes through Apple's StoreKit, between the phone and the App Store, and that nothing about it is sent to us; a refund there is Apple's. §3 and §10 add the iPhone's iCloud backup, §6 and the short version say that the iPhone app hands iOS its next bells (at most 58 at a time) on the phone, and §12 names the iPhone app. The sections that say "the Android app" still describe the Android app only. What the app collects, where it is stored and what leaves the device did not change: the answer to all three is still nothing.

• 2026-10-24 — §11 names an eighth permission, ACCESS_NETWORK_STATE. Google's Play Billing Library 9.0.0 brings it in through Google's logging component (com.google.android.datatransport 3.1.8), measured on the merged manifest and the Gradle dependency tree. It was in the build before and is named now; nothing in the app changed.

• 2026-10-24 — For the build that sells the unlock: §9 now lists exactly what leaves the phone when you buy or restore (everything goes to Google Play; Oratide's own code sends nothing), the Purchase row in §3, the permissions in §11 and the Data-safety rows describe purchases switched on, and the "nothing can be bought" sentences are gone. The answers stay "no data collected": the app transmits nothing of its own, and Google Play's billing system is the payment service.

• 2026-10-19 — Rewritten for the build that now goes to Google Play as a new app. §1 names its package, com.chibuapps.oratide; the earlier entry, app.horarium.prayer, was never published and is not updated again. The three Capacitor plugins that the earlier versions said were left out of the Google Play build are compiled into this one, and this version says what each does and where it talks: §2 names all three and no longer says the app carries no third-party SDK, because the billing plugin brings Google's Play Billing Library with it; §3 says where the notifications plugin keeps its copy of the bells; §6 says how, on Android, a bell can reach you with the app closed — Android holds it, on the phone, with no server — and what force-stopping the app and the Alarms & reminders setting change; §7 says why that is not push; §8 adds what the app reads back from Android; §9 says the billing library is compiled in but never started while buying is switched off, and that once buying opens each purchase is acknowledged to Google Play, the one purchase record the app sends; §11 lists the seven permissions and what each is for (eight from 2026-10-24). The preamble no longer says the bell rings only while the app is open. What the app collects, and what leaves the device, did not change: the answer to both is still nothing. Where your data is kept changed in one respect: in the Android app, the bells you turn on are also held by Android, and by the plugin's copy, on the same phone.
• 2026-09-30 — §2, §9 and the Data-safety "Financial info" row now name the billing plugin chosen that day, capacitor-plugin-cdv-purchase, and say exactly where a purchase goes: between your phone and Google Play or the App Store, and nowhere else — the plugin's optional receipt-validation server is not set up, and the part of it that would send one is not in the app. What is sold did not change: a one-time $9.99 purchase, no subscription, no trial. Buying is still not open in any build. A future Android build from this source also declares a sixth permission, com.android.vending.BILLING, which lets the app open Google Play's purchase screen; §11 will list it when that build is the one on Google Play. What the app collects, where it is stored and what leaves the device did not change: the answer to all three is still nothing.
• 2026-09-22 — Published at https://chibuapps.com/oratide/privacy/. The contact address is now support@chibuapps.com, which reaches the same person, and §16 adds a postal address. Before publishing, every statement was checked against the build on Google Play, and the ones that were wrong were corrected: §1 and §12 now say plainly that no web version is published; §11 now lists the five permissions the Android manifest declares, not one; §2 now says what the About screen actually lists; §9 and the §3 purchase row now say that the Google Play build has no store and no purchase ledger; §4 no longer promises a line in the exported file that the file does not carry; §10 now says how long the pre-erase backup really lasts; and §14 now says what happens to an email you send us. The bell is described as ringing while the app is open, because in this build that is the only time it can. What the app collects, where it is stored and what leaves the device did not change: the answer to all three is still nothing.
• 2026-09-09 — §9 rewritten. Oratide became a one-time $9.99 purchase; the subscription, the fourteen-day trial and every renewal were removed from the product, so this policy no longer describes a recurring billing relationship, a cancellation path, or trial-reminder emails. The four paid promises that needed people or a server — recorded readings, sung settings, offline audio, household sharing — were withdrawn from the product on the same day, so §9 no longer names them among what the money pays for. Nothing about what is collected, where it is stored, or what leaves the device changed: the answer to all three is still nothing. The §3 table's "Subscription" row is now "Purchase".
• 2026-09-03 — First version. Describes the build in which there is no server, no account, no analytics, no push, and a sandbox store in place of store billing.

This website

Everything above is about the app on your phone. This last part is about this website, chibuapps.com, which is a different thing.

• What it collects. Nothing. The pages are plain files: no form, no script, no cookie of ours, and no analytics of ours.
• Who serves it. Cloudflare. Like any web host, Cloudflare sees the IP address, the page requested, the time and the identification string your browser sends, in order to deliver the page, and handles that under its own privacy policy: cloudflare.com/privacypolicy.