Support

The local catalogue can show approved free cards. A “free” or demo entry is not a pricing promise for a future release.

1. Open an available card in the configured local build.
2. Check the label on the specific offer.

Limit: The final free offering, store prices and long-term availability are not approved yet.

A pack offer is intended for a particular card collection. Real purchases stay locked: the store flow is connected, but the server has not released checkout, so nothing is charged. A demo or a labelled test purchase in a development build does not pay for anything.

1. Check which pack and scope the offer names.
2. Leave a demo dialog if you expected a real purchase.

Limit: This does not promise a final price, purchased scope or lifetime access.

A subscription would be a recurring store offer. The current build has no accepted end-to-end real checkout. A future subscription is managed with the original billing provider.

1. Apple: Settings → your name → Subscriptions.
2. Google Play: profile → Payments & subscriptions → Subscriptions.
3. Check the account, offer, billing period and status confirmed there.

Limit: Deleting the app or yesumi account does not cancel a store subscription. Refunds and cancellations are different; use the provider’s confirmation.

“Käufe wiederherstellen” (Restore purchases) requires sign-in, looks for purchases on the current store account and sends only purchases bound to your yesumi account to the server for verification. Access appears only after the server confirms it.

1. First check the original Apple or Google Play account.
2. Read the message after “Käufe wiederherstellen”.
3. If the outcome is unclear, do not buy again to fix it.

Limit: Native restore and verification were tested locally only against a synthetic fixture verifier. That does not prove restore with real App Store or Google Play purchases.

Saved cards and store purchases are separate. Card sync was tested locally between an Android emulator and iOS simulator with the same test account. This does not prove purchase transfer between Apple and Google.

1. Keep cards on the old device until you can see them on the new one.
2. Use the same yesumi sign-in account and enable the separate card-sync option.
3. Manage any existing subscription with its original store.

Limit: Real Google sign-in remains unaccepted. Signing in does not automatically transfer guest cards, downloaded files or store billing.

You can stay a guest on this device. Connecting an account does not automatically enable card sync. Guest cards import only when you choose to do so. Independently of that, a signed-in account stores time zone, hidden cards, topics, feedback and the daily selection with the account (Profile → “Personalisierung” (Personalization)).

1. Profile → “Konto und Synchronisierung” (Account and sync) → “Mit Google verbinden” (Connect with Google).
2. Explicitly enable “Gespeicherte Karten mit diesem Konto synchronisieren” (Sync saved cards).
3. Choose “Übernehmen” (Import) or “Nur hier lassen” (Keep here) for offered guest cards.
4. Check “Abgeglichen” (Synced) or any changes still waiting.

Limit: Locally tested with test accounts. Real Google sign-in still needs acceptance; theme, language and purchases are outside this evidenced favorites sync. Feedback and hidden cards have no revision: between two devices the change that reaches the server last wins, including an older offline change sent later.

Signing out also works offline. The app warns about losing pending changes. After confirmation, turning off sync removes the synced favorites copy from the account; cards visible here remain in this device’s guest area.

1. Read the warning about changes that have not uploaded.
2. When signing out, choose “Erst übertragen” (Sync first) if needed.
3. Read the sync-off confirmation: the account copy also disappears for other devices.

Limit: Signing out does not delete the account or cancel a subscription. The separate push identity remains. The account’s local collection data is removed with its folder; daily-card caches and guest collection data use separate areas; complete physical file erasure is not evidenced. The warning also counts personalization changes not yet uploaded; the account’s personalization queue is removed with its folder. Cards hidden on this device only remain hidden.

When you are signed in with an account, you can export your account data in the app as a JSON file. You confirm the export by signing in again and choose where the file is saved. The app keeps no copy of the file.

1. Open Profile › Account and tap “Export my data”.
2. Read what is included; “How to read the file” explains every field.
3. Tap “Confirm with sign-in and save”, sign in again and pick a location in the system dialog.
4. The file is there only once “Saved” appears. Anything not in the file is available through support@reloop.cards; you get an answer within one month.

Limit: The export covers this application account only: no guest files, separate technical push identity, Firebase/Google/Apple sign-in data, usage and crash data or complete store history. It contains profile, consents, saved cards, feedback including hidden cards, daily cards, reminders, devices and inbox, purchases in yesumi and offline packs; cards hidden on this device only are not included. So far evidenced locally with test accounts only.

Without the installed app: open the yesumi “Delete account” page, explicitly sign in with the same Google account, request deletion, then confirm its consequences and fresh Google sign-in. Sign-in alone creates no application account and deletes nothing. Alternatively in the app: Profile → “Konto und Synchronisierung” (Account and sync) → “Konto löschen …” (Delete account). Confirm with fresh sign-in and wait for server confirmation. The server removes the yesumi application account and its synced data. The browser does not erase files on app devices. The account’s favorites and local collection data (content snapshot, thumbnails, saved times) are removed on a device only when its app recognizes the confirmed server deletion. On the server this includes topics, feedback, hidden cards and the daily-selection history.

1. First check for pending changes or a needed export.
2. Complete fresh sign-in and the deletion confirmation.
3. An error or unknown result does not confirm deletion.
4. The browser one-use confirmation expires after ten minutes. If the outcome is unknown, select “Check outcome”; reloading never repeats deletion. The operation receipt can be read with the same account for up to30days.
5. Optional guidance is currently a local test file only, never sent email or deletion authority.

