Why a Local App?

Many fitness apps run on an account and a central server: convenient for syncing your devices, but it also means a third-party company hosts your data, and the app becomes unusable without a connection β€” or if the service shuts down one day.

Kaivalya Trainer makes the opposite choice: everything runs in your browser, your data is stored locally, and nothing is ever sent to a server. This choice has a cost β€” no automatic sync or backup between devices β€” but that cost is covered by simple, manual solutions: see the How-to Guides for backup and sync.

JSON or Database: Which to Choose?

Two ways to export your data, for two different needs:

JSON exportDatabase export (SQLite)
ContentOne or more chosen data types (exercises, sessions…)Everything, no exceptions
Typical useShare a session, back up a subsetFull backup, migration to another device
On importMerge: conflicts resolved one by one, suffix if another userTotal replacement of existing data
File formatText file, readable, editable with careBinary file, never edit by hand

Concretely: a JSON file is a plain text file describing your exercises, combos, sessions, or collections in a structured, readable format. A SQLite file (.sqlite3 / .db) contains the app’s entire database; it can be opened with a specialized tool (DB Browser for SQLite, for example) but should never be edited by hand.

There’s a third way to get data out of the app: the HTML export of the home page (see How-to Guides). It’s also a data export, even though the format differs β€” except it’s one-way: an HTML file can’t be re-imported into Kaivalya Trainer. It isn’t meant for backup but for reading by someone else, typically a friend or a coach.

What Really Happens on Import

Importing a JSON file never deletes your existing data by surprise:

  • If it comes from you (same user ID): Kaivalya Trainer compares it with what you already have. For each item that already exists (same ID, or same title if it’s a different item), you choose to replace it or keep it, one by one or in bulk.
  • If it comes from another user: every imported title gets a short suffix you choose ("[JD]"), so it never gets confused with your own data. The suffix is remembered and reused if you import again from the same person. If the suffixed title conflicts with something already imported earlier (typically a new version of the same item, re-exported by the same person), you choose to replace it or keep it, exactly as with your own data.

Either way, a summary screen shows what will change before anything is applied.

By contrast, restoring a database (a .sqlite3 file) replaces everything, with no possible merge β€” that’s intentional: this mechanism is designed for full backup and restore, not selective sharing.

How the Timers Work (EMOM / AMRAP / TABATA)

The three timed combo types each follow their own logic:

  • EMOM (Every Minute On the Minute): a new exercise starts every minute. The duration you set is divided by the number of exercises in the combo to work out how many rounds to run β€” each exercise occupies a 60-second slot.
  • AMRAP (As Many Rounds As Possible): a single countdown runs for the whole set duration; you cycle through the exercises in a loop, doing as many rounds as possible.
  • TABATA: a strict alternation of work and rest phases, repeated a given number of times.

In all three cases, two different sounds guide you without having to watch the screen: a soft beep for intermediate cues, a louder BEEP for phase changes or time running out. For the minute-by-minute detail, see the Audio Cues section of the Reference.

Advancing between exercises or rounds is automatic for all three types β€” you don’t have to confirm anything yourself while the timer is running.

Why Pocket Mode? (GPS and the Locked Screen)

A dedicated running app lets you lock your phone and put it away. A web app can’t: Android only gives your position to a page while that page is on screen. Lock the phone and the clock keeps counting, the beeps keep coming β€” but no position arrives, and your run is saved as a time with no track. This is a browser limitation (Firefox has listed it as known since 2018, Chrome behaves the same), not a bug the app can fix. A 78-minute field test walk lost most of its track this way.

Pocket mode is the answer that stays within what a browser allows. Instead of letting the phone lock, the app keeps the screen on and covers it itself with a black screen. For the phone, the page is still on screen, so positions keep arriving. For you, it behaves like a lock screen: almost nothing lit, nothing triggered by a jostle in a pocket, and a 3-second press-and-hold to get out. Your headset buttons and the media notification keep pausing, skipping or going back underneath.

The trade-offs are deliberate:

  • The screen stays on. Black costs almost nothing on an OLED screen, but the backlight still draws power on other screens β€” turn the brightness down before you leave.
  • No buttons on the black screen. Anything tappable could be tapped by a pocket; every control is already on your headset and the notification.
  • It looks after itself. Leave it by accident and it covers the screen again after 20 seconds without a touch; it uncovers itself when a step needs you (typing in reps, the end of the session).

If you lock the phone anyway, the app keeps the rest alive (timers, sounds) and restarts location tracking when you unlock. The missing stretch is shown on the map as a gap, not as a straight line, and its distance is not counted: an honest hole is better than an invented distance.

Two other GPS choices follow the same logic:

  • A distance target never ends the step by itself. A phone’s position is only accurate to a few metres, often more; you tap Finish when you are actually there.
  • Elevation comes from a terrain model, not from the phone. A phone’s GPS altitude is much less precise than its position, and its jitter would add phantom climbing to a flat run. Climb and descent are computed after you finish, from IGN data in France and SRTM elsewhere.

The full details (settings, what is displayed, when it covers and uncovers) are in the Cardio Steps section of the Reference.

What About the Statistics?

The Statistics page has two halves, and they don’t have the same track record.

The Cardio half is used for real: the app’s author follows his walks and runs with it β€” distance and time totals, speed progression for one exercise across dates or across the intervals of a single session, climb and descent. It grew out of that use and will keep evolving with it. See Cardio Statistics in the Reference.

The Strength half (frequency, volume, per-exercise progression) is the one the author has the least personal feedback on β€” he doesn’t use it himself day to day. Those charts are a reasonable starting point, but if something is missing for you, it’s probably true for others too β€” your feedback is welcome.