Privacy

Version of 23 September 2026. Written in English, because Sheaf is an English-language app. Processing is governed by the GDPR and by German law.

The short version

Sheaf has no accounts. There is nothing to sign up for, nothing to log in to, and no profile attached to you. There is no advertising, no third-party analytics, no attribution SDK. Technical error reports go only to our own server, and this website sets no cookies.

What is left is small and it is listed below in full: a random device identifier so a subscription can be unlocked on the device that paid for it, a separate rotating identifier used to measure whether songs get finished, running totals that carry no identifier at all (how often a quiz question is answered right, which screen the subscription offer was opened from and how it ended, and how many people opened the app on a day), technical error reports, ordinary server records, and — only if you choose to write one — a message you send us from inside the app, which carries that device identifier so that we can answer it and delete it if you ask. What you write into the morning's reflection is not in that list, because it never leaves your phone.

1. Who is responsible

The controller within the meaning of Art. 4 (7) GDPR is:

…
…
Email
…

We have not appointed a data protection officer; on the size and the kind of processing described here, Art. 37 GDPR and § 38 BDSG do not require one. Write to the address above with anything about this page.

2. What stays on your device, and is therefore not collected at all

The following live in the app's own database, on that phone, and are never transmitted to us. They are not "data we protect carefully". They are data we do not have.

Deleting an entry deletes it. Deleting the app deletes all of it. We cannot restore any of it, because we never had it.

3. What is sent to us, why, and on what legal basis

3.1 Delivering the catalogue

The app asks our server for the catalogue and downloads the songs, lessons and morning pages it shows you. Those requests carry no identifier of you.

Legal basis: Art. 6 (1)(b) GDPR. The processing is necessary to perform the contract you entered into by using the app.

3.2 Unlocking what a household has paid for

The app registers a device identifier with us: a random UUID made for this purpose, sent together with the platform (ios or android) and the app's build number. We store it with the time it was created and the time it was last seen, and beside it the record of what has been unlocked and until when.

It is not your name, your email address, your advertising identifier, or anything Apple or Google tell us about you. It identifies a device, not a person, and it is worth no more than knowing what has been paid for. Because the identifier is itself the credential, anyone holding it can ask what that device has unlocked. It is deliberately worth nothing else.

When you play a premium track, the app asks us for a short-lived token tied to that identifier, and the token is what the media request carries.

Legal basis: Art. 6 (1)(b) GDPR.

3.3 Whether songs get finished, whether a question is as hard as we think, and which offer works

The catalogue is small, and every song in it is a decision. So when a song is played, the app records how many seconds were audible, the furthest point reached, where somebody skipped, and how the playback ended, and sends that to us in a batch.

The record also says roughly how old the install identifier below was when the song was played. It is one of six ranges: the same day, the next day, two to three days, four to seven, eight to thirty, or thirty-one to ninety. It lets us see whether people come back at all, which nothing else we hold can answer. It is the age of the identifier rather than of your installation. That identifier is replaced every ninety days. A replaced one starts again at nought, so we cannot see past ninety days for anybody. The date the identifier was made stays on your device and is never sent.

Three things make this what it is, and all three are enforced in the code rather than promised here:

No name, no account, no advertising identifier and no stored IP address sits beside the row.

The same switch also covers quiz questions. Each question in Sheaf is labelled easy, medium or hard by whoever wrote it, and that label is a guess until answers measure it. So when a question is answered — in a quiz round, in practice, or in a lesson check — the app sends us three things: which question it was, the level it was labelled at, and whether the answer was right. Nothing else.

There is no identifier on this at all, not even the rotating one described above. We keep two running totals per question — how often it was asked and how often it was answered right — and an answer is added to them on arrival, so there is nothing left to join it to. We cannot see which questions any one person answered, in what order, or how well anybody does. What we can see is that a question labelled easy is answered right by six people in ten, which means the label is wrong and the question needs a new one or a rewrite.

The same switch also covers the Sheaf Pro offer. When the offer is shown, the app sends us which screen it was opened from (a locked song, a locked quiz, a lesson, Settings, and so on), what happened — whether a purchase was started, whether it went through, was cancelled or failed, or whether the offer was simply closed — and the day it happened. Nothing else.

