Downloader for Apple Developers: a segmented downloader for Xcode and WWDC video

What the application does and what it is not

Downloader for Apple Developers is a macOS application whose stated purpose is to download Xcode and other developer tools up to 16 times faster with resume capability, and the description phrases it as downloading Xcode, WWDC videos and other developer tools up to 16 times faster.

The sixteen times figure is the project's own claim, and the README is clear where it comes from. The application is completely dependent on aria2, which is a utility for downloading files that supports segmented downloading. The speed, the segmentation and the resume all belong to aria2. What this program adds is the part that is tedious to do by hand, and the README says so plainly.

The mechanism is cookies. When you start a download, the program takes the download auth token from cookies, along with the other required parameters, and passes them to aria2. The comparison the README draws is the useful one: you can achieve the same thing with aria2 without this program, but you would have to manually take out the auth token from cookies and the other parameters and feed them into aria2.

So the honest framing is that this is a convenience wrapper around a command line tool, with a user interface. That is not a criticism; the manual step it removes is genuinely annoying, because the token has to be extracted from the browser's cookie store and reformatted for a command line argument.

The repository is a Swift application with a standard Xcode layout: a Downloader.xcodeproj, a Downloader.xcworkspace, a Downloader/ source directory, a Podfile with a Podfile.lock and a Pods/ directory, which means it uses CocoaPods for its dependencies, plus a docs/ directory holding the screenshots.

Installing it and the two download flows

Installation is a zip and a drag. You download the latest Downloader.app.zip from the releases page, unzip it, and move Downloader.app into the /Applications directory.

There is no package manager route, no brew cask and no build instructions in the README, which is consistent with a project that has not been restructured in some years.

The first flow is for Xcode and other developer tools, and it is three steps. You log in with your Apple Developer Account. After login you see the Apple Developer Downloads page. Then you select any file to start the download.

The second flow is for the video content. You select Videos, described as WWDC, Tech Talks and similar, from the download source list on the right. That gives you the Apple Developer Videos page. You select any video you want. Then you pick HD Video or SD Video from the Resources section to start the download.

The fact that the app authenticates through the browser session rather than asking for your Apple ID and password is the design decision worth understanding. It means the app never handles your developer account credentials, and it means the app's access is exactly the access your browser session already has. It also means the app depends on the shape of Apple's login flow and the cookie names, which is a fragility you should expect any browser-coupled tool to have.

The videos and the developer downloads are separate flows because they are separate pages on Apple's site with separate authentication, and the app handles both by driving the same underlying mechanism.

How the aria2 integration works in practice

The README describes the integration in a paragraph and a half, and the detail is what makes the design reproducible.

An instance of Process, which is the Foundation class for running a child process, takes the output from aria2 and shows it on the UI. So the architecture is: the app spawns aria2 as a subprocess, parses its output, and renders the progress. There is no download logic of its own.

That has a specific consequence for how you use it. Because aria2 is a separate binary, it has to be installed. The README does not spell out how to install it or list it as a dependency in the installation section, which means a user who does not already have aria2 will find the app doing nothing useful, and the documentation does not warn them. That is the single biggest practical gotcha with this project, and it is worth checking before you install.

The second consequence is that you can achieve the same result by hand, which the README says explicitly. If you are comfortable extracting the token and constructing the aria2 command line, the app saves you the effort of doing it repeatedly and gives you a progress display. If you are not, the app does the part you were going to get wrong.

The third is about resume. The feature list says the download resumes automatically if the download failed due to any reason. That is a property of aria2's segmented downloading rather than of the wrapper: with segmented downloads, a failure loses one segment rather than the whole file, and aria2 can pick up where it left off. The app inherits that behaviour because it hands aria2 the parameters that make it work.

The four features, and what each one actually buys you

The feature list has four entries, and reading them against the aria2 mechanism tells you which are the app's work and which are inherited.

Downloading Xcode and other developer tools up to 16 times faster and downloading WWDC, Tech Talks and other videos up to 16 times faster are the same feature applied to two content types. Both are aria2's segmented downloading. The speedup depends entirely on the server supporting range requests and on your link having spare bandwidth; a server that throttles per connection will not give you sixteen times anything.

