DYLD — Get Dialed Last updated: September 8, 2026
This policy explains what DYLD collects, where it goes, and what you can do about it. It is written to be read, not to be survived.
Two companion documents sit alongside this one: our Consumer Health Data Privacy Policy, which the law requires to stand on its own and which covers your training, food, and mental-health data in detail, and our AI Coach Disclosure and Safety Protocol, which says plainly that the coach is a machine and publishes exactly what happens if you write something that suggests you are in crisis.
The short version: the things you write stay on your phone. Your workouts, your food, your journal, your check-ins and your Word notes are stored only on the device. We have no copy of any of them and nobody here can retrieve them.
Three things are different, and you should know them before you read anything else:
DYLD is operated by RJ Galasieski, an individual developer based in California, United States.
Contact: [email protected]
You must be at least 13 to create a DYLD account. We do not knowingly collect information from anyone under 13. If we learn we have, the account and its data are deleted.
Crew — the in-app community — is 13+, the same floor as the account itself. If you are under 13 the Crew tab does not appear and its screens are not reachable. This is enforced in the app.
Because members aged 13 to 17 can post, Crew is moderated. Every message passes a content filter before it sends, any member can report or block any other, reports reach a human queue that is acted on, and the code of conduct must be accepted before a first post. Contact for anything urgent is published inside the app and here: [email protected]. There are no private messages in Crew and no way for one member to contact another off-platform through the app.
If you believe a child under 13 has given us information, email [email protected] and we will remove it.
This is everything you actually write. The following is stored only in a database on your device. We cannot see it, we have no copy of it, and it is not backed up to us:
None of this comes back on a new phone. What does come back is the backup described in section 4(b), which is a much smaller thing than the list above.
Your age comes from you, and from nowhere else. You give us a birth date when you create your account. That single answer decides two things: whether Crew appears (it needs 13) and whether the under-18 food guardrails apply (they need 18). Those are separate thresholds and your birth date answers both. Your birth date is stored on your device and, because it is part of your system backup, on our servers — section 4(b).
We do not ask Apple for your age. An earlier version of this app asked iOS for the age category on your Apple Account. It no longer does, and the code that did it has been removed. Nothing about your age reaches us from Apple.
One exception, and you trigger it: the AI coach. When you ask the coach a question, the app sends a snapshot of the above — your recent training, your food numbers, your check-ins, and your journal entries from the last 7 days, as you wrote them — along with your question, so the answer is about your actual life instead of generic advice. It is used to answer that one question and is never stored, by us or by the AI provider. If you never open the coach, none of this ever leaves your phone. Section 5 covers exactly where it goes.
If you delete the app, this data is gone. We have no way to restore it.
You need an account to use DYLD. There is no signed-out mode and nothing in the app works without one. An earlier version of this policy said an account was needed only for Crew. That stopped being true, and this sentence replaces it.
When you create one we receive:
Your starting display name is a neutral generated name, not your email.
Why: to let you sign in, to give your system back to you on a new phone, to attribute your messages to you in Crew, and to prove you accepted the community rules.
This is the part most people would not expect, so it gets its own section. When you finish onboarding, and again whenever your system changes, three things are saved to your account on our servers:
Why, and it is the only reason: so a reinstall, a new phone or a wiped device does not hand you an empty app and make you a new user twice. It is a backup. Nobody reads it, it is not analysed, it is not used for advertising, and it is not sold.
What is deliberately NOT in it: your workouts, your food logs, your journal entries, your Word notes, your coach conversation and the coach's notes about you. Those stay on the device (section 3), and a new phone does not get them back.
Only you can read it. Every row is scoped to the account that wrote it by a database policy, and there is deliberately no administrator path to it either.
If you set a profile picture, a copy is stored on our servers and is visible to every other member — that is what puts your face beside your messages. Your display name and your W–L record are visible to every member the same way.
If you would rather nobody saw a picture, do not set one. You can change or remove it at any time from the YOU tab.
The image you pick is cropped and shrunk to a small square on your phone before any of it is sent. We never receive your photo library and we never ask for access to it — iOS hands us only the one image you chose.
Crew is a public community inside the app. Anything you post there is visible to other members.
We store your messages, reactions, replies, the channel and the timestamp, plus any blocks you set and the last time you read each room.
Why: because a chat room does not work otherwise.
If you report a message, or if you are moderated, we store:
Why: Apple requires that we act on reports, and a moderation system that destroys its own evidence cannot be fair to either side. Report snapshots are retained as a safety record.
If you turn notifications on, we store a push token for your device and your two notification preferences (announcements, mentions). A push token is the address a notification is delivered to. It is not your name, your email or your location, and only your own account can read it.
Notifications are delivered through Expo's push service, which hands them to Apple.
Why: a notification cannot reach a phone without one. Turn notifications off and it stops being used; sign out and it is deleted.
If you open the invite screen we mint a six-character referral code tied to your account. If somebody redeems a code, we store who referred whom, the code, and when — one redemption per account, ever.
Why: so an invite can be credited to the person who sent it. Nothing else is derived from it.
We store whether your subscription is active, when it expires, which product it is, and which store event we saw last. This reaches us from RevenueCat, not from you.
Why: to know whether to unlock the paid features.
If you use the AI coach or the meal-photo scan, we store a count of how many times you used them today. Not what you asked. Not what you sent. A number.
Why: to enforce a daily limit and keep costs bounded.
When you ask the coach a question, it is sent to our AI router, OpenRouter, which passes it to a US-hosted model to generate a reply. Sent with it, so the answer is about you and not about people in general:
Nothing is stored on our servers, and every provider in the path is contractually barred from retaining it or training on it. The exchange exists for the length of one request. If you never ask the coach anything, none of this is ever sent.
Two different models handle a coach turn, and they are not the same company. One writes — every word you read comes from OpenAI's GPT-5 mini, reached through OpenRouter and run by OpenAI or Microsoft Azure. The other decides — safety checks, working out what you are asking, and which of your numbers to look up run on Qwen, an open-weight model hosted by DeepInfra or Parasail. The deciding model never writes anything you read, and the code enforces that rather than asking for it.
When you photograph a meal, or speak what you ate, the photo or the transcript is sent through the same router to estimate what is in it. Neither is ever stored on our servers — each exists for the lifetime of one request and is then gone.
On where these go, specifically, because it is the question worth asking. Every model we use runs on US-hosted infrastructure, chosen from a list pinned in our server code rather than left to whichever host is cheapest that day. Each is contractually barred from retaining what we send or training on it, and we set the router's no-retention flag on every request as well.
The current list, and it is short:
Changing that list is a change to this policy, not just a change to our code, and it is written into the code that way.
Barcodes are looked up against Open Food Facts, a free public food database. Only the barcode number is sent.
| Service | What it receives | Why |
|---|---|---|
| Supabase | Your account, your system backup, your profile picture, Crew messages, moderation records, push tokens, referrals, subscription status | Hosts the account and the community |
| OpenRouter | Coach questions with your numbers and recent journal entries; meal photos; spoken food logs | Routes each request to the right model |
| OpenAI (or Microsoft Azure, US-hosted) | The same, for the model that writes the coach's answers | Generates what the coach says |
| DeepInfra, Parasail (US-hosted) | Meal photos, spoken food logs, and the coach's background decisions | Runs the Qwen model |
| Open Food Facts | Barcode numbers | Food lookup |
| Expo | Your push token, and the text of a notification being delivered | Delivers notifications to Apple |
| PostHog | A fixed list of named app events, tied to your account ID | Product analytics |
| Sentry | Crash reports and error diagnostics | Fixing crashes |
| RevenueCat | Your subscription status and purchase events | Managing subscriptions |
| Apple | Sign in with Apple, subscription purchases | Sign-in and payment |
About analytics specifically, stated more precisely than most policies do. We use a fixed list of named events, written down in the app's own source and enforced by it — nothing outside that list can be sent. There is no automatic event capture, no session replay, and no screen recording.
Most of them are about the app: opening it, moving through onboarding, viewing the paywall, starting a purchase. Some of them are about what you did in a pillar — that you logged food, finished a workout, saved a journal entry, completed a Word session, asked the coach a question, or won the day. A few carry a value we wrote ourselves: the training goal you picked from our list, and the one-word state you tapped on a MIND check-in. These are tied to your account ID.
What an event never carries is anything you wrote. A journal line, a goal in your own words, a Crew message, a coach question, a verse note — none of them can be an analytics property. Where we want to know whether you wrote something, we send its length or a count, never its text. We do not log what you wrote, what you ate, or what you lifted — only that you did.
We never receive your payment details. Apple handles all payment. We see only whether a subscription is active.
You can revoke either in iOS Settings at any time. The app keeps working without them.
You can delete your account from inside the app, under the YOU tab. No email, no form, no waiting.
Deleting does two things in one action:
If the server deletion fails, nothing is wiped and nothing is claimed. You will be told it did not work.
Moderation records are the exception and are kept as described in section 9.
This cannot be undone. There is no backup and no recovery.
Depending on where you live, you may have the right to access, correct, delete, or export your personal information, and to not be discriminated against for exercising those rights.
California residents (CCPA/CPRA): you have the right to know what we collect, to delete it, to correct it, and to opt out of sale or sharing. We do not sell or share personal information as those terms are defined, so there is nothing to opt out of.
Washington, Nevada and Connecticut residents: your rights over health data — confirming it, accessing it, withdrawing consent, and having it deleted, plus an appeal if we say no — are described in full in the Consumer Health Data Privacy Policy.
Every other state with a comprehensive privacy law gives you some version of access, correction, deletion and portability. We honor those requests from anyone who asks, wherever you live, rather than checking your state first.
The fastest way to exercise any of these is the in-app delete described above. For anything else, email [email protected]. We respond within 30 days for general requests and within 45 days for health data requests, and we will tell you inside that window if we need longer. We never charge for this, and never treat you differently for asking.
Your account and Crew data sit behind row-level security policies in Supabase, so one user's data is not reachable by another. Traffic is encrypted in transit. Server-side keys are never shipped inside the app.
No system is perfectly secure, and we will not claim otherwise.
If a breach affects your information, we will tell you. We will notify affected users without unreasonable delay once we understand what happened, and we will notify state authorities wherever the law requires it. We will tell you what was taken, when, and what to do about it — even when that is an unflattering answer.
DYLD is available in the App Store regions listed on its store page. Availability changes over time.
Your account and Crew data are stored in the United States (Oregon). If you use DYLD from outside the US, your information is transferred to and processed in the US. Where that transfer is regulated — for example from the European Economic Area or the United Kingdom — we rely on the appropriate legal mechanisms, including the EU–US Data Privacy Framework and Standard Contractual Clauses with our service providers.
This applies to the data described in section 4. Everything covered in section 3 never leaves your device at all, and so is never transferred anywhere.
If we expand to new regions, this policy is updated before we do.
This policy is part of the Terms of Use, and the Terms of Use govern any dispute about it. They are one agreement. Everything below is stated in full in the Terms of Use — it is repeated here so that nobody has to go looking for it.
We describe our data practices as accurately as we can. DYLD and everything in it is provided "AS IS" and "AS AVAILABLE," without warranties of any kind, express or implied, including merchantability, fitness for a particular purpose, and non-infringement.
We do not warrant that any system is free from unauthorized access, that a third-party service we use will behave as documented, or that data stored on your device will survive a device failure, an OS update, or a deleted app. Section 12 says it plainly: no system is perfectly secure. Section 3 says the other half: we keep no backup of your on-device data and cannot recover it.
TO THE MAXIMUM EXTENT PERMITTED BY LAW, WE ARE NOT LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR FOR LOST DATA, LOST PROFITS, OR PERSONAL INJURY ARISING FROM OR RELATING TO THIS POLICY OR OUR HANDLING OF YOUR INFORMATION.
OUR TOTAL LIABILITY FOR ALL CLAIMS COMBINED IS LIMITED TO THE AMOUNT YOU PAID US IN THE 12 MONTHS BEFORE THE CLAIM, or $100, whichever is greater. This applies to every theory of liability — contract, warranty, negligence, strict liability, statute, or anything else.
Nothing here excludes liability the law does not allow us to exclude, including for fraud, willful misconduct, gross negligence, or violation of law. Some jurisdictions do not allow some of these limits, so parts of this section may not apply to you.
You agree to hold us harmless from claims arising out of your content, your use of DYLD, or your violation of the Terms of Use, this policy, or the law. Full text in Terms of Use section 12.
Any dispute about this policy or about our handling of your information is covered by Terms of Use section 13, which requires you and us to try to resolve it by email first, then to bring it in binding individual arbitration rather than in court.
None of the above waives a right the law says you cannot waive. Your rights under section 11, including access and deletion rights under the CCPA/CPRA and comparable state laws, and any statutory claim that cannot be sent to arbitration or waived, are unaffected by this section — and exercising any of them will never be held against you.
Either of us can end this relationship. You can delete your account from the YOU tab at any time, which wipes your server-side account and your on-device data. We may suspend or terminate an account under Terms of Use section 9. Section 9 of this policy covers what is retained afterward and for how long, and Terms of Use section 13 survives termination either way.
If we change this policy materially, we will update the date at the top and notify you in the app before the change takes effect. Continuing to use DYLD after that means you accept the change.
This section is a working reference for the App Store Connect privacy questionnaire, kept here so the answers and this policy cannot drift apart.
⚠ REVISED 2026-08-31. Four rows changed answer — Health & Fitness, Photos, Sensitive Info and Identifiers. If the App Store Connect questionnaire was already filled from the previous version of this table, it must be re-answered before submission. The cause is the system backup (section 4(b)) and the Crew profile picture (section 4(c)), both of which post-date the first version of this appendix.
| Apple category | Collected? | Linked to you? | Tracking? | Where |
|---|---|---|---|---|
| Contact Info — Email | Yes | Yes | No | Account creation. An account is required to use the app |
| Health & Fitness | Yes | Yes | No | Changed. Your body facts (sex, height, weight, activity), your plan and your day-by-day W–L record are stored in your account backup (§4b), and your W–L record is shown in Crew (§4c). Named analytics events also record that you logged food, finished a workout or saved a check-in, plus the one-word MIND state and the training goal you picked (§6). Your actual workout, food and journal entries stay on the device, and the copy sent with a coach question is not retained |
| User Content — Photos | Yes | Yes | No | Changed. Your profile picture is stored on our servers and shown to other members. A meal-scan photo is separate: sent for processing, never stored |
| User Content — Messages | Yes | Yes | No | Crew posts, reactions |
| User Content — Other | Yes | Yes | No | Report snapshots · the promise and food note you wrote in onboarding, stored in the account backup · coach context (journal entries + check-in lines), sent for processing and never stored |
| User Content — Audio Data | No | — | — | The spoken food log is recognised on the device. The recording never leaves the phone and we never receive it; only the resulting text is sent, and that text is User Content — Other above |
| Sensitive Info | Yes | Yes | No | Changed, and it is one narrow thing. Which pillars you switched off travels in the account backup, and one of the five is WORD, our scripture pillar — so the backup can reveal whether you use faith content. Nothing else in this app touches a sensitive category. See the note below the table |
| Identifiers — User ID | Yes | Yes | No | Account ID, analytics identity, RevenueCat, referral records |
| Identifiers — Device ID | Yes | Yes | No | New. A push token, stored only if you turn notifications on, and deleted when you turn them off or sign out |
| Purchases | Yes | Yes | No | Subscription status via RevenueCat, mirrored to your account |
| Usage Data — Product Interaction | Yes | Yes | No | Named PostHog events — the fixed catalog described in §6, never anything you wrote |
| Diagnostics — Crash Data | Yes | Yes | No | Sentry |
| Other Data — Date of Birth | Yes | Yes | No | New. Entered by you at sign-up; stored on the device and in the account backup. DYLD does not request an age category from Apple |
| Location | No | — | — | Not collected. The app never asks for the permission |
| Contacts | No | — | — | Not collected |
| Financial Info | No | — | — | Apple handles all payment; we never see a card |
| Browsing History | No | — | — | Not collected |
| Search History | No | — | — | Not collected |
On the Sensitive Info row, because it is a judgement and not a fact. Apple's sensitive category includes religious or philosophical beliefs. DYLD never asks your religion and stores no answer about it — but the backup carries which pillars you turned off, and WORD is scripture, so the row can be read as revealing whether you practise. Declaring it is the honest answer. The cheaper alternative, if that row is unwanted on the store page, is a code change rather than a wording change: drop the pillar list from the synced payload and let a restored account re-ask which pillars are on. That is RJ's call, and until it is made this row stands as Yes.
Tracking: DYLD does not track users across apps or websites owned by other companies. App Tracking Transparency does not apply.
Not legal advice. This document was drafted against the app's actual code and live database on 2026-08-06, re-verified on 2026-08-17, and re-verified again on 2026-08-31 against the live production database rather than the schema file — which is how sections 4(b), 4(c), 4(f), 4(g) and 4(h) came to exist: five tables and three profile columns were shipping and undisclosed. It should be reviewed by an attorney before or shortly after launch. See [[decisions/log]] for the rulings it reflects.