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. The developer cannot access its contents.

This article explains the different approaches cloud-based tools take for storing data, and why Kosshi chose this architecture.

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 as discussed below, it involves technical constraints, and few services have adopted it in practice.

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, choosing a trustworthy service is usually sufficient. Most services implement standard security measures.

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 provides strong confidentiality, but comes with constraints:

• Key management becomes the user's responsibility. Losing the key means losing the data.
• The server cannot process data contents. Full-text search, version history comparison, and data recovery from corruption are all limited.

Because of these constraints, few services have fully implemented E2EE in practice.

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 an API for developers to view individual users' data 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.

The user owns the sync data. 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. When "Advanced Data Protection" is enabled for iCloud, end-to-end encryption is applied to CloudKit data as well².

No developer-operated servers. Because the developer does not maintain servers that hold user data, there is no server to breach. This is also what makes the pay-once model possible. Without ongoing server costs, the service can continue without a subscription.

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.