Limit: This does not delete the Google account itself, the separate push identity, guest cards or provider-held data. After application-account erasure, yesumi attempts to remove the Firebase sign-in record; staff accounts remain excluded. The plaintext UID can wait in a retry table. A running worker removes the retry row after successful Firebase deletion or when no further retry is needed. If an actual attempt fails when the retry row is at least 14 days old, only retrying is abandoned; this does not confirm Firebase deletion. Without provider configuration, or with missing or unusable Firebase credentials or permission in the worker, the UID can wait indefinitely; this is treated as a configuration problem, never given up and logged loudly. Processing depends on a running worker and scheduled attempts; 14 days is not a guaranteed maximum retention period. Daily-card caches and guest collection data are separate; the account's open store purchase references are removed from the device on deletion; full physical file erasure is open, and existing local backups stay unchanged until their retention expires (30 days by default). Pseudonymous recreation/receipt-abuse fences remain; event hashes become eligible for applied maintenance after 180 days from receipt, excluding active jobs. There is no automatic maximum. Recreating with the same UID is blocked; signing in again after the Firebase record was deleted creates a new UID and therefore a new account. Store subscriptions are not cancelled. Cards hidden on this device only remain until “Personalisierung zurücksetzen” (Reset personalization). Resetting personalization is not account deletion; language, time zone, reminders and the daily-selection history without reasons stay. The browser path currently supports Google, not Apple sign-in. Public hosting/store URL, real Google acceptance and mail delivery remain open. WEB operation records are physically removed only by bounded maintenance (expired requests after24h, receipts after30days); these eligibility limits are not a guaranteed scheduler deadline. Optional local guidance contains your verified address; files become eligible for bounded cleanup after24hours, with no guaranteed deletion scheduler.

A previously loaded daily card can remain visible after restart, including its text and a valid cached image. Older cards show their own date. A fresh installation without a loaded card needs a connection first.

1. Load the card while the local service is reachable.
2. Read its date and offline notice.
3. Check for changes or withdrawals when you reconnect.

Limit: This is not a complete offline pack download. New content, sync, restore and remote services need a connection. A confirmed withdrawal removes the affected cache; an unknown withdrawal cannot be detected offline.

Local card-ritual sounds are optional. Sound is off by default; haptics are on by default. The app offers short feedback while holding, opening and saving; the separate switches take effect immediately. OS notification sounds are separate.

1. Profile → “Klang und Haptik” (Sound and haptics): set “Klänge beim Kartenritual” (Card ritual sounds) and “Haptik” (Haptics) separately.
2. Continue to use OS settings for notification sounds.

Limit: Sounds respect silent mode and are intended not to interrupt music; devices without suitable haptics keep visible feedback. This source refresh establishes the controls in code, not new physical listening or haptic acceptance. Earlier device evidence retains its original revision.

Notifications need both an enabled category and OS permission. Categories start off. An enabled switch or acceptance by the push service does not prove display on your device.

1. Check the daily-card status line in Profile, e.g. “Gewählt – bitte erlaube Mitteilungen in den Einstellungen.” or “Aktiv · nächste Erinnerung …”.
2. Check yesumi’s OS permission (and on Android the “Tägliche Karte” channel) and the connection.
3. Check chosen weekdays and any pause (“Pausiert bis einschließlich …”).
4. If changes are pending, wait for the displayed sync result.

Limit: One real Android test and local APP-04 emulator/simulator checks are documented; real iOS APNs delivery and physical devices remain open. Quiet hours, chosen weekdays, a pause and the OS can limit display. Already submitted messages cannot reliably be recalled.

Usage statistics and crash reports start separately disabled. After analytics opt-in, the app uses a fixed list of interaction names without attaching card or free-form text itself. Revoking consent disables collection and resets local analytics data. Topics, feedback and hidden cards are not analytics events; they are only used to choose your daily card.

1. In Profile, set “Nutzungsstatistik” (Usage statistics) separately.
2. Check “Absturzberichte” (Crash reports) separately.

Limit: This does not automatically delete data already held by Google. Technical services such as Remote Config/Installations may communicate independently. A complete SDK network audit before and after consent remains open.

If crash consent was already saved, pending reports from the previous session are explicitly sent at the next launch. Without consent or when the switch changes, unsent reports are deleted. API logs may separately contain technical connection data.

1. Choose “Absturzberichte” (Crash reports) in Profile deliberately.
2. For a problem, initially share only platform, app version, time and the visible error message.

Limit: Revocation cannot recall started transmissions or erase provider reports already stored. API logging may include IP/route; retention and the full release data set still need review.

The current native app offers no voice recording. Editorial image/PDF sources can be processed locally with OCR in Studio and, when deliberately configured, sent to OpenAI for analysis or generation. That is a separate editorial workflow.

1. Do not send private notes or recordings as error evidence.
2. Before editorial provider jobs, check source rights and settings.

Limit: Missing microphone permissions do not prove every SDK’s behavior. This is no zero-retention promise, and this task made no paid provider request.

Note the platform, app version, time and visible error message. Briefly describe what you tried to do. This local help does not upload diagnostics or personal content.

1. Leave out passwords, tokens, full purchase receipts and private card text.
2. Review screenshots before choosing to share them later.

Limit: Support contact, legal operator details and public URLs are not confirmed. These materials are a technical/editorial draft, not legally approved.