Publishing: the link, the QR code and le.store

Publishing an app on le.codes means getting one link that opens it for anyone: natively on a phone with the le.codes app, in the browser or via an install without it. And so people can find the app without your link, it gets a page in le.store — the catalogue of apps, games and libraries built on le.codes. Both steps below.

Press Publish in the editor. The project compiles and gets a link of the form le.codes/qr/<code> plus a QR code carrying the same link. What happens on opening depends on who opened it:

  • a phone with the le.codes app — the app launches natively, with the camera, AR and everything the device can do;
  • a phone without it — the page offers the App Store / Google Play install, and if browser launch is enabled in the publishing settings, runs the app right in the browser;
  • a computer — a page with the QR code and the app running in a phone frame.

The link is permanent: every subsequent publish updates the app for everyone who opened it — the host fetches the new version on launch. Unpublish any time from the same dialog; the channel settings are kept.

Note

The first publish asks for confirmation — after it, anyone with the link can see the project. Who may fork the project and read its code is a separate setting under access.

Publishing from the CLI

The same result from the terminal, for a project connected to the platform:

bash
lecodes push --publish -m "v1.2"     # a checkpoint plus a publish in one command
lecodes link --push --publish        # a local project: connect, push, publish

The link and QR code are the ones the editor issues. More on syncing in the CLI guide. Your own binary under your own name in the App Store and Google Play is a separate path, covered in App Store & Google Play.

A page in le.store

le.store is the storefront of everything built on le.codes. A project published there gets its own page: description, screenshots, versions, a run-in-browser button and a QR code for the phone, a source-code tab and a Fork button — when you open the code — and discussions where readers ask and the author answers. Apps land in categories, search and the "most run" / "most forked" sorts, and the best ones in the picks of the week. Every author has a page listing their projects.

The store is deliberately simple: no ratings, no ads, no prices. Publishing is free.

How to publish:

  1. Set a username in the le.codes settings — it becomes the address of your store page: store.le.codes/name.
  2. Open store.le.codes/publish and sign in with le.codes. The store asks for access to your projects — an access token named "LeStore" is created, revocable in the settings at any time.
  3. Pick a project from the list. Already published ones show "Update".
  4. Fill in the listing: category (app, game or library), name, tagline, a Markdown description, topics, an icon, screenshots with captions.
  5. Decide whether to show the code: open source gives a Code tab and a Fork button, demo only hides the code and disallows forks. Libraries are always open source — they cannot be added otherwise.
  6. Set a version and release notes — the first publish suggests 1.0.0.
  7. Press Publish. The store builds the project through the platform, keeps a snapshot of this version and opens the page.

An update is the same path with the fields prefilled: every publish adds a version, older ones stay in the history. A project can be delisted from your author page; the built version is kept.

What helps a project in the store

  • Screenshots and one honest tagline — the catalogue card is seen before the page.
  • Open source: forks are counted and lift the project in the sorts, and readers with the code ask concrete questions in the discussions.
  • Versions with notes: "what changed" under each release is what people read before updating.
  • Libraries are a category of their own: a component you wrote for yourself, others add with one command.