Privacy Policy

01 About this policy

This Privacy Policy explains how the Eucharistus iOS application (the "app", "Eucharistus", "we", or "us") processes your personal data. It is written to satisfy Article 13 of the EU General Data Protection Regulation (GDPR / Regulation 2016/679) and Czech Act No. 110/2019 Coll. on the processing of personal data, alongside Apple's App Store privacy disclosure requirements.

We have written it in plain language. Where a legal article number is helpful for compliance, you'll see it in parentheses — for example "(Art. 6(1)(b))" — so you can verify what we say against the source.

02 Who we are

Eucharistus is built and operated by an individual developer (the "data controller" under GDPR Art. 4(7)):

We are not required to appoint a Data Protection Officer under GDPR Art. 37: our processing is small-scale, we are not a public authority, and we do not carry out large-scale monitoring or special-category processing. You can still write to the controller directly at the email above for any privacy matter.

03 Scope

This policy covers:

• The Eucharistus iOS app distributed through the Apple App Store.
• The Supabase-hosted backend that the app communicates with.
• This policy page itself, served at eucharistus.com/privacy.

It does not cover the independent privacy practices of third-party platforms you interact with when you leave the app — such as external links or your operating system's settings. Apple's and RevenueCat's roles in processing an in-app purchase are described here, but each provider is also governed by its own privacy terms.

04 What data we collect

We collect only the data described below. Categories marked "optional" are never collected unless you explicitly turn them on or supply them.

4.1 Account & authentication data

When you create an account, we receive:

• Email address — required for sign-in, password reset, and account recovery. Stored by Supabase Auth.
• Display name (and first / last name if you supply them) — optional. You can leave them blank; you can also edit or remove them at any time from the Account screen.
• Account identifier — a randomly-generated UUID assigned by Supabase. It is the key we use internally to attach your visits, preferences, and submissions to you.
• Authentication method — whether you signed up with email and password or with Sign in with Apple. Sign in with Apple provides us your name on first authorisation only; you can use Apple's "Hide My Email" feature, in which case we only see Apple's relay address.
• Account creation timestamp.

We never see or store your password. Supabase Auth hashes and verifies it on its side; the app receives only an access token after a successful sign-in.

4.2 Profile preferences

To keep your settings in sync across devices we store:

• Country / jurisdiction code (ISO 3166-1, used to pick the correct Catholic feast calendar).
• Appearance preferences (light/dark/system colour scheme, accent colour, custom colour).
• Last-update timestamps used purely to resolve conflicts when the same setting is changed on two devices.

4.3 Church visit log

When you record a visit to a church, we store:

• The church's name and geographic coordinates (these are the church's coordinates, not yours).
• The activity type you selected (Eucharist, Mass, Adoration, Confession, or generic visit).
• Any optional note you added.
• The timestamp of the activity and the time the entry was created.

4.4 Feature suggestions, comments, and votes

If you submit a feature suggestion, post a comment, or upvote a suggestion, the body of your contribution is associated with your account so that we (and other users) can follow up. The in-app submission form discloses this before you post.

4.5 Feedback reports & screenshots

When you send feedback (bug report, praise, or complaint), we receive what you wrote, the category you picked, and an installation-scoped device identifier we use to rate-limit submissions. Submitting feedback requires a signed-in account, but the row itself does not store a link back to your account — your session token is the only identity check at the database layer; nothing user-identifying is persisted on the row.

Two additional toggles let you decide what else to include:

• Screenshot — optional. If you choose to attach one, we capture the current visible UI of the app and upload it to a private storage bucket. Orphan uploads (no matching report) are deleted automatically within 24 hours. Screenshots tied to a report are kept as long as the report itself.
• Logs & device info — optional. When enabled, we attach a JSON snapshot of: app version and build, bundle identifier, operating-system name and version, device model (both the raw utsname.machine identifier and a resolved marketing name where known, e.g. "iPhone 16 Pro Max"), locale, time zone, region code, your top five preferred languages, and your current in-app settings (jurisdiction country, color-scheme mode, accent-color mode, and travel mode). Capped at 64 KiB of logs and 8 KiB of device info per report.

