Unwatched: an RSS driven YouTube queue for Apple platforms

The premise: a queue instead of a feed

Unwatched is described as an RSS feed based YouTube video player for iOS, iPadOS, tvOS and macOS, and its central promise is stated in the first line of the feature list.

No autoplay, no algorithmic bottomless feed. Just the Videos queued up in the order you want.

That sentence is the whole argument, and it is a reaction to something specific. The standard YouTube experience is a recommendation engine with a video player attached, and the two are welded together. You open the app and something is already playing, and the decision of what to watch next has been made for you by a model that optimises for watch time rather than for whether you wanted to see the thing.

Rebuilding that on RSS feeds inverts the relationship. An RSS feed is a chronological list of what a channel published. There is no ranking in it, no personalisation, and no suggestion engine. If a channel publishes five videos, all five appear, in order, and the decision of which to watch is yours.

The application is Swift, GPL-3.0, with the App Store download free under id6477287463. The recent releases are v1.8.10 from 2026-08-21, v1.8.9 from 2026-08-09 and v1.8.8 from 2026-08-05, so it is releasing steadily and the version line has passed 1.8. The last push was on 2026-10-22.

The repository layout shows two applications and a service. There is Unwatched/ for the main app, UnwatchedShared/ for the shared code, and a cloudflare-worker/ directory, which is where the server side piece lives and which the next sections explain.

Why a queue and an inbox are the right shape

It is worth being explicit about the design problem the application is solving, because the feature list only makes sense against it.

Every video platform converges on the same loop. You open the app, something is already playing, and the next thing is chosen for you by a model that has been optimised for a metric you did not select. Watch time is the usual one. The result is a system that is very good at keeping you watching and very bad at letting you decide what to watch, because the decision is the thing the ranking is designed to take away from you.

Unwatched takes the opposite position on both halves. No autoplay means nothing starts until you start it. A queue means the order is yours. And the inbox is the mechanism that makes following channels compatible with that, because it separates the act of subscribing from the act of deciding to watch.

That last distinction is the subtle one. Most subscription systems conflate them, so every upload from every channel you follow lands in the same place, and the only way to deal with volume is to unfollow things you actually want to see. Here the inbox absorbs the volume and the queue stays short, which means you can follow a channel whose upload schedule you do not control without your queue becoming noise.

The consequence is that the application is organised around a decision rather than around content. The queue is a decision already made. The inbox is a decision pending. The features that follow from that are the ones that help you make it: triage for routing, per-channel playback speed for how you will watch it, chapter selection for what part of it you want, and the Shorts toggle for excluding a category entirely.

It is also why the RSS basis is load bearing rather than a detail. A feed is a chronological list with no ranking, which is precisely the property the design needs, and it is a property that a platform API generally does not offer.

Following channels and the triage inbox

The feature that makes the queue more than a manual list is the ability to follow channels and playlists, which automatically add new videos.

On its own that is the standard subscription model, and the risk with it is obvious. If you follow ten channels and each uploads weekly, you have a growing pile, and the pile becomes its own version of the algorithmic feed you were trying to escape, just with a different source of items.

Triage is the answer, and it is the most interesting feature in the list. You choose where new videos from each channel should end up. Directly on top of the queue, or in your inbox to sort through them. Pick the best, leave the rest.

So the model is two-tier. The queue is what you are going to watch, in the order you want, and it stays under your control because you can add things to it in any order you like. The inbox is where new arrivals land, and the inbox is where you decide what deserves to enter the queue.

That is a much better fit for the problem than either extreme. A pure manual queue means you have to remember to check each channel, which is a chore you will eventually stop doing. A pure auto-queue is a feed with extra steps. An inbox you empty deliberately is the middle path, and it mirrors how people actually handle subscriptions.

Directly Import YouTube Subscriptions is listed under the further features, which is a convenience for the initial setup. Rather than adding each channel one at a time, the existing subscription list can be brought across, and then triage can be applied to decide which of them deserve an inbox rather than the queue.

