Paid features, sync tiers and store release (design plan)

Status: future plan, not a decision. This explores how Jotry could be sold on the App Store and Google Play, and how that shapes sync. Agreed so far (see 05-decisions-and-open-questions.md): D-33 (hosted sync runs on Jotry’s own end-to-end encrypted server), D-34 (export and folder sync are never paid features), D-35 (hosted sync carries the full revision history; folder sync carries current notes only). Pricing, the business model and everything else below are open. Update 2026-10-08: D-45 makes hosted sync personal for now, on the owner’s backend infrastructure; whether that runs an own Ktor server or a self-hosted Supabase is still open. Update 2026-10-09: the billing model is now agreed: D-52 (entitlement belongs to the sync group; several stores can contribute; latest expiry wins), D-53 (a free app with a sync subscription bought in the stores; the purchase creates the group), D-54 (purchase bound to the group by the store’s account token), D-56 (lapsed groups are read-only and kept for a year) and D-58 (pluggable store verifier; promo entitlements possible). Prices, trial length and the rest remain open. Related plans: cloud-sync-and-e2ee.md (server, crypto, keys) and folder-sync.md (folder sync and the file format).

Starting points

• Folder sync is effectively free multi-device sync. Point Jotry at an iCloud Drive or Syncthing folder on two devices and they sync. A paywall on folder sync would not protect much revenue, and would break the “your data stays yours” promise in the README. Obsidian is in the same position (free app, paid Sync competing with free iCloud and git) and still sells Sync, because people pay for “it just works”, history and encryption, not for the bare ability to move files.
• What people pay for is convenience and safety: one switch, no folder setup, full history on every device, end-to-end encryption, and it works between an iPhone and an Android phone.
• Using the app should stay simple. Power features exist but don’t get in the way of people who never need them.

Proposed tiers

Why a subscription for sync: it has an ongoing cost (server, storage, support), and stores and users both understand “service = subscription”. A one-time “Pro” purchase only makes sense for local-only extras, and there are none planned.

Why not a paid app: an upfront price hurts discovery, and the free app is the marketing. People who try it and want sync convert; people who don’t still recommend it.

Principles to record (proposed)

1. Export is never paywalled. (Recorded as D-34, together with folder sync.)
2. Local features never need an account or a network connection.
3. The paid check lives in one place: the hosted-sync transport. The rest of the app never asks “is this user paying?”
4. Cancelling never locks anyone out of their notes. If a subscription ends, sync stops; every device keeps its notes and history, and export still works.

Sync architecture across tiers

One sync core, several transports (see doc 03’s destination capability contract):

                      shared sync core
   (identity map, reconcile, revisions, conflicts, link translation)
            |                         |                        |
   folder transport           hosted transport          (later: WebDAV, git…)
   free, current notes        paid, full history
   Android + desktop          all platforms

• Hosted sync moves the revision graph (records, as in cloud-sync-and-e2ee.md section 2), not files. That is the honest difference between the tiers (D-35).
• The entitlement check is one gate in front of the hosted transport.

Hosted sync: own end-to-end server (D-33)

The backend is Jotry’s own server (the Ktor server/ module), not a managed backend such as Supabase or Firebase and not the platform stores (CloudKit, Google Drive app data). Platform stores can’t sync an iPhone with an Android phone; a managed backend adds a third party that sees metadata. The cost: we run, secure and pay for a server.

The server is a dumb store for encrypted records and only sees ciphertext; the design is in cloud-sync-and-e2ee.md sections 3–5.

Accounts or no accounts

The README promises “no account”. Hosted sync needs some identity, so two options:

Chosen: A (D-45), with the store purchase tied to the group (D-52 to D-54).

Store rules and licensing

(Store policies change; check the current App Store Review Guidelines and Google Play policies before building.)

• In-app purchase: unlocking features inside the app generally has to use Apple’s and Google’s billing. Some regions now allow outside payment links or other billing under conditions; treat that as optional, not as the plan.
• No downloaded code: Apple does not allow apps to download and run new code. Extensions (folder sync, hosted sync, future ones) are built into the app, as doc 03 already assumes.
• Cross-platform licensing (D-52 to D-54): a store purchase is tied to an Apple ID or a Google account, so buying on iPhone does not unlock Android by itself. The client sends the store’s signed transaction to the server together with the group it belongs to; the account token inside the transaction names that group, so a leaked receipt cannot be claimed by another group. The server verifies it and attaches it to the group as an entitlement, and every device in the group syncs. A group can hold entitlements from several stores, and the latest expiry wins.
• Switching platforms: a new iPhone joins the group by QR from the old Android phone and needs no purchase; billing stays with Google until the user cancels there. To move billing, they buy the Apple subscription for the same group; the group then has two entitlements and the later expiry applies. The app shows which store bills the group and links to that store’s subscription page. The server cannot cancel across stores.
• Apple’s multiplatform rule: Apple lets an app grant access to a service bought elsewhere only if the same purchase is also offered in the iOS app (guideline 3.1.3(b) as we read it; re-check the current wording before submission).
• Lost phone, same store account: the recovery key restores the group (D-55). Restoring the purchase on the new phone reattaches a lapsed group within the year it is kept (D-56). There is no cross-store proof of ownership: Apple cannot verify a Google purchase or the reverse.
• Before the store accounts exist: the server’s entitlement check is a pluggable verifier (D-58). Sync, enrollment and recovery are built against a development verifier; Apple’s local StoreKit testing and recorded signed transactions cover the Apple verifier. Sandbox purchases, TestFlight and Play Billing need paid developer accounts; Google may also require a closed test with a minimum number of testers before production, so open that account early.
• Family sharing, refunds, grace periods, billing retry: the server must handle the store notifications for each platform.
• Privacy disclosures: hosted sync changes the App Store privacy label and the Google Play data safety form (encrypted content, device identifiers, purchase records). Decide what we collect before writing them.
• README promises to update when sync ships: “no Jotry cloud service” becomes “an optional, end-to-end encrypted sync service; no account; we can’t read your notes”.

Simple by default, power when wanted

Folder sync is strongest on desktop (file watchers, background running, Obsidian/VS Code/git on the same machine), works acceptably on Android, and is fragile on iOS. Proposal: Android and desktop get folder sync; iOS gets hosted sync, and folder sync only as a manual “Sync now” if at all (see folder-sync.md Q8).

A desktop app is a separate product to build and support (D-07 keeps it a later phase). The repo’s webApp is not a substitute: a browser can’t keep a folder in sync.

Formats become a contract at release

Once people have folders and exports in the wild, the file format is something other apps and users depend on. Decide these before the first public release:

• relative links in exported files (D-36, decided)
• file names and the front-matter default (folder-sync.md Q1)
• a format version in the managed-folder marker and in EXPORT-INFO.txt

The hosted-sync record format is versioned from the first implementation, as doc 03 already requires.

Suggested order

1. Export: relative links (D-36) and human file names. Small; builds the shared file-format code.
2. Release 1 ships with the export format settled.
3. Sync core (identity map, reconcile, conflicts), then Android folder sync (free; D-06).
4. Server, crypto, QR pairing, recovery key, then hosted sync on Android and iOS (paid).
5. Store billing and server-side receipt checks, tied to the sync group.
6. Desktop app with folder sync and hosted sync.

Open questions