Privacy Policy

The short version

The Daily Layer tells you what to wear. To do that it needs to know what the weather is where you are, what clothes you own, and — if you connect a calendar — what your day looks like.

• Your photos and your wardrobe go to Google’s Gemini AI, through our own servers. Google does not use them to train its models.
• If you let the app use your location, your precise position is sent to a weather service (Open-Meteo) and to your phone’s own geocoder. If you set your city that way, we also store that position on your profile, rounded to about 110 metres. It is not sent to advertisers, and we do not sell it.
• Your calendar is read by your phone, not through our servers — from Google if you connect a Google calendar, or from your iPhone’s own calendar if you connect that. Only if you connect one.
• If you shop from the app, the products come from Channel3, a product-search service. Our servers ask it for them without your account. Your phone then downloads the product photos, which shows Channel3, and sometimes the shop, your device’s IP address; and a buy button takes you to the shop by way of Channel3, which reports taps and purchases back to us (section 7).
• You can delete your account in the app. Almost everything goes with it — section 9 is honest about the exceptions.
• Section 8 lists everything the app keeps — what switches each thing on, whether it is tied to your account, and how long it stays.

The rest of this page is the detail. It is longer than average because we would rather be specific than reassuring.

---

1. Who we are

The Daily Layer is Dalmeny Inc., a Delaware corporation. For anything in this policy, including a request to see or delete your data, write to adam@thedailylayer.co.

We are the controller of the data described here. The companies listed in section 7 process it on our behalf, except where that section says otherwise.

---

2. What we collect, and when

We collect what the features you use need, when you use them — with one exception, described below under Every time you open the app. Section 8 lists everything the app keeps, what switches each thing on, and how long it stays.

When you create an account. Your email address, and a password if you chose email sign-in. If you sign in with Google or Apple, we receive an identity token from them instead of a password, and keep what it carries: from Google, your Google account’s name, profile-picture link and account ID; from Apple, the email address Apple shares and an account ID, but not your name. We also store the name you enter.

When you add clothes. A photograph of the garment, and its name, colour, material, brand and size. The photograph is stored in our own private storage and is also sent for AI classification (section 3).

When you save something you bought. After a buy button has opened a shop, the app asks whether you bought it. If you add it to your wardrobe, the item holds the product’s name and brand, its colour and materials as the shop lists them, the size the shop’s page was opened in if there was one, and the tags for that kind of item, all of which you can change before it is saved; and a copy of the shop’s photo of the product, kept in the same private storage as your own garment photos. That photo is not sent to Google’s AI: nothing is classified.

When you build a Fit Profile. Two full-body photographs, your height, your size brackets, your shoe size if you give one, your body shape and proportions, and any fit notes. This is the most sensitive thing the app handles and it is behind its own consent step.

When you get a recommendation. Your style and fit settings, the kind of day you are having, your commute and how much time you spend outdoors, the weather, and the clothes you own. If a calendar is connected, also the kinds of events in your day, in the order they come — office, gym, date night and the like; the outfit request never carries their titles or their times. If you turn on Usage Analytics, we also keep a history of your recommendations, which records each event’s type and times and a one-way hash of its title (sections 6 and 8).

When you shop. Tapping a shop button sends our servers the kind of item you tapped, your garment style, and your size for that kind of item if you have one: the size on the item’s own tag if you own it, otherwise the one in your Fit Profile. That can be a size you typed yourself. Opening one of the products also sends which product it is, which shop sells it and which of the three bands it was shown in; tapping a size, a colour or a fit on its page sends that size, that colour’s product or that fit. Tapping its buy button sends all of this once more, so that the link you are given is fresh. These requests are made signed in to your account. Section 7 says what goes on from there to Channel3 and to the shop.

Every time you open the app. We record when you opened it. If Coarse location logging and automatic location are both on, we also record roughly where you were — an area about 1 km across — and when your phone fixed that position. Both are recorded whether or not you use the morning notification, and the morning notification is the only thing that reads them: it pauses after 14 days without an open, and it forecasts for where you last were (section 5). The record of when you opened the app cannot be switched off.

When you use location. See section 5 — it is the part of this policy most often written misleadingly, so it has its own section.

When you connect a calendar. See section 6.

When you send feedback. The message you write, the type you pick, your app version, and your phone’s system and its version. If you leave the switch on, also the outfit, the day settings and the weather the app was showing you. That outfit includes the names you gave your own items. It never includes your city, your calendar event names or your photos. It is stored against your account so we can reply.

What we never collect: payment details, your contacts, or your device’s advertising identifier.

One thing we do read from outside the app, and only if you ask us to. If you connect a calendar — your iPhone’s, or a Google one — we read your events out of it: title, description, times, whether it is all-day, the guest list (only to count it), and the location field. Section 6 says what happens to each of those, including the two we deliberately never send anywhere, and where each calendar is read from.

---

3. Artificial intelligence, and what reaches Google

Four features send data to Google’s Gemini models: building a Fit Profile, classifying a garment photo, generating an outfit recommendation, and — only if you turn it on — labelling a calendar event.

Everything goes through our servers first. Nothing is sent from your phone straight to Google’s AI. Our backend receives the payload, calls Gemini, and returns the result. So both we and Google see it.

Two of the four are cached, and they are kept for different lengths of time. An identical repeat request is answered from the cache without reaching Google at all — but an outfit recommendation is deleted within days, whereas a calendar label is kept for up to a month. Section 8 gives both periods.

Calendar events are labelled on your phone first. A word list on your phone labels an event when its title matches exactly one type, without sending anything anywhere. An event it cannot label is sent only if you have turned on Calendar AI (section 10); otherwise it stays unlabelled.

Google does not use this data to train its models. We use Gemini’s paid tier, whose terms state that Google “doesn’t use your prompts … or responses to improve our products.” Google does keep prompts and responses for a limited period to detect abuse; Google does not publish a number for how long, so we cannot give you one. Google also states this data “may be stored transiently or cached in any country in which Google or its agents maintain facilities.”

One detail worth being precise about. When a garment photo comes back with an invalid category, we send a second, follow-up request containing only the name, colour and material the model itself produced. Your photograph is sent once, never twice.

---

4. Your clothes and outfits

Your wardrobe — item names, colours, materials, brands, sizes and photographs — is stored in your account. Saved outfits store the same item details along with the settings and the city they were saved in. Section 8 says how long each of these is kept.

Photographs live in private storage scoped to your account. They are not public, not indexed, and not readable by other users. The copy of a shop’s photo kept for something you bought is stored the same way.

---

5. Location, stated plainly

This is the section most privacy policies get wrong, usually in their own favour. Here is what actually happens.

Turning it on is a choice. If you tap “Use my location” while setting up, or choose Current under Location on the Profile page, the app asks your phone for your position. To turn it off, choose Manual there. Picking a city in the Today box does not turn it off.

Your position leaves your phone. It goes to three places:

1. Open-Meteo, the weather service, which needs your precise coordinates to return a forecast.
2. Your phone’s own geocoder — Apple’s on iPhone, and on Android whichever geocoding service your device ships with — to turn your precise coordinates into a city name.
3. Us. When you tap “Use my location” while setting up, that position is saved to your profile as your default city, on our servers, rounded to three decimal places, about 110 metres, before it is stored.

The first two are requests rather than storage: they carry no name, no account and no identifier we hold. Open-Meteo’s terms say their server logs may contain coordinates and that logs are deleted after 90 days.

If you turn on the morning notification, a weather request goes out without you. Each day the notification is due, our server sends Open-Meteo a position: the area about 1 km across where you last opened the app, if your phone fixed it in the last 48 hours, and otherwise your saved default city. It goes from our servers, while you are not using the app, on a schedule rather than because you opened something. After 14 days without you opening the app, the notification pauses — we send one notification saying so — and so does this request, until you next open the app. Turning the morning notification off stops it.

The third is different, and it is the one worth understanding. What we store is not a request that passes through — it is your position, kept against your account, rounded to about 110 metres. That is close to where you were: it is not an approximate area. It is written once, when you set your location, and it is not refreshed on later visits: it is where you were when you set it, and it stays there until you change it. If you pick a city by hand instead, we store that city’s own coordinates from Open-Meteo’s list of places, rounded the same way, not your position.

Everything else we store is a coarse area. The location saved with a recommendation, with a worn outfit, or as where you last opened the app is a grid square about 0.6 by 1 kilometre, not the exact position. These are saved only if Coarse location logging is on.

Our servers also look up past weather. Each night, for the areas saved with recommendations, our server asks Open-Meteo what the weather actually was over the past days (up to 30). The request carries the centre of each area and nothing about you.

We do not use location for advertising, and we do not sell or trade your precise position. The three recipients named above are the only ones that receive it.

---

6. Calendar

Connecting a calendar is optional and off unless you connect one.

Your phone reads your calendar, not our servers. How depends on which one you connect:

• A Google calendar is fetched from Google, by your phone, over the internet. That request carries your Google authorisation and the calendar’s identifier — which for your own calendar is your Google account address. When you connect, we store that address and the account’s name with the connection.
• Your iPhone’s calendar is read from the phone itself, through Apple’s system calendar. Nothing is requested over the internet and no calendar data is sent to Apple by us. What we read from each event is its title, description, start and end times, whether it is all-day, how many people are invited (the app reads the guest list only to count it, and keeps only the number), and the location field.

Either way it does not pass through our servers on the way in.

We ask for calendar access only when you connect a calendar — not when you sign in with Google.

On Google, the permission we request is read-only. On an iPhone, iOS has no read-only calendar permission: an app that reads your events has to ask for full access, which would also let it change them. The Daily Layer only ever reads them.

What happens to an event depends on a separate choice. Labelling events with AI is off by default. If you leave it off, events are labelled on your phone or not at all. If you turn it on, an event’s title and a cleaned-up description may be sent — through our servers — to Google’s Gemini.

Either way, an event’s type can reach Google. The type an event is given — office, gym, date night and the like — goes into the outfit recommendation request (section 3), in the order your day runs, so the outfit can plan for it. Never its title, its description or its time.

We remove the location field from events before sending, and we never send the attendee count either. Location is the most identifying part of a calendar entry and the model has no use for it, so it is read on your phone and goes no further.

Disconnecting on iPhone does not revoke the permission, and we would rather tell you than let you assume. Apple gives apps no way to hand back calendar access programmatically. Disconnecting in The Daily Layer clears the calendars we had selected and we stop reading them — but iOS still lists us as having calendar access until you remove it yourself in Settings → Privacy & Security → Calendars.

We store hashes, not titles. If Usage Analytics is on, your recommendation history records the events in your day: each one’s type, its start and end times and whether it is all-day, and its title only as a one-way hash. When you correct an event’s type, we keep its title only as a hash too, with the type you chose, the type it replaced and, if your phone’s word list had picked that type, the word or phrase from that list which the title contained (section 8).

---

7. Who else receives your data

We do not sell your data. We have never sold it and this policy would have to change before we could.

About OneSignal specifically, because the timing is the part that matters: they receive your account identifier when you turn the morning nudge on, and keep it after you turn it off. While it is on they receive the text of each notification. A few hours after each notification, we ask OneSignal how many devices it reached, so we can tell if notifications stop arriving. We keep their id for that notification, the hour it was sent and those counts for about 35 days, with no account id (section 8).

In the current version of the app, no device is registered there until you turn the nudge on and allow your phone’s notifications for the app. From an Android phone, that also sends how often and how long you have used the app. Earlier versions did register a device with them whenever you opened the app, even if you never turned the nudge on. Updating does not delete that record: OneSignal does not delete a subscription when consent is withdrawn, and we have not built the call that would. If you were signed in with the nudge off when you updated, updating opts the record out and unlinks it from your account, except on an Android phone that last had a version from 8 or 9 September 2026, where it can stay opted in. If you were signed out, it stays as the earlier version left it. An unlink the earlier version could not send at the time, because you were offline, can also stay unsent. Turning the nudge on and then off again opts the record out and unlinks it. Until early September 2026, earlier versions also gave them your account identifier whenever you were signed in, even with the nudge off. Unlinking a record does not remove your account identifier from OneSignal: they keep it, as they do once you have turned the nudge on.

Turning the nudge off again stops the notifications and unlinks your account from that record — but both of those need your phone to be online. If you turn it off while offline, the change reaches our servers and theirs by the next time the app starts with a connection, and a notification can still arrive before then.

OneSignal’s software also sends them error and crash reports, from iPhones and Android phones, whether or not the nudge is on. When something goes wrong inside the OneSignal software the app includes, such as an error, or a crash (or, on Android, a freeze) that involves its code, it can send OneSignal a report. On Android, it also reports any crash whose error says the app was not responding, whatever caused it. OneSignal has these reports switched on for our app. A report holds the error itself, which can include this phone’s push token, your account identifier once OneSignal has it, and, once you have turned the nudge on, a notification’s text; your phone’s make, model and system version; the app’s name and version and the version of OneSignal’s software; technical details such as whether the app was open at the time; and identifiers that OneSignal’s software keeps on your phone.

Whether or not the nudge is on, OneSignal’s software also contacts OneSignal. It asks for its settings each time the app starts. On Android it also does so without the app being opened: when your phone restarts; (from Android 7.1) when the app is updated; about 30 seconds after you leave the app, if your phone has closed it by then; and, while the nudge is on, when a notification arrives or is dismissed and the app is closed. On Android it also checks which of its features to switch on when the app comes to the front, and every 8 minutes while it stays open; and on an Android phone that was ever registered with them (by an earlier version, or since you first turned the nudge on), it fetches OneSignal’s record of that registration each time you start using the app. On an iPhone it also checks which of its features to switch on, in the same way, in any run of the app in which OneSignal’s software has had your consent, until the app is next closed. The app gives that consent while the nudge is on, from when you turn it on and allow your phone’s notifications, until turning it off has reached OneSignal. After updating from an earlier version, it can also give it until it has checked your setting. On Android, every one of these requests also carries identifiers that OneSignal’s software keeps on your phone; on a phone that was ever registered, one of them is that registration. Like any server, OneSignal sees your device’s IP address each time.

About PostHog specifically, because the OneSignal note above raises the question: no events and no account of yours reach them until you turn Usage Analytics on. The app asks the analytics SDK to start with collection switched off, and turns it on only once your choice is known, so an account that never opts in is never identified to them and sends no events. Turning it off again clears the link between this device and your account and switches collection back off. Neither of those reaches backwards, and we would rather say so than let you assume: events captured while it was on stay at PostHog, still attached to your account identifier. Both steps are done by the app on your phone, not by our servers, and either can fail: if switching collection off fails, collection can continue from that phone, and if clearing the link fails, your phone can stay linked to your account for anything it sends later. Uninstalling the app ends both. We send your account identifier, never your email.

Not all of it is something you did. While Usage Analytics is on, the SDK also records by itself when the app is opened, installed, updated or sent to the background. Earlier versions of the app also let it register this device’s notification token and record when you tapped a notification; the current version does neither, and asks PostHog to delete a token an earlier version registered. We list those separately because “which actions you take in the app” would otherwise suggest you pressed something each time, and this is the kind of detail we would rather you read here than discover.

One event the app sends itself. While Usage Analytics is on, once each time the app starts, it records how it got the key that protects its data on your phone: read from the phone’s secure storage; newly made, and whether older data had to be cleared; or not readable, and, on an iPhone, whether it was locked at the time. Never the key itself. We use it to see how often a phone’s secure storage fails, which decides whether the app needs another way to keep your data on such a phone.

About the fonts, which is the smallest item in that table and the one most policies leave out: the app downloads its two typefaces from Google rather than shipping them inside the app, so Google sees your device’s IP address and which font was wanted. No account, no name, nothing about you beyond the request itself. We would rather name it than have you find it in a network log. Bundling the fonts into the app removes this entirely and is on our list.

About shopping, because three parties are involved and each sees something different.

When you tap a shop button, our servers ask Channel3, a product-search service, for products: the kind of item, one shop at a time, and that the clothes are for an adult. Except for accessories, they also say men’s or women’s when your garment style is one of those or the item itself is made for one: a skirt is searched as women’s whatever your style. Our servers store each shop’s list of products, and search again only when they have none or the one they have is more than a week old; every tap has them read the listed products from Channel3 afresh. Tapping another colour of a product has them read that colour’s product too. Unless that colour is itself on the list the product was shown from, every read of it comes with a read of the product you first opened, to check that it lists that colour. When a product is checked in your size, or in one you tap, our servers also send that size, in the words the shop itself uses for it and not as you typed it; a fit you tap is sent in the shop’s words too, where the product being read lists it. These requests come from our servers, not from your phone, and carry no account and no name. For them, Channel3 works on our behalf.

Your phone then downloads the product photos, including the small pictures of a product’s colours, itself, most from Channel3’s servers and a few from the shop’s own. Whoever serves a photo sees your device’s IP address and which photo was wanted, and so which product you were shown. When we looked, on 4 October 2026, the address at Channel3 of each of a product’s own photos also carried an id of the request of ours that produced it; in the answers Channel3 gave us on 10 October, the small pictures of its colours carried none. So Channel3 is in a position to connect your IP address with that request: the product and, where it was read in your size or in one you tap, that size, and any fit it was read with. We do not know whether it does. These downloads do not pass through us, and what Channel3 or a shop keeps of one is on its own terms, not ours.

A buy button opens the shop inside the app, by way of Channel3. The link goes to Channel3 first, which passes you on to the shop. It is made for that product, and for your size where one was chosen, so Channel3 can tell both. Whether it also says a fit you tapped, we do not know. Going by way of Channel3 is how a purchase can earn a commission, and we may earn one if you buy. Channel3’s privacy policy lists what it collects about a tap: which product and shop were tapped, where the tap came from, session and device information, your IP address and an approximate location. Channel3’s own privacy policy is where these records are described, and it gives no period for them beyond “as needed to measure performance and operate commission and merchant reporting”, so we cannot give you a number.

After that you are on the shop’s own website, which has its own cookies and its own privacy policy.

If you tell the app you bought it and add it to your wardrobe, your phone asks for that product’s photo again, from where it was shown: when the form for adding it shows the photo, unless the phone still holds it from showing it before, and again when you save it, and it can ask once more each time you try again after a save that failed. Channel3, or the shop for a photo it serves itself, sees those requests as it does when the photo is shown. Our code sends Channel3 and the shop nothing about the purchase: those requests carry nothing of ours but the address of the photo. But they come after a buy tap, and that puts Channel3, or the shop for a photo it serves itself, in a position to tell that you said you bought it and that you saved it. We do not know whether it does. With Usage Analytics on, PostHog records that you saved a purchase, but not what it was, with your account identifier, as it does every event.

Channel3 reports taps and purchases to us. Its documentation says each tap it reports carries the time, the product where it can match one, and a city and country where it has them; the report we saw on 4 October 2026 showed a city and a country for each tap. If you buy, then or within a time the shop sets, it records the sale and reports that too: when, the brand, the product where it can match one, what the order came to and our commission, with a city and country where it has them. We send Channel3 no location of yours and no account, so neither report names you, and the location comes from the request your phone makes. But with few people using the app, a time, a product and a city can be enough to point to one of them. This happens whether or not Usage Analytics is on.

---

8. What we keep

This is everything the app keeps about you in our database and file storage: what it is, when it is saved, what switches it on, whether it is tied to your account, how long we keep it, and what deleting your account does to it. What this website keeps is in section 11.

Turning a setting off stops new records; it does not delete what is already kept. Deleting your account does, with the exceptions in section 9, or write to adam@thedailylayer.co.

Data held by Google, Apple, Open-Meteo, OneSignal, PostHog and Channel3 is kept on their terms; sections 3, 5 and 7 say what we know of them, which for OneSignal is that they keep your account identifier once they have it.

---

9. Deleting your account

You can delete your account from inside the app. It deletes everything section 8 marks as deleted — your profile and settings, your wardrobe and its photos, your Fit Profiles and their history, your saved outfits, your recommendation history, your calendar connection and your privacy choices.

Six honest exceptions.

Photographs are deleted on a best-effort basis. Your images live in file storage, which is not covered by the automatic deletion that handles everything else, so the app deletes them in a separate step. That step can fail — for example if it times out.

If it does, the app tells you and asks you to write to adam@thedailylayer.co, and we will remove what is left. You can also write to us at any time to have us check and confirm.

Weather records remain, and become anonymous when your account goes. If Usage Analytics and Coarse location logging are on, the app saves the weather each recommendation was based on — for its area about 1 km across and its hour — so that a recommendation can later be compared with the weather it was made for, and with what the weather actually did.

Being precise about this, because the obvious phrasing would be wrong: while your account exists these records are linked to you in two ways. Each one records which account fetched it, and its area and hour also match your own recommendation history. Deleting your account removes both links: the account is erased from each record, and your recommendations are deleted. What remains is an area, an hour and the weather, with nothing left to join them to — which is what makes them anonymous, rather than them having been anonymous all along. The settled weather our servers look up each night (section 5) never carried an account, and once your history is gone nothing links it to you either.

