Baby Bloom — Privacy Policy

1. At-a-glance summary

• Your baby's tracking data lives on your device by default. Baby Bloom stores everything you log (feedings, sleeps, diapers, growth, milestones, mood, activities, diary entries, photos, etc.) in a private SQLite database inside the app's own sandbox.
• An account is optional. The app is fully functional with no account. If — and only if — you create an account and sign in, your tracking data is synced to our backend at babybloom-api.vargary.com so it can be restored on a new device or shared with a co-parent you invite.
• The app shows no ads. Baby Bloom does not run any advertising. The free version is fully functional; the optional Pro subscription unlocks premium content and features rather than removing ads.
• We use Firebase Analytics and Sentry. These send a limited amount of diagnostic and behavioural data to Google and Sentry GmbH (EU region). Section 3 lists exactly what and when. We do not use Crashlytics, FCM push, OneSignal, Mixpanel, Amplitude, Segment, PostHog, AppsFlyer, Adjust, Branch, ML Kit, Facebook App Events / Meta SDK, Google AdMob / any ad SDK, or any speech-to-text/TTS service.
• The complete list of servers the app contacts (Sections 3 and 4): our own backend, Sentry, Firebase Analytics & App Check, Google Play (billing/review/update), Open-Meteo (only when the weather widget is enabled and you grant location permission), and Amazon / Shein (only when you tap an affiliate link, which opens your browser). Nothing else.
• We never sell your data, your baby's data, or any data about you.

2. Device permissions and why we use them

These are the permissions declared in the Android manifest. Some are auto-granted (e.g. internet); others trigger a runtime prompt the first time the relevant feature is used.

Notifications (POST_NOTIFICATIONS)

Why: to show local notifications — the persistent "tracking in progress" notification while you have a feeding/sleep/pumping/activity session running, scheduled reminders you choose to enable, and prediction nudges (Pro only).
Where processing happens: entirely on your device.
What is stored: notification scheduling metadata in shared_preferences. We do not run Firebase Cloud Messaging or any push-notification server — every notification you see is scheduled by the app, on the device.

Boot completed & exact alarms (RECEIVE_BOOT_COMPLETED, SCHEDULE_EXACT_ALARM, WAKE_LOCK)

Why: to re-arm previously scheduled reminder notifications after the device reboots, and to deliver time-sensitive notifications on Android 12+ at the scheduled minute rather than batched.
Where processing happens: on-device.
What is stored: the scheduled-notification table maintained by flutter_local_notifications.

Foreground service (FOREGROUND_SERVICE, FOREGROUND_SERVICE_SPECIAL_USE)

Why: Android requires a foreground service for the persistent "tracking in progress" notification so the OS doesn't kill the timer mid-session. The declared subtype is "Baby tracking timer and quick actions".
Where processing happens: on-device.
What is stored: nothing extra — the foreground service hosts the notification only.

Vibration (VIBRATE)

Why: tactile feedback on certain quick actions and notifications.
Where processing happens: on-device.
What is stored: nothing.

Internet and network state (INTERNET, ACCESS_NETWORK_STATE)

Why: to reach the network destinations listed in section 3 — cloud sync (only with an account), Sentry crash reporting, Firebase Analytics, weather. The connectivity check is used to skip sync attempts when you are offline.
Where processing happens: on-device decision; outbound calls go to the destinations in section 3.
What is stored: nothing additional.

Billing (com.android.vending.BILLING)

Why: to sell the Baby Bloom Pro subscription / lifetime through Google Play Billing.
Where processing happens: the purchase flow itself runs in Google Play; we never see your card details. After a purchase, the Play purchase receipt (purchase token, product ID, order ID) is sent to our backend at POST babybloom-api.vargary.com/purchases/verify so we can validate the receipt with Google and grant the entitlement to your account.
What is stored: validated entitlement state (the fact that you are a Pro subscriber, the product ID, and trial-eligibility flags) is stored on our backend keyed to your account and locally in shared_preferences.

Play Integrity (com.google.android.gms.permission.INTEGRITY_SERVICE)

