Zapp Data Formats

A core rule of the Zapp philosophy is Zero Lock-In: the user must be able to export their data into open, human-readable formats at any time. Internal storage may be optimized for speed (IndexedDB, Hive, SQLite WASM), but the exit door must be universal.

Below is a categorised reference of open formats a Zapp ecosystem can share, plus when to use each.

General state and structured data

The bread and butter for app state, preferences, and saved configurations.

Databases and complex queries

When JSON gets too slow or memory-heavy for large local datasets.

A note on internal-only formats: Hive (for Flutter) is fast but binary and Flutter-specific. Use it for performance internally, but always provide a 1-click export to JSON or SQLite for portability.

Knowledge, writing, and documents

For note-taking, blogging, task management.

Location, health, and fitness

For route data, workouts, and physical tracking.

See Indoor Virtual Run Data Sources for how to source GPX route data for treadmill / smart-trainer apps.

Personal information management

Graphics and media

The export-by-default rule

A useful rule to add to any Zapp design checklist:

Internal storage can be optimized. The export must be universal.

If a Zapp uses Hive or IndexedDB internally for performance, it must still expose a 1-click export to JSON (or a more specific open format) so users can move their data elsewhere. A Zapp ecosystem becomes truly useful only when data flows freely between apps — drag the JSON out of one and drop it into another.

A loose mapping of data type to format

Data type Default format When to upgrade
App preferences JSON TOML if shared with humans
Tabular records CSV SQLite for large queryable data
Notes / writing Markdown OPML for outlines, EPUB for compiled reads
GPS routes GPX TCX/FIT for workouts with biometrics
Calendar events iCalendar
Contacts vCard
Graphics SVG
Configuration JSON / YAML TOML for human-edited files

See also