App Storeからipaを取得するOSS「ipatool」の仕組み

「このバージョンの .ipa が手元にあれば切り分けられるのに」という場面は、iOS アプリの検証や不具合調査でたびたび発生します。App Store で配布されているアプリであっても、パッケージそのものをファイルとして手元に置く経路は、App Store Connect からのビルド取得や MDM 経由の配布とは別の話になります。

さらに厄介なのは、検索で出てくる手段の信頼性を判断しにくいことです。脱獄端末が前提のもの、Python のスクリプトを自分で組み合わせるもの、素性の分からない配布サイトを案内するものが混在しており、「業務の検証環境に持ち込んでよいか」という判断材料が揃いません。目的に合わないツールを選ぶと、環境構築まで進めたあとで「取得できたファイルが欲しかったものと違う」と気づく手戻りが発生します。

この領域で単一バイナリの CLI として選択肢に挙がるのが、Go で書かれた OSS の ipatool です。App Store 上のアプリを検索し、.ipa または macOS の .pkg をダウンロードするコマンドラインツールで、2026 年 10 月 5 日時点でスター 11,483、ライセンスは MIT、最終 push は 2026-10-01 と開発が継続しています。アーカイブもフォークもされていない本家リポジトリです。

ただし ipatool は「落とせるか」より「自分のユースケースに使えるか」で評価が分かれるツールです。Apple Account が必須であること、ライセンスを保有していないアプリはそのままでは取得できないこと、そして得られるのが App Store の配布物そのものであることが、採用判断を大きく左右します。

本記事では、ipatool のコマンド体系・内部の仕組み・類似ツールとの違い・導入前に確認すべき制約を、README とリリースノート、リポジトリのソースコードをもとに整理します。実行環境へのインストールや動作検証は行っておらず、公開されているドキュメントとソースコードに基づく机上の整理であることを先にお断りしておきます。記載した数値はすべて 2026 年 10 月 5 日時点の GitHub API 取得値です。

ipatool とは｜App Store の ipa / pkg を取得する Go 製 CLI

ipatool は、App Store 上のアプリを検索し、そのアプリパッケージをコマンドラインからダウンロードするツールです。README は冒頭でプロジェクトを次のように定義しています。

ipatool is a command line tool that allows you to search for iOS, iPadOS, tvOS, visionOS, and macOS apps on the App Store, and download .ipa or macOS .pkg app packages.

出典: github.com/majd/ipatool（README）

対象プラットフォームが iOS だけでなく iPadOS・tvOS・visionOS・macOS まで広がっている点、そして取得物が iOS 系の .ipa と macOS の .pkg の両方である点が、定義文から読み取れます。

リポジトリの基本情報

数値はいずれも 2026 年 10 月 5 日時点の GitHub API 取得値です。5 年以上継続しているプロジェクトで、スター 11,483 に対してオープン Issue が 18 件という比率は、課題が溜まり続けている状態ではないことを示します。

一次情報は README と Releases に限られる

採用判断の前提として押さえておきたいのが、情報源の構造です。ipatool には公式サイト・公式ドキュメントサイト・Wiki・Discussions のいずれも用意されていません。GitHub API 上でも homepage は空、has_wiki / has_pages / has_discussions はすべて無効です。

したがって一次情報は、(1) README、(2) GitHub Releases のリリースノート、(3) リポジトリ内のソースコード、(4) LICENSE の 4 つに限られます。本記事で「公式の記述」と書いている箇所も、この 4 つのいずれかを指しています。README に書かれていない挙動を調べるにはソースコードを読む必要がある、という前提はツール選定時のコストとして見積もっておくとよいでしょう。

ipatool が必要になる場面｜ipa を手元に用意したい理由

ipatool が候補に挙がる場面は限られています。いずれの用途でも Apple Account とアプリのライセンス保有が前提になるため、先にそこを確認しておくと無駄な検討を省けます。

検証・QA で過去バージョンの挙動を確認したいとき

「特定バージョンでだけ再現する不具合」を追うには、そのバージョンのパッケージが必要になります。ipatool は利用可能なバージョンの識別子を一覧し、識別子を指定してダウンロードする経路を備えているため、バージョンを固定した検証環境を組む用途に向きます。手順は後述の「ipatool のコマンド体系」で整理します。

一方で、ipatool が取得できるのは App Store が配布しているバージョンに限られます。社内のベータビルドや TestFlight 配布分は対象外で、こちらは App Store Connect や MDM の領域です。

配布パッケージの中身を確認したいとき

Info.plist の値、バンドル構造、同梱リソース、署名まわりのファイル配置といった「配布物の構成」を確認したい場合、パッケージをファイルとして手元に置けると調査が進みます。ipatool は App Store が配る .ipa / .pkg をそのまま取得するため、配布物の構成を一次資料として保全する用途には素直に使えます。

ただし ipatool は取得したパッケージに手を入れる処理を 1 つだけ行います。ライセンス情報（sinf）をパッケージ内に書き込む処理で、これについては後述の「ipatool の仕組み」で詳しく扱います。「ダウンロードしたバイト列がそのまま保存される」とは限らない点は、ハッシュ値の比較などを前提とする調査では意識しておく必要があります。

ipatool では満たせない目的（復号済みバイナリが必要なケース）

ipatool が担えない領域を先に切り分けておくことが、このツールの評価では特に重要です。App Store が配布する iOS アプリの実行バイナリは FairPlay（Apple の DRM）で暗号化されており、端末上でインストールされる過程で復号されます。ipatool は App Store の配布物を取得するツールであり、この暗号化を解く処理は行いません。

したがって、実行バイナリを逆アセンブルして解析したい、文字列やシンボルを直接読みたいといった目的では、ipatool の出力は出発点になりません。この用途では脱獄済み実機と Frida を組み合わせて復号済みパッケージを抽出する系統のツールが使われます。詳細は後述の「類似 OSS との違い」で比較します。

ipatool のコマンド体系｜auth から download までの流れ

ipatool のサブコマンドは README の ipatool --help 出力で一覧できます。原文のまま引用します。

$ ipatool --help
A cli tool for interacting with Apple's ipa files

Usage:
  ipatool [command]

Available Commands:
  auth                 Authenticate with the App Store
  completion           Generate the autocompletion script for the specified shell
  download             Download iOS, iPadOS, tvOS, visionOS, and macOS app packages from the App Store
  get-version-metadata Retrieves the metadata for a specific version of an app
  help                 Help about any command
  list-purchases       List apps owned by the authenticated App Store account
  list-versions        List the available versions of an App Store app
  purchase             Obtain a license for the app from the App Store
  search               Search for iOS, iPadOS, tvOS, visionOS, and macOS apps available on the App Store

Flags:
      --format format                sets output format for command; can be 'text', 'json' (default text)
  -h, --help                         help for ipatool
      --keychain-passphrase string   passphrase for unlocking keychain
      --non-interactive              run in non-interactive session
      --verbose                      enables verbose logs
  -v, --version                      version for ipatool

Use "ipatool [command] --help" for more information about a command.

出典: README の Usage 節（原文のまま引用、改変なし）

グローバルフラグのうち自動化で効いてくるのが --format と --non-interactive です。README は実行モードについて次の注記を置いています。

Note: the tool runs in interactive mode by default. Use the --non-interactive flag if running in an automated environment.

出典: README の Usage 節

既定が対話モードであるため、CI やスクリプトから呼ぶ場合は --non-interactive を明示する設計になります。--format json を併用すれば出力を構造化データとして受け取れるため、後続処理にパイプで渡す構成が組めます。--keychain-passphrase は、資格情報を保存しているキーチェーンのロック解除に使うフラグです。

auth login｜Apple Account での認証と 2FA の扱い

auth には login / info / revoke の 3 つのサブコマンドがあります。login のフラグはソース上で次のように定義されています。

cmd.Flags().StringVarP(&email, "email", "e", "", "email address for the Apple ID (required)")
cmd.Flags().StringVarP(&password, "password", "p", "", "password for the Apple ID (required)")
cmd.Flags().StringVar(&authCode, "auth-code", "", "2FA code for the Apple ID")

出典: cmd/auth.go（原文のまま引用、改変なし）

ソースを読むと、対話モードではメールアドレスとパスワードを未指定でもプロンプトで入力でき、パスワードはマスク入力になります。非対話モードでは未指定だとエラーになるため、--email と --password を渡す必要があります。

2 要素認証（2FA）の扱いには非対称性があります。対話モードではコードが必要になった時点で入力プロンプトが再表示されますが、非対話モードでは「2FA code is required; run the command again and supply a code using the --auth-code flag」というログを出して処理が終わります。つまり自動化環境では「コードを取得してから --auth-code 付きで再実行する」という設計をあらかじめ用意しておく必要がある、ということです。ここは CI 組み込みの検討で最初に詰めるべき点になります。

なお login 実行時には「preparing authentication; the first login may take a few minutes」というログが出力されます。初回ログインには時間がかかる想定である旨が、実装側で明示されています。

search｜検索にも認証が必要

search のフラグは次のとおりです。

cmd.Flags().Int64VarP(&limit, "limit", "l", 5, "maximum amount of search results to retrieve; visionOS supports up to 12")
cmd.Flags().StringVar(&platformValue, "platform", "", "Platform to search: iphone (iOS), ipad (iPadOS), appletv (tvOS), visionos, or macos")

出典: cmd/search.go（原文のまま引用、改変なし）

取得件数の既定は 5 件で、visionOS は最大 12 件という制約が説明文に書かれています。--platform で指定できる値は iphone / ipad / appletv / visionos / macos の 5 種です。

実装上の注意点として、search も内部でアカウント情報の参照を行います。アプリを探すだけの操作でも認証済みのアカウントが前提になるため、「まず検索して様子を見る」という試し方はできません。

download｜アプリ ID / バンドル ID とライセンスの関係

download のフラグ定義は次のとおりです。

cmd.Flags().Int64VarP(&appID, "app-id", "i", 0, "ID of the target app (required)")
cmd.Flags().StringVarP(&bundleID, "bundle-identifier", "b", "", "The bundle identifier of the target app (overrides the app ID when found)")
cmd.Flags().StringVarP(&outputPath, "output", "o", "", "The destination path of the downloaded app package")
cmd.Flags().StringVar(&externalVersionID, "external-version-id", "", "External version identifier of the target app (defaults to latest version when not specified)")
cmd.Flags().StringVar(&platformValue, "platform", "", "Platform to download for: iphone (iOS), ipad (iPadOS), appletv (tvOS), visionos, or macos")
cmd.Flags().BoolVar(&acquireLicense, "purchase", false, "Obtain a license for the app if needed")

出典: cmd/download.go（原文のまま引用、改変なし）

ソースから読み取れる挙動のうち、採用判断に関わるものを 3 点挙げます。

1 点目は、アプリ ID とバンドル ID のどちらも指定しない場合はエラーになることです。バンドル ID を指定した場合はアプリ情報の照会で解決されますが、照会に失敗してもアプリ ID が指定されていれば処理が続きます。この分岐にはソース上で次のコメントが添えられています。

// Delisted apps may still be downloadable by their numeric ID.

出典: cmd/download.go（原文のまま引用、改変なし）

App Store から取り下げられたアプリは、バンドル ID では引けなくても数値の ID 経由で取得できる場合がある、という意図のコメントです。取り下げ済みアプリの調査が目的の場合、この挙動は押さえておく価値があります。

2 点目は、ライセンスが必要というエラーを受けた際のリトライ条件です。実装では --purchase が指定されている場合にのみライセンス取得処理を実行して再試行する形になっており、指定がなければそのまま失敗で終わります。ライセンスを保有していないアプリは、--purchase を明示しない限り取得できません。

3 点目は、資格情報の期限切れエラーを受けた場合に、保存済みの資格情報で自動的に再ログインしてリトライする実装になっていることです。長時間動かすバッチでも、トークン期限切れで即失敗するわけではありません。

list-versions と get-version-metadata｜特定バージョンを取得する 3 ステップ

過去バージョンの取得は、3 つのコマンドを組み合わせて行う設計になっています。

1. list-versions で、対象アプリの利用可能な外部バージョン識別子（external version identifier、App Store 内部でバージョンを識別する数値）を一覧する
2. get-version-metadata で、その識別子に対応するバージョン情報を照会し、表示上のバージョン番号と突き合わせる
3. download --external-version-id <識別子> で、目的のバージョンを取得する

get-version-metadata では --external-version-id が必須フラグとして定義されており（出典: cmd/get_version_metadata.go）、識別子を先に手に入れる前提の設計であることが読み取れます。download 側の --external-version-id は未指定なら最新バージョンが対象になります。

「1.2.3 を落としたい」という指定が直接できるわけではなく、識別子への変換を 1 ステップ挟む点が、スクリプト化する際の設計ポイントになります。

list-purchases と purchase｜所有アプリの確認とライセンス取得

list-purchases は認証済みアカウントが所有するアプリを一覧するコマンドで、--max-results / --page / --platform でページングとプラットフォーム絞り込みができます（出典: cmd/purchases.go）。このコマンドは v2.5.0 で追加され、v2.6.0 で Mac アプリを含むように拡張されました。

purchase は App Store からアプリのライセンスを取得するコマンドです。v2.6.0 のリリースノートには「Use purchase --app-id to obtain an app license without looking up its bundle identifier.」と記載されており、バンドル ID の照会を経ずにアプリ ID 指定でライセンスを取得できるようになっています（出典: v2.6.0 リリースノート）。

ipatool の仕組み｜認証・部分 ZIP 取得・sinf 注入

ここからは、ipatool が内部で何をしているのかを整理します。繰り返しになりますが、以下はリポジトリのソースコードとリリースノートの読解であり、実行して観測した結果ではありません。

App Store への認証をどう成立させているか

ipatool の中核パッケージは pkg/appstore で、認証に関わるファイルとして appstore_login.go / action_signer.go / appstore_bag.go / appstore_kbsync.go / machine_id.go などが置かれています。これらのファイル名と、リリースノートに並ぶ変更内容を突き合わせると、認証部分が継続的に作り替えられてきたことが分かります。

Releases 一覧から認証関連の変更を拾うと、次のような流れになっています。

• v2.3.0（2026-02-16）: 認証エンドポイントを動的に解決し、専用の pod を使う変更（PR #438）
• v2.3.1（2026-07-05）: Bag（App Store クライアントが参照する設定情報）から認証エンドポイントを取得する変更。「iTunes Store Sign-in required」を期限切れと同様に扱う修正（PR #432）
• v2.3.2（2026-08-03）: レガシーな Store 認証へのフォールバック追加（PR #514）
• v2.4.0（2026-08-28）: App Store 認証を SAP 署名付きリクエストに置き換える変更（PR #525）。あわせて「An unknown error has occurred」（FailureType 5002）の修正（PR #500）
• v2.5.0（2026-08-31）: SAP のゲストタイムアウト対応（PR #528）、一時的な認証応答のリトライ追加（PR #533）

つまり ipatool の認証は、公開された API を叩いているのではなく、App Store クライアントが行っている通信を再現する形で成立しています。machine_id.go や appstore_kbsync.go といったファイルが置かれているのも、クライアント側が送る識別子や同期用のデータを生成する必要があるからだと読み取れます（ファイル構成と変更履歴からの推測で、公式の説明ではありません）。

この構造が意味するのは、Apple 側の仕様が変われば動かなくなり得るということです。リリースノートの大半が認証周りの追随であるという事実は、裏を返せばそのたびに修正が必要になってきた証拠でもあります。

資格情報はどこに保存されるか

資格情報の扱いは pkg/keychain が担っています。OS のキーチェーン（キーリング）に保存する実装で、グローバルフラグ --keychain-passphrase はそのロック解除に使われます。

関連する変更として、v2.3.1 で依存している keyring モジュールをメンテナンスされているフォークへ移行（PR #466）、v2.5.0 で macOS の資格情報アクセス設定の修正（PR #531）が入っています。また cmd/keyring_default.go と cmd/keyring_ios.go が分かれており、iOS 向けには別実装が用意されています。これは v2.6.0 で追加された脱獄済み iOS デバイス向けビルドに対応するものです。

v2.6.0 では保存場所に関する変更も入っています。リリースノートには「Added support for XDG_STATE_HOME and XDG_DATA_HOME, with automatic migration of existing sessions when possible.」とあり、XDG の環境変数に従った配置と既存セッションの自動移行がサポートされました（出典: v2.6.0 リリースノート）。共有環境やコンテナで動かす場合は、この配置を押さえておくと設計しやすくなります。

ダウンロードの実装｜レンジ取得・再開・ZIP の再梱包

ダウンロード側には appstore_download.go / appstore_download_range.go / appstore_partial_zip.go / appstore_zip_headers.go といったファイルが並び、依存ライブラリには howett.net/ranger（HTTP のレンジ取得を扱うライブラリ）が含まれています。ZIP の一部だけを範囲指定で読み取る処理が実装されていることが、ファイル構成と依存関係の両方から読み取れます。

機能面での変更としては、v2.3.0 で未完了ダウンロードの再開（PR #322）が入り、v2.6.0 のリリースノートでも「fixed issues with resuming interrupted downloads, including when progress output is disabled」として再開処理の修正が挙げられています。大きなパッケージを不安定な回線で取得する場面を想定した実装が積み重ねられている、と見てよいでしょう。

処理性能に関わる変更としては、v2.5.0 で ZIP の再梱包処理（replicateZip）の高速化と ZIP フォーマットエラーの修正が外部コントリビュータから入っています（PR #506）。

sinf（ライセンス情報）の注入が意味すること

ipatool がダウンロード後に行う処理のうち、成果物の性質を理解する上で最も重要なのが sinf の注入です。sinf は App Store が発行するライセンス情報のファイルで、ipatool は取得したパッケージの中にこれを書き込みます。

pkg/appstore/appstore_replicate_sinf.go の実装を読むと、処理は次の流れになっています。

1. 取得した ZIP を一時ファイルへ「再梱包」する。各エントリは OpenRaw / CreateRaw を使い、圧縮済みデータとタイムスタンプを変えずにコピーする
2. エントリの種別に応じてフラグを調整する。deflate 圧縮のエントリには data descriptor のフラグを付け、無圧縮（store）のエントリとディレクトリでは外す
3. SC_Info/Manifest.plist が読める場合はその SinfPaths が示すパスへ、読めない場合は Info.plist の CFBundleExecutable から Payload/<バンドル名>.app/SC_Info/<実行ファイル名>.sinf を組み立てて sinf を書き込む
4. 元のファイルを削除し、一時ファイルをリネームして置き換える

手順 2 の意図は、ソース上のコメントに書かれています。

// Frame deflated files with a trailing descriptor for streaming
// installers, without changing their compressed data or timestamps.
// Stored files need inline sizes because they have no stream terminator.

出典: pkg/appstore/appstore_replicate_sinf.go（原文のまま引用、改変なし）

ストリーミング形式のインストーラが扱えるように ZIP の構造を整える一方、圧縮データとタイムスタンプには手を付けないという設計意図が明記されています。v2.6.0 のリリースノートでも「Downloaded IPAs now include iTunes artwork when available, with fixes for OTA installation compatibility.」として OTA インストール互換性の修正が挙げられており、取得したパッケージをそのままインストールに使える状態に保つことが設計目標に含まれていると読み取れます。

また、sinf が提供されないケースについてもコメントが残されています。

// Device-based downloads can omit sinfs even when the package has a
// manifest. Preserve the archive rewrite, but only inject supplied data.

出典: pkg/appstore/appstore_replicate_sinf.go（原文のまま引用、改変なし）

この実装から整理できるのは、ipatool の出力は「App Store が配る配布パッケージ + ライセンス情報」であるということです。実行バイナリの暗号化を解く処理はソース上に見当たりません。この点は ipatool 側の文書に明示されているわけではなく、sinf 注入の実装内容と、後述する復号系ツールの位置づけを突き合わせた整理です。

依存ライブラリの構成

go.mod から主要な依存関係を挙げると、CLI フレームワークに spf13/cobra、リトライに avast/retry-go、ログに rs/zerolog（--format json の構造化出力と整合します）、進捗表示に schollz/progressbar/v3、plist の解析とレンジ取得に howett.net/plist と howett.net/ranger、Mach-O 形式の解析に blacktop/go-macho、アーカイブ処理に bodgit/sevenzip と klauspost/compress、資格情報に byteness/keyring が使われています。テストは onsi/ginkgo + onsi/gomega + go.uber.org/mock の構成で、cmd/ 配下の各ファイルにはテストファイルが併設されています。

依存先の blacktop/go-macho は、後述する類似プロジェクト blacktop/ipsw の作者が開発しているライブラリです。この領域のツール群が互いのライブラリを使い合う関係にあることが、依存関係からも見て取れます。

対応プラットフォームと動作環境｜macOS / Linux / Windows / 脱獄 iOS

README の Requirements 節は、前提条件を 2 つだけ挙げています。

• A supported operating system (macOS, Linux, Windows or iOS).
• An Apple Account already configured to use the App Store.

出典: github.com/majd/ipatool（README「Requirements」）

実行できる OS は macOS / Linux / Windows / iOS です。このうち iOS については、v2.6.0 のリリースノートで「Run on jailbroken iOS devices.」として脱獄済みデバイス向けのビルドが追加されたことが示されています（出典: v2.6.0 リリースノート）。通常の iOS 端末で動くという意味ではない点に注意が必要です。

そしてもう 1 つの前提が、App Store の利用設定が済んでいる Apple Account です。この条件は後述の制約セクションで改めて扱います。

インストール経路

README は Linux / Windows では GitHub Releases からバイナリを取得する方法を案内し、macOS では Homebrew を案内しています。

$ brew install ipatool

出典: README の Installation 節（原文のまま引用、改変なし）

Homebrew formula のページでも、配布されているバージョンが v2.6.0、ライセンスが MIT であることが確認できます。

ソースからビルドする場合は Go のツールチェインを使います。

$ go build -o ipatool

出典: README の Compiling 節（原文のまま引用、改変なし）

go.mod の指定は Go 1.25.0 です。ユニットテストは go generate ./... と go test -v ./... で実行できると README に記載されています。

取得対象プラットフォーム

--platform で指定できる値は iphone（iOS）/ ipad（iPadOS）/ appletv（tvOS）/ visionos / macos の 5 種です。このうち visionOS は v2.5.0 で検索・ダウンロード対応が追加され（PR #534）、macOS App Store 対応は v2.6.0 で追加されました。

v2.6.0 のリリースノートでは macOS 対応の範囲が「Search for and download Mac apps, list available versions, and retrieve version metadata using --platform macos」と記載されており、検索・ダウンロード・バージョン一覧・メタデータ取得が揃っていることが分かります（出典: v2.6.0 リリースノート）。言い換えると、macOS 対応はごく最近追加された機能であり、iOS 系と同等の実績を期待する段階にはないと見ておくほうが安全です。

類似 OSS との違い｜ipatool-py・frida-ios-dump との使い分け

この領域で名前が挙がるツールは、取得対象と必要環境が大きく異なります。「どれも ipa を落とすツール」とまとめてしまうと選定を誤るため、軸を分けて整理します。

数値はいずれも 2026 年 10 月 5 日時点の GitHub API 取得値です。

ipatool-py との違い｜同じ目的・別実装、ただしライセンス未設定

NyaMisty/ipatool-py は、App Store から ipa を取得するという目的がほぼ同一の Python 実装です。ipatool を候補に挙げる場面では、ほぼ必ず比較対象になります。

差分は 3 点です。1 つ目は実行環境で、Python 実装のため Python ランタイムが必要になり、単一バイナリを配置するだけの構成は取れません。2 つ目はライセンスが設定されていないことです。GitHub API 上でライセンス情報が null であり、業務利用の可否を法務レビューで判断する際にこれは大きな障害になります。ライセンスが明示されていないコードは、原則として利用条件が保証されていない状態です。3 つ目は更新頻度で、最終 push が 2026-01-11 と、連続してリリースが出ている ipatool に比べて間隔が開いています。

「同じことができる Python 実装」という理解で候補に並べるのではなく、ライセンスの有無が選定条件になるかを先に確認するのが実務的な判断順序です。

frida-ios-dump / bagbak との違い｜目的がそもそも別

AloneMonkey/frida-ios-dump は、リポジトリの説明文で自らを「pull decrypted ipa from jailbreak device」と位置づけています。ChiChou/bagbak も同系統で、「Yet another frida based iOS dumpdecrypted」と説明され、App Extension も復号対象に含めると述べています。

両者と ipatool の違いは、機能の多寡ではなく目的そのものです。

• 必要環境: ipatool は Apple Account があれば macOS / Linux / Windows で動きますが、Frida 系は脱獄済みの実機と Frida の環境構築が前提になります
• 取得物: Frida 系は端末上でインストール・復号された状態のバイナリを抜き出します。ipatool は App Store の配布物を取得するため、実行バイナリは暗号化されたままです
• メンテナンス状況: frida-ios-dump の最終 push は 2023-05-03 で停滞気味です。bagbak はリポジトリの説明文に「[deprecated]」と自ら記載しています

したがって選択は「どちらが優れているか」ではなく、暗号化を解いた実行バイナリが必要かどうかで決まります。静的解析でバイナリを読みたいなら ipatool の出力は出発点になりませんし、配布物そのものを一次資料として保全したいなら脱獄環境を用意する必要はありません。なお「ipatool の出力は復号されない」という整理は、ipatool 側の文書に明示された記述ではなく、復号系ツールの自己定義と sinf 注入の実装内容から導いたものです。

ipsw・apkeep との違い｜対象レイヤとプラットフォームが別

blacktop/ipsw は「iOS/macOS Research Swiss Army Knife」と説明されており、アプリ単体ではなく iOS / macOS のファームウェア（IPSW）や OS の内部構造を調査するツールです。ipatool が依存している blacktop/go-macho の作者プロジェクトでもあります。アプリの配布物を取得したいのか、OS 側を調べたいのかで対象レイヤが分かれます。

EFForg/apkeep は Android の APK をコマンドラインで取得するツールです。「ストアの配布物を CLI で取得する」という発想は ipatool と同型で、iOS と Android の両方で同じ運用を組みたい場合の対応物として位置づけられます。

導入前に確認すべき制約とリスク

ここまでの内容から、採用判断を左右する制約を整理します。いずれも導入後に判明すると手戻りになる項目です。

1. Apple Account が必須で、検索だけでも認証が必要 README の Requirements に明記されている前提です。さらに実装上、search もアカウント情報を参照するため、認証なしで試す経路はありません。業務で使う場合は「どのアカウントを使うか」「2FA の運用をどうするか」をツール導入と同時に決める必要があります。

2. ライセンス未保有のアプリは --purchase なしでは取得できない download の実装では、ライセンスが必要というエラーを受けたときのリトライが --purchase 指定時に限られています。無料アプリを含め、アカウントがそのアプリのライセンスを持っていない状態では、明示的なライセンス取得を挟まないと取得できません。

3. 出力は配布パッケージであり、実行バイナリは復号されない sinf 注入の実装内容から読み取れる整理です。解析用に復号済みバイナリが必要な場合、ipatool だけでは目的を満たせません。

4. 取得したパッケージは ZIP として再梱包される sinf を書き込む過程で ZIP が再構成されます。圧縮データとタイムスタンプは保持される設計ですが、ファイル全体のバイト列が配布物と完全に一致する前提の検証（ハッシュ値の突き合わせなど）には向きません。

5. App Store の非公開 API に依存する構造的リスク 認証方式の置き換え・エンドポイントの動的解決・レガシー認証へのフォールバックといった変更がリリース履歴の中心を占めています。これは追随が継続している証拠でもありますが、同時にApple 側の変更で動作しなくなり得ることを意味します。業務フローの不可欠な部分に組み込む場合は、停止したときの代替手段を用意しておくのが安全です。

6. 自動化には --non-interactive と 2FA の設計が必要 非対話モードでは 2FA コードが必要になった時点で処理が終わり、コードを添えた再実行が求められます。CI から定期実行する構成を組むなら、ここを人の介在なしでどう回すかを先に設計しておく必要があります。

7. アプリの取得・取り扱いは利用条件に照らした判断が必要 README には法的な注意事項の記載はありません。取得したパッケージの取り扱いについては、対象アプリの利用条件や社内規程に照らして各自で判断する領域になります。ツールがライセンス情報（sinf）を扱う設計であること自体が、配布物には権利関係が紐づいているという前提を示しています。

なお ipatool 自身のライセンスは MIT で、LICENSE で確認できます。ツールのライセンス条件そのものは明確です。

ipatool を選ぶ・選ばない判断軸とメンテナンス状況

候補として残すケース

• 自アカウントが所有するアプリの特定バージョンを再現したい。バージョン識別子を介した取得フローが用途に合います
• クロスプラットフォームの単一バイナリで済ませたい。Go 製で Homebrew と Releases から配布されており、Python 等のランタイムを前提にしません
• 配布物そのものを一次資料として保全したい。App Store が配るパッケージを取得する設計が目的と一致します
• macOS App Store のアプリも同じ道具立てで扱いたい。v2.6.0 で --platform macos が追加されています

別手段を検討すべきケース

• 復号済みの実行バイナリが必要 → Frida 系（frida-ios-dump / bagbak）の領域です。ただし脱獄実機が前提で、frida-ios-dump は更新が停滞し bagbak は deprecated を自称している点も踏まえた判断が必要です
• OS・ファームウェア層の調査が目的 → ipsw が対象レイヤとして合致します
• Android が対象 → apkeep が対応物です
• Apple Account を用意できない / 2FA 運用を回せない → ipatool の前提条件を満たせないため、候補から外れます

メンテナンス状況の評価

「メンテナンス状況は健全か」という観点では、ポジティブな指標が揃っています。

• 2026 年 2 月〜9 月に v2.3.0 / v2.3.1 / v2.3.2 / v2.4.0 / v2.5.0 / v2.6.0 の 6 リリースが出ています
• 最終 push は 2026-10-01、オープン Issue は 18 件、フォークは 961 件です
• 外部コントリビュータの PR がマージされています（ZIP 再梱包の高速化 PR #506、FailureType 5002 の修正 PR #500 など）
• アーカイブされておらず、フォークでもない本家リポジトリです

一方で、その更新内容を読むと大半が Apple 側の変更への追随です。これは「活発に直されている」と同時に「直し続けなければ動かない」ことも意味します。健全性の評価は「開発が止まっていないか」だけでなく、「止まったときに自分たちが困る度合い」まで含めて行うのが妥当でしょう。

リリース履歴が一次情報として公開されているため、採用後も Releases 一覧を定期的に確認する運用を決めておくと、仕様変更の影響を早く把握できます。

まとめ｜ipatool 採用判断のチェックポイント

ipatool は、App Store 上の iOS / iPadOS / tvOS / visionOS / macOS アプリを検索し、.ipa または .pkg を取得する Go 製の CLI です。2026 年 10 月 5 日時点でスター 11,483、ライセンスは MIT、最終 push は 2026-10-01 で、アーカイブもフォークもされていません。認証は App Store クライアントの通信を再現する形で成立しており、ダウンロードはレンジ取得と再開に対応し、取得後にライセンス情報（sinf）をパッケージへ書き込む設計になっています。

候補を絞り込む前に埋めておきたい項目を挙げます。

• Apple Account を用意できるか: 検索を含むすべての操作で認証が必要です。業務用アカウントの運用方針を決められるか
• 対象アプリのライセンスを保有しているか: 未保有なら --purchase でライセンス取得を挟む設計を許容できるか
• 復号済みバイナリは不要か: 必要なら Frida 系が領域であり、ipatool の出力は出発点になりません
• 実行環境は対応 OS か: macOS / Linux / Windows、または脱獄済み iOS。CI で動かすなら --non-interactive と 2FA の再実行設計を用意できるか
• Apple 側の仕様変更に追随する運用を許容できるか: 動かなくなった場合の代替手段と、Releases を追う運用を決められるか

ipatool には公式サイトもドキュメントサイトもなく、一次情報は README と Releases、そしてソースコードに限られます。本記事は 2026 年 10 月 5 日時点の公開情報に基づく整理であり、実行環境での動作検証は行っていません。採用を判断する段階では、GitHub リポジトリの README と Releases 一覧で最新の記述を確認することをおすすめします。

関連情報

モバイルアプリの検証環境の整備や、OSS を組み込んだ開発・運用体制の設計をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。

出典・参考リンク

• majd/ipatool（リポジトリ / README）
• README の Usage 節
• README の Installation 節
• GitHub Releases 一覧
• v2.6.0 リリースノート
• LICENSE（MIT）
• Homebrew formula: ipatool
• cmd/auth.go / cmd/download.go / cmd/search.go / cmd/get_version_metadata.go / cmd/purchases.go
• pkg/appstore/appstore_replicate_sinf.go
• 類似リポジトリ: NyaMisty/ipatool-py / AloneMonkey/frida-ios-dump / ChiChou/bagbak / blacktop/ipsw / EFForg/apkeep