Ayne — Privacy Policy

Introduction

Welcome to Ayne (the “App”). This page explains how we handle data, the permissions the App requires, how third parties are used. Please read sections carefully. By using Ayne you accept these terms. If you do not agree, please do not use the App.

Quick privacy summary (short)

• Core functionality uses device-only data: the App uses Android Accessibility + overlay to allow "shielding" selected apps; package names of apps a user chooses to shield and local shield statistics are stored locally on the device.
• We minimize collection: we only send to third parties what is needed for authentication, analytics, crash reporting, ads, and subscription management (see details below).
• No sale of personal data: we do not sell your personal data to third parties.
• Payments: subscriptions are handled by RevenueCat / app stores; we do not collect payment card details directly.

Platform permissions (what we request and why)

Below are the Android permissions the app currently requests. iOS-specific permissions are listed as placeholders (you'll update that section when you prepare the iOS Info.plist).

Android (current)

• android.permission.INTERNET — needed to reach our services and third-party SDKs (analytics, crash reporting, RevenueCat, AdMob).
• android.permission.POST_NOTIFICATIONS — to show notifications (subscription receipts, reminders, shield-related notifications).
• android.permission.SYSTEM_ALERT_WINDOW — for the overlay we display when shielding a blocked app (overlay shows the "shield" screen).
• android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS — optional; used to reduce interruptions to long-running shielding or background tasks when the user enables this setting.
• android.permission.QUERY_ALL_PACKAGES — used only to present a list of installed apps so a user can select which apps to shield. This is not used to upload the full installed apps list off-device.

iOS (current)

• FamilyControls (Screen Time API) — used to allow the user to select apps and categories they want to limit or "shield". This permission is granted explicitly by the user via Apple’s Screen Time interface.
• DeviceActivity — used to detect when selected apps are opened so the app can trigger the configured gate (e.g., showing a mindful prompt before access).
• ManagedSettings — used to apply shielding (temporarily restricting access) to apps the user has selected. The app cannot access or control apps outside of what the user explicitly selects.

These capabilities are provided by Apple’s Screen Time framework and operate entirely on-device. The app does not receive a full list of installed apps, does not track usage across all apps, and cannot monitor activity beyond what the user has explicitly selected.

All permissions are user-controlled and can be revoked at any time in iOS Settings under Screen Time.

Accessibility access, Overlay, and how shielding works (for Android)

What we use Accessibility for: on Android the App requests Accessibility permission to detect which app is foregrounded so it can temporarily show the shield overlay when the user has enabled shielding for a selected app. Accessibility is required for the core app gating feature to work; without it the App will still open, but shielding (the primary feature) will not function.

What data Accessibility sees and where it goes: the App observes the foreground app package name (to know when to show the shield). We do not read or persist UI text content. Only the list of apps that you explicitly choose to shield is stored locally on your device. No Accessibility-derived data that could identify your content is uploaded off-device.

Overlay usage: the overlay (SYSTEM_ALERT_WINDOW) is used to show a shield screen. The overlay records only aggregated local metrics such as total duration of shield sessions for use in local statistics and to show progress inside the App. These metrics are stored on-device and not shared unless you explicitly enable a feature that sends such stats to a server (currently not used).

Data we collect and how it is stored

We collect and process the following categories of information. For each category we explain where it is stored and who it is shared with.

Account & identity

• What: email address, username (if provided), Supabase user identifier.
• Why: to authenticate you, let you restore purchases, and associate your subscription across devices (if you sign in).
• Where: Supabase (authentication). We may send a user identifier to RevenueCat to associate purchases. We do not store raw payment card details ourselves.

Device & identifiers

• What: device identifiers necessary for analytics and third-party SDKs (app instance IDs, advertising ID when required by ad SDKs), IP address as used by servers.
• Why: analytics, crash reports, ad serving, fraud prevention, and to operate the App.
• Where: sent to third-party services like Firebase/Google Analytics, Crashlytics, AdMob, Google Tag Manager, and RevenueCat as described below; we do not use identifiers for sale or cross-context behavioral advertising beyond serving ad networks as required by their SDKs.

Usage & analytics

• What: events (screen opens, feature usage events, crash logs), install time, in-app events. We also log shield session durations locally (for user-facing statistics).
• Why: product improvement, debugging, usage metrics.
• Where: Firebase / Google Analytics (analytics), Crashlytics (crash reports), and other configured analytics tools. Consent for ads in EEA users is obtained via UMP before personalized ads are shown.

Payments & subscriptions

• What: payment is handled by RevenueCat and the platform stores payment details (Apple / Google). We receive only a user identifier and subscription status (as configured) — we do not handle card numbers.
• Why: to manage subscriptions and restore purchases across devices.
• Where: RevenueCat servers and the app stores.

Crash reports & diagnostics

• What: crash logs, stack traces, device model, OS version, and relevant app state at the time of crash.
• Why: to fix errors and improve stability.
• Where: Crashlytics (Firebase) and similar services.

Third-party services and SDKs

Ayne uses a small number of third-party services. Below is what we use and the types of data they typically receive. Many SDKs collect identifiers, events, and IP for their functionality.

• Supabase (Auth): used for authentication and user accounts. Supabase stores user records (email, username, uid). Data is hosted in Supabase projects (you use the Singapore region). Supabase transmits data over TLS and uses encryption-at-rest (AES-256) per their security docs.
• Firebase / Google Analytics / Crashlytics: used for analytics and crash reporting. These SDKs receive event data, app-instance identifiers, and diagnostic data. Firebase products encrypt data in transit and encrypt stored data at rest on Google Cloud infrastructure.
• AdMob (Google Mobile Ads): used to show ads. AdMob may use advertising identifiers, IP address, and device data to serve ads. Personalized ad serving is gated by UMP consent in EEA regions and as required by platform policies.
• RevenueCat: handles subscription purchases and management. We send a user identifier (Supabase UserID or app-provided user id) to RevenueCat to associate purchases and enable restores.
• Google Tag Manager: used for controlling deployed tags and analytics snippets; it may load additional scripts that collect analytics and tracking data.

Note on data sent to these providers: they commonly receive pseudonymous identifiers (app instance ID, advertising ID), event data (analytics), crash traces, and IP addresses. They are used only for their stated purpose. We do not authorize third-party access to your raw shielded-app lists or Accessibility content.

Advertising, consent, and cookies

We display ads through Google AdMob. In jurisdictions where consent is required (e.g., EEA), we show a consent prompt (UMP). Consent choices are stored locally in the App's preferences. If personalized ads are enabled, ad SDKs may use Advertising IDs and other identifiers to personalize ads. You can reset or revoke an advertising ID via the device OS settings.

Payments, subscriptions & refunds

All subscriptions are processed via RevenueCat and the platform billing providers (App Store / Play Billing). We do not collect or store payment card details. For refunds, users should follow the app store refund processes:

• App Store (iOS): contact Apple for refunds via App Store support.
• Google Play (Android): contact Google Play support or follow the Play refunds flow.
• Website / RevenueCat-managed receipts: if a purchase was made via a web flow managed by RevenueCat (or otherwise), please check the store or RevenueCat guidance. In general, subscriptions are non-refundable except as required by law or the store’s policies.

Where we host data and cross-border transfer

Hosting: account authentication uses Supabase (project region: Singapore). App analytics and crash reporting use Firebase (configured to an India region for project resources where applicable). Backups and provider storage are managed by those services.

Cross-border transfer: data may be transferred across borders as required to operate services (for example, analytics backends, RevenueCat, or other service endpoints). We rely on provider safeguards (encryption in transit, encryption at rest, and the providers' compliance measures). You can contact us for more details about safeguards in place for transfers.

Data retention

• Account data: retained while your account exists. If you delete your account we remove your account data from active databases; backups may persist for up to 90 days.
• Analytics: retention follows the default settings of the analytics provider (Google / Firebase) unless changed; typical analytics retention periods apply.
• Backups: provider backups and snapshot retention may be up to 90 days depending on provider settings.

Your rights (GDPR, CCPA, and other privacy law rights)

We support user rights under applicable laws:

• GDPR (EU/EEA/UK) rights: access, rectification, erasure, restriction of processing, portability, and to object to processing. You may also withdraw consent where processing is based on consent.
• CCPA/CPRA (California) rights: right to know categories collected, right to request deletion, right to opt-out of sale (we do not sell personal data), and other rights specified by California law.

How to exercise your rights: contact us at dev@beigelynx.com or use the in-app settings where present for account deletion. When contacting us, please state the request (e.g., access, deletion) and provide the email address or identifier associated with your account. We may need to verify your identity before fulfilling requests.

Security measures

We take reasonable measures to protect data: connections to our services and to third-party providers are encrypted in transit (TLS) and provider-side storage is encrypted at rest. Supabase and Firebase document encryption-in-transit and encryption-at-rest for their services. While we take steps to protect your information, no system is 100% secure, so we cannot guarantee absolute security.

Data breach response

In the event of a security incident involving user personal data, we will investigate, take remediation steps, and notify affected users and regulators as required by applicable law.

Children

Ayne is not intended for children under 13 (or applicable age in your country). We do not knowingly collect information from children under the age required by local law. If you believe we have collected data from a child in violation of law, contact us and we will promptly take steps to remove that data.

Changes to this policy

We may update this policy from time to time. We will publish the updated policy and the “Last updated” date at the top. Substantial changes will be highlighted for existing users where feasible.

Contact

If you have questions about this policy or want to exercise your rights, contact:

Developer / Data Controller:
Name: Mohammed Sané (personal developer)
Email: dev@beigelynx.com
Address (minimal contact): Jaipur, Rajasthan, India