Hello everyone!
So, after much soul searching, thinking about what I want for the future and whether I could make this a sustainable concern, I've decided TurnOver is now free and open source, under the GPL. Anyone can use it, read the code, check it, change it and build it themselves.
I started out with this on a whim. Safari and Word were unusable for me, so I set about fixing them for myself, and discovering it was possible to fix not only those two apps but improve the logic and layout of others, I realised there might be something here. It was exciting. It was wild! I was doing something many of us had hoped for for so long. Of course, it's a big undertaking. As pointed out by several commenters, maintaining the code base, keeping up with apps as they change and generally keeping the whole thing ticking along takes a significant amount of time, as it has. So, to make it sustainable, I thought, rightly or wrongly, I'd keep it closed and charge a small subscription to cover my time.
From speaking to others, I came to understand that most people won't pay for a screen reader when a free one is built in, so I wouldn't get enough to make it worthwhile. Also, I admit, other ventures on here did make me realise that even a half-baked free screen reader that's open source might be preferable to a fully functional, notarised one with a plan for sustained development. *mutter mutter mutter*
As it stands, I'm happy. I've got a screen reader that rocks. All I really wanted. I just thought others might want it more.
What this all means:
- TurnOver is free for everyone. No tester keys, no waiting list, no price.
- The code is on GitHub: https://github.com/TurnOver-For-Mac/turnover. Yes, it was written with an AI, and tested by hand, with a hundred-odd unit tests. It's all there to judge, and I'm hoping there's something useful in it for people to build out from.
- It's a spare-time project. I'll keep working on it a few hours a week, on what I can. No support or roadmap promises. I'm going to do what I should have done before: get on with finishing my book. It's amazing what procrastination can look like! This is still a project I care deeply about. There are areas of the Mac I still want to reach and fix. I'm a tinkerer and a maker, coding and 3D printing are my jam. It's just not going to be viable as a larger commitment.
- Bug reports and ideas go through GitHub's issue form now, not email.
- Fixes, plugins, guides and testing are all very welcome. Plugins are the easiest way in, no Swift needed.
- The released builds are still signed and notarised by me, and update themselves. Nobody else can ship an update to your copy.
If it's useful to you and you'd like to help with running costs, there's Ko-fi, no account needed: https://ko-fi.com/oliverkennett. It's in TurnOver's menu too, under Support TurnOver. GitHub Sponsors is coming.
Download and guides, as before: https://doll-eye.github.io/turnover-updates/
A massive thank you to the testers, who sent hundreds of careful reports and made TurnOver what it is. You are heroes, rocket men and women willing to climb onboard a wild ride. You rock.
Stay frosty
O
Comments
Re: Refactory
yea but who would wonna do that.
Re: Refactory
I don't see how AI can help in this situation, especially considering that it's what got us here in the first place. Writing code is by far what takes the least amount of time, and deterministic tools like macros and Perl can help with the repetitive bits. What takes time is coming up with a proper architecture, and AI sucks at that, so it's optimizing the wrong aspect of development.
In Vosh I put some effort into separating things, but stopped short of deciding how high level the core should go. For example should the core recognize the different kinds of controls and provide them to the add-ons already classified, or should that work be left to the add-ons? Should there be an intermediate level of add-ons that work more closely to the core to do the classification, or should all add-ons work at the same level? In my opinion the core should be responsible for classifying things and abstracting away from the lower levels of Apple's accessibility, like attributes, parameterized attributes, actions, custom rotors, and accessibility graphs. Another question that needs to be answered very early is whether the navigation model should be flat, as is the default on iOS, or should it continue to be a hierarchy, as is the case on macOS? I think that it should be flat, with a browse mode like NVDA's that works everywhere not just in browsers. I'm also against adding too many features too early. I think that we should focus into moving slowly but steadily, and not rush to implement new features until the existing ones are polished.
I don't mind to do the refactoring, but it will be heavily based on what I wrote for Vosh, since I consider it well designed and it's already battle tested as I used the same code to write a context collector for an AI assistant in my last job. Vosh is written in ergonomic Swift, it avoids all the concurrency problems with the accessibility API by relegating all calls to that API to a global actor backed by a dedicated thread, it is organized such that it doesn't need input monitoring permissions, its output module is ready to replace some utterances with audio icons, but it isn't customizable yet. My work can focus mostly on providing a library that can be used both for screen-readers and AI agents, and then people can implement the high level screen-reader on top.
I'm also considering abandoning GitHub and adopting a custom distributed solution that is more in tune with the distributed nature of git. This solution, which I've been working on recently, will be entirely based on public git repositories in the cloud and E-mail exchanges to discuss issues. Pull requests will preferably be based on sending an E-mail with a summary of the commits, the branch, and the location to pull from, as output by the `git request-pull` command. People wanting to use GitHub can continue to do so since it already provides public git repositories. This solution isn't ready yet since I'm waiting for my cloud provider to implement a feature so initial work will remain on GitHub, but I think that the project should have a self-hosted home that's more cognitively accessible to the common user than GitHub.
If people agree with this then I'll make a shallow fork of Vosh and work towards making it a library, with a screen-reader demo notarized by Apple and published once I think it's ready for early testing.
Re: Pro tip for using GitHub
I use Markdown a lot to format my text, and in that particular comment I used it to express all the commands in code voice, which essentially translates to monospaced characters to the sighted. While I understand that most people here are totally blind like me, I'm used to writing to a sighted audience so I cannot stop myself from formatting things with them in mind.
Another thing that needs investigation
The private CoreAccessibility framework needs to be investigated. It currently powers the public accessibility framework but might be more versatile, since the public accessibility framework suffers from some questionable design decisions such as blocking calls, lack of thread safety, and lack of features like the custom rotors. I'd like to reverse-engineer VoiceOver in order to learn more about this, but with my Mac Studio currently seized, there's no way I'm gonna be running virtual machines to do that on this 16GB MacBook Air.
Re: Refactory
I completely agree with you on managing scope and avoiding feature creep—moving at a steady pace to build a rock-solid foundation is definitely the right path.
To share how I’ve structured this architectural split in Armoni—which I’m planning to make publicly available on Git very soon—here is how the responsibilities and extended capabilities are organized:
Core (Host & OS Integration): Handles low-level AX ingestion, macOS shell interfaces (Desktop, Dock, Menu Bar), system notifications (volume/brightness OSD), and the screen reader’s own UI/settings.
Shared (The Common Engine & Domain Layer):
Multi-Provider Ingestion & Unified Interpretation: We ingest accessibility data from multiple providers (AX API, AppleScript, PDFKit, Chromium CDP, WebKit, Office APIs). Rather than passing raw, fragmented data around, a single Object Resolver/Interpreter unifies and normalizes all incoming data into a single, cohesive semantic representation.
Data-Driven Component Catalogs: Both Native and Web components are defined declaratively via catalogs. This handles roles, states, and navigation semantics cleanly, ensuring outputs (like Speech or Braille cell mappings) stay decoupled from raw AX quirks.
Data-Driven Keymaps & Localization: Key bindings and key labels are fully data-driven, allowing dynamic remapping and localization tailored to different keyboard layouts and languages.
Cursors & Contracts: Manages virtual/flat navigation states, reading snapshots, and strict data protocols.
Utilities & AI Integration (Armoni Intelligence):
Incorporates specialized tools alongside Armoni Intelligence, powered by a locally running AFM3 advanced model.
Provides on-device video audio description, real-time meeting presentation descriptions, advanced OCR, and vision-based contextual analysis.
When native or web applications fail to expose AX attributes, vision analysis programmatically infers and constructs missing accessible names, roles, and states directly into the navigation tree.
App Modules (Extensibility Infrastructure): To ensure app-specific fixes and commands never pollute the Core, every application support package (e.g., modules/whatsapp/) lives independently with its own manifest, documentation, localization files, and src directory. Extensions interface with Armoni via dedicated SDKs in three tiers:
JSON Profiles: Declarative overrides, labels, regions, and keyboard remappings.
JavaScript (via JavaScriptCore): Dynamic scripts for custom app navigation and commands.
Native Swift (.framework): Signed, compiled modules for complex edge cases requiring C-ABI performance.
Both core and module-level localization support are deeply baked into this design. I find that this separation gives us the best of both worlds: a clean, high-performance core alongside a sandboxed, data-driven extensibility model that scales gracefully.
I look forward to opening up the Armoni repository soon so we can explore these architectural ideas and potential synergies on open ground!
command control comma doesnt seam to work
First, I wanna say, turnover is so awesome! I use it for safari some times, and it's very snappy! However, the command control comma to bring up the turnover menu from everyware, doesn't seem to work. I have it in my menu bar. I hope this can be fixed in a future build!
Keep up the wonderful work
Contributor guidelines updated
TUrnover's contributor guidelines have now been updated to reflect the need for larger refactors. "Moving app logic into app modules is welcome, and is the direction the code is going: less special-casing in the core, more in Sources/TurnOverCore/Modules/. That work doesn't need to come as a string of tiny pull requests. Open an issue or a Discussion with the plan first, so two people don't move the same thing, then send it in a few larger pieces, an app or a mechanism at a time."
see here
Hopefully this makes things easier, and will encourage more people to contribute to a larger refactoring effort.
How can we contribute as users
Ashly, to be honest, I didn’t understand much of your comment above. The technical terminology can be difficult to follow for someone like me who has no background in app development.
I used to send bug reports to Oliver regularly, but since the move to GitHub, I’ve barely submitted any. The terminology and reporting process there feel confusing and intimidating for everyday users.
Would it be possible to add a built-in bug reporting feature to TurnOver? A simple form with clear questions could help us describe the issue directly in the app, then automatically submit it to GitHub in a format that gives the information it needs. That would make it much easier for users like me to keep contributing feedback.
Re: How can we contribute as users
hmmmm i didn't think of that when i said i didn't like github. but i wouldn't be apposed to that change as a normy myself. no i am not the dev i was just aggreeing with you but my point from my last comment still stands.
Re: How can we contribute as users
The comment above was really for those devs in the thread discussing major code refactors. I wrote a guide earlier in the thread on submitting bug reports as an every-day user, does this help?
https://www.applevis.com/comment/219815#comment-219815
I'll look into how such a feature might be implemented into turnover itself.