If you don't tick those toggles, nothing beyond your text body, category, and device identifier is collected with the report.

4.6 Church submissions

If you propose a missing church, we store the coordinates you pinned plus a device identifier (for rate-limiting at five submissions per device per day). Submissions go into a queue we manually review before any data is added to the public church map.

4.7 Challenge attempts

Eucharistus offers spiritual challenges such as the Sacred Heart nine-month sequence. For each attempt we store the challenge identifier, an attempt number, a status, a score, and timestamps — tied to your account so progress survives reinstall.

4.8 Device-only data

Some data never leaves your device unless you explicitly send it to us via feedback or backup:

• A device identifier (UUID) stored in the iOS Keychain. It survives reinstall on the same physical device and is used for rate-limiting feedback and church submissions. It is not linked to your Apple ID or to advertising identifiers.
• Your travel-mode preference (walking vs. driving).
• A local cache of your visits and challenges (SwiftData).
• Your confession passcode, examination profile answers, selected examination items, encryption keys, and encrypted vault payload. These remain device-only and are never included in diagnostics or product analytics.
• The consent values we store in UserDefaults — the Privacy Policy version you acknowledged, whether diagnostics are enabled, and whether you completed the consent step.

4.9 Location data

The app requests "While Using" location permission. iOS will ask you the first time the map needs it; you can revoke it at any moment from Settings → Privacy & Security → Location Services → Eucharistus.

Your device location is used only on your device: to centre the map and to query nearby churches. It is sampled at roughly 100-metre resolution, and it is never sent to our server. The coordinates we do store on the server are those of the church you visit or submit — public locations, not yours.

The Privacy Manifest (PrivacyInfo.xcprivacy) declares precise location as "App Functionality, Not Linked to the User". This is the conservative Apple privacy category for the Core Location reading used on-device, even though the app applies roughly 100-metre accuracy and does not upload that reading. It separately declares purchase history for app functionality and analytics, not linked to your identity and not used for tracking.

4.10 Optional support purchases

You may buy a repeatable consumable in-app purchase to support research, verification, and addition of a stated number of churches to the shared global map. These purchases do not unlock a personal feature and do not require you to sign in.

• Apple handles payment credentials and billing. Apple provides purchase identifiers and receipt or transaction information needed to verify the purchase and handle a refund. Eucharistus never receives your card number, bank-account details, or Apple Account credentials.
• RevenueCat receives Apple's receipt and transaction identifiers, product identifier, purchase date, price and currency where supplied by the store, storefront, environment, and purchase or refund status. Its SDK creates a random installation-scoped App User ID. Eucharistus does not attach that identifier to your Supabase account, email address, display name, or journal.
• Our private Supabase ledger receives a reduced server-to-server event: event and transaction identifiers, product identifier, environment, purchase/refund timestamps and status, price and currency when available, the church-count commitment derived from the product, and fulfilment records for churches added to the map. It does not store a RevenueCat customer alias, Apple receipt, raw webhook body, Supabase user ID, email address, or display name.

Support purchases are therefore anonymous to Eucharistus in the ordinary sense that we cannot identify the purchaser through an app account. Apple may still know the purchaser through their Apple Account, and RevenueCat must process the random App User ID and store transaction data to verify the purchase. RevenueCat also provides aggregate product and revenue metrics so we can reconcile the program and understand which support tiers are used. Purchase data is not used for advertising, cross-app tracking, or to infer religious practice.

Historical records from the retired Plenus subscription and lifetime-purchase system remain in a restricted archive for audit, refund, and legal-record purposes. The current app cannot read those records, they are not reused for support purchases, and no new Plenus data is collected.

4.11 Diagnostics and usage data — opt-in only

The onboarding consent step gives you a single toggle, "Share diagnostics and usage data", which turns the following two services on or off together. Both are off until you tap to enable them, and both are disabled if you later turn the toggle back off in the app's settings.

• Sentry (crash, app-hang, and operational reports) — receives sanitized stack traces, fixed feature, operation, and reason-code tags, technical app and device metadata, your opaque Supabase user UUID while signed in, and the originating IP address. We sample 10% of performance traces. Screenshots, view hierarchy, session replay, user-interaction tracing, automatic network breadcrumbs, and automatic network tracking are disabled. Request URLs and raw error descriptions are removed before sending. While confession preparation is visible, generic reports and breadcrumbs are blocked; events tagged as captured on that route are also dropped after relaunch. Only fixed-code Guide operational reports with no raw error or user context may pass. Data is ingested in Germany (ingest.de.sentry.io).
• PostHog (product analytics) — receives only manually declared event names and bounded properties, together with a per-install distinct identifier and, while signed in, an opaque user_id UUID. Every event carries $geoip_disable=true, preventing IP-derived geolocation from being added to analytics. Events cover coarse navigation sources, whether the supported Guide deep link was accepted and applied, Guide setup and completion milestones, ordinal examination-step views, Journey and Insights openings, visible insight-card categories, and activity logging with a count bucket and Boolean flags. The raw deep-link URL, calculated insight values, church details, selected activity types, dates, and times are not sent. Lifecycle capture, screen and element autocapture, rage clicks, surveys, session replay, automatic error tracking, and SDK swizzling are disabled. A final schema allowlist drops undeclared events and properties. Data is ingested in the EU (eu.i.posthog.com).

Neither provider receives passcodes, confession selections or item identifiers, examination profile answers, notes, church identifiers or names, precise location, raw URLs, screenshots, recordings, encryption material, ciphertext, or vault contents.

If you decline diagnostics, neither SDK is initialised at app start; no event is captured and no network request is issued to either vendor.

4.12 What we deliberately do not collect

• No passwords — Supabase hashes them; we never see plaintext.
• No phone number, date of birth, ethnicity, or religious-belief content beyond data you deliberately store in the app.
• No prayer text, confession selections, examination answers, or other sacramental content leaves your device through telemetry. If diagnostics are enabled, coarse use of the Guide is reported as linked sensitive-information analytics because the feature is religious in nature.
• No advertising identifiers (no IDFA, no ASIdentifierManager).
• No card number, bank-account details, or Apple Account password. Those remain with Apple.
• No cross-app or cross-site tracking — NSPrivacyTracking is false and NSPrivacyTrackingDomains is empty in the manifest.
• No microphone, photo library, contacts, calendar, reminders, motion, or HealthKit access — the app does not request these permissions.

05 Why we use it

Each category we collect maps to a concrete purpose:

• Email, account UUID, authentication metadata — to let you sign in, recover access, and bind your data to your account.
• Display name — to show you in the Account header and on suggestions or comments you author.
• Profile preferences (country and appearance) — to keep your in-app experience consistent across devices and reinstalls.
• Church visit log and challenge attempts — to power your personal "journey" view of mass attendance and challenge progress.
• Feature suggestions, comments, votes — to let us collect and prioritise community-driven product input.
• Feedback bodies, optional logs and screenshots — to reproduce, diagnose, and fix bugs you report.
• Church submissions — to grow the public church map with locations we don't yet have.
• Anonymous purchase and fulfilment records — to verify optional support purchases, account for the exact number of churches promised globally, prevent duplicate processing, handle refunds, and audit fulfilment.
• Device identifier — to rate-limit feedback and church submissions, preventing abuse.
• Device location (on-device only) — to centre the map and find nearby churches.
• Sentry events (opt-in) — to detect and fix crashes you would otherwise have to live with.
• PostHog events (opt-in) — to understand which features people actually use, so we know what to improve.

06 Legal bases (GDPR Art. 6)

We rely on the following lawful bases:

Performance of a contract — Art. 6(1)(b)

For account creation and sign-in, profile sync, the church visit log, challenge attempts, and processing an optional support purchase. You ask us to provide a service or fulfil a purchase; we need this data to do so.

Consent — Art. 6(1)(a)

For Sentry crash reports and PostHog product analytics (bundled as a single "diagnostics" toggle during onboarding), and for the optional logs / device-info and screenshot toggles on each feedback report (each a separate per-submission choice). Consent is opt-in and withdrawable at any time without affecting processing carried out before withdrawal.

Legitimate interests — Art. 6(1)(f)

For rate-limiting, abuse prevention, security monitoring, and the orphan-screenshot cleanup. Our interest in keeping the service running and free of abuse is balanced against the minimal data footprint these uses involve (a device UUID and short-lived storage entries).