There is no identifier on this either. We keep one running total per day, per screen and per outcome, and each step is added to it on arrival. We cannot see who saw the offer, whether the same person saw it twice, or what anybody did before or after. What we can see is that an offer opened from one screen is rarely taken up and from another often is.

The same switch also covers a count of app opens. The first time the app is opened on a day, it sends us the same age range described above — how old the install identifier is, in one of the six ranges — whether it is the iPhone or the Android app, and the day. At most once a day, and nothing else: not the identifier whose age it is. We keep one running total per day, per age range and per platform, so we can see how many people come back after a day, a week or a month without being able to see who.

Legal basis: Art. 6 (1)(f) GDPR. Our legitimate interest is knowing which of a very small number of songs people finish and which they abandon, so that we make more of the first kind, knowing whether a question is as hard as its label says, so that a level means something, and knowing where the offer to subscribe helps and where it only gets in the way, and whether people come back to the app at all. The question counts, the offer counts and the open counts hold no identifier whatsoever, so the balancing for them is simpler still: there is nothing in them that is about a person. We consider it to override your interests because the record is pseudonymous under an identifier that expires, cannot be joined to the identifier that knows what you paid for, is deleted after ninety days, and never changes what you are shown. The age range is a property of the identifier rather than of you, is deliberately coarse, and is left off entirely whenever it could not be given without linking a replaced identifier to the one before it. Those records are also the one thing an erasure request cannot reach, precisely because they carry no identifier that could be matched to you. They expire instead.

You may object at any time and without giving a reason (Art. 21 GDPR). In the app: Settings → What Sheaf measures, and turn off "Which songs and questions work". That stops the listening records, the question counts, the offer counts and the open count, throws away anything measured and not yet sent, and replaces the install identifier, so what has already been sent cannot be joined to anything the device does afterwards. You can also write to the address in section 1 and we will confirm.

3.4 Buying a subscription

Payment happens in the App Store or in Google Play. We never see a card number. From the store we receive only the fact that a subscription started, renewed, lapsed or was refunded, so that content can be unlocked or locked again.

That flows through RevenueCat, which keeps subscription state for us. The app tells RevenueCat the same device identifier as in section 3.2, and RevenueCat tells our server when something about a subscription changes. We store the notification it sends, which contains that identifier and the store's own description of the event — including whether the period it describes is a free trial, an introductory or promotional price, or an ordinary paid one. We keep that last fact beside the unlock, so that a message you write while you are still trying Sheaf can be read as one.

Legal basis: Art. 6 (1)(b) GDPR.

3.5 A message you send us from inside the app

Settings has a form headed Write to us. Nothing is sent from it unless you write something and press send.

What we then receive is what you wrote, which of the three headings you chose, and a few small facts about the app and your situation: its version, whether it is the iPhone or the Android build, what your system calls its version, the language the app is being read in, the device identifier from section 3.2, and whether the app believed you were subscribed, in a trial, or neither — and if so, which day of it. It only ever says “trial” where the store has told us it is one, and where it has not been able to ask us at all, it says that rather than guessing. Every one of those is on the form above the send button, so nothing goes that you were not shown; the identifier itself sits behind Show identifier, where it is printed in full and never shortened, because it is the string you would quote back to us to have everything you sent deleted.

Why the identifier goes with it. Sheaf is a paid app with one person reading what arrives, and without it a message is a paragraph from nobody: we cannot tell three reports from one person having a bad week, we cannot tell whether something is failing for people who have paid, and we can never find your message again. With it we can do all three, and we may be able to answer you. It is the same identifier section 3.2 describes — not a name, not an email address, not an account, because the app has none of those.

What that means for your rights. A message you sent is now something we can find and delete: tell us the device identifier and it goes with everything else filed under it (section 8). Whatever is left is deleted after 180 days either way. Whether you were subscribed is what the app believed at the moment you pressed send, which is not always what our records say — it is context on a message, and it decides nothing about what you can open or what you are charged.

Legal basis: Art. 6 (1)(f) GDPR. Our legitimate interest is learning what is wrong with the app and what people want from it, and being able to answer the person who told us. Automatic technical reports cannot explain what you experienced.

3.6 Keeping the service up

Our server writes one line per request with the method, the path, the status code and how long it took. It does not log IP addresses, user agents or request bodies. A few lines do contain the device identifier from section 3.2: the ones about a refused premium request and about a failed device registration.

To stop one caller flooding a route, the server counts recent requests per IP address in memory only. Nothing is written to disk, nothing survives a restart, and an entry is worthless within a minute.

Legal basis: Art. 6 (1)(f) GDPR. Our legitimate interest is operating the service and defending it against abuse.

3.7 Technical errors and crashes

Release builds send error types, technical stack frames of every thread, event times and app build versions to our self-hosted Sentry at sentry.sheesh.solutions. Native crash reports may be sent on the next launch. To tell a fault on one kind of phone from a fault everywhere, a report also carries the device model and manufacturer, processor architecture, whether it is an emulator, operating system name, version and build, whether the app was in the foreground, the screen orientation and pixel density, and memory and free storage rounded down to broad steps.

It also lists up to the last twenty screens opened before the fault, by the screen's name in the app's code (for example /songs/:songId) — never which song, lesson, quiz or text, and never what was typed or tapped on it.

Reports contain no reflection or feedback text, exception messages, purchase receipts, user, device or installation identifiers, device name, language or region, time zone, network or carrier, battery state, exact screen size, request URLs, screenshots or screen recordings. We do not use session replay, profiling or performance tracing.

These reports help us find and repair failures. They are not joined to purchase, feedback or listening records, and we do not attempt to identify people from them. IP storage is disabled in the Sentry project. Network transport still necessarily exposes a source IP to the server.

Legal basis: Art. 6 (1)(f) GDPR: our legitimate interest in maintaining a reliable app, limited to technical diagnostics. You may object using the contact details above.

4. This website

It sets no cookies, and it loads its fonts, styles and images from this server alone. There is no analytics of any kind.

The postal address and the email address on the imprint appear only after your browser has quietly solved a small computational puzzle. It asks nothing of you, and it is there to stop address harvesters collecting them in bulk. Doing it loads a script from captcha.sheesh.solutions, which is our own server and not a third party. That server necessarily sees your IP address and the ordinary headers your browser sends, and uses them to tell a browser from an automated client. It is Cap, self-hosted for exactly this reason: the alternative would hand a visit to our imprint page to a third-party captcha company, and there is no version of that we would be comfortable with on this page.

Legal basis: Art. 6 (1)(f) GDPR. Our legitimate interest is not having our contact details harvested, weighed against a transient technical record.

5. Storing things on your device (§ 25 TDDDG)

The app stores on your device what is needed to give you what you asked for: the catalogue, your downloads, your progress, and the device identifier that unlocks what you paid for. That is strictly necessary within the meaning of § 25 (2) no. 2 TDDDG and needs no consent.

The install identifier described in section 3.3 is also stored on your device, for the measurement described there. Listening records and answered questions wait on your device until they have been sent, and are deleted once they have; the answered ones carry no identifier, on your device or on ours. This website stores nothing on your device beyond what your browser needs to display the page.

6. Who else sees anything

We use the following processors and recipients, and no others:

netcup GmbH, Daimlerstraße 25, 90441 Nürnberg, Germany
Hosting of our server and of this website, in Germany. A processor under Art. 28 GDPR.
RevenueCat, Inc., San Francisco, USA
Subscription state. Receives the device identifier from section 3.2 and the purchase information the store provides. A transfer to the United States, made on the basis of the European Commission's standard contractual clauses under Art. 46 (2)(c) GDPR and, where applicable, a certification under the EU–US Data Privacy Framework.
Apple Distribution International Ltd., Ireland / Apple Inc., USA
Distribution and payment on the App Store. Apple is a controller in its own right for what it does with your Apple Account; what reaches us is only what section 3.4 describes.
Google Ireland Ltd., Ireland / Google LLC, USA
Distribution and payment on Google Play, on the same footing as Apple.

There is nobody else. No advertising network, no analytics company, no attribution service, no external crash-reporting provider, no third-party content delivery network. We run the Sentry software on our own infrastructure; reports are not sent to Sentry's hosted service. Nothing is sold, and nothing is shared with anybody for their own purposes.

We pass data to public authorities only where we are legally obliged to, and only what we are obliged to pass.

7. How long anything is kept

Technical error reports (section 3.7)
Ninety days. Reports expire automatically in the event store; a daily cleanup job removes expired records and associated metadata.
Listening records (section 3.3)
Ninety days, then deleted by a job that runs every night. The identifier on them expires on the same ninety-day clock, so no chain of listening longer than that window can exist.
Question counts (section 3.3)
Kept for as long as the question is in the catalogue: they are two running totals per question and hold nothing about anybody, so there is nothing in them for a retention period to protect. Nothing is stored per answer, and nothing dated — an answer is added to a total the moment it arrives and stops existing as an answer.
Offer counts (section 3.3)
Kept as running totals per day, per screen and per outcome. They hold nothing about anybody — no identifier and no time finer than the day — so there is nothing in them for a retention period to protect.
Open counts (section 3.3)
Kept as running totals per day, per age range and per platform. They hold no identifier, so there is nothing in them for a retention period to protect.
Device identifier and what it has unlocked (section 3.2)
For as long as the device may need it to restore a subscription. A subscription that has ended is kept rather than deleted, because a refund or a billing dispute can arrive months later and answering one needs the history. Ask us and we will delete it. See section 8.
The store's subscription notifications (section 3.4)
400 days, then deleted by a job that runs every night. The longest thing we sell is a yearly subscription, so a year is the shortest window in which the whole life of a purchase can be read side by side: the first payment, and the renewal or the expiry that answers it. The rest is room for a late renewal, and for the time it takes somebody to write to us and be answered.
A message you sent us (section 3.5)
180 days, then deleted by a job that runs every night — or sooner, if you ask us to delete what is filed under your device identifier. Long enough that a report can still be read when the fix ships, and finite because nothing here should become a permanent archive of other people's words.
Server log lines (section 3.6)
For as long as the server keeps its output. They are not archived.
Rate-limit counters
In memory only. Gone on restart, and worthless within a minute.
What is on your device (section 2)
Until you delete it, or delete the app. We have no say in it and no copy of it.

8. Your rights

You have the right to:

How to exercise them, given that we do not know who you are. There is no account, so we cannot look you up by name, and we will not ask you for identity documents in order to create a link that does not otherwise exist. What we can act on is an identifier: tell us the device identifier from section 3.2 and we will show you, correct or delete everything filed under it. Deleting it is one command on our side and it reaches all three places that identifier appears, including the store's notifications, which do not go with the rest on their own, and any message you sent us from inside the app. What it cannot reach is the listening records in section 3.3, and a message you sent us under section 3.5 from a device that had not yet been given one. In the first case that is deliberate and permanent — a listening record carries a different identifier on purpose, so that it cannot be matched to you at all — and in the second there is simply nothing on the row to match. Both expire on their own instead. If you cannot produce an identifier, say so, and we will tell you honestly what can and cannot be found. In most cases the honest answer is that we hold nothing that can be tied to you, which is the point of the design rather than an evasion.

You have the right to complain to a supervisory authority (Art. 77). You may complain to any of them; the one competent for us is Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit, Ludwig-Erhard-Str. 22, 20459 Hamburg — datenschutz-hamburg.de.

9. Automated decisions

There is no automated decision-making producing legal or similarly significant effects, and no profiling, within the meaning of Art. 22 GDPR. Nothing in Sheaf changes what you are shown on the basis of what you have done.

10. Children

Sheaf is made for families to use together and is not directed at children as its primary audience. It collects no personal data from anybody, of any age, beyond what is described above. The learning path collects nothing at all, and that is the part meant to be worked through together with your children. What a child writes stays on the device.

11. Do you have to give us anything

Only what section 3.2 describes, and only if you want a subscription unlocked: without a device identifier we cannot tell which device paid. Everything else is either not personal data or not required, and nothing bad happens if you object to section 3.3.

12. Changes to this page

If this page changes in a way that matters, the version date at the top changes with it. We will describe any material change to collection here. Our technical error reports remain separate from personal writing and identifiers; we do not use third-party analytics or advertising.