Analytics events already sent to PostHog remain. If you ever turned Usage Analytics on, the events captured while it was on stay with PostHog, still attached to your account identifier. Deleting your account removes our copy of everything above and switches analytics collection off on your phone, but it does not reach into their records. Section 7 says what those events are, and what happens if your phone fails to switch collection off. If you never turned Usage Analytics on, there is nothing there to remain.

Feedback messages remain, without your account attached. If you sent us feedback from the app, deleting your account erases the account identifier on each message. The message stays, with its type, the app and system version, and the outfit, the day settings and the weather if you included them.

Being precise about the limit of that: we cannot erase what you wrote inside the message. If you typed your name, it is still there. If you want your messages deleted, write to adam@thedailylayer.co before you delete your account. Afterwards we can no longer tell which ones were yours.

Notification delivery checks remain until they expire. They carry no account id, so we cannot pick out yours to delete them early; each is deleted about 35 days after its notification was sent, as everyone’s is. While your account exists, the hour one was sent can match your notification time, and a pause notice’s hour can match when your notification was paused; deleting your account deletes both. OneSignal can also link its id to your account, and what OneSignal keeps is on their terms (section 7 says what we know of them).

Your record at OneSignal remains, if there is one. Nothing we run deletes it, and once OneSignal has your account identifier they keep it (section 7). If the nudge is on and your phone is online, the sign-out that ends the deletion opts that record out and unlinks it from your account; another phone signed in to the account stays linked.

---

10. Your choices

• Calendar AI — off unless you turn it on. It labels calendar events your phone cannot recognise, using Google’s AI (section 6).
• Coarse location logging — off unless you turn it on. It stores an area about 1 km across with recommendations and worn outfits, and the area where you last opened the app.
• Usage Analytics — off unless you turn it on. It keeps the history in section 8 and sends usage events to PostHog (section 7).
• Automatic location — on only if you turn it on: “Use my location” while setting up, or Current under Location on the Profile page. Switch it off there with Manual.
• Notifications — turn the morning nudge off in the app. Turning notifications off in your phone’s settings only stops them appearing: until you turn the nudge off, our server still sends OneSignal each morning’s notification and your account identifier.
• Your data — write to adam@thedailylayer.co for a copy, a correction, or deletion.

Turning a setting off stops new records; it does not delete old ones. What is already kept stays for as long as section 8 says, or until you delete your account or ask us to delete it. One record is kept whether or not a feature you use needs it: when you open the app (section 2).

Some AI features are not individually switchable: classifying a garment you photograph, and generating a recommendation, are what the app is for. If you do not want your wardrobe sent to Google’s AI, the app is not much use to you, and we would rather say that than offer a toggle that breaks it.

---

11. This website

thedailylayer.co is a plain website. It sets no cookies, runs no analytics, and loads its fonts from itself rather than from Google.

It is hosted by Google’s Firebase Hosting. Like any web host, it receives your device’s IP address and the page you ask for when you visit. Google’s terms govern what it keeps, and we add no analytics of our own.

If you sign up for the alpha, we store your email address, which phone you use, the boxes you ticked and anything you wrote, when you signed up, and when we sent your invite. We use it only to invite you and to tell you when the alpha opens. To invite you, we give your email address to Apple (TestFlight) for an iPhone or to Google (Firebase App Distribution) for an Android phone, and they send you the test app (section 7); their terms govern what they keep. We keep your sign-up until you ask us to delete it — write to adam@thedailylayer.co.

To stop the sign-up form being abused, each sign-up also stores a scrambled form of your IP address — a one-way hash, mixed with a secret value — for 25 hours, up to 26 by the time the hourly cleanup runs, and then deletes it.

---

12. Children

The Daily Layer is not intended for children under 13, and we do not knowingly collect their data. If you believe a child has given us data, write to adam@thedailylayer.co and we will delete it.

---

13. Changes

If we change what we collect or who receives it, we will update this page and change the date at the top. The app does not yet tell you when this page changes; until it does, the date at the top is how to tell.

---

14. Contact

adam@thedailylayer.co