Legal obligation — Art. 6(1)(c)

For responding to data-subject requests, retaining records required to satisfy regulators, and handling complaints lodged with supervisory authorities.

07 Who we share data with

We use a small number of named third-party processors. Each one has agreed to act on our instructions under a Data Processing Agreement (or equivalent terms), and each provides industry-standard security controls. Sub-processor changes will be reflected in this table when they happen.

We do not share your data with advertising networks, data brokers, social networks, or anyone else. We do not sell it. We do not exchange it for anything.

If we ever need to disclose data in response to a binding legal request (court order, subpoena), we will challenge requests that look overbroad and notify you wherever law permits.

08 International data transfers

Your account, profile, visits, feedback, suggestions, submissions, and private fulfilment ledger stay in our Supabase EU project; Sentry ingests events in Frankfurt; PostHog uses its EU cloud. Purchase verification additionally involves the providers below.

Two services may involve processing in the United States:

• Apple — App Store distribution and payment processing, Sign in with Apple, and push notification delivery. Apple is certified under the EU–US Data Privacy Framework (DPF).
• RevenueCat — purchase verification and lifecycle events. Its Data Processing Addendum provides contractual safeguards for international transfers.

You can ask us for a copy of the safeguards in place by emailing the address in section 16.

09 How long we keep it

The general rule: we keep your data for as long as your account exists. When you delete the account, almost everything is erased immediately. Specifics:

• Account record, profile, church visits, suggestions, comments, votes, challenge attempts — kept until you delete your account, at which point they are removed by cascading database deletes.
• Feedback reports — feedback rows are never attributed to your account in the first place (they're identified only by an installation-scoped device identifier), so deleting your account leaves them unchanged. We keep them so we can still triage outstanding bugs. If you would like a specific report deleted, email us and we'll remove it.
• Church submissions — when you delete your account, your authorship link on each submission is set to NULL so the row is no longer attributed to you, but we keep the coordinates themselves so we can still process the missing-church queue. If you would like a specific submission deleted, email us.
• Feedback screenshots — orphan uploads (no matching report row within 24 hours) are deleted automatically by a scheduled job. Screenshots linked to a report are kept as long as the report.
• Current support-purchase ledger and fulfilment records — retained while needed to verify purchases and refunds, prevent duplicate processing, account for the exact global church commitment, audit fulfilment, and meet applicable tax, accounting, or legal obligations. Because the ledger contains no app account identity, deleting your Eucharistus account does not alter it. If you contact us with an App Store transaction identifier, we can assess whether a particular record can be located or deleted without breaking a legal or anti-fraud obligation.
• Restricted historical Plenus archive — retained only for audit, refund, and legal-record purposes. It is inaccessible to the current app and is not used to create or enrich a support-purchase profile.
• RevenueCat purchase records — retained while the purchase integration is operated and as otherwise described in RevenueCat's retention terms; deletion requests may be sent to us using the transaction details Apple provides.
• Sentry events — retained for 90 days by default per Sentry's policy.
• PostHog events — retained per PostHog's policy.
• Backups — managed-service rolling backups (typically 7–30 days). Deleted data falls out of backups within that window.

10 Your rights

Under the GDPR and the Czech data-protection act, you have the following rights. They are free of charge and we will respond within 30 days (Art. 12(3)).

• Right of access (Art. 15) — ask us what we hold about you. We'll send you a copy.
• Right to rectification (Art. 16) — ask us to fix anything inaccurate. You can edit your display name yourself from the Account screen.
• Right to erasure / "right to be forgotten" (Art. 17) — use the "Delete account" button in the Account screen, or email us. Deletion is irreversible. The anonymous support-purchase ledger is not keyed to your Eucharistus account, so account deletion cannot locate or delete those records; contact us with an App Store transaction identifier if you want us to assess a purchase-specific request.
• Right to restriction (Art. 18) — ask us to pause processing of your data while a dispute is resolved.
• Right to data portability (Art. 20) — ask us for a structured, machine-readable export (JSON) of your account, visits, and submissions.
• Right to object (Art. 21) — object to processing we base on legitimate interests; we'll stop unless we can demonstrate compelling overriding grounds.
• Right to withdraw consent (Art. 7(3)) — flip the diagnostics toggle off, or untick the optional toggles in the feedback form. Withdrawal does not affect processing that already happened lawfully.
• Right not to be subject to automated decision-making (Art. 22) — we don't make any decisions that produce legal or similarly significant effects about you using automated processing. There is no profiling that would fall under Art. 22.
• Right to lodge a complaint (Art. 77) — see section 16.

11 How to exercise your rights

For most things you don't need to email us at all — the app exposes the controls directly:

• Edit your display name — open the Account screen and tap your name; a pencil affordance reveals an inline editor.
• Delete your account — Account → Delete account. This removes account-linked data but cannot identify an anonymous support-purchase ledger entry.
• Turn diagnostics off — Settings (the same toggle you saw during onboarding).
• Opt out of optional feedback metadata — leave the "Include logs and device info" and "Include screenshot" toggles unchecked when submitting a report.

For anything else — copies of your data, restriction, portability, objection, or simply a question — email help@eucharistus.com. To prevent identity-theft of accounts, we may need to verify your identity using the email address on file before acting on a request.

12 Children

Eucharistus is intended for users aged 16 and older. This matches the default age threshold for consent to information-society services under GDPR Art. 8 across Europe.

We do not knowingly collect personal data from children under 16. We do not target the app at children, we do not run any kind of behavioural profiling, and we do not run advertising. If you are a parent or guardian and you believe a child under 16 has provided us with personal data, please contact us and we will delete the account.

13 Security

We use the following safeguards:

• Encryption in transit — every network request uses TLS.
• Encryption at rest — Supabase managed Postgres and Storage encrypt data at rest by default.
• Row-level security (RLS) — every user-data table enforces that a request can only see or modify rows owned by the authenticated caller, at the database level.
• Column-level grants — newly added columns are invisible to the app role by default; visibility is granted explicitly, column by column.
• Private purchase ledger — client roles cannot read or write purchase events or fulfilment records. A server-only ingestion path validates signed RevenueCat events, derives church counts from known product identifiers, and rejects duplicate or conflicting events.
• Authenticated uploads only — feedback screenshots can only be written by an authenticated caller and only at a path matching their own user UUID.
• Rate limits — email lookup (5 / minute / IP), feedback (5 / day / device), church submissions (5 / day / device), defending against enumeration and spam.
• Size caps — feedback logs ≤ 64 KiB, device info ≤ 8 KiB, screenshot path validated against a strict UUID-shape pattern.
• Orphan cleanup — a scheduled job deletes feedback screenshots that never landed against a report.
• Sentry IP capture — opt-in only; tied to the diagnostics toggle.

No system is perfectly secure. If we ever become aware of a personal-data breach that's likely to result in a risk to your rights and freedoms, we will notify the competent supervisory authority within 72 hours and you (Art. 33, 34) without undue delay.

14 Cookies and local storage

The app uses iOS-native storage only — UserDefaults for preferences, the acknowledged policy version, and the diagnostics choice; the Keychain for the device identifier and session token; and Apple's StoreKit storage plus RevenueCat's local cache for anonymous purchase processing. There are no cookies and no web tracking inside the app.

This privacy page itself is intentionally a static HTML document. It loads no scripts, no fonts, no external images, no analytics, and sets no cookies — its job is to tell you about data collection, not to perform it.

15 Changes to this policy

We will update this page whenever we change how we process data. The effective date at the top of the page is bumped each time we publish a new version.

If the change is material — for example a new sub-processor that handles personal data, or a change in legal basis — the onboarding consent step inside the app will re-prompt you to acknowledge the updated policy before you can continue. Previous versions are available on request.

16 Contact & complaints

To exercise a right, ask a question, or raise a concern:

You also have the right to lodge a complaint with a data-protection supervisory authority (Art. 77). Our lead supervisory authority — because the controller is established in Czechia — is:

If you live in another EU member state, you may instead complain to your local supervisory authority. A list is maintained by the European Data Protection Board at edpb.europa.eu/about-edpb/about-edpb/members.