Why: Firebase App Check uses Google's Play Integrity API to attest that a request to our backend really comes from a genuine, unmodified Baby Bloom binary running on a real Android device. This protects accounts and the backend from automated abuse.
Where processing happens: attestation is performed by Google on-device, the attestation token travels to Firebase App Check and then to our backend.
What is stored: nothing on our side beyond short-lived attestation tokens; Google's handling is governed by Google's own privacy policy.

Location (ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION)

Why: only for the optional weather widget on the home screen, which displays the current temperature, conditions and UV index so the dressing-suggestion card can suggest baby outfits appropriate for today's weather. If you do not grant location, the weather widget simply does not run.
Where processing happens: the latitude and longitude are sent to the free public Open-Meteo API (api.open-meteo.com) and the response is cached on your device. We do not log, store or transmit your location anywhere else.
What is stored: the latest cached weather result on the device. The raw coordinates are not persisted.

Other capabilities the app uses without a runtime permission: photo selection via the system photo picker (image_picker) — you grant access only to the specific images you pick; file pickers for data export/import (file_picker, flutter_file_dialog); the system share sheet (share_plus); device battery state (battery_plus, used to suppress notifications when the device is in a critical battery state); device timezone (flutter_timezone); device locale (easy_localization); package info (package_info_plus); high-level device model/OS info (device_info_plus, used only to derive a hashed local device fingerprint for trial-abuse prevention — not transmitted).

3. Every network connection the app makes

This table is the complete and exhaustive list of every host the Baby Bloom app contacts on its own. (Hosts opened in your browser when you tap a hyperlink, e.g. a Play Store URL or an affiliate product page, are listed at the end.) If a destination is not on this list, the app does not contact it.

User-initiated browser hand-offs. When you explicitly tap one of these, your default browser opens that URL. The Baby Bloom app itself does not exchange data with these hosts:

• play.google.com/store/apps/details?id=com.vargary.babybloom — "Rate us" / share-the-app deep link.
• play.google.com/store/account/subscriptions — "Manage subscription" link.
• www.amazon.com (with our affiliate tag babybloom01-20) — opened from the Essentials & Articles features when you tap an Amazon product card.
• us.shein.com — same, for Shein product cards.

If a diary entry or article references an external image URL, that image is loaded over the network from the URL itself — Baby Bloom does not proxy it.

4. Third-party services and SDKs

Vargary backend (babybloom-api.vargary.com)

Operated by Vargary. Hosts the optional cloud sync, account system, care-team invitations, referral rewards, and Google Play purchase verification. The backend is the only place — besides your own device — where a copy of your baby tracking data exists, and only if you signed in. Without an account, no baby tracking data is sent to this server.

Google Firebase — Analytics & App Check

We use Firebase Analytics for product-usage metrics in release builds. We do not use Firebase Crashlytics, Firebase Cloud Messaging (FCM), Firebase Authentication, Firestore, Firebase Storage or Firebase Remote Config. Firebase App Check (Play Integrity provider) is used to attest requests to our own backend. Firebase's role and data handling are described at firebase.google.com/support/privacy.

