Overview#
Kawa (the “App”) is developed and operated by independent developer Kami (the “Developer”). The App processes only the data needed to provide live-stream aggregation, short-drama viewing, go-live alerts, synchronization, diagnostics, and App Store purchase features. This policy explains which information the Developer, Cloudflare, Apple, and third-party streaming platforms process. Cloud Standby Recording is a service separate from the App; the data it processes is described in the Cloud Standby Recording service notes (in Chinese).
Data We Process#
- Versions 1.8.1 and earlier collect basic analytics data through TelemetryDeck. Later versions no longer collect product analytics, such as playback and feature usage. Purchase processing and sales, subscription, and refund statistics are described under RevenueCat below.
- App Store purchases: the App uses the RevenueCat SDK to load product information, complete and restore purchases, and determine Full Version access. Apple processes orders, payments, and billing information. The Developer does not require a purchase email or receive payment card or bank account details. The signed-transaction verification and current-status query described below apply only when you explicitly enable Cloud Go-Live Alerts.
- iCloud sync: when enabled, followed-streamer lists, the addresses and names of streamer lists you subscribe to, cross-device preferences (including content translation settings and caption style), third-party platform login credentials you choose to save, and the API key for a custom translation service (synced in encrypted form) are synchronized through your own iCloud / CloudKit account across devices using the same Apple Account. The caption translation count is an exception; see “Content Translation and Live Captions” below.
- Third-party platform login: when you sign in, the App stores the cookies or credentials required by that platform on your device. They are used only to restore your session, request live-stream content, or provide signed-in features.
- Referral rewards: after your Promotion Program application is approved and you become a Referrer, our cloud service stores your referral code, a one-way digest of your Referrer credential, your successful referral count, referral reward ledger entries (report date, referral code, product, country or region, and amount), your balances, and withdrawal records (request code, amount, status, times, and rejection reason). The credential itself is kept only in your device keychain and syncs through your iCloud when iCloud Keychain is on; the Developer does not store the credential itself. Successful referrals rely only on data in Apple's sales reports aggregated by referral code; we do not collect, and cannot learn, the identity of referred friends. When you apply, the random device identifier the App sends and the request IP address are used for rate limiting only as irreversible HMAC digests; the digests are used only within the 10-minute rate-limit window and are cleaned up after the window ends. The feature collects no email address and requires no account registration, and withdrawal records contain no payment method or payment account. When a friend opens a referral link page, the page asks our cloud service for the friend prices; this lookup needs no sign-in or credential, and the request IP address is likewise used for rate limiting only as an irreversible HMAC digest, used only within the 10-minute rate-limit window and cleaned up after the window ends.
- Promotion Program applications: when you apply to join the Promotion Program (推广计划), our cloud service stores a one-way digest of your Referrer credential, the promotion statement and images you submit, the application status, the review result and any reason for not approving, and the submission and review times. To confirm that you currently hold the Full Version, the App uploads your current StoreKit signed transaction, which the cloud service verifies and checks with Apple. The signed transaction is used only for that request; we store neither the original nor the transaction ID, only the verified product and transaction environment (production or test). Before upload, the App converts images to JPEG and removes EXIF information such as capture location. Images are kept in dedicated private storage with no public address. Application materials are not made public; apart from the AI model service and the push summary described below, only the Developer can see them. During review, the application text and images are sent to a third-party AI model service chosen by the Developer, which returns a review suggestion or result. When an application arrives, a summary of it (an excerpt of the promotion statement and the AI review suggestion) is sent through the Bark push service to the Developer's own device. While an application is under review, a copy of its promotion statement is also kept on your device, only to refill the form if you withdraw it; it does not sync through iCloud and is deleted once the application is no longer under review.
- The App does not use advertising SDKs or track you across apps or websites.
Local Storage and iCloud#
Followed-streamer lists, video quality and danmaku preferences, temporary player state, and third-party platform login credentials you choose to save are primarily stored on your device. Turning off iCloud sync stops future synchronization; data already on the device remains available.
App Store purchase records and entitlement status are managed by the RevenueCat SDK. They are not synchronized through Kawa’s iCloud / CloudKit data area and do not create a website purchase credential. iCloud sync excludes purchase and historical trial status, player caches, live-status snapshots, livestream watch-duration logs, crash logs, and other temporary local state. Livestream watch-duration logs are stored only on the device.
Short Dramas and Viewing Records#
Short dramas are currently available only in some iPhone and iPad test builds. When you use them, your device requests catalogs, search results, series, episodes, and media directly from the short-drama content platform. The platform receives information necessary for those requests, such as your IP address and temporary request identity, and handles it under its own privacy policy. Temporary request identities, signed media addresses, and decryption parameters are used only in request and player memory.
The App stores public series metadata, series and episode identifiers, follow decisions, actual resume positions, watched status, and clear decisions on your device. With iCloud sync enabled, these drama records and the random device/session identities, viewing start/end facts, and operation ordering needed to merge them sync through your private CloudKit data area. Complete drama operation payloads use encrypted fields. The Developer's servers do not receive these records. Playback remains under local control; another device's position is offered as a resume choice. When you leave the player, the App keeps one thumbnail of the last frame you saw for that series in the device cache, used by the Watching list and the Continue Watching entry; recent search terms are likewise kept only on the device. Neither is synced through iCloud. The thumbnail is deleted when you clear that series' viewing history, and recent searches can be cleared on the search screen.
While sync is off, viewing, follow, and clear operations continue to be saved locally, and cloud records remain. When sync is reenabled and the same Apple Account is available, operations made while it was off merge automatically. Removing a drama follow preserves viewing records. Clearing one series or all drama viewing records preserves follows; clear decisions remain saved and synced to constrain late old records. Starting playback again creates new records normally.
Once an Apple Account is confirmed, drama operations are stored in account partitions. The first confirmed account adopts earlier local records; later account switches use the corresponding partition, and returning to the original account restores its records. If the system account is temporarily unavailable, local records and pending sync operations remain available, with status and retry controls.
Episode posters are generated on your device from the actual current playback frame and contain the series title, episode number, content source, capture time, and a QR code carrying series/episode identifiers. Whole-series links contain the series identifier. You choose recipients through the system share sheet; the Developer does not receive posters or shared content. An episode recipient starts from the beginning and can return to their own previous resume position. Share targets carry no signed media addresses, decryption parameters, account identifiers, or viewing progress.
Streamer Lists#
A streamer list is a list of streamers that someone has put together and shares as a JSON file. The preset streamer list is downloaded from the Kawa website (delivered through Cloudflare). When you subscribe to the address of a third-party streamer list, the App connects directly to the third-party server at that address to download it, and refreshes it as needed when you open that list later. That server receives ordinary request information, such as your IP address, and its operator decides how that information is handled. Avatar addresses in a streamer list are likewise requested by your device directly from the servers they point to.
Streamer list files you import and the contents of all streamer lists are stored only on your device. They are included in your device backups and are not synchronized through iCloud. When iCloud sync is enabled, the address and name of each streamer list you subscribe to are synchronized through your own iCloud / CloudKit account across devices using the same Apple Account, and each device downloads the list's contents from that address itself. Which list you are currently browsing is remembered separately on each device and is not synchronized. Kawa does not upload any streamer list data, and the Developer cannot see which streamer lists you subscribe to or import.
Content Translation and Live Captions#
Content translation translates stream titles, streamer nicknames, and danmaku. Live captions transcribe what the streamer says into on-screen captions and can show a translation alongside. Live captions are off by default until you turn them on. Both use the same translation engine, which you choose in Settings: Apple system translation or a custom translation service.
- Speech recognition: live captions use the stream audio the App has already decoded for playback, and recognition happens on your device. The App does not use the microphone and does not record audio from other apps or the system. Depending on your system version and the caption language, recognition uses one of two paths:
- Apple speech recognition: used when both your system version and the language are supported. Recognition happens on your device. Audio never leaves your device; the system downloads the required language resources from Apple.
- Fallback recognition engine: in other cases, the App uses its built-in open-source recognition engine, sherpa-onnx. Recognition also happens on your device. Audio never leaves your device. When you choose to download a recognition model, it is downloaded from Kawa's model storage (delivered through Cloudflare), then verified and stored on your device. As when visiting a website, that storage receives ordinary request information during the download, such as your IP address; the download request carries none of your followed streamers, login credentials, or stream content.
- Apple system translation: with this engine, translation happens on your device and the text to be translated is not sent to the Developer. The first time you use a language, the system may need to download the corresponding language pack from Apple.
- Custom translation service: with this engine, the text to be translated is sent directly from your device to the service address you entered. These requests never pass through the Developer, and the Developer cannot see their content. What is sent includes caption text, danmaku in the danmaku list, stream titles, and streamer nicknames; scrolling danmaku is sent only after you turn that on separately. To improve accuracy, caption translation also includes the original text and translations of the previous few captions, the stream title, and the streamer nickname. How that service handles this data is governed by the terms and privacy policy between you and that provider.
- Service configuration: your translation engine choice, the related switches, and the service address, API key, and model name are stored on your device, with the API key kept in the system keychain. When iCloud sync is enabled, this configuration syncs across your devices through your own iCloud, with the API key synced in encrypted form; with iCloud sync turned off, it stays on this device only.
- Caption translation allowance: the Free Version's count of translated captions is kept across devices using the same Apple Account in Apple's iCloud key-value storage. Only the number of captions used is recorded, never the captions or translations themselves. This count is not affected by the App's iCloud sync switch and is kept even if you delete the App.
- Caption source language: a caption source language you set for a specific room is stored on this device only.
- Captions, translations, and text to be translated are not sent to the Developer.
Go-Live Alerts#
Local go-live notifications (liveNotifications) are triggered when the client checks status while the App is running or during a system-scheduled background refresh, then uses the system notification service. This is a Free feature. Notification permission, APNs, and system banners are also free system capabilities.
Cloud Go-Live Alerts (cloudLiveMonitoring) are an optional service hosted by the Developer and included with the Full Version. You must explicitly enable the service on iPhone, iPad, or Mac; it is off by default. Once enabled, the Developer uses Cloudflare to keep monitoring registered rooms while the App is not running, deduplicate live-state changes, and deliver alerts through Apple Push Notification service (APNs). Delivery depends on network and third-party services and is provided on a best-effort basis.
Cloud Alert Data and Retention
- Room subscriptions: Cloudflare D1 stores a random installation ID, platform, room ID, the nickname used by that installation, the notification setting, and the identifier needed for platform status checks (currently the streamer UID for Bilibili). Status and go-live events are deduplicated by platform and that check identifier. Each delivery target separately snapshots the matching installation's room route and nickname. Some platforms’ online checks read a public per-broadcast identifier in memory for that request (the video ID on Yizhibo, the broadcast number on SOOP, the session code on PandaTV, the stream session ID on Twitch, the live stream ID on TikTok, the live-feed ID on Huajiao, the session ID on Inke) to distinguish separate upstream sessions that remain continuously online. The raw value is not persisted; D1 stores only a platform- and check-identifier-scoped HMAC digest in room state, and deletes it after confirmed offline status or room-state cleanup. Neither the raw value nor its digest enters Queue, APNs, or logs. For every platform, upstream room names and live titles are discarded at the adapter boundary even when returned; they do not enter D1, Queue, APNs, logs, or the shared business fixtures. An incorrect check identifier affects only the subscription belonging to that installation. Each successful signed registration from iPhone, iPad, or Mac renews that installation for 90 days. Monitoring uses only subscriptions whose lease and push address are valid and whose notifications are enabled. After 90 continuous days without a successful registration, the installation expires and enters bounded daily cleanup, which deletes its room subscriptions, delivery targets, push address, and installation record. Turning off the service immediately sends an unregister request; successful unregistration deletes the records immediately, and the client retries on a later launch after a network or service failure.
- Scheduled program reminders (iPhone / iPad): after you explicitly enable cloud alerts, the App sends this installation's official occurrence identifier, source, official time recorded when reserving, and a sequence number that prevents late requests from replacing newer reservations. The server stores delivery jobs only; it provides no reservation-list read endpoint or cross-device sync. Program titles, platform cookies and signed playback URLs are not uploaded. The notification says “Program reservation” and “It is time for your reserved program” and carries an occurrence route; it does not mean the program is live. Canceling a reservation or disabling reminders requests cancellation of pending jobs. Offline or uncertain requests remain pending confirmation; notifications already handed to APNs cannot be guaranteed to be withdrawn. Jobs and cancellation records are retained for 24 hours after the 45-minute delivery window following the reserved time, then removed by cleanup. Successful installation unregistration, lease expiry or installation removal following an invalid token also removes them. Local reservations remain on this device after delivery.
- Push address: the client sends its APNs device token to Cloudflare. The device token is encrypted at rest in D1 with AES-GCM, with a separate HMAC digest used for deduplication, and is retained until successful unregistration, expiry of the 90-day installation lease, or an APNs 410 response reporting the token as invalid. When a 410 deletion leaves the installation without another token, the service also deletes that installation's room subscriptions, delivery targets, and installation record. For delivery, Cloudflare sends APNs the device token, the corresponding room route, and a visible alert containing only the title “<nickname for this installation's subscription> 开播了” with no body. Apple processes delivery data under its privacy policy.
- StoreKit verification input: registration after you explicitly enable Cloud Go-Live Alerts sends a StoreKit signed transaction. The Cloudflare Worker performs one-time offline verification with Apple's root certificates and queries Apple for the current transaction or subscription status, checking the product, purchase source, and validity period. Plaintext transaction identifiers are used for that query only and are neither logged nor persisted. The original value exists only in memory for that request and is discarded after processing. The Developer does not persist the original signed transaction or retain a plaintext transaction ID. The service retains necessary one-way transaction digests, authorization sources, expiry information, and the
cloudLiveMonitoringadmission result to process renewals, refunds, and revocations. Successful registration renews a 90-day installation lease; successful unregistration or cleanup of an expired lease removes the installation's associations. An authorization digest is deleted when its last associated installation is deleted. Purchase chains without an opted-in installation and notification receipts are not persisted. Invalid subscription access stops the affected hosted services; an installation lease does not extend subscription access. - Short-term registration claim: initial registration creates a short-term registration claim after request HMAC authentication and IP admission, and before StoreKit verification. The claim stores only an installation-keyed digest, encrypted installation secret, one-way secret digest, and expiry for at most 601 seconds; it contains no plaintext installation secret, StoreKit JWS, or device token. It permits authenticated unregistration during verification and prevents an in-flight registration canceled by that unregistration from being persisted. Authenticated unregistration immediately deletes the claim. A later registration that passes request HMAC authentication and IP admission lazily deletes expired claims.
- Security rate limits and unregistration protection: the registration endpoint converts the request IP address into a one-way HMAC digest for replay protection and short-term rate limiting. The digest is retained for no longer than the configured 10-minute window. A random nonce digest is retained until signed timestamp + 301 seconds for ordinary mutation replay protection. When the service successfully processes unregistration, the same D1 batch deletes installation data and makes logical unregistration effective immediately. It then retains a 601-second active installation tombstone containing only an installation-keyed digest, generation, expiry, and encrypted installation secret. This blocks older registrations from restoring data and permits an authenticated retry after a lost 204 response. After expiry, the next registration admitted by the IP limit lazily deletes the tombstone row. A structurally valid, current unregister request for an unknown installation ID returns a read-only 204 and performs no cleanup write. Logs exclude device tokens, signed transactions, JWTs, and complete notification payloads.
Cloud Go-Live Alerts use an explicit opt-in, one-way, non-readable notification subscription index. It is separate from product-data sync: the Worker exposes no subscription read endpoint and never returns your follow list to any client. iCloud remains the product-data sync path between Apple clients.
The cloud service never uploads third-party platform cookies, platform login credentials, or a device fingerprint. Those sign-in credentials remain on your device or in your personal iCloud when you choose to enable iCloud sync.
Network Services#
- Streaming-platform APIs: retrieve streams, danmaku, streamer status, and signed-in features you request.
- Apple StoreKit: the RevenueCat SDK uses it to complete App Store purchases. The App separately reads signed transactions for the cloud-service verification described below.
- Apple App Store Connect: referral codes are created in App Store Connect as Apple offer codes. Each day the Developer reads sales reports there that are aggregated by referral code and contain no buyer identity, to record successful referrals and referral rewards.
- RevenueCat: the in-app SDK sends purchase records and an anonymous RevenueCat ID to complete and restore purchases and determine Full Version access. It does not send your name, email address, payment method, following data, or device name. RevenueCat also receives a copy of the App Store server notifications Apple sends to the Kawa server, used to measure sales, subscriptions, and refunds. What is forwarded is Apple’s own signed notification and contains transaction identifiers, product, price, currency, and storefront. It contains no name, email address, payment method, device identifier, push address, or your following data.
- Apple iCloud / CloudKit: synchronizes the data described above only when you enable iCloud sync, except the caption translation count, which is kept in iCloud key-value storage regardless of that switch.
- Cloudflare: hosts registration, room subscriptions, status monitoring, deduplication, and delivery orchestration for Cloud Go-Live Alerts that you explicitly enable.
- Cloudflare and Apple TestFlight: Cloudflare hosts website Beta application verification, invitations, and digest-based binding records. Apple receives and retains the tester email address for TestFlight invitations; see “Website Beta Applications.”
- Apple Push Notification service (APNs): delivers cloud-detected go-live alerts to a registered iPhone, iPad, or Mac.
- Cloudflare D1 and R2: host the website feedback board's submissions and attachments.
- AirBuild: receives and stores the reports you send from “Report a problem” in the App; see “In-App Problem Reports” below.
- Cloudflare D1 and R2: store the text and images of Promotion Program applications. Images are kept in a dedicated private storage bucket with no public address, separate from feedback board attachments.
- AI model service: a third-party AI model service chosen by the Developer receives the application text and images when a Promotion Program application is reviewed, and returns a review suggestion or result.
- Bark: when a Promotion Program application arrives, sends a summary of it (an excerpt of the promotion statement and the AI review suggestion) through the Apple Push Notification service to the Developer's own device.
- Cloudflare R2: hosts Kawa's model storage and delivers the model files used by the fallback recognition engine for live captions.
- Servers hosting third-party streamer lists you subscribe to: receive download requests sent directly from your device, only when you subscribe to or refresh a streamer list.
- The custom translation service you specify: only when you choose that engine, it receives the text to be translated directly from your device.
Apple’s privacy policy applies to purchases, refunds, and Apple Account data. The Developer processes only the data expressly described in this policy.
Website Feedback Board#
The website's feedback board (Chinese only) is a public, anonymous page. Anything submitted there becomes publicly visible immediately, with no pre-publication review. Do not include phone numbers, government identifiers, credentials, or anything else that identifies you.
- Submission content: the text you write, the type (defect or request), an optional device type and app version, and the submission time. This content is retained long term because it forms the product's record of requests.
- Display nickname: derived from a random string generated locally in your browser. That string is sent with the request and used only to compute the nickname on the spot; it is never written to the database or to logs. Only the resulting word pair is stored. It is not an account, cannot identify you, and clearing browser storage yields a new nickname.
- Attachments: images or videos you choose to upload, stored in Cloudflare R2 and deleted automatically after 180 days. Images are re-encoded inside your browser before upload, so EXIF data such as capture location never leaves your device; videos are not processed and may contain location data, so decide accordingly before uploading.
- Source IP address: stored only as a keyed digest that cannot be reversed to the original address, used to rate-limit submissions. A digest expires after 24 hours and is deleted the next time anyone visits the feedback board. The raw address is not stored.
- Local storage: the page keeps the random string above and your own up or down votes in your browser's localStorage so it can remember what you voted on. Neither is uploaded or used for tracking.
The board requires no sign-in, collects no email address or other contact details, and sets no tracking cookies. Votes carry no server-side identity.
The page provides no in-page reporting or deletion control. To have your submission removed, or to report advertising, unlawful, or privacy-violating content, contact [email protected].
In-App Problem Reports#
In the App, tapping Report a problem in the About area of the main Settings screen sends a report to the Developer. A report is sent only when you tap Send; nothing is uploaded automatically. Reports are delivered and stored through a feedback service provided by AirBuild. They are not public: only the Developer can view them.
- The text you write, up to 4,000 characters.
- Screenshots you choose to add, up to 3. They are recompressed as JPEG on your device before upload.
- Diagnostic log: every report includes the App's runtime log to help find the problem. Before it leaves your device, the log is scrubbed on the device of sign-in data such as accounts and cookies, and of room numbers, email addresses, IP addresses, URL paths, danmaku (chat) text, and long identifier strings. If the log cannot be prepared, you can choose to send without it.
- The App version and build number, device model, system version, and language and region setting.
Sending a report requires no sign-in, and a report contains no account or device identifier, so reports are anonymous. If you would like a reply, include a way to reach you in your text. Reports are used only to find and fix problems, and for no other purpose.
AirBuild processes these reports under its privacy policy. The service does not currently support deleting reports or setting a retention period, so a report is kept after it is sent. Because reports are anonymous, the Developer also cannot tell which report is yours. A report therefore cannot be deleted at your request after it is sent. Do not put anything in the text or screenshots that you do not want stored.
Website Beta Applications#
This section applies only to applications you choose to submit on the website's Beta application page. The page sends your Apple order ID and the email address you choose for TestFlight invitations to the Developer's service hosted on Cloudflare, to verify a Lifetime Full Version purchase, send an invitation, and enforce one email address per order. Application details are not made public.
The service does not store or log raw order IDs, email addresses, IP addresses, or transaction payloads returned by Apple. To manage applications, it stores irreversible digests of the order, the purchase (derived from the Apple transaction ID), and the email address, plus an Apple tester ID, the application status, and timestamps. To avoid sending duplicate invitation emails, the email digest is also kept in a send record for up to 24 hours. Short-term rate-limit digests expire when their rate-limit window ends and are deleted while later requests are processed. Raw IP addresses are not stored.
To send an invitation, the email address you provide is submitted to Apple. Apple retains the tester email address in TestFlight and processes it under its privacy policy. The order-to-email binding in the Developer's service is retained while your testing eligibility remains valid. You can contact the Developer to request deletion: you are first removed from the Beta testing group, and the service's binding record is then deleted. The order can be used to apply again after deletion. This does not delete purchase records held by Apple; Apple manages the data it holds under its own policies.
Historical Website Purchases and Support Services#
New App Store purchases do not require a Kawa purchase account and do not use the historical systems described below. The historical account, payment-result, and Apple TV authorization pages on the website have been taken offline. To support existing website purchasers, the Developer may still hold the following historical data:
- Account and contact data: purchase email, account status, deletion requests, and withdrawal status, used to authenticate historical accounts, recover Licenses, send reset or migration email, and handle support requests.
- Purchase and entitlement records: original order ID, payment status, amount and time, payment-provider transaction identifier, License Key and status, and refund or dispute status, used to verify historical purchases, restore an existing License, handle disputes, and arrange entitlement migration. Original payment card and bank-account details were handled by the former payment provider and are not provided to the Developer.
- Device and activation records: a device-fingerprint hash, device name and type, activation state, last-active time, License device seat, and temporary Apple TV authorization codes valid for ten minutes, used to maintain historical-version authorization and unlink or replace devices.
- Security and session data: historical account session tokens, payment-result query tokens, and necessary audit records, which were used for sign-in, existing-order status checks, abuse prevention, and account protection. Now that those pages are offline, the website no longer offers sign-in or payment-result lookups.
This data is used only for historical account support, existing-order verification, entitlement migration, refund or dispute handling, security audits, and legal obligations. It is not used to create new website purchases. Eligible historical purchasers will primarily migrate through App Store offer codes; an offline final build will be available when that method cannot be used. Steps and timing are available from [email protected].
When an account deletion request is submitted, the historical License and device sessions are disabled immediately and a seven-day withdrawal period begins. The historical account page is offline, so to request deletion or cancel it during that period, email [email protected]. After the period ends, the Developer deletes or de-identifies the account email, device records, login sessions, and usage data. Minimal order, transaction, audit, and historical trial anti-abuse records may be retained until applicable tax, reconciliation, transaction-idempotency, fraud-prevention, refund-dispute, purchase-recovery, and migration obligations end, then deleted or anonymized.
Historical website purchases are not App Store transactions and cannot be read through Restore Purchases in the App. With the historical account page offline, contact [email protected] to review or unlink devices, reset the License Key, request or cancel account deletion, or request access to, correction of, or deletion of other historical support data held by the Developer. Data required by law or for unresolved refunds, disputes, or migration obligations may not be deleted immediately.
Your Controls#
An App Store purchase does not create a Kawa purchase account. Apple manages Apple Accounts and App Store purchase history under its policies, and the Developer cannot delete purchase history held by Apple. When you turn off Cloud Go-Live Alerts, the local switch immediately remains off and the client immediately sends an unregister request. After the service successfully processes it, the service deletes that installation's cloud subscriptions, push address, authorization associations, and service-admission record; the transaction digest is removed when its last associated installation is deleted; the client retries on a later launch after a failure. Uninstalling the App or going 90 continuous days without a successful registration expires the installation lease and places the related cloud records into bounded daily cleanup; short-term security digests expire under the limits above. You can also clear local data in the App and manage iCloud data in system settings. Contact us regarding diagnostics, support, or historical migration data held by the Developer. For how in-app problem reports are kept and deleted, see “In-App Problem Reports” above.
For Promotion Program applications, including those not approved or withdrawn, the text, status, review result, and any reason for not approving are kept while the Promotion Program runs, to determine the interval and number of reapplications. Images are deleted 30 days after review ends (approved, not approved, or withdrawn). Referral codes, Referrer credential digests, referral reward ledger entries, balances, and withdrawal records are kept while the Promotion Program runs, to reconcile referral rewards, refunds, and withdrawals. You can contact [email protected] to delete this data, including application text and images; after deletion your referral code stops working, any unwithdrawn balance is forfeited, and any application under review is void. Records we must keep by law or for unsettled withdrawals and refunds may be deleted later.
Third-Party Platforms#
The App accesses third-party streaming platforms including Bilibili, Douyu, Huya, Douyin, Xiaohongshu, Bigo, Laixiu, Twitch, YY, TikTok, CHZZK, PandaTV, and SOOP. Saved login credentials are used only to request live streams, danmaku, or signed-in features from the corresponding platform on your behalf. Your use of those platforms is also subject to their terms and privacy policies.
Changes to This Policy#
We will announce material changes through an App update or on this website. Material changes affecting existing paid entitlements will be communicated separately in accordance with applicable law and approved legacy arrangements.
Contact#
For privacy questions, contact [email protected].
If you contact us to withdraw a referral reward, the payment details you provide in that email do not enter our systems. They are used only to complete that payout and are given to the payment channel used for it, and we delete the emails containing your payment details once the payout is done.