NativeYoutube is a menu bar YouTube client for macOS built with SwiftUI

A player that lives in the menu bar

NativeYoutube is described as a lightweight menu bar YouTube client for macOS, giving quick playback, playlist support and a clean native experience without opening YouTube in a browser tab. The framing is the whole design brief. A menu bar client is not a YouTube replacement, it is a way to start and resume playback from where you already are, and the word lightweight in that sentence is doing real work, since the app is meant to be resident rather than something you open and close.

The project started as a personal app and the repository description records that history plainly, calling it a personal app that turned into an alpha released app v3. The release history supports that: versions 3.2.5 and 3.2.6 both landed on 2026-02-12 and 3.2.7 on 2026-09-12, with the last push to the repository on 2026-09-19. The repository is not archived. So this is a single developer project with a public source tree, and that shapes both what it does well and where its edges are.

The topic list names the technologies directly: Swift, SwiftUI, macOS, YouTube, and IINA. IINA is the open source macOS video player built on mpv, and its presence as a topic suggests the app leans on an existing playback stack rather than implementing its own video pipeline. That is a sensible choice for a solo developer and also a dependency to be aware of when you consider what happens to the app if that project changes.

The YouTube Data API key is the price of admission

The stated requirements are short and one of them is a real constraint. You need macOS 14.0 or later, and you need a YouTube Data API key. The setup sequence confirms how little else is involved: open the app from the menu bar, click the gear icon and paste the API key, then start searching and playing videos.

That is a meaningfully different model from a client that just scrapes the web interface. A Data API key is obtained by registering an application with Google, which means the app identifies itself to YouTube as a specific piece of software with its own quota. The practical consequence is that the app's capability is bounded by what the API exposes and by the quota attached to that key, and a shared or abused key can be disabled. It also means an API key sits on the user's machine and is stored through the settings interface.

For a developer evaluating this, the API requirement cuts both ways. It is a clean, documented interface with stable semantics rather than a screen scraper that breaks when YouTube changes its markup. It also adds a setup step that a browser-based or keyless client would not have, and it puts a third party between the app and the content.

Playlist support and the custom playlist ID

Playlist support is the feature the documentation gives concrete instructions for, and the mechanism is simpler than you might expect. Rather than parsing a playlist URL for you, the app takes the playlist identifier directly. The documented procedure is three steps: open any playlist URL, copy the value after the list parameter, and paste it into the Custom Playlist ID field under NativeYoutube, Settings, reached with Command and comma.

The example in the documentation uses a YouTube watch URL with both a video identifier and a list parameter:

   `https://www.youtube.com/watch?v=dQw4w9WgXcQ&list=PL634F2B56B8C346A2`

and the value to copy in that case is the playlist identifier after the list parameter. In practice the workflow is: find a playlist on YouTube in the browser, copy the identifier out of the address bar, and paste it into settings. That the app does not accept a URL directly is a limitation of the implementation rather than of the platform, and it means the user does a small amount of string handling that a URL parser would otherwise do.

This is also the clearest example of how much of the app is a front end over an API rather than a player of its own. Searching, resolving a playlist and starting playback are API calls; the value the app adds is the menu bar presentation and the native feel of the surrounding interface.

How the codebase is laid out

The repository layout gives a fairly clear picture of a small SwiftUI project that has been through a few structural passes. There is an NativeYoutube.xcodeproj directory holding the Xcode project, a NativeYoutube directory that is the application target, and a NativeYoutubeKit directory that is a separate framework or module, so the code is split between the app itself and a reusable library layer. There is a dmg-assets directory for the disk image used when packaging, and a docs directory for documentation.

Two configuration files are worth a mention because they say something about how the project is run. There is a .periphery.yml file, which is the configuration for the Periphery tool that finds unused code in Swift projects. A solo Swift developer keeping a codebase tidy will usually leave that kind of tool to a lint step, and having the configuration committed means the dead code check is repeatable rather than a one-off manual pass. There is also a .claude directory and a .github directory, so the repository carries both assistant tooling configuration and the usual GitHub community files including a code of conduct.

The .xcodeproj being a directory rather than a single file is the modern Xcode layout, where project data lives in a folder that can be merged on a branch. That is a small sign of the project being worked on with a real branching workflow rather than developed as a single file dropped into a folder.

Free to use, paid to remove the reminders

The licensing arrangement is unusual enough to be worth reading carefully. The repository is MIT licensed, with the terms in LICENSE.md, and the documentation says NativeYoutube is free to use. It then adds that purchasing a license removes reminders and supports development. The download and support links both point at the author's Gumroad page.

So there are two things going on. The code is MIT, which means you can read it, modify it and redistribute it under that licence. And the distributed application carries a nag behaviour, with a paid tier that removes it. That is a workable arrangement for a solo developer who wants the project public without giving away the convenience of a prebuilt binary, and the MIT licence does not prevent it, since the licence covers the code rather than the compiled artefact.

What is worth checking before you rely on it is the reminder behaviour itself, which the documentation does not describe in detail. If the reminders appear during playback and interrupt your use of the app, that changes the experience of a lightweight menu bar player significantly, and the documentation gives no detail on how often they appear or what they say. The purchase route is on Gumroad, and the badge in the documentation is the only description of what a licence gives you.

Where a menu bar client is the wrong tool

The first limitation is scope. This is a quick playback client. The documentation describes it as lightweight and gives instructions for searching, playing and playlists. It does not mention downloads, offline viewing, subtitles, background playback, casting to a television, or any of the features that make the YouTube website or its official apps what they are. If your use of YouTube includes any of those, this is not the tool, and the browser tab it was designed to avoid is still the answer.

The second is the API key and the quota behind it. A Data API key comes with request limits, and the app's usefulness depends on how many searches a session makes. For casual use that is a non-issue. For a workflow that runs many queries in a short window, it is a ceiling you do not control, and the failure appears as missing results rather than as an error message.

The third is the platform and the scale of the project. macOS 14 or later on an Apple Silicon or Intel Mac, with a single developer maintaining the app, is a narrow support surface. The Darwin build depends on the IINA playback stack, so a change there can affect the app's behaviour in ways the project does not control.

The honest alternative for some people is simply to use the YouTube website in a dedicated browser profile with a picture-in-picture extension, which gives the same quick playback benefit with none of the API setup and with the full feature set, at the cost of a browser process. The difference in approach is that NativeYoutube replaces the web player with a native interface and a documented API, so it feels like a Mac app rather than a web page, and that difference is exactly what it is asking you to trade the browser for.

Editorial conclusion

Adopt NativeYoutube if you play YouTube constantly while working and want a small menu bar player with playlist support instead of a browser tab, and you are willing to obtain a YouTube Data API key. Do not adopt it as a replacement for the full YouTube experience, since the project describes it as a lightweight client for quick playback, and it does not document downloads, offline viewing or background playback. Before you install it, note that the application is distributed as a paid release on the author's Gumroad page while the repository is MIT licensed, and confirm you are on macOS 14 or later with a Data API key in hand.

Frequently asked questions

Official sources

1. Aayush9029/NativeYoutube on GitHub
2. Issues
3. License: MIT
4. README
5. Releases