A list of 710 macOS apps where the category counts disagree

Each entry is a language tag, a website line, and a collapsed screenshot block

An entry follows a fixed shape, which is what makes 710 of them skimmable at all. The name links to the project, most often on GitHub, and one sentence says what the app does. Under that comes a Languages line naming the implementation languages, then a Website line when the project has a site of its own. Audacity is listed with the language C and a website pointing at audacityteam.org, while Aural Player is listed with Swift and no website line at all. A collapsible Screenshots block closes most entries. The consequence for a reader is that the useful facts are the name, the one line of purpose, and the language, and the rest is decoration you have to expand to reach. Cog shows the shape tolerating a hosted source too, since its link points at a Bitbucket tree rather than a GitHub repository.

The header links 11 categories, the contents list 47, the stats say 49

Three counts of the same taxonomy do not agree, and the disagreement is the first thing to check. The row of links under the title jumps to 11 destinations: Audio, Backup, Browser, Chat, Cryptocurrency, Database, Development, Editors, Graphics, Productivity, and Utilities. The Contents section that follows the languages table enumerates 47 of them, running all the way down to Touch Bar, Wallpaper, and Window Management. The statistics table reports 49 categories next to 710 total applications. The consequence is that the header row is a hand-picked shortlist rather than a complete index, so if you arrive looking for a screensaver, a VPN, or a touch bar utility, the navigation will not get you there and you have to scroll or use your browser's find instead.

Swift accounts for 320 of the 710 applications

The language data is the most useful signal in the file for judging what the list is made of. The statistics table reports Swift at 320 applications, Objective-C at 137, JavaScript at 114, C++ at 59, and TypeScript at 43, which is the top of the distribution. The language reference table that follows enumerates twenty languages in total, adding C, C#, Clojure, CoffeeScript, CSS, Elm, Go, Haskell, Java, Lua, Python, Ruby, Rust, Shell, and Metal to those five. The consequence is that the tail is long. Five languages account for the great majority of entries, so a reader hunting for a Rust, Go, or Haskell macOS application is working through a small part of the list, and the language tag on an entry is a more honest filter than the category it happens to sit under.

The data sits in applications.json and categories.json, and the README never says so

The repository is not only a markdown file. Alongside README.md there are applications.json, categories.json, api.json, and buildServer.json, plus an icons directory, a Dangerfile, a PULL_REQUEST_TEMPLATE.md, and a CONTRIBUTING.md. The README does not document how the JSON files relate to the rendered list, or which one a contributor should edit when adding an application. The consequence is concrete: an entry written into one file and not the other leaves the data and the document out of step, and nothing in the visible documentation tells you which side is authoritative. The pull request template and the Dangerfile at least show that review automation is expected, but the data contract between the files and the page is left for a contributor to infer from the directory listing.

JSON appears twice in the contents, and Other catches the overflow

The category list is not a clean partition, and the duplication is visible in the contents alone. JSON Parsing and JSON are separate entries, as are Development, Web development, and Other development, and Text sits alongside Editors, CSV, Markdown, and TeX rather than containing them. There is also a platform bucket, iOS / macOS, mixed in among task buckets, and an Other at the end to absorb whatever does not fit. The consequence is that category membership is a judgement call rather than a rule, so one app can plausibly be filed in two places, and browsing by category will either miss an entry or meet it twice. For a list meant to be scanned by eye, that ambiguity is the price of keeping everything in a flat markdown table.

Screenshots are collapsed, and some are only counted in the repository

Images are the bulk of the file and almost none of it is visible at a glance. Most entries end in a collapsible Screenshots block, and inside the ones that survive the trimming of the file you find a note reading 5 more screenshots available in the repository, or 1 more screenshots available in the repository. So the rendered list shows fewer images than its entries actually have, and the remainder is reachable only by opening the raw file. The consequence is that judging an app by its screenshots takes two passes, one in the browser and one in the source, and a mirror or an archived copy of the list will render less completely than the repository itself. It also means the document is heavy to load for what is, in information terms, a table of links.

No releases and no changelog, so an entry cannot be pinned

The repository publishes no GitHub releases, and the last push is dated 2026-09-10. There is no CHANGELOG in the tree either, only the data files, the icons, the configuration, and the documentation set. The consequence is that the catalogue has no addressable versions. You cannot pin a snapshot of it, cannot diff two dates of it, and cannot tell from this repository whether an entry arrived last week or three years ago. The only stability on offer is per entry, because each app links out to its own project where that project carries its own history and its own release tags. The list itself is released under CC0-1.0, which removes friction from reuse but does nothing about the absence of a version to reuse.

Editorial conclusion

The list is worth reading if you want a survey of what exists on macOS outside the App Store, and worth scanning by language rather than by category, because the taxonomy has duplicates. Do not build automation on it: there are no releases, no changelog, and the README never explains how the JSON files relate to the rendered page. Before you rely on any single entry, open its link and check the project's own repository, since the list carries no version of its own and no date beside each app.

Frequently asked questions

Official sources

1. Official README
2. Project repository