AirPosture reads your head position from the AirPods you are already wearing

The reason it went open source is a trademark problem, not a philosophy

The readme has a section about impersonation, and it is the most informative paragraph in the document. The author describes unofficial apps using the name with aggressive paywalls, and posts not affiliated with the project, some of which copied the name and branding while distributing modified versions of the original release or pointing users at unknown downloads, with links to a warning post and to an app store listing described as malware distribution. The author says they reached out to almost all of them asking for a rename or a takedown, and that most either denied the request or ignored it. Then the sentence that explains the decision: the situation led Apple to repeatedly reject the author's own app during review, because others were using the original open-source version and the name on the app store. That is a specific, well-evidenced chain of events, and it is worth reading carefully because it inverts the usual open-source narrative. The original plan was to keep the project commercial and open it after version one. The trigger was not conviction about licensing, it was that opening the source let imposters ship the app under the same name, which then made the app store a hostile environment for the legitimate app. The stated solution is radical transparency, opening the whole codebase so that the original is unambiguously the one in the repository.

What the app actually does, and on which hardware

The feature description is one sentence: an app that turns your AirPods into a real-time posture coach, giving gentle nudges to sit better, move more and reduce neck strain through the day. The word gentle is doing design work, and the rest of the readme's forward-looking section explains why it can be gentle. It says the earbuds now include richer motion and medical-grade heart rate sensors, and that a framework from Apple enables private, low-latency models on the device without cloud delays or privacy compromises. So the pipeline is: motion data from the headphones, a model running locally, a decision about whether the current posture is bad, and a nudge delivered through the same device. The supported hardware list is specific rather than aspirational, which is the right way to write it. It covers AirPods Pro across all generations, the third-generation and later AirPods, AirPods Max, and compatible Beats earphones that support spatial audio with dynamic head tracking. The qualifying clause is doing the work: head tracking is the feature that provides the motion signal, so a pair of earbuds without it is not supported regardless of generation. That also tells you the app is not using the audio path at all, which is the interesting engineering choice here. A posture signal from head orientation is a small amount of data from a sensor you already wear, and the entire value of the project is the model and the feedback policy rather than new hardware.

The subscription framing, and what the usage number actually says

The readme opens the open-source announcement with a sentence about intent that is worth sitting with. The author says they were not trying to create another subscription app, and simply wanted a tool that could help people improve their posture using the devices they already wear every day. Then a number: since the beta launch, the app has been used in over a hundred thousand sessions. A number followed by a change of direction usually means the number was supposed to justify the opposite decision, and the readme is candid that seeing the response forced a rethink of why the project was being built. The stated conclusion is that what the author cares about is not maximising revenue but helping as many people as possible build healthier habits. Read charitably, that is a coherent position. Read sceptically, a hundred thousand sessions is not a hundred thousand users, sessions can be one person opening the app repeatedly, and the number is not broken down by retention or by whether people kept the app. Neither reading tells you whether the product works, because the readme reports no outcome measure, no adherence figure and no feedback about whether people sat better. It is a demonstration that the app was opened, which is a different claim. The author's own conclusion is stated in the same terms, that if it helps even a small number of people it has succeeded, which is a standard any hobby project can clear and any health product probably cannot.

Three directions, and the repository shape that suggests how it is built

A section describes where the project is going, with three named directions and screenshots for each. The first is a Mac version, illustrated with what appears to be a camera framing of the screen. The second is automatic activity switching. The third is a section explaining the sensor and model situation rather than a feature. So the roadmap is a second platform, better context detection, and a note about the model infrastructure, and the ordering suggests the author thinks the on-device model quality is now a solved problem and the remaining work is platform coverage and knowing when to intervene. The repository layout supports a reading of how the code is organised, and it is more structured than a single-target app. There is a main application target, a separate core directory, a shared directory, a live activity target, a separate test target for the app, a separate user-interface test target, a third test directory, an Xcode project file, a package resolution file, a build configuration file for a universal architecture, a project specification file, a directory for a live activity relay, a website directory, and an assets directory. The separation of core, shared and app is the usual way to make logic testable, and the two test targets plus the separate test directory suggests tests exist at more than one level. A project specification file alongside an Xcode project usually means the project file is generated, which is worth knowing before you try to open and build it.

Documentation is the honest limitation

The documentation section is three lines and two of them are warnings. The project has a site, and the setup document is the entry point:

https://airposture.github.io/

There is a setup document, and the marker says work in progress, pointing at a table of contents file for prerequisites, configuration and build instructions. There is a contribute document, also marked work in progress, with no link behind the text. And there is no architecture documentation, no model description and no explanation of the training data. For a project whose entire technical content is a posture model, that absence is the significant gap. A reader can see that there is a model and that it runs on device, but not what it predicts, how many classes it has, what the training set was, or what the false-positive rate looks like when someone is on a train. That last one matters more than usual for this category, because a posture app that nudges you on a train is worse than no posture app, and the readme's screenshots cannot tell you how often that happens. The other gap is the platform. The readme gives a Mac direction without saying whether it exists, and the beta channel note is precise enough to be trusted, which is to say the author is telling you the distributable build is behind the source. For anyone wanting to run this, the practical route is the beta channel and the app store rather than a build, and for anyone wanting to study the approach, the source is the point and the missing documentation is the cost.

Editorial conclusion

Read AirPosture if you are interested in on-device posture sensing, because the combination of a sensor you already wear, private inference and a real-time feedback loop is a pattern more hardware projects will copy, and the source is available. Do not expect to build and run it today, since the setup and contribute documents are both marked as work in progress and the only way to use the app today is a beta channel pointed at an older build than the repository. Four things to verify. Which build you can actually get, because the readme says the test channel points at an earlier build than the one in the repository, so a tester and a builder are looking at different software. Which headphones it supports, since the list is specific about generations and includes compatible Beats models that support spatial audio with head tracking, and the underlying feature is motion data. How the feedback works for you, because a real-time nudge every time you slouch is either the point or the reason you uninstall it, and the readme's screenshots are not a substitute for trying it. And that you are comfortable with a project whose documentation is unfinished. The licence is MIT, there are no published releases, and the last push was on 2026-07-18.

Frequently asked questions

Official sources

1. allenv0/AirPosture on GitHub
2. Issues
3. License: MIT
4. README