Ruddarr: a native iOS client for Radarr and Sonarr instances

A phone client for a server you already run

Ruddarr is described as a beautifully designed, open source, companion app for Radarr and Sonarr instances, written in SwiftUI. The word companion is the important one. It is not an alternative to Radarr or Sonarr and it does not download or index anything itself. It is a native front end for a server that is already running on your own hardware.

The feature list makes that clear by its ordering. You can manage movies and TV series, browse upcoming releases in a calendar, receive fine-grained notifications, view activity queue tasks and history events, and switch between multiple instances. After that come the quality-of-life items: a customizable colour scheme and appearance, settings and instances synchronized between devices through iCloud, automation through Siri Shortcuts, connection to reverse proxies using custom HTTP headers, and Spotlight search to jump quickly to media. The last entry is that the app is fully localized and ready to be translated.

That combination tells you the target user. Somebody with a self-hosted media stack who wants a phone interface that behaves like a phone app, rather than a bookmarked web page that squashes a desktop layout into a narrow screen.

The screenshots in the README match that reading. There is a movies library, a series details view, a calendar, and a discover movies view, all laid out as native iOS screens.

The app is on the App Store under the identifier id6476240130, the primary language is Swift, the licence is MIT, the default branch is develop, and the last push was on 2026-10-15. The release history shows v2.0.0 on 2026-08-12 and v2.0.1 a week later, so the project recently made a major version jump, with v1.8.5 in July before it.

The notification service is a separate open source project

One line in the README is worth pulling out, because it changes how you should think about the app: the code of the notification service is and also open source, linking to a separate ruddarr/apns-worker repository.

The wording is a little awkward but the structure is clear. A native iOS app that delivers push notifications for a self-hosted server needs a component on the server side, because the phone cannot be reached from your LAN and the server cannot push to Apple's push service on its own. That bridge is a small service, and the project has made it open source separately.

That matters for two reasons. The first is trust. The service sits between your server and your phone, and being able to read it means being able to check what it does with the credentials it holds for both sides. The second is that it can be run your way rather than through the app's own infrastructure, which matters for people who do not want a third party involved in their notification path at all.

The repository layout is consistent with a project that takes its own release engineering seriously. There is a NotificationService/ directory for the extension, a Ruddarr/ directory for the main app, a Ruddarr.xcodeproj/, a TestFlight/ directory, a Tests/ directory, and ci_scripts/ for the build pipeline. There is a .swiftlint.yml for Swift linting, a .typos.toml for a spell checker, a crowdin.yml for translations, and both an AGENTS.md and a CLAUDE.md describing the conventions for the tools used in development.

So the app is one repository for the iOS code and another for the server-side piece, with the App Store build being the packaged version of the first.

Localisation is done on Crowdin, and some strings cannot move

The localisation setup is the part of the project that most directly affects whether the app is usable in your language, and it comes with an honest limitation.

The README asks for help translating Ruddarr into any language, links the Crowdin project, and points at a translators channel on the Discord. Then it says that unfortunately some messages cannot be translated by Ruddarr, and links an issue about it.

The reason is almost certainly structural rather than an oversight. A SwiftUI application has user-facing strings that come from the app's own localisation catalog, and it has strings that come from the server's API responses, which are localised on the server side and arrive already translated. Any message that the server sends as an error or a status string cannot be translated by the client, because the client is displaying text it does not control. Issue 433 is the tracker for those.

So the practical expectation is that the app's own interface is fully localisable, and that a slice of server-generated text stays in whatever language your Radarr or Sonarr instance is running in. If you run your server in English and the app in another language, those server strings are the ones that will look wrong.

The rest of the localisation infrastructure is in place. There is a crowdin.yml file at the root of the repository, which is what connects the codebase to the Crowdin project, and the app is described as fully localised and ready to be translated, which is the phrase a project uses when the string catalog is in place and the translations are what is missing.

The translations therefore depend on the community, and the contributor list for the project is a mix of people who wrote code and people who wrote strings, which is the shape you would expect of a client for a self-hosted service where the users are the operators.

Building locally needs an Apple Account and a decision about capabilities

The development section is short and the requirements are specific, which is unusual for a README of an App Store app and useful if you plan to fork it.

To build the app locally, Xcode has to be signed into an Apple Account, and you select that account's team for the Ruddarr and NotificationService targets. After that comes a fork in the road.

The first option is to create a provisioning profile on your account for the iCloud, App Groups and Push Notification capabilities, and skip the remaining steps. The second is to continue on and remove the capabilities from both targets, and here the README notes that the NotificationService target only has App Groups, so it is the smaller of the two.

With the capabilities removed, you uncomment the CloudKit mock in the app's init:

dependencies.cloudkit = .mock

That single line is what makes a build work without a paid developer account and without iCloud, because the mock stands in for the real CloudKit dependency. It is also the reason the app still functions for anyone who has no iCloud configured.

Then you select a run destination and build. The README closes that section with a note that has bitten more than one fork: instances and other settings are stored in the group.com.ruddarr App Group so that app extensions can read them, and if you use your own bundle identifier you have to update Ruddarr.group in Ruddarr.swift and the App Groups entry in both the Ruddarr and NotificationService entitlements to match.

That is the cost of the App Group. The extension and the main app have to share a group identifier, and changing your bundle identifier means changing it in three places, and the entitlements of two targets.

Sentry symbols, resetting Xcode, and the URL scheme

Two development chores are documented, and one of them is a mistake most people make at least once.

The first is Sentry, where you create a .sentryclirc file in the project with the auth token:

[auth]
token=sntrys_eyJp...

The second is resetting Xcode, and the two commands are there because a stale simulator state breaks builds in ways that are hard to diagnose:

sudo xcode-select -s /Applications/Xcode.app
xcrun simctl --set previews delete all

The first points the developer directory at a known Xcode install, and the second clears the cached SwiftUI previews.

The URL scheme is the feature that makes the app scriptable from outside. Ruddarr supports the ruddarr:// URL Scheme to open specific tabs or items and to perform actions, and the README points at the QuickActions.swift file as the place where all the supported schemes are listed. That file lives in the Ruddarr/Dependencies/ directory in the source tree, so the list of what can be triggered is in the code rather than in a document.

The Siri Shortcuts support and the URL scheme together are what turn a companion app into something that can sit inside an automation. A shortcut can ask the app to open a tab or start an action, and the URL scheme is the transport, with the list of verbs defined in one Swift file.

Editorial conclusion

Ruddarr is worth installing if you run Radarr or Sonarr on a home server and want to check the queue or add something from your phone without opening a browser, because the SwiftUI interface is built for that job and the multi-instance switching and calendar views are the features the web UI does not do as well. It is the wrong tool if you do not already run Radarr or Sonarr, since it is only a client and holds no library of its own, and it is the wrong tool if you need to configure the server itself, because the configuration is the server's own web interface. Before you set it up, verify three things yourself: that your instance exposes an API key you can add to the app, since the app talks to the server over its API and the repository does not describe a different mechanism, that your server is reachable from outside your network or that you have a path to it, since a self-hosted server on a LAN is the common case, and that you understand what the iCloud sync carries, because the README says instances and settings are stored in the group.com.ruddarr App Group so that extensions can read them.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ruddarr/app on GitHub