Effective date: 24 September 2026
1. Who is responsible?
Weida is provided by:
Moritz Stößlein
Sudetendeutsche Straße 11
90480 Nürnberg
Germany
Privacy contact: info@weida-coach.com
In this policy, “we”, “us” and “our” refer to this provider. We are the controller for the personal-data processing for which we determine the purposes and means in connection with Weida.
This policy covers the Weida app, its promotional website, the connection authorization service described in section 5, and support communications with us. External services you connect have their own privacy notices for their services.
2. Our local-first approach
Weida is a training-planning app for running, cycling, swimming and strength training. Your training database and coaching calculations are primarily stored and processed on your device. You do not need to create a Weida account, and we do not operate a central server that receives your training database. We do operate one small service of our own, described in section 5: it handles the sign-in step for Strava and intervals.icu, routes course requests for you when you create a course without an openrouteservice key of your own, and, if you enable activity notifications, asks Apple to wake the app on your device. The app asks it which of these it currently offers. It never receives your training database.
Local-first does not mean that no data ever leaves your device. Connected services, weather and map requests, course generation, backups to a storage location you select, credential synchronization where enabled, purchases and information you send to support involve the transfers described below.
We do not sell your personal data, use advertising trackers, or use your health data for advertising. We do not send your coaching conversations to a hosted AI service or use your personal training data to train shared AI models.
3. Information the app processes
The information processed depends on what you enter, import, connect and authorize.
Profile and planning information: Your chosen name, optional date of birth, optional body weight, selected sports, experience, fitness thresholds and training zones, equipment, preferences, weekly availability, goals, races, planned sessions and changes to your plan.
Activity and health information: Workout dates, duration, distance, pace, speed, power, cadence, elevation, energy expenditure, heart rate, GPS tracks and other available activity measurements. Depending on your connections and permissions, this also includes sleep, resting heart rate, heart-rate variability, body weight, recovery information, perceived effort and feedback. A body weight you enter in your profile is used only to estimate climbing in cycling race predictions; a measured weight is copied into your profile only when you choose to use it. Information you enter about illness, injury, fatigue or other limitations may also reveal your health status.
Location and travel information: Saved training locations, a location requested from your device, course starting points, imported routes, and travel destinations and dates you enter. Routes and saved coordinates may reveal sensitive places, such as your home.
Coaching information: Messages you enter, generated replies, activity reviews, training-load and recovery estimates, and records of applied plan changes.
Connection and purchase information: Connected-service account identifiers, access and refresh tokens, API keys, and purchase-entitlement information provided by Apple.
Privacy and backup settings: Your recorded consent choices, the version and language of the notice shown, the time of your choice, your selected backup location and its access reference, backup status, and the technical information needed to encrypt and restore your backup. Your backup password is used on the device and is not sent to us.
Data comes from you, authorized connected services, Apple Health, a connected sensor, or files you select. Weida also derives training estimates and recommendations from these inputs. These locally processed categories are not automatically made available to us as the developer.
4. Purposes, legal bases and your consent
We process ordinary profile, availability and app-setting information to provide the functions you request, on the basis of Article 6(1)(b) GDPR where necessary to perform our contract with you.
We process health information for personalised training, recovery analysis and associated coaching only with your explicit consent under Articles 6(1)(a) and 9(2)(a) GDPR. This covers health information you enter, import or supply through a supported sensor, not only information read from Apple Health. The onboarding includes a separate consent page before health-related account connections, imports or restoration. You can decline; functions that need health information will then remain unavailable until you agree.
Optional health-data backups require a separate affirmative choice. We rely on your consent under Article 6(1)(a) and, for the health information involved, Article 9(2)(a) GDPR to create and save these encrypted copies at your selected supported destination. Enabling coaching does not enable backups or every external connection. Privacy → Optional connections and transfers lists separate controls for imports, Apple weather, maps/geocoding, openrouteservice, planned-workout delivery to intervals.icu, completed strength uploads, Watch and Calendar. Connection setup and system permissions are separate requirements.
Each destination for completed strength recordings also requires a separate affirmative choice, on the consent bases in Articles 6(1)(a) and 9(2)(a) GDPR. You can turn each destination off independently.
We keep a limited local record of your choice, purpose, notice version, language and time to honour and document your preferences and meet our accountability obligations under Article 6(1)(c) GDPR in conjunction with the applicable GDPR obligations. We do not create a central consent-tracking account for you. Withdrawal and reset retain a minimal local refusal record until the next consent choice or app deletion; a new installation or restoration cannot treat an old backup as a new consent.
We process support correspondence to handle your request: under Article 6(1)(b) GDPR where it concerns our contract, or Article 6(1)(f) GDPR for our legitimate interest in answering other enquiries. Necessary legal recordkeeping is based on Article 6(1)(c) GDPR. Any additional basis or exception required for health information sent to support must be assessed separately; please avoid including health records in ordinary support messages.
Consent may be withdrawn at any time through Settings → Privacy. Withdrawal does not affect the lawfulness of processing before withdrawal. System permissions, connecting an account and acknowledging this privacy notice are distinct from the consent choices described here. Installing the app, continuing to use it, or accepting this policy does not by itself constitute explicit consent to health-data processing.
5. Permissions and connected services
Apple Health and heart-rate sensors
With your permission, Weida reads selected Apple Health categories to import activities, assess training and recovery, and adapt your plan. These categories include workouts, heart rate, resting heart rate, heart-rate variability, body mass, sleep analysis, walking/running/cycling/swimming distance, active energy, running and cycling power, and workout routes.
A supported Bluetooth heart-rate sensor can supply heart-rate measurements during a strength session you record. Bluetooth access is used for that connection.
If you separately enable completed-strength uploads to Apple Health, Weida requests permission to write workouts and heart rate. Future strength sessions recorded in Weida are saved as strength workouts with their date, elapsed duration and recorded heart-rate samples where write permission is granted. Weida does not estimate calories or locations for this transfer. Apple Health's own synchronization and sharing settings govern further use. Import permission alone does not enable these writes.
You control Health access in Apple Health or the relevant iOS settings. Disconnecting Health inside Weida stops the app's connection but does not itself revoke Apple's system permission or delete previously imported copies.
Strava
When you connect Strava, Weida uses Strava's authorization process and stores the resulting tokens on your device. The sign-in step, later token renewal and disconnection run through our connection authorization service, described below. Activity imports do not: they go directly between your device and Strava. It imports the activity information, routes and measurement streams permitted by your authorization. Your Strava password is handled through Strava's sign-in process, not stored by Weida. If our connection authorization service does not offer Strava, you can instead enter the client ID and secret of your own Strava API application in Weida. They are stored in the Keychain on your device and used only between your device and Strava, for sign-in and token renewal; none of these steps then involve our service. Disconnecting in Weida ends such a connection on your device only, so remove the application's access in Strava's settings as well.
If you separately enable completed-strength uploads to Strava, Weida requests activity-write permission through Strava's authorization screen. Future strength sessions recorded in Weida are uploaded directly from your device to the selected Strava account. They include the workout name, start time, elapsed and active duration, recorded heart rate, and a description of completed exercises, sets, repetitions or timed work and perceived effort. Your Strava privacy and onward-sharing settings apply to the resulting activities. Previously connected read-only accounts require an additional authorization before uploading.
intervals.icu
When you connect intervals.icu using your athlete identifier and API key, Weida can import activities, routes, measurement streams and wellness information. You can instead connect through intervals.icu's own authorization process, which runs through our connection authorization service described below; the API-key connection remains available and works as it did. When you enable workout delivery, it sends planned workout information to your intervals.icu account. Further delivery from that account to services or devices you have connected there is governed by those connections.
If you separately enable completed-strength uploads to intervals.icu, the same recording information described for Strava is sent directly to your intervals.icu account. An OAuth connection needs activity-write permission; an API-key connection uses your existing key. This choice is separate from importing activities and delivering planned workouts.
Each strength-upload destination is off until you enable it in Apps & devices → Strength uploads or Privacy. Enabling it applies to future sessions, not your existing history. Upload status and identifiers are retained locally so successful uploads are not repeated. A pending upload keeps a protected, stable recording file on your device until confirmed, or until the local activity or app data is deleted. This upload journal is excluded from profile backups and requested to be excluded from system backups. Disabling a destination stops further attempts; it does not remove copies already sent. You can delete those copies in the receiving service. If connected services forward activities to one another, selecting more than one upload destination may produce additional copies through those connections.
Weida connection authorization service
Connecting Strava or intervals.icu requires an application credential issued to Weida. Such a credential cannot be distributed inside an app that anyone can download, so the sign-in step runs on a small service we operate on our ALL-INKL.COM hosting in Germany. It handles authorization, the exchange that turns your approval into an access token, token renewal and disconnection. Optional activity webhooks and course-routing requests are described separately below. Before offering one of its functions, the app asks the service which of them it currently provides. That request carries nothing beyond what every web request carries, such as your IP address, and nothing about it is kept except short-lived counters that limit repeated requests.
The service does not store your training database, activities, routes, measurements, plans or coach conversations. Imports and strength uploads travel directly between your device and the provider. Intervals.icu webhook requests can contain activity information transiently in request memory, as explained below. It does not store your access or refresh tokens either; they are passed to your device and kept in its Keychain.
While a sign-in is in progress the service keeps a short-lived record of it, including the provider's one-time authorization code in encrypted form. That record lasts at most ten minutes, and the code is deleted as soon as it has been exchanged, within sixty seconds of the provider issuing it.
After a successful connection the service keeps a connection record: the provider, the permissions you granted, the times it was created and last used, and non-reversible fingerprints of your provider account identifier and of the current token. The fingerprints let it confirm that a renewal or disconnection request belongs to that connection; they cannot be turned back into an identifier or a token. The record is kept until the connection is disconnected and deleted thirty days after that.
Requests to the service carry the network information any web request carries, including your IP address. Its own log records the time, the kind of event and an error reference, never a credential, and is deleted after thirty days. Our hosting provider keeps separate web-server and backup records under its own arrangements.
When you disconnect, the service asks the provider to revoke the authorization, ends the connection on our side whether or not the provider could be reached, and reports which of the two happened.
To keep course routing through the service — and, where we require it, the sign-in step — for the genuine Weida app, the app proves itself with Apple's App Attest. Once per installation, your device creates a key in its Secure Enclave and asks Apple to confirm that the key belongs to an unmodified copy of Weida on genuine Apple hardware; Apple thereby learns that Weida did this on your device. The service then keeps the public part of that key, the app identifier, whether the key came from a test build or an App Store build, a counter and when the key was last used. Each request that needs this proof carries a one-time signature made with the key, and during a sign-in the short-lived sign-in record also notes which key started it. The key identifies this installation of the app, not you or your provider accounts; it is not linked to your training data, and reinstalling the app creates a new one. The service deletes a key that has not been used for 180 days. If your device cannot give this proof, the app offers the ways that work without the service, such as your own openrouteservice key.
Activity notifications
Wake-up notifications are optional and are not sent to your device unless you turn them on. With it enabled, supported Strava or intervals.icu activity events can cause the service to ask Apple to wake Weida on your device. Intervals.icu upload and analysis events are supported for accounts connected through OAuth; API-key-only connections do not receive these wake-ups. Intervals.icu does not send activity webhooks for Strava activities. Calendar and sport-settings events do not change your plan through this receiver.
For this the service stores your device's Apple push token in encrypted form, together with the connection it belongs to. It is deleted when you turn notifications off, when you disconnect that provider, or when Apple reports that the token is no longer valid.
The notification itself carries nothing to display: no activity, no name, no numbers and no text. We hold no copy of your plan on the server and are in no position to write a message about it. Your device wakes, fetches the change from the provider itself, and decides on your device whether anything is worth showing you.
Apple Inc., in the United States, receives your device's push token, the app identifier and the timing of each notification in order to deliver it. It does not receive the activity or your provider account.
Strava's report names the provider's identifier for the changed activity and your provider account identifier. Intervals.icu sends authenticated batches that may also contain activity content, including names and training measurements. The service checks the shared secret, extracts only the activity ID, event kind, event time and a keyed account fingerprint, and discards the remaining content. Neither the payload nor the secret is logged. A configured provider may deliver events for connected OAuth accounts even without a registered device; only opted-in device registrations receive a wake-up. The event metadata, not the activity content, is queued for delivery. It is stored for the minutes between arrival and delivery, identified only by the fingerprint described above, and deleted once the notification has been sent or abandoned. A report for an account that is not connected is discarded without being stored.
Strava also reports it to the service when you withdraw Weida's access in Strava's own settings. The connection is then ended on our side and any device registration for it is deleted, without you needing to open the app.
parkrun
When you connect parkrun, your athlete identifier and password are sent to parkrun to authenticate you. Weida does not retain your password; it retains the returned tokens and relevant account information. It imports results such as event, date, finishing time, position and age grade.
Maps, weather and location
These are optional online functions. Before sending location information derived from health/activity records for weather or place lookups, Weida explains the disclosure and requires the relevant feature to be enabled. General on-device coaching consent does not silently authorize every external request.
Weida uses Apple MapKit for maps and place searches or lookups, and Apple WeatherKit for weather. These functions send the information necessary for the request to Apple, such as a search query, map area or coordinates. Weather requests can include a saved training or travel location, or a recorded route's starting location and the activity's date and time.
You can select a saved location or place a map pin instead of granting access to your current location. Denying current-location access does not prevent an online request for a location you select manually.
Course generation
When you request a generated course, Weida sends the necessary routing information to openrouteservice, operated by HeiGIT gGmbH. This includes starting coordinates, any requested or calculated waypoints, requested distance, sport/routing profile and relevant route preferences. Where our connection service offers course creation, the request goes through it: the service checks the request, adds its own openrouteservice key and passes the route back to your device. It neither stores nor logs the coordinates or the route, and openrouteservice then sees our service's address instead of your device's. Such a request carries the App Attest proof described in the section on the connection service. If the service is unavailable, switched off or at its limit and you entered your own openrouteservice API key, the request goes directly from your device to openrouteservice with your key. This request does not include your full health history or coaching conversations.
Apple Watch, calendars, files and system features
When you enable the relevant features, Weida sends planned workouts to Apple Watch through WorkoutKit and creates, updates or removes workout entries in your calendar. Calendar entries may synchronize through the account you use for that calendar.
Selected activity and course files are imported into the app. Exported workouts or calendar files are shared with the destination you choose; that destination then handles the copy under its own terms and privacy practices.
Notifications, widgets and Shortcuts may display or provide access to selected training information outside the main app, including on your Lock Screen. Review your device's notification and privacy settings before enabling these features on a shared device.
Connected online services also receive network information needed to handle a request, such as your IP address and relevant authentication information. Connecting a service can enable subsequent synchronization, including background synchronization; authorization is not necessarily limited to a single import.
6. Optional encrypted backups and saved credentials
Enabling a backup
Backups are off by default. To enable them, you must choose a supported storage folder, set and confirm a backup password, and separately agree to the health-data backup processing explained on the setup screen. There is no preselected cloud destination and no automatic upload to a Weida backup server.
A backup may contain your profile, availability, goals, plans, activity history, routes, measurements, feedback, injury and wellness information, and the coaching state needed to restore those features. Health information remains health information when encrypted. Cached weather and AI choices, notification authorizations and saved coach conversations are excluded from the profile-backup archive and retain the separate local retention rules in section 10.
Backups do not contain your service passwords, integration tokens or API keys, saved backup-unlocking keys, device-specific access bookmarks, active consent grants, system permissions or purchase entitlements. Services and optional automatic transfers must be enabled separately after restoration.
Storage destination and metadata
You choose an existing folder through Files. Accessible folders may be on your device, in iCloud Drive or another file provider, or on a connected external drive. The app uses the access granted by your selection and saves a folder bookmark for future manual backups. Unavailable or read-only destinations produce an error; the app does not silently choose a different folder.
The file’s existence, size, filesystem timestamps, random filename and technical header remain visible to anyone who can access its folder. The header contains the format/version, salt, fixed KDF parameters and a random archive identifier, without a profile name or health values. If you select cloud storage, its provider receives the encrypted file and this metadata and handles synchronization under its own storage, versioning and deletion policies. A successful write and read-back confirms file access, not completion of remote synchronization. Copies you make elsewhere are also governed by their destination’s policies.
Saving only on the same phone does not protect against losing that phone. A successful write means that the app completed its operation at the selected location; it is not necessarily confirmation that an external provider has finished synchronizing the file to its servers.
Encryption and password
The backup content is encrypted and authenticated on your device before it is written to the destination. The implementation uses CryptoKit AES-256-GCM with a fresh random 256-bit data key for each backup. CommonCrypto PBKDF2-HMAC-SHA-256 derives a key-encryption key from the password, using 600,000 iterations and a random 32-byte salt per configuration. A password change creates a new salt. CryptoKit generates fresh nonces. Authenticated data binds the header, wrapped data key and encrypted payload. Salt and key-derivation settings are stored with the encrypted archive so it can be restored on another compatible device.
There is no developer-held master password or hidden recovery key. We do not receive your backup password and cannot recover it for you. You normally need the backup file and its password to restore it on a new installation. A still-working installation may retain your local data; that is different from recovering an encrypted file whose password has been lost.
An app-specific file format is not a promise that the data owner cannot decrypt their own data using other compatible tools. Anyone who obtains the file and the information needed to unlock it may be able to access its contents. Password strength, device protection and how you store the file all matter.
Manual operation and retention
Manual backups ask for your password when you tap Back up now. Setup saves the first backup immediately. If you separately enable automatic daily backups, Weida keeps a password-derived encryption key in a separate, non-synchronizing Keychain item available only while this iPhone is unlocked. The key does not migrate to another device through Keychain; you still need your password to restore there. The password itself is not saved. Setup stores a salt, an encrypted known-value password verifier, a folder bookmark and display name, the profile association, an optional identifier for the automatic-backup key, and the backup-consent timestamp/version/language in a protected, system-backup-excluded local configuration. The password verifier permits offline password guessing if this configuration is obtained; choose a strong, unique passphrase.
Automatic mode attempts a backup when the last successful backup is at least 24 hours old and Weida runs with this iPhone unlocked, including available background refresh opportunities. iOS does not guarantee an exact background schedule. If the folder or key is unavailable, the app shows the failure and retries on a later opportunity, no sooner than one hour after the previous automatic attempt in the current app session. Wi-Fi only is enabled by default. Automatic attempts wait for a non-metered Wi-Fi connection unless you turn that setting off. Manual backup and export requests remain available on any connection. The selected storage provider controls later synchronization and its own cellular-data settings. Opening and using Weida provides foreground opportunities. Activity records are encrypted in batches into protected temporary app storage. The completed file is copied to the selected folder, verified and atomically published. Automatic mode replaces the same app-managed file at that destination, preserving the previous file until replacement succeeds. No unencrypted profile archive is staged at the backup destination. Temporary memory may hold clear data during encryption and restoration; this is not a promise of perfect memory erasure.
Changing the password protects new backups. Existing files retain their previous password. Turning off automatic mode removes its saved encryption key while keeping manual backups available. Disabling backups, resetting, withdrawing health-data consent or restoring a profile disables automatic mode and removes saved backup keys; cleanup failures are reported. Changing the password or destination replaces the saved key if you opt into automatic mode again. Existing backup files remain. Forgetting the destination also removes the configuration and the local index of known versions, including all retained folder bookmarks. Files remain at their destinations and must then be managed through Files.
Automatic mode keeps one current app-managed backup per profile at the selected destination by replacing its previous automatic backup. Manual mode retains up to seven successful app-managed versions per profile at the current destination. It deletes only indexed filenames whose content digest still matches what the app wrote. A changed or inaccessible file is preserved and reported as an error, so manual resolution may be needed to complete rotation. Private copies, previous destinations and provider history are outside automatic rotation.
Restore and deletion
Restoring requires your current consent for the health-data processing involved, the password and your confirmation. A restored file does not reinstate old consent choices, system permissions, service connections, automatic exports or the backup destination.
Resetting the app or withdrawing health-data consent does not create a fresh backup. You can ask the app to delete known, accessible backup files it manages. The result is reported, including access failures. Copies you made elsewhere, files at disconnected destinations, and provider-retained versions may need to be deleted using the relevant device or provider tools. Local withdrawal and deletion do not depend on successfully reaching these external copies.
Integration credentials and operating-system services
Integration credentials are separate from backup encryption keys. The existing integration Keychain implementation supports iCloud Keychain synchronization. Those credentials may be synchronized through Apple's service when you use it; they are not included in Weida's encrypted backup archive. Their availability does not itself authorize a new installation to import or share health data.
New local transfer choices are required even when credentials arrive from iCloud Keychain. There is no new Weida account or backup server.
Weida requests exclusion of its database directory and existing SQLite/WAL/SHM files, local privacy and conversation files, app preferences directory, widget snapshots and new export staging files from automatic system backups using the operating system’s exclusion settings. These settings do not provide a universal guarantee against copies made by the operating system or other software. This does not delete backups already created by older releases. Apple's own Health-data synchronization, a provider's copies, and exports you move independently are separate mechanisms and are not controlled by this app setting.
7. Automated coaching and on-device AI
Weida analyses your training history, goals, availability, fitness and recovery information to generate and adapt training plans. This includes personalization and profiling of your training performance.
The planning engine runs locally. On supported devices, Apple's on-device Foundation Models framework helps interpret requests and explain verified app information. Otherwise, supported functions use local rules. Unless you switch on the option described next, the app does not send these prompts or training records to a remote AI inference service.
On iOS 27 you can switch on "Answer coach chat with Apple Private Cloud Compute" in Privacy. Coach chat then sends your message, the recent messages of that chat and the plan, activity, load, recovery and availability details it looks up for the answer to Apple's Private Cloud Compute, where Apple Inc. processes them to produce that answer and, according to Apple, does not retain them or make them accessible to Apple. This option is off until you enable it, and you can switch it off at any time; with it off, or when the service is unavailable, chat uses the on-device model or local rules.
We do not use this functionality to make decisions producing legal or similarly significant effects about you, such as decisions about employment, insurance or access to healthcare. Coaching estimates are not medical diagnoses. You remain in control of your training choices and can review proposed conversational plan changes before applying them.
8. Purchases
Apple processes in-app purchases through the App Store. Weida uses StoreKit to verify purchases, determine access and restore entitlements, including information about products, transactions and relevant purchase dates.
We do not receive your payment-card details from Apple. Apple's handling of your Apple Account and payment information is governed by Apple's privacy notice.
9. Website, support and diagnostics
Website and email hosting
Our website and email are hosted by ALL-INKL.COM – Neue Medien Münnich, proprietor René Münnich, Hauptstraße 68, 02742 Friedersdorf, Germany. ALL-INKL.COM provides the hosting and mailbox infrastructure on our behalf. It describes its German data-centre infrastructure and processing in its privacy information.
When you visit the website, its hosting infrastructure receives the connection information necessary to serve the page, including your IP address, request time and requested resource. Technical access or error logs may also include browser and operating-system information, response status and the referring page where your browser supplies it. This processing supports reliable delivery, troubleshooting and protection against misuse, on the basis of our legitimate interests under Article 6(1)(f) GDPR. Access information is kept only for these operational and security purposes; information needed to investigate a specific incident may be retained until that investigation and necessary follow-up are complete, or longer where legally required.
The website itself does not use advertising trackers, analytics scripts or tracking cookies. Its fonts, images and videos are served as local website assets, rather than embedded from external advertising or video platforms. Merely visiting the website does not transmit your app’s training database to the host.
When you email us, ALL-INKL.COM handles the message and associated sender, recipient and delivery information as our email host. Ordinary email is not an end-to-end encrypted channel for health records. Provider backups and mail systems may retain copies separately from your app’s local data.
Support and TestFlight
When you contact us, we receive your email address and whatever you include in your message, such as your name, screenshots or diagnostic information. Please avoid sending health records, passwords or API keys unless specifically necessary; we do not need your account passwords for support.
Support information is used to answer your request and resolve related issues. We retain it until the request and necessary follow-up are complete, and thereafter only to the extent necessary for applicable legal obligations or the establishment, exercise or defence of legal claims.
If you use a TestFlight beta, Apple may provide us with testing information, such as installation and usage information, device details, crashes and feedback you submit. Depending on how you join the test, this can include your name or email address. We use this information to administer the beta and improve the app, not for advertising.
10. Retention, deletion and your controls
Local profile, activity and planning information is generally retained until you delete it using the relevant controls or reset the app, subject to withdrawal of the consent on which the relevant processing depends. Saved coach conversations are limited to 40 messages per chat and a 30-day retention period. Deleting a chat does not delete the separate record of changes already applied to your training plan. Full health-data deletion also addresses health information in those records and related derived data.
Stop importing or disconnect. This prevents future imports through that connection. Previously imported data may remain available for local coaching while the relevant processing consent continues to apply. Removing Apple Health access requires the relevant Apple Health/iOS controls; disconnecting in Weida does not itself revoke Apple's system permission. For a third-party provider, use its own authorization or API-key controls for provider-side revocation. Disconnecting a Strava or intervals.icu connection made through our connection authorization service also asks the provider to revoke the authorization and deletes the connection record and any device registration held by that service; section 5 states what remains there and for how long. A Strava connection made with your own Strava API application ends on your device only.
Disable backups. This stops new backups. It does not delete local training data or existing backup files. Backup-file deletion, version rotation and forgetting the destination are explained in section 6.
Withdraw health-data consent and delete health data. Use Settings → Privacy. Weida stops the consent-dependent imports, processing and backup jobs, and deletes the relevant health information from its active local records, health-related free text, derived assessments, caches and displayed system integrations it controls. Non-health settings and independently verified purchases need not be erased. This action is not conditional on making a new backup or buying a paid feature.
Reset Weida. A full reset clears the app's local training data, app preferences, cached widget information, active local consent and saved app connections. It does not first create a backup. Reset does not delete your original records at Apple Health, Strava, intervals.icu or parkrun, nor does it automatically remove previously exported sessions from another service, your own copies of files or a provider's retained versions.
Previously issued network requests or operating-system deliveries cannot be recalled by a local withdrawal. New service operations are gated and stale results are rejected; remote originals and already delivered copies require separate management.
For accessible backup files controlled by the app, you can request deletion and see which operations succeeded. You must manage copies beyond the app's access at their storage destination. A remote deletion failure does not prevent local withdrawal. Restoring an old file requires fresh current consent and does not undo your privacy choices silently.
Uninstalling alone is not a reliable way to erase every external copy or synchronized credential. Contact us for help with the app's controls or requests concerning information we hold directly.
The app keeps the most recent device-local consent or refusal record until you replace it or remove the app. It contains the purpose, status, time, language and notice versions; it does not contain your workout history. The backup ownership index remains until its entries are deleted or you choose to forget folder access. It enables deletion of known backup files without requiring access to your health profile.
11. Recipients and international processing
Information may be received by the services described above when you use the relevant functions, by a destination to which you independently copy or share a file, by our support providers when you contact us, or by authorities where disclosure is legally required. We do not provide personal data to advertisers or data brokers.
Our establishment in Germany does not mean that every connected service processes data exclusively in Germany or the European Economic Area. A service may process information outside the EEA. Its privacy notice explains its processing, retention and safeguards for its own service.
Connected Apple, Strava, intervals.icu, parkrun and openrouteservice services handle their own services under their respective privacy terms; they are not all processors acting on our instructions. ALL-INKL.COM supplies the website, email, connection-authorization and course-routing infrastructure described above, on servers in Germany. If you enable activity notifications, Apple Inc. in the United States receives the delivery information described in section 5. When the app proves itself to our service with App Attest, your device contacts Apple Inc. in the United States as described in section 5. If you switch on Private Cloud Compute for coach chat, Apple Inc. processes the chat content described in section 7 on its Private Cloud Compute servers. Our local training engine does not add a central international transfer of your training database. If you need information about a specific disclosure or safeguards relevant to processing for which we are responsible, contact us using the details in section 1.
12. Security
We use iOS storage protections, Keychain protection for relevant credentials and HTTPS for the online integrations implemented by Weida. Backup protection is described in section 6. If you independently move a copy to another service, that service applies its own transfer and account-security mechanisms.
Our connection authorization service exists so that the application credentials for Strava and intervals.icu are not distributed inside the app. It does not store your access or refresh tokens; what it keeps about a connection is stored as non-reversible fingerprints, and the one credential it holds temporarily is encrypted.
We do not embed a global backup-decryption secret in the app or operate a developer recovery service for backup passwords. Authentication checks are designed to detect corruption or changes by someone without the required key; they do not make user-owned files trustworthy input or establish that the developer created their contents.
Protect your device, passwords and connected accounts. Use a strong backup passphrase and take care when sending an export or screenshot. No storage or transmission system can be guaranteed completely secure. Deleting app-controlled files does not constitute a promise of forensic erasure of every physical storage block or remote provider copy.
13. Your data-protection rights
Subject to the applicable legal conditions, you have rights of access, rectification, erasure, restriction of processing and data portability. You may object to processing based on legitimate interests on grounds relating to your particular situation, and withdraw consent at any time.
Contact info@weida-coach.com to exercise your rights. Much of your app data is held only on your device or in accounts we cannot access remotely. We will explain the available controls and assist with exercising your rights, as well as handle any personal data we hold directly. We may request proportionate information needed to verify a request. Data & backup → Encrypted backups → Export your data provides a separate unencrypted JSON export of the profile-backup data, excluding chat histories and credentials, rather than requiring you to reverse-engineer the encrypted restore format. This export is initiated by you, with a warning and appropriate controls before sensitive information is saved or shared. Access to privacy controls is not restricted to a paid tier.
We normally respond within one month. Any permitted extension will be explained within that period.
You may lodge a complaint with a data-protection supervisory authority, particularly in the EU Member State of your habitual residence, workplace or the alleged infringement. Our relevant German supervisory authority is the Bavarian State Office for Data Protection Supervision (Bayerisches Landesamt für Datenschutzaufsicht, BayLDA), Promenade 18, 91522 Ansbach, Germany. Email: poststelle@lda.bayern.de. You can find its contact details and complaint service online.
14. Changes to this policy
We may update this policy when the app or its data processing changes. The current version will be available through the app's privacy-policy link and our published privacy-policy page. We will provide additional notice of material changes where appropriate and obtain new consent where required. Continued use is not a substitute for consent where the law requires it.