Resume download automatically if the download failed due to any reason is also aria2, and it is the feature that matters most in practice for a multi-gigabyte Xcode download. A dropped connection mid-download is the normal case rather than the exception on a home connection, and resuming a partially downloaded Xcode is the difference between waiting and starting again.

Multiple downloads supported is the fourth, and this one is genuinely the app's. aria2 can do it, but the wrapper has to hand it several concurrent jobs and keep their output separated on screen.

What is not in the list is worth noticing too. There is no scheduling, no queue persistence across launches, no checksum verification of the downloaded archive, no notification when a download finishes, and no automatic update check. The application is a thin, focused utility: pick a file from Apple's pages, get a fast and resumable download of it.

The licence is MIT and there is a PayPal support link in the header. The thanks section credits Tatsuhiro Tsujikawa and the other aria2 contributors, which is the correct person to credit given that the project is mostly a front end for their work.

Limits: an ageing project, a cookie dependency and a manual aria2 install

The limits are the sort that come from a project that has not changed shape in years, and the README is short enough that you can see them by what it does not say.

The first is the age. The tagged releases are 2.2.0 from 2021-08-03, 2.1.0 from 2021-06-04 and 2.0.1 from 2020-06-21. The last push to the repository was on 2026-09-09, so there has been recent activity, but no new tagged release in five years and the version has not moved past 2.2. The build badge still points at Travis CI, which is a service that stopped being the default long ago, and the README uses relative screenshot paths that begin with a slash, which is a detail that breaks in some Markdown renderers.

The second is the cookie dependency. The application authenticates by taking the auth token out of your browser's cookies. That is a deliberate design that avoids handling your password, but it also means the app is coupled to the shape of Apple's login and to the cookie names it expects. When Apple changes either, the app breaks, and there is no published mechanism for updating the expectations because the source is a single developer project.

The third is that aria2 is a hard requirement that the installation section does not mention. The README says the program is completely dependent on aria2 and thanks its contributors, but the install step is only download the zip, unzip, move to Applications. A user with no aria2 gets an application that appears to do nothing.

The fourth is the platform. It is a macOS application built with Xcode, and the top level listing includes a Pods directory checked into the repository, which is unusual and means the dependency tree is pinned by the project rather than resolved by you.

The fifth is that the app gives you no verification that what you downloaded is intact. The speed and the resume come from aria2, and aria2 will report a completed download whether or not the resulting archive is valid.

Downloader for Apple Developers against aria2 by hand and against the direct download

Two comparisons make the choice clearer.

The first is against driving aria2 yourself. That is what the README says you would do without this program, and the difference in effort is a couple of minutes per download, once you have worked out how to extract the auth token from the cookie store and what parameters aria2 needs alongside it. The app does that once and turns it into a page and a click. If you download Xcode a few times a year on a fast link, doing it by hand is entirely reasonable and gives you a script you can reuse.

The second comparison is against downloading Xcode the normal way, through the browser or the official download page. The difference is that Apple's own download is a single stream, and a single stream gets whatever the connection gives it, while segmented downloading opens several connections and uses the spare capacity. On a link that is bandwidth-limited rather than connection-limited, the segmented approach genuinely goes faster, and on a link that is neither, it does not.

That is the honest boundary of the sixteen times figure. It describes a comparison against a single-stream download on a connection where the server and the link permit parallel ranges, and it is not a property of the application.

A third option exists for people who download Xcode rarely and want it to be reliable rather than fast. The official route through the developer downloads page always works and always gives you the file Apple intends. This application is worth its small amount of setup if you are the person who reinstalls Xcode every time a new version ships, or if you also want the WWDC video archive, which is the case where the video list is large and the individual files are big.

Editorial conclusion

Adopt this app if you are on a slow link to Apple's developer servers and want segmented downloading and resume for a multi-gigabyte Xcode download, and you are comfortable with a tool that reads your browser cookies. Do not adopt it if you want an actively maintained project, since the last tagged release is from 2021 and the application has not been restructured since. Verify first that the aria2 binary it expects is available on your PATH, that your Apple Developer account gives you access to the files you are trying to fetch, and that you understand the app reads your session cookies to do it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vineetchoudhary/Downloader-for-Apple-Developers on GitHub