Sentry (Functional Software Inc., served from Sentry GmbH's EU region)

We use Sentry for crash and performance reporting. Sentry receives stack traces, breadcrumbs, device and OS metadata and the app version. It does not receive your baby tracking content, email or password. We selected Sentry's EU ingest endpoint so the data stays inside the EEA. Sentry's privacy notice: sentry.io/privacy.

Open-Meteo

A free public weather API. Receives only the latitude and longitude when the optional weather feature is active. No API key, no account, no identifier. open-meteo.com/en/terms.

Google Play (Billing, In-app Review, In-app Update, Play Integrity, Wear OS Data Layer)

Standard Google Play Services components on Android. The Play SDK handles the purchase flow directly with Google — Baby Bloom never sees your payment instrument. policies.google.com/privacy.

Amazon Associates and Shein

External affiliate partners. Baby Bloom does not exchange any data with them itself; tapping an Essentials / Articles product card opens your default browser to a search URL. The Amazon URL carries our affiliate tag babybloom01-20; the Shein URL does not. Once you are on their site, their privacy policies apply.

What we do NOT use

For transparency, the following are commonly bundled by similar apps but are not present in Baby Bloom: Firebase Crashlytics, Firebase Cloud Messaging (FCM) / OneSignal / any other push-notification server, Mixpanel, Amplitude, Segment, PostHog, AppsFlyer, Adjust, Branch, RevenueCat, Google ML Kit, speech-to-text / text-to-speech, OAuth sign-in (Google/Apple/Facebook), Facebook App Events / Meta SDK, Google AdMob / Google Mobile Ads / any advertising SDK, Firestore, any AI / LLM provider. Baby Bloom does not declare the Android Advertising ID permission, so neither Firebase Analytics nor any other component receives the Android Advertising ID. The google_fonts package is included but is configured with allowRuntimeFetching = false, so no fonts are downloaded from fonts.gstatic.com at runtime.

5. Where your data lives and how it is protected

On your device

All baby tracking data is stored in a local SQLite database at <app documents>/databases/babybloom.db, created and accessed via the sqflite plugin. App settings, onboarding state, notification preferences, cached weather, the streak counter, last-export timestamp, hashed device-trial fingerprint and the authentication token (if signed in) are stored in Android's shared_preferences.

Photos you attach to diary entries, milestones or growth measurements are downscaled (max 1920 px) and re-encoded as JPEG at ~128 KB or less, then stored as base64 strings inside the same SQLite database. Original photo files are not retained by the app.

OS-level protections

Both the database and the preferences files live inside the app's private storage area. Android's app-sandbox model prevents other installed apps from reading them. On modern Android devices, the user-data partition is encrypted at rest by the OS while the device is locked. We rely on these OS-level protections; the app does not add its own database encryption layer, and authentication tokens are stored in the same shared_preferences store rather than in a dedicated encrypted keystore — so a device that is unlocked and rooted could expose those values. Keep your device's lock-screen passcode / biometric enabled.

On our backend (only if you sign in)

If you create an account and sign in, the tracking data described above is uploaded to babybloom-api.vargary.com over HTTPS (TLS) and stored server-side under your account so it can be restored on another device, shared with people you explicitly invite, and recovered after an uninstall. Passwords are never stored in plaintext.

If you uninstall

Uninstalling the app removes the entire local database, the preferences file and any cached files — Android deletes the app's sandboxed storage as part of uninstall. If you were signed in and want the server-side copy removed too, see Section 7.

6. Data sharing

We do not sell, rent, trade or otherwise transfer your data, your baby's data or any data we hold about you to any third party for their own marketing or commercial purposes.

The only outbound data flows are the ones listed in Section 3: our own backend (only if you sign in), Sentry (crash/perf), Firebase Analytics (events), Firebase App Check (attestation), Open-Meteo (lat/lon when weather is on), Google Play (billing/review/update/integrity), and Wear OS Data Layer (peer-to-peer to your paired watch).

If you explicitly invite a co-parent or caregiver to your baby via the in-app care-team feature, and they accept, then the tracking records you've chosen to share are visible to that person inside their own Baby Bloom app. You can revoke their access at any time from the Care Team screen — once revoked, their app no longer syncs your baby's data on the next sync cycle.

7. Data retention

• On your device: data is retained until you delete the relevant entry, clear app data, or uninstall the app. There is no automatic expiry.
• On our backend (signed-in users only): baby tracking records are retained as long as your account exists, so we can keep cloud sync working. To delete the server-side copy and your account, email vargarytech@gmail.com from the address associated with your account — we will permanently delete your account and all server-side records within 30 days and confirm by email. Care-team invitations you sent are removed at the same time.
• Sentry crash reports: retained per Sentry's standard retention (currently 90 days for events) under our Sentry plan.
• Firebase Analytics events: retained per the default Firebase retention window (currently 14 months for event-level data), under Google's control. You can request earlier deletion of analytics data associated with your installation ID by contacting us.
• Email correspondence with support: emails you send to vargarytech@gmail.com are kept inside the Gmail inbox of the developer for as long as the conversation is useful, and otherwise deleted on a best-effort basis. We do not feed those emails into any external CRM or marketing tool.

8. Children

Baby Bloom is a tool that adult parents and caregivers use to track information about their baby. The baby is the data subject; the account-holder using the app is an adult user (typically a parent or other legal guardian). The app is not designed for, and is not intended to be used by, children themselves.

If you choose to use Baby Bloom without an account, no information about your baby ever leaves your device through Baby Bloom. The cloud sync, care-team sharing and backup features only become active when an adult account-holder creates an account and signs in, which constitutes that adult's consent (and, as applicable, their consent as the baby's legal guardian) for the baby tracking records to be sent to our backend so those features can work.

The diagnostic and behavioural signals collected by Firebase Analytics and Sentry (see Sections 3 and 4) describe how the adult user interacts with the app — they do not include the baby's identity, the baby's name, photographs of the baby, or any tracked-event content.

If you believe a child has used Baby Bloom directly without an adult's involvement, please contact us at vargarytech@gmail.com and we will delete the associated account on request.

9. Your rights (incl. GDPR / EEA users)

If you are located in the European Economic Area, the United Kingdom or Switzerland, you have the following rights under the EU General Data Protection Regulation (GDPR) and the equivalent UK and Swiss laws:

• Right of access (Art. 15) — confirmation of whether we process your personal data, and a copy of what we hold.
• Right to rectification (Art. 16) — correction of inaccurate data.
• Right to erasure / "right to be forgotten" (Art. 17) — deletion of your account and the server-side copy of your baby tracking data.
• Right to restriction of processing (Art. 18) — to limit how we process your data while a dispute is resolved.
• Right to object (Art. 21) — to object to processing based on our legitimate interests.
• Right to data portability (Art. 20) — a machine-readable copy of your data. The app also has a built-in "Export data" feature in Settings that exports everything we hold for your baby as a single JSON file.
• Right to withdraw consent (Art. 7(3)) — at any time, by signing out (stops cloud sync), revoking the location permission (stops weather), or uninstalling the app.

To exercise any of these rights, email vargarytech@gmail.com from the address associated with your account. We aim to respond within 30 days.

Data controller

The data controller for the purposes of GDPR is Vargary. Contact: vargarytech@gmail.com.

Legal bases for processing

• Art. 6(1)(a) — consent. For device-permission-gated features (notifications, location/weather, photos).
• Art. 6(1)(b) — performance of a contract. For account creation, authentication, cloud sync, care-team sharing, and Google Play purchase verification — these are the service you signed up to receive.
• Art. 6(1)(f) — legitimate interests. For crash and performance reporting (Sentry), Firebase App Check anti-abuse attestation, and aggregated product analytics that help us prioritise improvements. Our legitimate interest is keeping the app reliable and usable; you can object under Art. 21 by contacting us.

International transfers

The Vargary backend operates inside the EU. Sentry data goes to Sentry's EU region. Google (Firebase Analytics, Firebase App Check, Google Play) is US-headquartered and may transfer personal data outside the EEA; in those cases Google relies on the European Commission's Standard Contractual Clauses and / or the EU–US Data Privacy Framework. Links to Google's notices are in Sections 3 and 4.

Supervisory authority (Hungary)

If you are unhappy with how we handle your data, you have the right to lodge a complaint with the Hungarian data-protection supervisory authority:

Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH)
Address: 1055 Budapest, Falk Miksa utca 9-11., Hungary
Web: https://naih.hu/

EEA residents outside Hungary may also contact their local supervisory authority.

10. California residents (CCPA / CPRA)

If you are a California resident, the California Consumer Privacy Act, as amended by the California Privacy Rights Act, gives you the right to know, the right to delete, the right to correct, and the right to opt out of the "sale" or "sharing" of your personal information.

We do not sell your personal information in the meaning of CCPA / CPRA. We do not "share" your personal information for cross-context behavioural advertising in the meaning of CPRA. The third-party SDKs we use (Section 4) act as service providers in the meaning of the law; they receive only the data described in Section 3 and are contractually bound by their own terms not to use it for their own marketing purposes.

To exercise any CCPA / CPRA right, contact vargarytech@gmail.com. We do not discriminate against users who exercise their privacy rights.

11. Changes to this policy

We will update this page when our data-handling practices change. The "Last updated" date at the top of the page reflects the most recent revision. Material changes (a new third-party SDK, a new data flow, a change to retention) will be summarised at the top of the page for at least 30 days. Trivial editorial fixes are simply applied.

12. Contact

Questions, data-rights requests, deletion requests, security reports — please email:

vargarytech@gmail.com

Postal correspondence can be requested via the same address.