Yonder Privacy Policy

This page and the support page were both verified sentence by sentence against the product's current source code on September 5, 2026. "Final" does not mean "will never change" — this text only guarantees that it matched the code at the moment it was checked, and it will be updated when the code or Apple's privacy questionnaire changes.

1. Who this policy applies to

This policy applies to the Yonder iPhone app and its companion Apple Watch app (together, "the App"). The App is a tool that helps you keep the 20-20-20 eye-rest habit. It does not provide medical diagnosis and should not be treated as medical advice.

2. The short version

The App collects none of your data, and we run no servers of our own. There is no account system, and no third-party analytics, advertising, or crash-reporting SDK. The cycle state, personalized settings, and daily count you generate in the App all stay on your own device.

But "we have no servers" is not the same as "this app never goes online," and those two things have to be stated separately. Precisely:

• The App itself contains no network request code of its own. As of this writing, searching the Swift sources of all four shipping targets for URLSession, URLRequest, and NWConnection returns zero hits, and Core/Package.swift declares no third-party dependencies.
• Everything it exchanges with the outside world happens inside Apple's system frameworks, not through any channel of ours:

How Apple handles information that passes through StoreKit is governed by Apple's own privacy policy.

The privacy manifest submitted to Apple alongside the App, PrivacyInfo.xcprivacy, declares NSPrivacyTracking = false and an empty array of collected data types — that says "we do not collect and do not track," not "no network traffic is ever produced."

3. What we do not collect

The App requires no account registration, so it will not — and has no channel to — collect:

• Your name, email address, or phone number
• Login credentials (passwords, verification codes, and the like)
• Any form of unique user identifier — the App builds no user system of its own and generates no custom user ID, device fingerprint, or advertising identifier

We operate no servers of our own. No product feature depends on any backend of ours, and therefore:

• There is no such thing as "our server received your data"
• We do not share or sell your data to any third party, nor use it for advertising
• The App contains no advertising and integrates no advertising SDK, analytics SDK, or crash-reporting SDK

The one exception is in-app purchase: looking up the Pro product, buying it, and restoring purchases all go through Apple's App Store servers (see sections 2 and 4). That channel is provided and handled by Apple; we can neither see nor store your payment information.

4. Pro purchase and payment information

The App offers one "Pro, one-time purchase" in-app purchase item, which unlocks four personalized settings: work duration, look-away duration, reminder sound, and snooze duration.

• The purchase flow is handled entirely by Apple StoreKit. The App completes purchases through Apple's official APIs (Product.products to look up the product, product.purchase to start a purchase) and never touches or stores your card number, billing address, or any other payment information.
• These steps do communicate with Apple's App Store servers — the price and the purchase result both come from Apple. Your current entitlement is not judged by some boolean flag the App saved for itself, but by the verified transaction record the system maintains on-device (see the next point). No server of ours takes part in this chain, but that does not mean the chain is offline; both halves of that sentence have to be said.
• Your purchase records, receipts, and refunds are all managed by Apple. The only basis on which the App decides "do you have Pro" is the verified transaction record supplied by the system (StoreKit) (Transaction.currentEntitlements). The App does not keep its own "purchased" credential, and has nowhere to upload one. (That record is maintained on-device by the system, so reading it does not necessarily require a network connection; what does require one is the interaction with Apple described above.)
• The "Restore Purchases" entry point is inside the App: Settings → "About" → open the purchase page → "Restore Purchases" at the bottom of that page. The label on that row in the About section changes with state: before purchase it reads "Unlock Pro"; once you own Pro it shows the Pro product name instead. Restoring calls AppStore.sync() so the system re-checks the purchase records under your Apple Account — this step also requires a network connection, and may ask you to sign in to your Apple Account again.
• For how Apple handles your payment information, please see Apple's privacy policy. Apple's own documentation on these two things: In-App Purchase, AppStore.sync()

The core reminder capability is fully available in the free version and is not a paid feature — the standard 20-minute work / 20-second look-away cycle and the default alert cost nothing. AlarmKit persistent alerts cost nothing either, but they require iOS 26.0 or later plus the Alarms permission; when those conditions are not met the App automatically falls back to an ordinary system notification (see the section above). Pro unlocks only the four personalized settings listed above. Whether a reminder actually goes off on time also depends on your system version, permissions, the state of your device and system settings such as Silent Mode and Focus; the App does not promise that every reminder will sound, and it does not force its way through Silent Mode or Focus.

