When you save a task in Pinwork, it goes into a local database on the device first. When iCloud is available, Apple’s CloudKit system synchronizes that data through the private iCloud database associated with the Apple Account on the device. Pinwork does not require a Pinwork account, and no separate Pinwork task server holds the database.
That is a local-first model, not a device-only model. A synced task leaves the physical device and passes through Apple’s iCloud infrastructure so it can reach another device. What matters for privacy is who provides that sync path and where the records live, not a claim that the data never leaves the phone.
The path of one task
Consider a task created on an iPhone while it has no network connection. The task, its When and Deadline values, and its other structure are saved to the iPhone’s local Core Data store. It is available on that iPhone immediately, even though an iPad or Mac cannot see it yet.
When the iPhone reconnects and iCloud is available, Core Data exports the pending change to CloudKit. Apple’s sync system then makes the record available to the other devices on its own schedule. When another device imports the change, Pinwork refreshes its local views and reloads open task, project, and tag screens from that device’s store.
The result is a local database on each device, with iCloud carrying changes between them:
- Pinwork saves the change on the current device.
- Core Data exports it to the app’s private CloudKit scope.
- Apple’s system delivers it to another device.
- That device imports it into its own local store.
- Pinwork refreshes what is visible from the updated store.
This sequence explains why a device can remain usable before every change from another device has arrived. It also explains why sync is automatic but not instant on demand. The iCloud sync guide documents the status messages and the full set of records that follow this route.
What private iCloud means
The CloudKit container belongs to the app, while the records are stored in the private iCloud scope for the Apple Account on the device. Pinwork does not receive the task database on a company task-sync server. There is also no Pinwork login whose job is to own or synchronize those tasks.
Private iCloud does not mean that every byte stays on one device. Synchronizing an iPhone with an iPad or Mac requires the data to move through Apple’s iCloud infrastructure. Apple controls the CloudKit service and the timing of record downloads.
It also does not justify a blanket encryption claim for every task field. The documented model is private CloudKit scope, local storage, and the absence of a separate Pinwork task server. It does not make a field-by-field encryption guarantee.
This is the practical trust boundary: Pinwork keeps a local store and uses the Apple Account already present on the device for private iCloud sync. Apple supplies the cloud infrastructure. The broader sync and privacy guide describes this boundary, including the smaller local data sets used by system features.
What travels through the main sync store
The main CloudKit-backed Core Data store includes more than task titles. It synchronizes tasks, projects, tags, checklist items, status, When and Deadline values, estimates, recurrence rules, project and tag relationships, archive state, ordering, and app metadata.
That matters because a task should arrive as the same structured object, not as a line of plain text. A task planned for Tuesday with a Friday Deadline should retain both dates. Its checklist, project, tags, estimate, and recurrence rule should follow it as parts of the same database.
Selected preferences use a separate iCloud Key-Value Storage path. Most preferences remain local device settings. Device-specific flags, Spotlight controls, deep-link state, and widget settings can also stay local or use the shared App Group container instead of the main task store.
These distinctions prevent every system surface from becoming another full copy of the database with its own sync model.
What works without a network connection
The current device keeps using its local store while offline. Normal task work continues: creating and editing tasks, completing and reopening them, rescheduling, changing status, adding notes and checklist items, organizing with projects and tags, and archiving or deleting tasks.
Only the cross-device part waits. An offline change cannot appear elsewhere until the current device can export it through iCloud. After connectivity returns, other devices import the change on Apple’s schedule.
The trade-off is straightforward. Local storage keeps the current device useful without a connection, but local-first does not make multiple offline copies agree immediately. The offline behavior guide covers the actions that remain available and the conditions that can delay export.
Sync can be delayed, and conflicts can happen
CloudKit can pause when iCloud is signed out, unavailable, not authenticated, out of quota, rate limited, or temporarily busy. Settings shows a Sync section with account status, recent Cloud activity, the last checked time, and the last error. Status labels can include Ready, Checking, Recent activity, or Needs attention.
Check Sync Status saves pending local changes, refreshes data that the device has already imported, and updates the visible status. It cannot force Apple to download a new CloudKit record immediately. Pressing it repeatedly does not turn Apple’s scheduled import into an on-demand transfer.
Editing the same task on two devices before synchronization finishes creates another honest limitation. Pinwork does not present a field-by-field conflict resolver. Core Data and CloudKit merge incoming records, and Pinwork reloads the result from the local store. If the result is unexpected, the documented recovery is to edit the task again on the device showing the current data, or use Undo or Archive restore where available.
Widgets, extensions, Spotlight, and Apple Watch use smaller local views
Widgets, Shortcuts, the Share Extension, Focus Filters, and Live Activity controls need data outside the main app. They use lightweight payloads and action queues in a shared App Group container, not a second full task database.
A widget snapshot can contain a Today summary and task rows with details such as title, When, Deadline, priority, overdue state, and completion state. Other small indexes and caches support intents and sharing. Because these surfaces have less access to the full app runtime, they can look stale while offline or while the device is locked. Opening Pinwork when the device is online lets the main app refresh the shared snapshot.
Active tasks can also be indexed into Spotlight on the device. That indexing is on by default, remains local to the device, and can be disabled, rebuilt, or cleared in Settings. Done and Canceled tasks are removed from the index.
Apple Watch has its own local Watch store, which synchronizes task data through the same private iCloud path, with best-effort transfers between the Watch and a nearby iPhone on top. Access state still arrives through the companion iPhone. Data already on the Watch remains available for review, and sync can lag while iCloud has not yet delivered the latest records to the Watch.
Task sync and purchase access are separate
No Pinwork task account is required, but paid access still needs an account system. The App Store and StoreKit handle purchases and entitlement state through the Apple Account. One plan, as subscription access or lifetime access, covers supported Apple devices signed in with the same App Store Apple Account.
Restoring a purchase asks the App Store to synchronize and refresh that entitlement. It does not restore tasks through StoreKit. Purchase restoration and private iCloud task synchronization are separate mechanisms provided by Apple.
If subscription access enters billing retry, expires, or is revoked, Pinwork can enter read-only recovery. Tasks stay visible and their details remain inspectable, but creating, editing, completing, scheduling, and destructive actions are blocked until access is restored. A billing grace period still counts as active access, so task changes remain available during that period. The account and access guide explains these states without treating an access problem as data deletion.
The phrase “in the cloud” is too vague to explain where a task goes. Pinwork’s route is more specific: local database first, private iCloud sync through Apple, local copies on the other devices, and a separate StoreKit path for access.
For the account side of that distinction, continue with using a to-do app without another account. For the separate question of app analytics and tracking, read what your to-do app tracks.