apps.json

Why this exists

More people are making small, personal software: tools, experiments, Claude skills, prototypes, tiny utilities, and apps that do one useful thing.

But there is no simple way to follow someone's apps as a set. They are scattered across GitHub repos, launch posts, personal sites, app stores, Discord links, and half-forgotten demos.

apps.json gives those apps a home on the open web. It is RSS-ish: publish one plain file, and any reader, crawler, launcher, directory, or search engine can understand it.

How it works

Create a file at:

https://yourdomain.com/apps.json

Start small:

{
  "version": "1.0",
  "apps": [
    { "name": "My Cool App", "url": "https://example.com/cool" }
  ]
}

That is enough.

Add claims when they help

Apps are different from posts. People want to know where an app runs, whether it is current, whether the source is available, whether it was vibe-coded, and whether it can be forked.

apps.json handles that with optional creator claims:

{
  "name": "My Cool App",
  "url": "https://example.com/cool",
  "version": "1.2.0",
  "tags": ["writing", "utility"],
  "vibe_coded": true,
  "forkable": true,
  "source": "https://github.com/example/cool",
  "prompt_log": "https://example.com/cool/prompts",
  "targets": [
    { "kind": "web", "url": "https://example.com/cool", "label": "Open" }
  ]
}

These are not certifications from apps.json. They are useful facts declared by the creator. Readers can show them, search over them, and build trust layers on top later.

Principles

• Publish to participate. A public apps.json file is the opt-in.
• No central registry. Directories and readers can exist, but the standard is just the file.
• Tiny required surface. Only version, apps, name, and url are required.
• Useful app context. Apps need a little more metadata than posts: where to run them, what version they are, where the source lives, and whether they can be forked.
• Claims, not certification. Creator fields are creator claims. Readers can show them; trust layers can come later.
• For builders and audiences. Builders get a canonical list. Audiences get a way to follow and discover what people are making.

Tools

These are optional reference tools around the standard:

• Reader. Paste a feed URL into the reader to render and validate it.
• Badge. Use the badge generator to link your site or README back to your feed.
• Digest. Follow the example digest, JSON Feed, or RSS feed for seeded updates.
• Set up a feed from your repos. apps-json-setup scans local repos, finds apps, Claude/Codex skills, CLIs, MCP servers, extensions, templates, and other creator-made software, then drafts entries and flags anything that needs confirmation.
• Keep a feed current. apps-json-publisher adds or updates app entries, preserves creator claims, and validates the feed.

They are examples and helper workflows, not required infrastructure. The standard is still just the apps.json file.

Try it

Append your feed URL as a query string:

https://apps-json.org/?feed=https://yourdomain.com/apps.json

Loading seeded directory…