pixel-point/media-downloader: a native macOS front end for yt-dlp

What Media Downloader is for, and who it is not for

The gap this project fills is narrow and real. yt-dlp handles extraction and ffmpeg handles merging, but neither gives you a window where you paste a link, get an MP4, and find that file already on your clipboard. Media Downloader is that window. The README describes it as a native macOS video downloader with support for thousands of sites through yt-dlp, and the feature list is built around the moments after a download finishes: copy the file, reveal it in Finder, open the original source URL, trim it and copy the trimmed clip.

The audience is a macOS user who downloads video occasionally and does not want to remember flags. If you already script yt-dlp with a config file and a shell alias, this app adds a GUI layer you did not ask for. If you are on Windows or Linux, there is nothing here for you: the README's download link points at MediaDownloader-macos-arm64.dmg, and the local development requirements start with macOS 14 or newer. The related searches for a media downloader for PC, a Chrome extension, or a Firefox add-on describe products this repository is not.

How the app delegates work to yt-dlp and ffmpeg

There is no download engine inside this repository. According to the README's How It Works section, Media Downloader uses yt-dlp to fetch media and ffmpeg to merge, convert, trim and export video files. Downloads land in the folder you selected. Preferences go to UserDefaults, while history and generated thumbnails are stored under the app's Application Support directory.

That split matters when something breaks. Site support is not implemented in Swift; it is inherited from the yt-dlp binary on your machine. The README says this outright in its Notes section and gives the fix: if a site stops working, run brew upgrade yt-dlp first. The app also converts and merges to MP4 with H.264 and AAC when possible, which is ffmpeg's job, and trimming is ffmpeg cutting the downloaded file rather than a re-download of a shorter range.

The project layout is a single Swift Package: Package.swift, Sources/MediaDownloader for the app, Tests/MediaDownloaderTests for unit tests, and a script/ directory holding build_and_run.sh, create_dmg.sh and release_macos.sh. The update check is small and self-contained: the app queries https://api.github.com/repos/pixel-point/media-downloader/releases/latest and compares the latest release tag, such as v0.2.0, against CFBundleShortVersionString.

Building Media Downloader from source on macOS

The README does not present a Homebrew cask or a Mac App Store listing. Its download link resolves to a DMG asset on the latest GitHub release, and the local development path is a source build. The stated requirements are macOS 14 or newer, Xcode Command Line Tools or Xcode with Swift 5.9 or later, plus yt-dlp and ffmpeg.

Start with the toolchain and the two runtime dependencies:

xcode-select --install
brew install yt-dlp ffmpeg

Confirm both binaries resolve before you build, because the app shells out to them at runtime:

yt-dlp --version
ffmpeg -version

From the repository root, one script does the build, bundles the app and launches it:

./script/build_and_run.sh

The README states that this runs swift build, creates a local development app bundle at dist/MediaDownloader.app, and launches it. If you prefer SwiftPM directly, swift build and swift test work on their own. The script also takes modes that are useful while iterating: --verify, --logs, --telemetry, --debug and --setup.

Once the app is running, the first real use is the loop the README describes: paste a URL from a supported site, let it download, and the finished MP4 is copied to the clipboard and saved to your chosen folder. The custom download folder is persisted, and history keeps thumbnails so you can copy a file again, reveal it in Finder, or reopen the source URL.

Site support is a moving target you maintain yourself

The most honest limitation is structural. Because extraction is delegated, the app's coverage equals whatever yt-dlp version is installed. A site that changed its player last week may fail in Media Downloader even if the app itself has not changed, and the remedy in the README is a yt-dlp upgrade rather than an app update. That is a reasonable design, but it means you own part of the maintenance.

Two smaller constraints follow from the README. The build targets macOS 14 or newer, so older Macs are out. And the release pipeline is heavyweight for a personal fork: it signs with hardened runtime, submits to Apple notarization, staples the ticket, and produces zip and DMG artifacts, all driven by credentials in a .env copied from .env.example. If you only want to run the app locally, you can ignore that path entirely; if you want to ship your own build, you need a Developer ID identity and either an App Store Connect API key or the Apple ID fallback variables.

The repository has no declared licence, which is the first thing to resolve before you redistribute a build or vendor the source into another product.

How it compares with driving yt-dlp directly

The alternative is yt-dlp on the command line, optionally with ffmpeg, which is exactly what this app calls. The difference is not capability but surface area. A terminal invocation gives you the full flag set, playlists, format selection, subtitle handling and output templates, and it is scriptable. Media Downloader gives you a paste field, an automatic clipboard copy, a thumbnail history, and a trim step, and it deliberately hides the rest.

That trade is worth naming. The app cannot do anything yt-dlp cannot, and it can do less. What it buys is the post-download ergonomics: the file is already copied, already findable in history, and trimmable without a second command. If your workflow is one video at a time and you keep reaching for Finder afterwards, the GUI earns its place. If your workflow is a list of URLs, a terminal loop is still the shorter path, and the README documents no bulk queue.

Release builds, signing and licence questions

If you build releases rather than just running the app, the cost is in credentials and Apple's notarization flow. The README says release credentials belong in a local .env copied from .env.example, and that .env, .p8, .p12, certificates, provisioning profiles and private keys must not be committed; the repository ignores them. The example file defines MEDIA_DOWNLOADER_DEVELOPER_ID, BUNDLE_ID, APP_VERSION, APP_BUILD, and the preferred App Store Connect API key trio APPLE_API_KEY_ID, APPLE_API_ISSUER_ID and APPLE_API_KEY_PATH, with commented Apple ID alternatives.

Publishing a version is one command:

./script/release_macos.sh v0.2.0

The README states that this script runs tests, builds a release .app, signs it with hardened runtime, submits it to Apple notarization, staples the ticket, creates dist/release/MediaDownloader-macos-<arch>.zip and .dmg, and uploads both to the matching GitHub release. To produce signed and notarized artifacts without publishing, use ./script/package_macos.sh instead.

The licence is unknown, so the practical implication is that you cannot assume redistribution rights for a signed build. Treat that as an open question to settle with the maintainers rather than something the README answers. On maintenance: the last push was on 2026-05-07, which is more than six months before today, so the repository should not be described as actively maintained on the strength of that date alone.

Editorial conclusion

Adopt Media Downloader if you work on macOS 14 or newer, already keep yt-dlp and ffmpeg around, and want a paste-a-URL window instead of a terminal. Skip it if you need Windows, a Chrome or Firefox extension, bulk queueing, or a drag-and-drop DMG you did not build yourself: the README's install path is a source build through ./script/build_and_run.sh. Before relying on it, confirm your installed yt-dlp version and that the site you care about is in yt-dlp's supported list, since the app inherits that coverage rather than maintaining its own extractors.

Frequently asked questions

Official sources

1. Issues
2. pixel-point/media-downloader on GitHub
3. README
4. Releases