Drag and drop videos and channel urls covers the other direction, the ad hoc addition, and the Add Video Shortcut gives the same thing from the share sheet so a link found anywhere can be sent to the queue.

Playback controls and the short video problem

The playback features are where the project shows it is aimed at people who watch a lot of video rather than at people who want a simple player.

Chapter support is listed twice in effect, because there are two distinct abilities. Jump to any chapter, or pick and choose a few to watch while skipping the rest. The second one is the unusual part. A video with chapters is often a talk or a tutorial with sections you do not care about, and being able to mark the ones you want and skip the others is a different operation from being able to jump to a specific point.

The attribution section names SponsorBlock, with a link to sponsor.ajay.app, as being used to enhance chapters. That is the crowd-sourced database of known sponsor segments in YouTube videos, and using it means the chapter list can include automatically detected sponsor breaks rather than only the ones the uploader marked.

Custom Playback Speed Per Channel is the feature that stands out most, because it is unusual to see. Set custom speeds for any channel. Want to watch trailers in 1x and podcasts in 2x? You can.

The reasoning is good. A trailer is designed to be watched at full speed and a podcast is designed to be listened to at double speed, and a global playback speed setting makes you compromise on one or the other. Per-channel speed means the setting follows the content rather than being applied to everything.

Then there is the Shorts problem, and the readme is blunt about it. Sick of #shorts? Hide them all. That is a single toggle rather than a filter, and it is a reasonable choice because Shorts are mixed into feeds from channels you follow for their long-form content, and there is no good reason to have to skip past them.

The rest of the list covers the ordinary but necessary features: Picture-in-Picture with background audio, so you can keep a video playing while doing something else, continuous play, notifications, a sleep timer, custom themes and iCloud Sync.

The iCloud Sync entry is worth isolating, because it changes what the application is. A local queue on one device is a tool. A queue that follows you between an iPhone, an iPad and a Mac is a habit.

Building it, and the Cloudflare Worker

The setup section is short and there is exactly one requirement.

In order to build this project, you need to add an apiKey.swift file that contains a YouTube Data API Key, with a link to the Google developers page for registering an application. An apiKey.swift.example file is already in the project.

The reason a key is needed is the search and metadata side of the application. Following a channel and pulling its RSS feed does not need a key, because a channel's feed is a public XML document at a predictable URL. Finding a video by URL and pulling its title, description and duration does, because that is the YouTube Data API.

The .example file convention is worth noting on its own. The key lives in a Swift source file rather than in a plist or an environment variable, which means it is compiled into the app binary. That is fine for a developer running on their own devices and it is the reason the example file exists, so the key file is never committed. It is a pattern that only works because the project is open source and every contributor has their own key.

The cloudflare-worker/ directory is the other half of the architecture, and the reason it exists is YouTube's feed behaviour. A channel's RSS feed carries a bounded number of recent entries, and following a large number of channels through their feeds directly would mean a lot of requests. Putting a small server side component in front turns that into one place that knows what has been seen.

Running that component on Cloudflare Workers means it is a serverless function, so there is no server to run and no bill when it is idle, and the same code works whether it is being hit by the iPhone app, the tvOS app or the Mac app.

The repository structure follows from that split. Unwatched/ holds the application, UnwatchedShared/ holds the code the platforms share, and cloudflare-worker/ holds the service. The shared directory is what keeps the iOS and tvOS builds from diverging, which matters on a project that ships three platform variants of the same product.

Editorial conclusion

Adopt Unwatched if you are on an Apple platform and want a watch-later queue for YouTube that behaves like a list you control rather than a recommendation engine. Do not adopt it if you want a client with a full local video library, because it is built around following channels and adding links rather than managing downloaded files. Before you commit, note that building from source needs your own YouTube Data API key in an apiKey.swift file, and check the App Store listing for the free download if you would rather not build it.

Frequently asked questions

Official sources

1. fer0n/Unwatched on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases