Privacy Policy

1. Who operates Relm

Relm is operated by Batu Ganioglu, an individual sole trader in Massachusetts, United States. In this policy, “Relm,” “we” and “us” mean that operator. Batu Ganioglu is responsible for the processing described here and is the controller where that term applies.

This policy covers the Relm iOS app, getrelm.app, beta and platform-interest signups, and communications with Relm. Contact Batu directly at support@getrelm.app for privacy questions or requests. Batu monitors this mailbox.

Our separately accessible Consumer Health Data Privacy Policy provides additional information about consumer health data and associated rights. Accepting the Terms of Use, reading a privacy notice or granting Apple Health permission does not, by itself, authorize every use described in these notices.

2. Information and purposes

Relm handles the following information according to the features you use.

Fitness records, nutrition, subjective ratings and derived scores can reveal health information. Feature-use events and identifiers can also reveal health-related activity even when they contain no measurement or entered text.

Core logging works locally. Optional online features and reporting have the separate data flows described below. Declining Health access prevents the corresponding Health readings; declining Cloud Backup leaves those local records without a Relm cloud backup. Optional usage reporting is not needed for core logging.

3. Accounts, purchases and communications

Guest and permanent accounts

When the app connects to its backend, it can automatically create a guest account without asking for an email address. Supabase assigns an account identifier and handles authentication and connection metadata. A guest account does not enable uploading your saved tracking records to Cloud Backup.

You can sign in or upgrade a guest account using an email sign-in link or Sign in with Apple. Where possible, an upgrade preserves the guest account identifier. Apple can supply a relay email address. Relm requests your email for Apple sign-in, not your Apple name, and does not ask you to create a Relm password.

Authentication uses account and provider identifiers, email addresses where supplied, sign-in/session metadata, access and refresh tokens, and Apple credentials where relevant. The app stores authentication credentials using system credential storage. Apple authorization codes can be exchanged on the backend, and an Apple refresh token can be retained for revocation during account deletion. Supabase currently uses Resend to deliver sign-in email.

Purchases

Apple processes payments and subscriptions. Relm uses StoreKit transaction and entitlement information to unlock Premium features; it does not receive your payment-card number. App analytics can record whether paid access was obtained through a purchase or restoration, as explained in section 6.

Manage or cancel subscriptions through your Apple Account subscription settings, including the link in Relm when shown. Deleting your Relm account or removing the app does not cancel an Apple subscription.

Signups and support

Beta and platform-interest forms collect your email address, signup source/platform and signup or invitation times. These records are stored in Supabase separately from app accounts. The iOS beta signup path sends invitations through Resend; the Android-interest path stores the request without sending that iOS invitation. Form processing uses connection information for abuse limits, including an IP-derived identifier where the request supplies the relevant IP header. Hashing that information does not necessarily make it anonymous.

Support and privacy messages include your email address, the contents and attachments you send, and related message metadata. Cloudflare email routing and the receiving mailbox service handle these communications. Please avoid sending health information that is unnecessary for your request.

4. Apple Health, storage and exports

Apple Health access

With the relevant permissions, Relm requests read access to bodyweight, steps, workouts, sleep analysis, resting heart rate, heart-rate variability (SDNN), and heart rate. You can manually import bodyweight readings into saved weight history. Steps support the steps display. Sleep and heart readings support recovery calculations, including recent baselines and relevant sleep windows. Workout reads check for duplicate exports; Relm does not import your entire Apple workout history.

After Health is connected, reads can refresh when the app opens, returns to the foreground or observes a relevant Health change while running. Some recovery queries cover a recent 30-day period. Relm does not use background Health delivery. Completing Apple's permission sheet does not tell Relm that every requested read category was allowed.

Health exports are manual. With your chosen export and write permissions, Relm can write bodyweight and workouts, including associated walking/running, cycling, swimming and rowing distance samples. Health access and export are available without Premium.

Raw step, sleep and heart-reading caches stay in memory. Imported weight and saved daily sleep, resting-heart-rate and HRV sub-scores are persistent records. The saved sub-scores are calculated values, not the raw readings, and include capture-date/time-zone information. They can enter local exports and optional Relm Cloud Backup. The displayed overall recovery score can also use your current subjective recovery information.

Change category permissions in Apple Health or iOS settings. Withdrawing a permission stops future access to that category; it does not automatically erase prior imports or saved scores. Deleting Relm records or an account does not remove information already written to Apple Health. Manage that information separately in Apple Health.

Local storage and optional Cloud Backup

Saved tracking records start on your device. Cloud Backup is off by default and requires a permanent account. Signing in alone does not turn it on. If you previously enabled backup for the same account, signing back into that account can resume it. Signing in can also check for an existing cloud copy and offer a restore while automatic backup remains off.

When enabled, Cloud Backup uploads saved workouts, routines, programs, exercise-library information, nutrition, personal records, weight history and goals, manual recovery, daily recovery sub-scores, coaching history and profile inputs to Supabase. Account and installation identifiers, data-category/version information, timestamps and change metadata help manage those copies. New snapshots replace the corresponding active category snapshots; this is not a history of every prior edit.

Turning Cloud Backup off or signing out prevents new backup uploads from that device. An upload request already sent may still finish. Existing cloud records remain. Another device with backup enabled can continue uploading. Successful account deletion removes the associated active cloud backup; other records and copies have the separate retention and deletion limits described in section 8.

iCloud and computer device backups

Relm excludes its designated bodyweight, weight-goal, manual-recovery, daily-recovery, profile-input and Health export-ledger files from iOS device backups. Other records remain eligible for iCloud or computer backup according to device settings, including workouts, nutrition, personal records, coaching history and active-workout files. Workout files can themselves contain a subjective recovery rating and, in older records, a retained bodyweight value. Preferences such as the daily step goal and saved streak information are also outside those excluded files.

Device backups are separate from Relm's Cloud Backup switch.

Exports and other copies

You can export supported saved local records as JSON or completed workouts as CSV and choose recipients through system sharing. Workout CSV exports also include recovery ratings and associated bodyweight where available. The local JSON export does not automatically include account metadata, social/moderation records, vendor telemetry, email, raw Health caches, preferences or the active workout. A local export therefore has a different scope from a broader privacy-access request.

Other people and services control copies they receive, including exported files, screenshots and saved workout images. Relm cannot erase every recipient-held copy through an in-app deletion action.

5. Social features and external content

Profiles, sharing and reports

Supabase stores social profiles, handles, display names, biographies, profile images, posts, captions, comments, replies, likes, follows, blocks and reports. Shared workout summaries can include exercise names, loads, repetitions, personal records, distances and durations. Other users can supply information about you in their content or reports.

New social profiles are public. With a private profile, your workout posts and follower/following lists are limited to you and approved followers. Private profiles remain searchable, and the setting does not hide your comments or interactions on other people's visible posts. Profile photos use public URLs even for private profiles: anyone with the direct URL may be able to view the image. Uploaded avatars are resized and re-encoded. People who see content can save it elsewhere.

Reports can preserve snapshots of a reported profile, post or comment after the original content or target account is deleted. A profile snapshot can retain text and an avatar reference; it is not a stored copy of the image itself. Reports filed by an account are deleted with that reporter's account; reports about a deleted target can survive.

Moderation emails sent through Resend contain report/target identifiers, timestamps and fixed reason categories, where present: spam, harassment, inappropriate or other. They do not include arbitrary free-text reasons, the stored snapshots or original reported content. Stored snapshots can contain health information; emailed identifiers can refer to health-related content.

Food searches, barcodes and videos

Food searches and lookups send search words or food/product identifiers to USDA FoodData Central or Open Food Facts, as appropriate. Barcode lookup sends the decoded barcode. These services also receive ordinary connection metadata, such as IP address and request information, even though Relm does not attach your account ID. You can enter food information manually instead.

Camera frames are processed on your device to recognize barcodes; the scanner does not record the frames. Profile-photo selection and saving workout images use separate system photo controls.

Tapping an exercise video loads a Google/YouTube player using the privacy-enhanced embed domain. Google and its delivery services receive the video request and associated connection/playback information. The player can use webview storage. Privacy-enhanced mode limits certain personalization; it does not mean no information is collected.

Third parties may collect information about your activity over time and across services during your use of Relm. Google's policy describes collecting identifiers and activity through Google services on other apps and sites, and use across its services depending on the service and your settings. This describes Google's published practices, not a claim that every video view is linked to your other activity. Google Privacy Policy.

YouTube states that views through its privacy-enhanced embedding mode do not personalize your YouTube browsing experience or advertising, and that ads shown through that mode are non-personalized. Those limits do not prevent all collection. YouTube privacy-enhanced mode.

Local notifications and Live Activities can display workout or rest-timer information on your device and lock screen according to your settings. These features do not use remote push-notification tokens.

6. Analytics and diagnostics

App usage reporting

Share Usage Data is on by default. It controls PostHog usage analytics and Sentry crash/error reporting. Collection can begin before you visit Settings → Analytics → Share Usage Data.

PostHog receives these twelve app events:

