From upload to the store

Publishing takes an app from your machine to the store. The developer commands below run in the project's folder and act on the app and the version that ledable.json names: its app_id and its version.

Before you start

You publish with your LEDABLE account; there is nothing else to register. Sign in once, as Install and sign in shows:

ledable auth login you@example.com

The store shows your apps under your account's nickname. An account created with an email address takes its nickname from the part before the @, so check it before your first submission: auth whoami prints it. To change it, open the LEDABLE phone app and go to Profile, then Nickname. A nickname is 1 to 32 letters, digits, dashes and underscores, no two accounts share one, and a change shows on all your apps at once.

ledable auth whoami

Claim the app id

An app id is the app's name in the store's addresses, and every app has its own. Claim yours before your first upload:

ledable developer create

developer create claims the app_id in ledable.json for your account: lowercase letters, digits and dashes, starting with a letter or a digit, at most 64 characters. Ids are first come, first served; one that is taken is refused with App id is taken. An id stays yours and an app never changes it, so choose one you can keep.

Upload a version

ledable developer upload

developer upload type-checks and builds the project as developer build does, and sends the version to the store. The store checks it before anything is published and prints the outcome of every check: what they are and how to fix a failure is in Publishing checks.

A version that passes is published and never changes again. Anything that changes what the app draws or how it is listed needs a new version, higher than every version that passed before. A version that fails is not published, so you can fix it and upload the same number again.

developer versions lists every upload, newest first, with the outcome of each check.

Try it and share it

Before anything is listed, you and the people you choose can install the version on a display:

ledable developer test
ledable developer share

developer test puts the version ledable.json names behind the app's share link, and developer share prints the link. Share links explains what people see when they open it.

Submit it for review

ledable developer submit

developer submit asks for the version ledable.json names to be listed. The version must have passed every check and be newer than the version the store lists now, and an app has one submission waiting at a time. A reviewer then approves or rejects it, following the review guidelines.

developer status shows where the app stands: the listed and test versions, the submission that is waiting, the latest decision with the reviewer's note, and the failed checks of the latest upload if it failed.

{
  "app": {
    "app_id": "gitlab-todos",
    "official": false,
    "test_version": "1.0.0",
    "store_version": null,
    "unlisted_reason": null
  },
  "pending": {
    "id": 41,
    "version": "1.0.0",
    "state": "pending",
    "note": "",
    "created_at": 1791216000,
    "decided_at": null
  },
  "last_decision": null,
  "last_failure": null
}

Once the submission is approved, the store lists the version: people find the app, install it, and those who have an older version are offered the update. If it is rejected, the note says why; fix it, upload a new version and submit that one.

How a version moves

Each upload creates one version, in one of two states:

1. failed: a check failed. Nothing was published, and the same version number can be uploaded again.
2. ready: every check passed. The version is published for good and can be put behind the share link, installed by its number, and submitted.

Each submission of a ready version goes through these states:

1. pending: waiting for review. developer withdraw takes it back, and it becomes withdrawn.
2. approved: the store lists this version.
3. rejected: the version stays as it was, and the note says why.

The app itself is listed from its first approval until it is unlisted, by you with developer unlist, or by LEDABLE with a reason that developer status shows as unlisted_reason. A later approved submission lists it again. Updating your app covers new versions, withdrawing and unlisting.