Cloud and Privacy

Outliners and note-taking apps store work notes, unfinished ideas, and personal records over time. For tools like these, where data is stored and who can access it matters.

Kosshi stores data locally on each device as a SQLite database. For syncing between devices, it uses Apple's CloudKit, and sync data is stored in your iCloud account. CloudKit does not give the developer server-side access to individual users' private records.

Sync Services and Data Storage

There are several patterns for how tools sync data across devices.

Stored on the service's servers. Notion and Workflowy use this approach. Data is stored on servers operated by the service provider, and client apps or browsers retrieve it for display. This enables access from any device and supports collaborative editing.

Stored as local files. Bike uses this approach. Data exists as files on the device, with no sync or sync delegated to a file-syncing service. The user has full control over data management.

End-to-end encrypted (E2EE). Standard Notes uses this approach. Data is stored on servers, but it is encrypted on the client before upload, so the server cannot read its contents. This provides strong privacy protection, but the server cannot run features such as full-text search or version comparison on plaintext data.

Which approach fits depends on the tool's purpose and how it is used.

Kosshi stores data locally on each device and uses Apple's CloudKit for sync. CloudKit is the same iCloud sync infrastructure used by Apple's Notes¹ and Reminders². If you sync notes via iCloud, you are already using the same infrastructure as Kosshi.

What It Means to Store Data on a Service's Servers

Most productivity tools store data on servers operated by the service provider.

This approach has practical implications:

• The service provider is technically able to access the data.
• If the service shuts down, data continuity depends on export options.
• Changes to terms of service can affect how data is handled.

For personal use, relevant factors include the provider's security practices, terms of service, and export options.

For organizations, the situation can be different. When handling information about clients or customers, the storage location and third-party access are subject to security audits and compliance requirements. There are situations where you need to explain where data is stored and who can access it.

About End-to-End Encryption

E2EE prevents the server from reading data contents. Data is encrypted on the client, and only the encrypted version is stored on the server. This technically prevents the service provider from accessing the contents.

E2EE keeps encryption keys and plaintext data on the client:

• Depending on the design, users may need to protect a password or recovery key. Losing it can make recovery impossible.
• A server cannot process plaintext contents, so features such as search, version comparison, and recovery need to run on the client or use a design compatible with encrypted data.

E2EE still stores data on a server — just encrypted. It is not the same as keeping data off the server entirely. Which is more appropriate depends on what you are trying to protect.

Why Kosshi Uses CloudKit

Kosshi uses CloudKit's "private database" for sync. Data is stored in storage tied to the user's iCloud account, and Apple does not provide developers with server-side access to view individual users' records in private databases³.

This architecture has several advantages.

Data always lives on your device. Outline data is stored locally on each device, so the app works fully offline. CloudKit is used to sync changes between devices — the primary storage is always the user's device.

Sync data stays in your iCloud account. Data stored in the cloud for sync purposes goes into the user's iCloud container. It is managed as part of Apple's iCloud storage, not on the developer's servers.

No account creation required. Sync uses your Apple Account. There is no need to create a new account or share an email address and password with the developer.

Built on Apple's infrastructure. Data is stored in Apple's data centers and encrypted both in transit and at rest.

No developer-operated servers. The developer does not operate a server that stores outline data. CloudKit handles synchronization instead.

Considerations for Organizations

For personal notes, any of these approaches works fine. For business use, more careful evaluation of data handling is required.

With server-based storage, you need to assess the service provider's security posture. SOC 2 reports, data center locations, employee access controls, and incident response procedures may all be subject to audit.

With CloudKit, data is stored on Apple's iCloud infrastructure. Apple holds SOC 2, ISO 27001, and other certifications, and supports iCloud account management through Apple Business Manager. Not needing to add the app developer's servers to the audit scope can be a relevant factor for organizations.

However, CloudKit has its own constraints. It is limited to the Apple ecosystem, does not support collaborative editing, and lacks granular access controls for administrators. Depending on organizational requirements, a server-based tool may be a better fit.

Summary

The sync approach determines where data resides and who manages it.

By using CloudKit, Kosshi achieves cross-device sync while keeping data under the user's control.

Where your data is stored is one factor when choosing a tool.