onboarding_started, onboarding_step_reached, onboarding_completed, app_session, workout_started, workout_discarded, workout_completed, meal_logged, surface_reached, paywall_viewed, paywall_dismissed, and paywall_completed.

The nine app-defined event properties are app_version, is_beta, build_channel, days_since_install, paywall_feature, purchase_outcome, discard_stage, surface, and onboarding_step. Identifiers, event timestamps and delivery/control fields accompany the events. Surface categories include Health, Add Food, Weight, Recovery, Steps and History. Repeated reaches of the same surface are limited within an app-session window; a new app process can start another window.

These event properties do not contain measurements, exercise or food names, workout/meal contents or text you enter. They can nevertheless reveal fitness or health-related activity. Events use a persistent pseudonymous analytics identifier, not an anonymous identifier. Relm does not attach your Relm account ID, use PostHog account identification or enable person profiles, session replay or automatic screen/tap capture. Event delivery requests that PostHog not perform IP-to-location enrichment; that does not prevent the receiving service from seeing a connection's IP address.

Switching reporting off stops new app-event capture, but previously queued events can still be transmitted, including after the app relaunches. It changes the main analytics identifier without deleting events already received by PostHog. Re-enabling reporting permits new capture.

The switch-off sequence also triggers a separate PostHog configuration request. That request can contain the new analytics identifier, a continuing SDK device identifier and time zone. It is outside the twelve-event filter. Consequently, changing the main identifier does not remove every identifier or prevent links with earlier activity.

Crash and handled-error reports

Sentry receives native crash reports and selected handled-error reports. Reports can include stacks, threads, loaded-software metadata, app/device/operating-system information, event and correlation identifiers, and a pseudonymous device/app identifier. Some diagnostic context also includes locale and time zone. Native exception reports can contain the exception's reason and associated information supplied with the exception. Selected handled errors are reduced to an error type/domain/code and fixed operation and data-store labels, with diagnostic context. A label or stack can reveal the health feature involved without containing the underlying measurement.

Relm clears the report's user field and activity breadcrumbs and disables performance tracing, replay, screenshots, automatic session reporting and network tracking. Event correlation identifiers can still be present. Removing the user field does not remove the device/app identifier or all identifying context. Native and startup crashes have a different payload path from reduced handled errors; their context can contain identifying or health-related information. A saved crash report can be sent very early on the next launch when reporting is enabled. The SDK requests that Sentry not infer an IP address for the event, but the receiving infrastructure still sees connection information.

Switching Share Usage Data off initiates cancellation of pending Sentry transmission, removal of cached reports and closure of reporting. If cached-report removal fails, the app blocks restarting Sentry until that cleanup succeeds. These actions do not delete reports Sentry has already received. The device/app identifier is not an account identifier, and clearing the report cache does not ensure that future reports use a different one.

Website processing

The website sends page-view and completed-signup events to PostHog using a cookieless client configuration. The analytics filtering removes query strings and fragments from the page/referrer URL fields but retains page and referrer paths. It does not mean that URLs containing sensitive information in a path become harmless. Events also carry signup source/platform where relevant, browser, operating-system, device-type, screen, time-zone and user-agent information, with delivery identifiers and times. Connection information is processed by the receiving services. The analytics software accesses browser storage during initialization, including temporary checks. “Cookieless” does not mean anonymous or that no device information is accessed.

The current public website does not forward a separate event stream to Relm's Supabase website-event database. Form submissions and hosting/security records are separate from website analytics. Cloudflare hosts and delivers the website and processes associated request metadata.

The website currently has no dedicated analytics consent or objection control and does not implement a response to Do Not Track or Global Privacy Control. Those signals have different purposes and legal effects. The app's Share Usage Data switch does not control website processing or a third party's own settings.

7. Recipients and processing locations

Services can use infrastructure providers and subprocessors. Apple, food services, Google/YouTube and recipients you choose have their own privacy practices and are not all processors acting only on Relm's instructions. The app's PostHog requests and the website's PostHog configuration use its US service. A primary server region does not describe every support, email, onward-processing or backup location. The supplemental GitHub (Microsoft) backup workflow was disabled on 8 September 2026. Previously created GitHub artifacts keep their original expiration of up to 48 hours after creation; this does not expire copies downloaded or restored elsewhere.

Relm does not include an advertising or attribution SDK or a data-broker integration. That fact does not determine whether a particular disclosure meets a law's definition of “sale” or “sharing,” which can extend beyond a payment for data.

8. Retention and deletion

Different copies have different lifetimes and controls.

Account deletion and surviving information

Use account deletion in Settings to request deletion of the active account and associated backend records. The process attempts Apple-token revocation for Apple-linked accounts, removes the profile image and deletes the account data. A failed attempt can already have revoked Apple access or removed the image before a later step fails. Missing stored Apple tokens can instead require manual Apple revocation instructions.

The app clears the local stores covered by the account-deletion flow after server deletion succeeds. If server deletion fails, those local stores are not wiped. If local file cleanup fails after server success, some files can remain and backup is blocked until cleanup is resolved. A new guest account can be created after successful cleanup for continued operation.

Some preferences, onboarding/install state and installation identifiers survive local cleanup. Deletion does not automatically remove separate signup/email records, reports about you, prior vendor telemetry, provider logs, exports, Apple Health records or every device/recipient-held copy. It does not cancel subscriptions. Removing the app alone is not a request to delete all these separate records.

9. Choices, requests, appeals and complaints

You can edit or delete supported local records, export supported data, change social visibility, turn Cloud Backup or Share Usage Data off, and change Apple Health/device permissions. These controls have the effects and limitations described above.

For requests beyond those controls, email support@getrelm.app. Describe the right you want to exercise and the account or feature concerned. For signup removal, identify the email used. A suggested subject is “Privacy Request”; clear wording is sufficient. You do not need to create a Relm account or send unnecessary health records or identity documents to ask.

Depending on the law and processing involved, rights can include access, correction, deletion, portability, information about recipients, consent withdrawal, restriction or objection, sale/sharing or targeted-advertising opt-outs, limits on sensitive-information uses, authorized-agent requests and appeals. Rights can have specific legal exceptions. Exercising protected rights must not result in unlawful discrimination.

Pseudonymous analytics records are not necessarily impossible to locate. Requests concerning them need an appropriate way to match available identifiers or other limited information without creating unnecessary new tracking. A local JSON export is only part of a broader access request.

Where the respective consumer-health laws apply, Washington residents and other protected consumers can request confirmation/access, the required actual third-party/affiliate list and contacts, consent withdrawal and deletion. Nevada additionally provides cessation rights covering collection, sharing or sale. Their deadlines differ: Washington generally requires a response within 45 days of receipt; Nevada generally uses 45 days after authentication and a separate 30-day active-deletion deadline. Both have appeal rights. The Consumer Health Data Privacy Policy must be read with these rights and their statutory conditions.

You may complain to the relevant regulator, including the Washington Attorney General, Nevada Attorney General, California Privacy Protection Agency, your EEA supervisory authority, the UK ICO or the Swiss FDPIC. Contacting Relm does not waive those rights.

10. Regional and international information

Relm is operated from the United States and intended for worldwide distribution. Information can be processed outside your country. Supabase's primary project is in Oregon; that location alone does not establish the location of all processing or a lawful international-transfer arrangement.

EEA, United Kingdom and Switzerland

Where EEA/UK data-protection law applies, each purpose requires an appropriate lawful basis; health processing also requires a separate health/special-category condition. Necessary contract performance or legitimate interests alone does not supply that additional condition.

Rights can include access, correction, erasure, restriction, objection and qualifying portability. When processing relies on consent, you can withdraw it without affecting the lawfulness of earlier processing based on valid consent. EEA/UK rights requests generally require a response within one month, with permitted extensions and timely explanation. UK personal-data complaints have a separate duty to acknowledge within 30 days and investigate, provide progress information and communicate the outcome without undue delay.

Relm's training and recovery inferences personalize fitness information. They do not make decisions about credit, insurance, employment or similar eligibility with legal or similarly significant effects. Personalized analysis can still be profiling under data-protection law.

United States and other markets

California categories relevant to Relm include identifiers, customer records, age/sex characteristics, commercial information, internet/app activity, visual content, health information and inferences. The sources, purposes and current recipients appear above.

Consumer-health, sensitive-data and children's protections can apply independently of ordinary business-size thresholds. Connecticut's sensitive-data coverage is one example. Other applicable requirements can include stricter necessity limits, parental permission, additional contact information and notice when information comes from another person or source.

11. Children, security and changes

Relm is intended for people aged 13 and older. The profile age field supports fitness calculations; it is not an eligibility check or parental-consent process. Contact support@getrelm.app if you believe information has been provided by a child without required permission.

Security

Relm uses encrypted network connections, database access rules, scoped credentials, submission limits, reporting filters and iOS file protection. No safeguard guarantees complete security.

Changes and contact

The date above identifies this version of the policy. A revised notice does not itself supply consent for new health-data categories, purposes or recipients.

Privacy contact: Batu Ganioglu, Relm — support@getrelm.app.