5. System permissions

The App requests the following system permissions only when they are needed, solely to deliver reminders, never to collect personal information.

When permissions are requested: the App does not fire a chain of permission dialogs the first time you open it. After you finish the intro, nothing is requested until the first time you actually tap "Start"; and whether you allow or deny, that "Start" still runs as normal. Denying does not swallow your action, and you will not be asked a second time.

The two items below are two independent system authorizations, not one switch: notification permission is governed by iOS's "Notifications" settings, while AlarmKit permission is a separate authorization introduced in iOS 26. Allowing one and denying the other is entirely possible; the App picks which path to remind you through based on what it actually has.

1. Notification permission (UNUserNotificationCenter)

Used to remind you when a work interval is up and when a look-away break ends, and as the fallback reminder path when AlarmKit below is unavailable. Notification content is only "time for a break"-style prompts and action buttons; it contains no personal information and is not uploaded anywhere.

2. AlarmKit permission (NSAlarmKitUsageDescription)

Used to deliver a system-level alert that is more definite and more persistent than an ordinary notification (closer to an alarm clock in feel). The permission text the App shows you reads:

"Used to send you a persistent reminder at your scheduled time, prompting you to look into the distance."

AlarmKit requires iOS 26.0 or later. On system versions below iOS 26, or if you deny the AlarmKit authorization, the App automatically falls back to ordinary system notifications — not getting AlarmKit permission does not leave you without reminders.

The App does not request location, contacts, photos, microphone, camera, health data, or tracking permission of any kind.

6. Data sync between Apple Watch and iPhone

If you install and pair the Apple Watch version of Yonder, the two devices sync the following through Apple's official WatchConnectivity framework:

• A read-only projection of the current cycle state: whether you are in a work phase or a look-away phase, the absolute end time of the current round, and the cycle identifier and revision number;
• A small number of control commands: for example tapping "Start looking away," "Snooze," or "End session" on the watch, plus one launch record from the watch app (launch time, cumulative launch count, and the watch app's version and build number). That launch record is stored on the Apple Watch itself and merely rides along with messages to the iPhone so the diagnostics page can show whether the watch app has actually run; once the iPhone receives it, it is kept in memory only and never written to the iPhone's storage.

About this channel:

• It is a direct local link between the two devices (Apple's system-level iPhone-Watch pairing channel). It passes through neither our servers (we have none) nor Apple's servers — this channel is strictly a matter between your two devices.
• What is synced is limited to the cycle state and control commands above, and contains no identity information.
• Whether the alert ultimately appears on iPhone or on Apple Watch is decided by iOS. The App neither controls that nor makes any promise about it.

7. What the App stores on your device

The list below was verified item by item on September 5, 2026 against the actual read and write sites in the code (not merely by searching for key names). Everything is saved in UserDefaults on the device itself (the local app settings store provided by iOS/watchOS). The developer does not receive any of this data, and the app itself never uploads it to any server and never syncs it to iCloud or any cloud account on its own.

About system backups. The persisted settings listed below may be included in a system backup, according to your own system settings and Apple's device / iCloud backup mechanisms. That is platform-level behaviour of iOS / watchOS, which you turn on or off yourself in the system Settings app; the app neither controls it nor can read such a backup, and it receives no data as a result of it. This does not contradict the table in section 2: the only network traffic the app itself initiates is still StoreKit, which talks to Apple's App Store servers — "the app uploading your data on its own" (which does not happen) and "the system backing up the whole device according to your settings" are two entirely different things.

"Which device is it on" is a point that gets misread, so it gets its own column: the data on your iPhone and the data on your Apple Watch are two separate sets, each living on its own device. There is no shared cross-device pool.

About the difference between the "authoritative copy" and the "projection" (today's completed count takes two rows above; that is not a duplicate): the copy that actually counts as the truth for "how many breaks you took today" lives in the main app's own UserDefaults. The one in the shared container is a derived, read-only projection written specifically for the widget to read. The reason for splitting them is practical: under some signing configurations the App Group may be unavailable, and when that happens you should not also lose the count inside your own app. The only thing that should be lost is whether the widget can still show it.

About the App Group shared container: the main app and the "today's progress" widget belong to the same App Group of this App (group.com.adrain.tiaoyixia); the main app writes the projection above into it and the widget reads it. That container is shared only on your iPhone and only among these components of this App. Other apps cannot read it, and nothing outside the group is ever written to. This is declared to Apple in the submitted privacy manifest, as required, under the two UserDefaults reason codes CA92.1 and 1C8F.1. The Apple Watch does not take part in this shared container — the watch is a different device, and the two ends exchange messages over WatchConnectivity rather than sharing one block of storage.

The Lock Screen Live Activity and the Dynamic Island take a different path and do not go through this shared container (do not conflate these two things):

Both paths happen only on your device and involve no server at all. They are written separately only so that the "who reads what" column in the table above is accurate — not to suggest a second place where data is retained.

About development and debugging features: developer options, the simulated-purchase panel, the short-cycle test mode, and other internal-development-only features are not compiled into release builds and will not be present in the App you install from the App Store. This has been verified item by item against the signed release build product (the counts of the relevant entries in both the binary symbols and the string resources of all four languages are 0); it is not "hidden at runtime."

8. No account — so how do you clear local data?

Because the App requires no account registration, there is no "request account deletion" process.

The App currently offers no in-app "clear local data" button; the way to clear it is to delete the App. Because the data on your iPhone and on your Apple Watch are two separate sets (see the table above), there are three things to be clear about:

1. Delete Yonder from your iPhone — iOS clears that app's local storage on this iPhone, including everything marked "iPhone" in the table above, as well as the App Group shared container.
2. The Apple Watch copy goes with the watch app — the two items marked "Apple Watch" above (the launch record and the cached cycle-state projection) live on the watch itself. They are removed along with the watch app. When you delete from the iPhone, the system usually removes the companion app on the paired watch too, but if you had previously chosen to keep it in the Watch app, you will need to delete it on the watch as well. Go by what you actually see on your devices; do not assume that deleting one end necessarily cleared both.
3. A purchased Pro is unaffected, and cannot be deleted — the purchase record is managed by Apple and lives under your Apple Account, outside anything we can reach. After reinstalling, tap "Restore Purchases" on the purchase page to regain the entitlement. Conversely, deleting the App does not revoke or refund that purchase.

Also: because we have never collected any of your data and run no servers of our own, there is no remote copy for us to delete on your behalf. (Data on Apple's side related to your purchase record is handled by Apple under its own privacy policy and does not pass through us.)

9. Children's privacy

The App collects no personal information from any user, regardless of age. It has no accounts, no social features, no user-generated content, and no advertising, and it performs no tracking of any kind, so there is no data collection directed at children.

10. Changes to this policy

If this policy is updated, we will update the "Last updated" date on this page and note it in the App's release notes. Because the App has no account system, we cannot notify users individually; please treat the current contents of this page as authoritative.

11. Contact

If you have any questions about this policy, you can reach us at:

Email: safferuk@gmail.com

12. How this maps to the App Store Privacy Nutrition Label

App Store Connect requires the "App Privacy" questionnaire to be filled in before review. Based on the facts verified above, the correct answers for this App are:

• Data collection: Data Not Collected — no accounts, no third-party SDKs, and we ourselves neither receive nor store any user data. Note that the reasoning has to be stated correctly: this answer cannot be justified by claiming "the app never goes online," because in-app purchase goes through Apple's App Store servers (see sections 2 and 4). The correct reasoning is that Apple handles that channel and the developer side neither receives nor stores any data linkable to you; Apple's questionnaire itself also does not require Apple's own in-app-purchase handling to be counted as developer data collection.
• Used for tracking: No — consistent with NSPrivacyTracking = false in the PrivacyInfo.xcprivacy submitted with the build.

This questionnaire has to be filled in by the project owner in App Store Connect; this page does not replace that step. Before submitting, verify it once more against the exact build being submitted, using Apple's questionnaire options as they stand at that time. Reference: Apple App Store Connect: Manage app privacy