The generated iOS app list that stops at star counts and a year

README.md is generated from contents.json, so hand edits disappear

The README opens with a warning saying it is generated, should not be updated, and that contributions belong in contents.json. That one line decides how the entire project works. README.md is an output, contents.json is the input, and a pull request that adds an app by editing the rendered Markdown is editing a file that gets rebuilt. The entry vanishes on the next generation run. The repository root is small enough to read in one glance: README.md, contents.json, APPSTORE.md, ARCHIVE.md, LATEST.md, LICENSE, plus a .circleci/ directory alongside .github/ and .gitignore. Contribution guidance sits at .github/CONTRIBUTING.md. The practical consequence for anyone who found a broken or missing app is that the fix has to land in the JSON file, and the rendered page is not the place to argue about wording.

The newest release is 3.3.0 from 2022 while entries are dated 2026

The three most recent releases are 3.3.0 on 2022-03-22, 3.2.0 on 2021-03-07, and 3.1.0 on 2021-02-28. The last push to the default branch is 2026-09-25, and entries in the Apple TV section carry year tags of 2026, 2025, and 2023. Those two facts sit awkwardly next to each other. The version tags stopped moving more than four years ago while the content kept changing, which is what you would expect from a repository whose main artifact is regenerated text rather than a released library. For anyone deciding how current the list is, the tag number is close to useless: it dates the last release, not the last edit. Pinning your fork to release 3.3.0 pins you to an index from 2022, so the useful freshness signals are the commit dates and the year tags on individual entries.

A star count on every line is a popularity number, not a health check

Each entry ends with a star figure written as a star glyph followed by a number. In the Apple TV section those numbers range from 3 for RAYN Weather up to 19425 for VLC, with Swiftfin at 4115 and Provenance at 6358 in between. A count like that measures how many people bookmarked a repository on GitHub. It does not tell you whether the app still compiles, whether its dependencies still resolve, or whether anyone answers issues. The rest of the line is a year, a set of lowercase tags such as swift, swiftui, tvos, cloudkit, and ipad, an App Store link where one exists, and a screenshot link. None of those is a build or maintenance signal either. The consequence for a reader is that the list answers only the first question, whether a project exists and where to find it. Every other question is left for you.

Two visionOS entries link to Apple documentation instead of a repository

The Apple Vision section mixes community repositories with Apple sample pages. Beatmap AR points at a GitHub repository and carries a 2024 year tag, the tags swift, swiftui, vision, visionos, and realitykit, and a star count of 47. Dream points at a repository with a 2023 tag and 200 stars. BOT-anist and Destination Video point instead at developer.apple.com documentation pages, and their lines carry only the tags swift, vision, visionos, and xcode16, with no year and no star count at all. So the same category holds both things, and the two documentation entries are the only ones in view with nothing to clone. A reader who assumes every line is a forkable project will click two links in that section and land on a documentation page, with no source tree, no commit history, and no issue tracker to fall back on.

The table of contents mixes tasks, platforms, and frameworks

The jump-to index runs through more than thirty headings, and the headings are not all the same kind of thing. Most name a task or a subject: Weather, Finance, Tasks, Text, Security, Travel, Scan, Shopping. Three name a platform and sit at the top level: Apple TV, Apple Vision, Apple Watch. Then there are parents that split again, and one of those splits on technology rather than subject. Under Misc there are fourteen subcategories named Appcelerator, Core Data, Firebase, Flutter, GraphQL, Ionic, macOS, React Native, ReactiveCocoa, Realm, RxSwift, SwiftUI, VIPER, and Xamarin. Health breaks into four, including Contact Tracing and a separate Contact Tracing Reference, and Media breaks into six including Animoji and GIF. The consequence is that a SwiftUI app sits under Misc rather than under the subject it serves, so browsing by task and browsing by framework return different sets and neither view is complete on its own.

Entry metadata stops at a year, tags, and a star count

Look at what a line does not carry. An entry has a name, a link, a one-sentence description, an optional App Store link, a screenshot, a year, lowercase tags, and a star count. There is no field for the license the app ships under, no date of the last commit, no release tag, no statement that the project builds, and no minimum iOS version. For a project whose entire purpose is helping you find software to build on, those are precisely the fields that decide whether you can use it. The year is the only time signal available, and the generated header does not define what the year refers to, so it cannot be read with confidence as a release date. You end up opening each repository to answer the two questions that matter before writing any code against it: what license, and when did it last change.

CC0 covers the list, not the apps it points at

The repository is released under CC0-1.0, a public domain dedication. That covers the index itself: the Markdown, the JSON, the curation work. It says nothing about the many apps the list points at, since each of those is a separate project under its own terms. Blurring the two is easy when one page links to hundreds of codebases and every link looks equally official. The tags give you a hint about the stack, naming swift, objc, realm, or specific dependencies such as alamofire, swiftyjson, or promisekit, but a dependency list is not a license grant, and an app tagged c or objc is not thereby free of copyleft. The consequence is that CC0 should be read as a statement about the index only. Read the license in each repository you actually intend to use before it reaches your product.

iPad is a tag, while watchOS, tvOS, and visionOS get their own heading

Three of the five supported platforms have a top-level section of their own: Apple TV, Apple Vision, and Apple Watch. iPad has none. The iPad apps visible in the Apple TV section are marked with an ipad tag, on Moonlight Game Streaming next to a c tag, on Stepik, and on VLC. An iPad-only project and a phone project that also runs on a tablet are therefore not separated anywhere in the structure. ipad is a filter you apply by reading tags, not a section you browse. That matters when you are looking for something built natively for a tablet, because the flat categories mix both cases and the entry format will not tell you which one you have until you open the repository and look at its deployment targets.

Editorial conclusion

open-source-ios-apps is worth bookmarking as a discovery index and worth treating as a starting point rather than a decision. It cannot tell you whether an app is maintained, what license it carries, or whether it still builds, so use the year tags and the framework tags to narrow the field, then check each repository yourself before depending on it. To contribute, edit contents.json rather than the generated README, and follow the guidance in .github/CONTRIBUTING.md.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes