ipatool: search the App Store and download .ipa or macOS .pkg packages from the command line

What problem ipatool solves, and who actually needs it

Apple distributes App Store apps through the App Store client. There is no supported command-line path for pulling a specific version of an app as a file. ipatool fills that gap: the README describes it as a command line tool that searches for iOS, iPadOS, tvOS, visionOS and macOS apps on the App Store and downloads .ipa or macOS .pkg app packages.

The audience is narrower than the tagline suggests. Security researchers and reverse engineers who want to inspect a shipped binary, teams that need to archive a known-good build of a dependency app, and anyone automating App Store lookups in a script are the natural users. The repository topics include reverse-engineering and security, which matches that framing. Someone who just wants to install an app on their phone should use the App Store, not this.

How ipatool talks to the App Store: authentication, licensing, download

The command list in the README reveals the data flow. It is not a single download call; it is a sequence of separate operations that you can run individually or in order.

auth authenticates with the App Store. purchase obtains a license for the app. download retrieves the package. search finds apps, list-purchases lists apps owned by the authenticated account, list-versions lists available versions of an app, and get-version-metadata retrieves metadata for a specific version. That separation is deliberate: a download only works for an app your account is entitled to, so the license step exists as its own command.

The project is a Go module, github.com/majd/ipatool/v2, and the dependency list shows the mechanics underneath. github.com/juju/persistent-cookiejar persists session cookies, so an authenticated session survives between invocations. howett.net/plist handles Apple property lists. github.com/blacktop/go-macho and github.com/bodgit/sevenzip appear in the dependency set, which is consistent with inspecting Mach-O binaries and handling compressed archives. Credentials are stored through keyring libraries (github.com/byteness/keyring, github.com/byteness/go-keychain), which is why the global flag --keychain-passphrase exists. None of this is documented as an API in the README, so treat the dependency list as an indication of what the binary does, not as a public interface.

Installing ipatool and running a first real download

The README gives two install paths. On macOS, Homebrew:

brew install ipatool

On Linux and Windows, the README says to grab the latest version from GitHub releases rather than naming a package manager. If you prefer to build from source, the repository uses the Go toolchain and the README gives this command:

go build -o ipatool

Before anything else, confirm the binary is present and see the full command surface:

ipatool --help

You should see the command list from the README: auth, completion, download, get-version-metadata, help, list-purchases, list-versions, purchase and search.

Authentication comes first. The README lists auth as the command that authenticates with the App Store, and the tool runs in interactive mode by default. In an automated environment, the README says to pass --non-interactive:

ipatool auth --non-interactive

Once authenticated, search for an app, then obtain a license and download it. The README does not spell out the exact flag names for search, purchase and download, so run --help on each subcommand before scripting it:

ipatool search --help
ipatool purchase --help
ipatool download --help

One global flag is worth knowing early: --format can be set to text or json, with text as the default. Switching to json is the difference between parsing output with a text filter and parsing it with a real JSON parser.

The Apple Account requirement is the real constraint

The requirements section is two lines long and both lines matter. You need a supported operating system (macOS, Linux, Windows or iOS), and you need an Apple Account already configured to use the App Store. That second requirement is not a formality.

ipatool does not create entitlements. It operates on the account you give it. If the account has never used the App Store, or if the app you want is not available to that account's region or is not something the account can license, the purchase and download steps have nothing to work with. The tool also does not bypass App Store rules; it uses them through a different interface.

This is also where the licence question sits. The repository is MIT licensed, which covers ipatool's own source. It does not grant you rights to the apps you download through it. Those remain governed by Apple's terms and by the app developer's licence. Downloading a package for analysis and redistributing it are different activities with different legal footing, and the MIT licence on the tool says nothing about either.

Where ipatool is the wrong tool

The README is explicit that the tool runs in interactive mode by default. That is a design choice with consequences. A default interactive prompt in a CI job will hang, and the fix is the --non-interactive flag described in the README note. If your pipeline cannot pass that flag, or if the subcommand you need still prompts, ipatool is not a drop-in for unattended automation.

The README also does not document rollback, retry behaviour or rate limits. There is a retry dependency in go.mod (github.com/avast/retry-go), but the README does not describe when retries fire or how they are configured. Anyone planning to download many packages in sequence should treat that as unverified ground and test it against their own account before relying on it.

Finally, ipatool is a CLI with no GUI. The related searches include "ipatool gui", and the repository does not describe one. If a graphical interface is a requirement, this is the wrong project regardless of how well the CLI works.

Alternatives, and how they differ in approach

The most direct alternative is Apple's own tooling. Xcode and the App Store client can install apps, and on macOS there are supported ways to obtain app packages for apps you own. The difference is control: Apple's tools are built around installing and running software on a device, while ipatool is built around producing a file at a path you choose, with a version you can pin using list-versions and get-version-metadata. If you need the file, the App Store client is the wrong interface.

A second alternative is writing against Apple's private App Store endpoints yourself. That is effectively what ipatool does, and the dependency list shows how much incidental work it absorbs: cookie persistence, plist parsing, keychain storage, Mach-O handling, archive extraction. Reimplementing that is a project, not a script. The trade-off is that a third-party client tracks Apple's changes on its own schedule, and the README does not describe any compatibility guarantees.

Maintenance, releases and upgrade cost

The last push to the default branch was on 2026-09-19, and the most recent release is v2.6.0 from 2026-09-13, with v2.5.0 on 2026-08-31 and v2.4.0 on 2026-08-28. The repository is not archived. That cadence matters more here than for a typical library: ipatool talks to App Store endpoints it does not control, so a stalled release stream would be a real risk. The three releases in the weeks before the last push suggest active work.

Upgrade cost is low by construction. It ships as a single Go binary, installed via Homebrew on macOS or a release download elsewhere, and the module path is versioned (github.com/majd/ipatool/v2), so the Go import path changes only on a major version. The friction is in the flags, not the install. A minor release can add or change subcommand flags, and since the README documents the command list but not every flag, pinning a version in a script and reading the release notes before bumping is cheaper than discovering a changed flag in production. The MIT licence places no conditions on internal use or modification of the tool itself.

Editorial conclusion

ipatool fits engineers who need reproducible access to App Store binaries for analysis, version pinning or internal archives, and who are comfortable with an Apple Account plus a terminal. It is the wrong tool if you want a GUI or a one-step sideloading flow, and it is not a replacement for the App Store's own distribution rules. Verify first that your Apple Account can already use the App Store, then check the flags on the exact subcommand you plan to automate, because the README documents the command list but not every flag.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. majd/ipatool on GitHub
4. README
5. Releases