# Vienna: a Mac Mail style feed reader with sync that outlived Google Reader > Vienna is an RSS, Atom and JSON Feed reader for macOS built around an Apple Mail workflow, with a read-in-place browser view, a custom style system, XML plugins and syncing through the Open Reader API. The current line is a 3.11 beta, and the minimum system requirement moves with every major version. **ViennaRSS/vienna-rss** — Vienna is a free and open-source RSS/Atom/JSON feed newsreader for macOS. - Repository: https://github.com/ViennaRSS/vienna-rss - Website: https://www.vienna-rss.com - Stars: 1,978 · Forks: 234 - Language: Objective-C - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/viennarss-vienna-rss ## A reader designed around triage, not around a list of links Vienna is a free and open-source RSS, Atom and JSON Feed reader for macOS, and the README describes its design in terms of a mail client. It offers an experience modeled after Apple Mail: you quickly scan feed summaries, then open individual articles for deep reading inside a simplified browser view. That single sentence describes the whole interaction model. A three pane layout where the left is the group list, the middle is the list of items, and the right is the article, with the article rendered in a stripped-down browser view rather than in an embedded full browser. The web view is deliberately simplified, which is what makes reading a long article feel like reading rather than like navigating a site. The format list matters too. RSS is the base, and Atom and JSON Feed are supported as well, so the reader is not limited to the oldest feed format still in use. The project is written in Objective-C, and the repository layout shows a mature desktop application rather than a script: a `Vienna/` directory for the application sources, `Vienna Tests/` for the test bundle, `Vienna Help/` for the in-application help files, `External/` for bundled dependencies, `Packages/`, `Scripts/`, `Documentation/` and the `Vienna.xcodeproj` project. There is a `.clang-format` and a `.swiftlint.yml`, and the build status badge in the README points at an `xcodebuild` workflow. The licence is Apache-2.0, the site is vienna-rss.com, and the last push was on 2026-10-14. ## Sync goes through the Open Reader API, not through Google The syncing story is the part of the project that has aged most interestingly, because the original target is gone. Vienna can connect directly to the websites you want to track. Alternatively, or additionally, you can sync with a cloud based server supporting the Open Reader API, which the README describes as an adaptation of the now deceased Google Reader API. That parenthetical is the whole point. Google Reader's API is gone, and the Open Reader API is a community specification that re-creates the shape of it so that servers like BazQux, FreshRSS, FeedHQ, InoReader and TheOldReader can be sync targets. The README says Vienna has been successfully tested with each of those five. The practical value is that a self-hosted FreshRSS or a paid InoReader account can hold your subscription list, your read state and your starred items, and Vienna becomes one more client of that account. You can move between clients without losing the reading state, which is the problem the closed Google Reader API created for everyone when it shut down. What the README does not describe is the limits of the adaptation. The Open Reader API is not the whole Google Reader API, and a server that implements it will differ in how it handles label operations, sharing and annotations. For a reader that treats its server as a source of truth for read state, those differences show up as sync conflicts rather than as errors. ## The minimum macOS version moves with every release line The compatibility section is a list, and it is worth reading as a deprecation policy in reverse. Vienna 3.11.x requires a minimum of macOS 10.15, Catalina. Vienna 3.9.x and 3.10.x require macOS 10.13, High Sierra. Vienna 3.8.x requires macOS 10.12, Sierra. Vienna 3.6.x and 3.7.x require OS X 10.11, El Capitan. Vienna 3.2.x to 3.5.x require OS X 10.9, Mavericks, 3.1.x requires 10.8, Mountain Lion, and 3.0.x requires 10.6, Snow Leopard. So the project keeps older lines buildable, but each new major line raises the floor. The consequence for an installation is that your choice of version is partly a choice of which systems you can still support, and a team with a mix of machines has to pick a line rather than always taking the newest. The release list shows where the project is right now. The three most recent tags are 3.11.0 Beta 5 from 2026-09-10, 3.10.8 from 2026-07-19 and 3.11.0 Beta 4 from 2026-07-19. Two betas and one stable in the same window is the pattern of a maintainer testing a new line while still shipping fixes on the old one, and it means the newest version number is not the recommended one for most users. ## Three ways to install, and the Homebrew cask is the shortest Admins upload release and test versions at the GitHub Releases page, and the README also points to Sourceforge as an alternative source of downloads. For most people the shortest route is the Homebrew cask: ```bash brew install --cask vienna ``` Vienna is listed as a cask in the Homebrew repository, and a cask is the right mechanism here because it is a macOS application bundle rather than a library or a command line tool. Building it yourself is the third option, and the `Makefile` shows exactly what a release build involves: ```bash xcodebuild -project Vienna.xcodeproj -scheme Vienna archive xcodebuild -project Vienna.xcodeproj -target Notarization -configuration Deployment xcodebuild -project Vienna.xcodeproj -scheme Deployment ``` The default target and the `release` target run the same three steps: an archive of the Vienna scheme, a Notarization target for the Deployment configuration, and then the Deployment scheme itself. The notarization step is the part that a macOS application outside the App Store has to handle, and having it wired into the Makefile tells you the project takes distribution seriously. The `development` target builds the Development configuration, and `clean` removes the `Build` directory along with the derived data. Support is documented in three layers. The in-application help files and the FAQ on the website come first, then the GitHub Discussions page, and only then an issue, with the README asking for concision and precision so that others can reproduce the problem, and suggesting a link to a relevant discussion to keep the issue short. ## Styles and plugins are the two extension points Vienna has two documented ways to change what the application does, and neither of them requires writing Objective-C. A style is a combination of an HTML template that controls the placement of the various parts of an article and a CSS stylesheet that controls its appearance. Styles are provided on the Styles sub-menu off the View menu, and the project documents how to write them, pointing at the existing styles in the `Styles` folder as examples. This is a template plus stylesheet, so it is a matter of HTML and CSS, and it is the mechanism behind the themes the reader offers. A plugin is installed in menus and/or on the toolbar and can run defined actions. Plugins are XML-based and can be created by editing a simple `.plist` file without any knowledge of Cocoa programming, in as little as 15 minutes according to the README. The existing plugins in the `Plugins` folder serve as the reference. Both extension points are unusual for a native Mac application, and both are documented on the project website. They are also the reason a reader like Vienna can accommodate workflows that the developers never anticipated, which is the usual argument in favour of open formats and pluggable design. Localisation works the same way, through a different route. Translations are kept up to date on Crowdin, registration is required but free, and the README asks people not to localise the project's files directly, so the translation files stay consistent with the source layout. ## The project has a written policy on AI contributed code The contributing section contains a rule that is becoming common and is worth reading before you open a pull request. The project has strict rules regarding the usage of so-called AI, and points to an LLM usage policy document in the `Documentation` directory. For a project of this size and age, that is a sensible policy to have written down. A code base that has been maintained for years by a small group has a house style, an architecture and a review process, and generated contributions that ignore them cost more to review than they save. Saying so in the README, and pointing at a document, is better than discovering it in a rejected pull request. The rest of the contribution guidance is conventional and points at two documents: `Contributing.md` for the mechanics of writing code, and `Architecture.md` as an entry point into the structure of the project. There is a `Documentation/` directory for those, along with the LLM policy, and the repository has a `CHANGELOG.md`, a `Credits.rtf`, a `Makefile`, and a `Scripts/` directory. The application also has a `Vienna Help/` directory, which is the in-application help that the README tells users to consult first, and a `Vienna Tests/` directory for the test bundle, so the help and the tests are part of the repository rather than separate artefacts. ## Where Vienna is the wrong choice The first wrong case is any platform other than macOS. The application is an Objective-C Mac app built with Xcode, distributed as an application bundle and notarized for distribution, and the compatibility table is a list of macOS versions rather than a list of operating systems. A team with mixed platforms, or with Linux servers reading the same feeds, needs a different reader. The second is a cloud-first workflow. Vienna is a desktop client, and its sync story is a client talking to a server that implements the Open Reader API. There is no web interface, no mobile client and no headless mode described, so the reader is tied to the machine in front of you. The third is a reader that needs features from the modern feed ecosystem. The Open Reader API is a partial re-creation of a dead API, and a server implementing it will differ from Google Reader in how it handles label operations, sharing and annotations. For most reading workflows that difference is invisible, and for a workflow that depends on those specific features it is a blocker. The fourth is wanting the newest features today without the beta risk. The most recent tags are 3.11.0 betas while 3.10.8 is the latest full release, and picking the beta means picking a minimum macOS version of Catalina, which is itself a decision about the systems you can support. The fifth is contributing code generated with an AI assistant, unless you have read the project's LLM usage policy, which the README says applies to the project. It is the one contribution route the project has explicitly restricted. ## Conclusion Adopt Vienna if you read feeds on a Mac and want a native reader with a Mail style triage workflow, custom article styles, plugins, and syncing with a server that speaks the Open Reader API. Do not adopt it if you need a reader on platforms other than macOS, or if you are looking for a stable release, since the newest tags are 3.11.0 betas while 3.10.8 is the latest full release. Before you install, check the minimum macOS version for the line you pick, because Vienna 3.11 needs Catalina and older lines support progressively earlier systems, and read the project's LLM usage policy if you intend to contribute code or translations. ## FAQ ### What formats can Vienna read? Vienna is an RSS, Atom and JSON Feed reader for macOS, and the README describes an experience modeled after Apple Mail, where you scan feed summaries and then open articles in a simplified browser view. ### How does Vienna sync with other feed readers? It syncs with a cloud server that supports the Open Reader API, an adaptation of the now deceased Google Reader API. The README says Vienna has been successfully tested with BazQux, FreshRSS, FeedHQ, InoReader and TheOldReader. ### How do I install Vienna on macOS? Vienna is available as a Homebrew cask with `brew install --cask vienna`, as release and test builds from the GitHub Releases page, and as downloads on Sourceforge. Building from source uses the Makefile, which runs xcodebuild archive, a Notarization target and the Deployment scheme. ### Can I change how Vienna displays articles without writing code? Yes. A style is a combination of an HTML template for the placement of the parts of an article and a CSS stylesheet for its appearance, and plugins are XML based, edited through a simple plist file, without needing Cocoa knowledge. Existing examples are in the Styles and Plugins folders. ## Sources - [License: Apache-2.0](https://github.com/ViennaRSS/vienna-rss/blob/master/LICENSE) - [Project website](https://www.vienna-rss.com) - [README](https://github.com/ViennaRSS/vienna-rss/blob/master/README.md) - [Releases](https://github.com/ViennaRSS/vienna-rss/releases) - [ViennaRSS/vienna-rss on GitHub](https://github.com/ViennaRSS/vienna-rss) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/viennarss-vienna-rss