Privacy Policy — Ahea
Last updated: 3 August 2026
Ahea is a clothing discovery app. This policy describes what it does with your information. It is written to be accurate rather than reassuring — where something is a limitation, it says so.
Before you publish: this document must be reachable at a public HTTPS URL, and that URL entered in App Store Connect and the Play Console. Replace the contact address below with a real one you monitor. Both stores check the link resolves.
The short version
In its default configuration, Ahea sends none of your personal information anywhere. Your account, your swipes, your saves and the photographs of your own wardrobe are stored on your own device. There is no analytics, no advertising, no tracking, and no third-party SDK collecting anything.
What is stored, and where
On your device only (default configuration):
| Data | Why | Where |
|---|---|---|
| Email address and display name | To identify your account | App storage |
| Password, salted and hashed | To verify sign-in. The password itself is never stored | App storage |
| Session token | To keep you signed in | iOS Keychain / Android Keystore |
| Swipe history (left and right) | To build your taste profile and avoid repeating items | App storage |
| Taste profile (style traits and weights) | To order your feed | App storage |
| Saved items | To show them back to you | App storage |
| Wardrobe photographs you add | To show you what you already own | App storage, in the app's own folder |
None of the above leaves your device. It is deleted when you delete your account or uninstall the app.
Wardrobe photographs, specifically. Pictures you add to your wardrobe are copied into the app's own storage and stay there. They are never uploaded, never sent to the brands, and never read by the recommender — it learns from swipes on catalogue listings and has no access to your photographs at all. The app asks for photo-library access only when you tap to add one, and requests no location data from the images it receives. Removing a piece from your wardrobe deletes the app's copy.
If the operator has enabled cloud accounts (Supabase): the same data is stored on a Supabase project controlled by the operator instead, so it can sync across your devices. Row-level security restricts every record to its owner. Supabase acts as a data processor; see their sub-processor list for hosting regions.
Counts sent to the brands
This is the one thing the app sends that is not about your account, so it is set out in full rather than summarised.
Brands that list with Ahea can see how their own pieces are doing. To make that possible, the app increments counters against a product, never against a person. When you swipe, save, open a piece or tap through to a brand's site, the app adds one to a tally and sends it in a batch. What arrives is exactly this:
| Field | Example |
|---|---|
| Product id | colorfulstandard-15664182362437 |
| Brand | Colorful Standard |
| What happened | one of: swiped right, swiped left, saved, opened, clicked through |
| How many times | 1 |
There is no user id, device id, session id or install id in that payload, no IP address is stored with it, and the only time recorded is the calendar day the server received it. The counters can only be incremented, never read back, by the app.
The consequence is deliberate: a brand can learn that a jacket was kept 62% of the times it was shown. Nothing in the database can tell them, or us, that you kept it, or that the same person who kept the jacket also kept the trousers. The reports a normal analytics stack would offer — funnels, cohorts, per-person journeys — are not possible here, and are not planned, because building them would mean linking these counts to a person.
Your taste profile is not part of this and never leaves your device.
Batching is part of the design rather than an optimisation: one request per swipe would leak the timing of your session, and a sequence of timings can identify someone even with no name attached.
If no Supabase project is configured — the default build — none of this is sent anywhere, because there is nowhere to send it.
What is never collected
- Location, contacts, photos, camera or microphone. The app requests none of these
permissions.
- Advertising identifiers. The app does no tracking as Apple defines it, and its
privacy manifest declares NSPrivacyTracking: false.
- Crash telemetry, and any analytics tied to a person. The per-product counters above
are the only measurement in the build, and they are anonymous by construction.
- Payment or card details. Ahea never takes a payment — see below.
Buying things
Ahea does not sell anything and holds no stock. Each product is sold by the retailer named on its card. Tapping "Buy at …" opens that retailer's own website in a browser, and from that point their privacy policy and terms apply, not this one. Any address or payment details you enter are given to them, never to Ahea.
Product information in the app — photographs, names, descriptions, prices, sizes — is retrieved from those retailers' own public product listings. It is a periodic snapshot, so a price or a stock level may be out of date; the retailer's page is always authoritative, and the app labels how old its snapshot is.
Network requests the app makes
- Product images, loaded from the retailers' image CDN when a card is shown.
Those CDNs will see your IP address, as with loading any image on the web.
- The retailer's website, only when you tap through to buy.
- `u.expo.dev`, on launch and when the app returns to the foreground, to ask
whether a newer version of the app is available. The request carries the app's version and platform, not anything about you or your account. This is how fixes and refreshed product data arrive without a store update.
- Supabase, only if the operator has enabled cloud accounts.
There are no other outbound requests. The product catalogue itself ships inside the app, so browsing works offline.
Your choices
- See what it learned about you: Profile → What it has learned shows the whole
taste profile, including what it is steering away from.
- Reset the taste profile: Profile → Forget what it learned.
- Erase your activity: Profile → Erase my activity.
- Delete your account and all of its data: Profile → Delete my account. This
is immediate and cannot be undone.
Children
Ahea is not directed at children and does not knowingly collect information from anyone under 13 (or the age of digital consent in your country). It is rated for a general audience; it sells nothing and contains no user-generated content.
Security, stated honestly
In the default on-device configuration, passwords are salted and hashed with iterated SHA-256 before being written to app storage, and session tokens are held in the platform keystore. That protects against casual inspection of the device's storage. It is not equivalent to server-side password handling: there is no memory-hard key-derivation function available to the app and no rate limiting, so someone with your unlocked device could attack the stored hash offline. If this matters for your deployment, enable the Supabase configuration so credentials are handled by a server.
Changes
Material changes will be reflected in the "last updated" date above, and in the app's release notes.
Contact
Questions or data requests: privacy@example.com (replace before publishing)