Mac アプリの更新前に確認しておきたいこと
「すべてをアップデート」を押せば済むように見えても、更新前にはアプリの入手先、パッケージの信頼性、失敗した場合の復元方法を確かめたいところです。確認せずに進めると、ライセンスが使えなくなったり、同じアプリが二重に入ったり、インストールが途中で止まったりすることがあります。
まず、このアプリをどこからインストールしたのか、置き換えに失敗したら元に戻せるのかを確認します。
3つの更新経路には、それぞれのルールがある
Mac アプリの主な入手先は3つあり、入手先によって更新の仕組みも異なります。
| チャネル | 次のバージョンを決めるのは誰か | 典型的な失敗パターン |
|---|---|---|
| Mac App Store | そのApple ID向けのAppleストアカタログ | 購入状態、ファミリー共有、新しいmacOSの要件のためにアップデートできない |
| 開発者ダウンロード（Sparkle、Electron、独自方式） | ベンダーのフィードまたはダウンロードページ | 不一致のパッケージ、残ったヘルパー、または通知されないまま一部だけ置き換わる問題 |
| Homebrewのformulaまたはcask | Homebrewのformula/caskメタデータ | アプリ内蔵のアップデータがHomebrewと衝突する、またはbrew upgrade が一度に多くの項目を更新する |
これらとは別に、macOS 自体を更新する「ソフトウェアアップデート」があります。Chrome や WhatsApp、デザインツールは更新しません。システムが最新版でも、アプリまで最新とは限りません。
経路ごとの操作は Mac アプリの更新ガイド にまとめています。この記事では、更新を待つ場面、事前の確認事項、一括更新を避けたいケースを見ていきます。
新しいバージョンを今すぐ入れるべきとは限らない
セキュリティ修正は通常、優先してよいです。機能追加や大きなバージョン変更は、内容を確認してから判断します。更新を承認する前に、次の3点を確認してください。
- リリースノートに互換性を壊す変更がないか。 プラグインホスト、オーディオツール、IDE、署名付きバイナリを持つものは、更新後に既存の作業環境で使えなくなることがあります。
- ロールバックできるか。 App Storeの履歴、保管したDMG、Time Machineのスナップショット、Homebrewのpinは必要な版を保存・復元できるか確認する手がかりです。古いバージョンをあとで再ダウンロードできるとは限りません。
- 他の何かがこのビルドに依存していないか。 ピン留めしたCIイメージ、クライアント案件、ビルド番号に紐づくライセンスは、最新版への更新で追加の対応が必要になることがあります。
締め切り前は、手が空いている週でも、ついでに大型アップグレードをするには向きません。バックアップを済ませた、急ぎの作業がない週末のほうが適しています。
一括更新では一つの問題がほかにも影響する
一括更新ではアカウントやダウンロード、インストールの処理を共有するため、一つの問題がほかの更新を止めることがあります。
| 共有リスク | 起こること | より安全な習慣 |
|---|---|---|
| ブロックされた購入がリストを止める | 有料のApp Store更新がサインインまたは購入待ちになり、残りが始まらない | Storeの行と無料／検証済みダウンロードを分ける |
| 失敗後に全件をやり直してしまう | 置換失敗で半分更新されたバンドルが残り、すべてを再試行する | まず重要なアプリを一つずつ更新する |
| 誤ったチャネルの上書き | ウェブサイトのDMGでHomebrewまたはApp Store管理のコピーを上書きする | 置換前に出所を確認する |
| 未完了のチェックを「更新なし」と扱う | UIがまだスキャン中で空に見える | 判断する前にチェック完了を待つ |
更新情報が紛らわしいこともあります。ユニバーサル購入の記録、iOS 専用のバージョン、プレビュー版、特殊な形式のバージョン番号などが Mac 用の更新として表示される場合です。毎日同じ更新が出るのにインストールできないときは、繰り返し押す前に原因を調べます。
置換の前に検証する
開発者のサイトからダウンロードする場合は、パッケージの入手先と内容を確認します。
- すでに信頼しているHTTPSのダウンロードページを優先し、転送されたDiscordリンクは避けます。
- ベンダーが署名やチェックサムを公開している場合は、それで検証できるパッケージを優先します。
- 出所のわからないzipを
/Applicationsに展開するより、同じバンドル識別子のまま置き換えるアプリ内アップデータを優先します。 - アプリやヘルパーがファイルを書き込んでいる途中で更新しないよう、対象アプリを通常の手順で終了します。
Homebrew では brew outdated で更新候補を確認し、brew upgrade <token> で指定した項目を更新します。独自の更新機能を持つ GUI アプリもあるため、brew info を読んで管理方法を確認し、同じ .app を二つの更新機能で管理しないようにします。
問題に対処しやすい順番で更新する
- バックアップする、またはTime Machine／いつものスナップショットが新しいことを確認する。
- App Storeのサインインや購入プロンプトは単独で終わらせる。
- 今日使う予定の1〜2個のアプリを更新し、開いて普段の操作ができるか確かめる。
- 残りの低リスク更新をバッチで実行する。
- プラグイン、ドライバ、メジャーバージョンの更新は、別に時間を確保して行う。
更新が失敗したらバッチを止めます。失敗したアプリだけを再試行し、ベンダーの案内を読んでから続けます。キャンセルや失敗があっても、ほかの項目まで危険だということにはなりませんが、まずその失敗を確かめるべきです。
Mole でできること
Mole の更新一覧では、アプリごとに状態を確認できます。App Store と Sparkle 系の更新を並行して進められ、購入待ちの項目がほかの更新を止めません。失敗やキャンセルのあとも、そのアプリだけを再試行できます。更新はすべて 1 つの一覧に並びます。Mole だけで完了できるものを「すべて更新」の下に先に置き、その後に残りを並べます。それぞれのボタンには、アプリを開き直してアプリ自身に更新させるなど、更新方法を表示します。Mole がパッケージをダウンロードしてインストーラで開く場合は「アップデート」と表示し、完了まではインストーラの手順に従います。インストール済みアプリを置き換えられる方式では、対応するダウンロードを Mole が検証してから置き換えます。
中国のユーザーから、Mole 経由の Homebrew と App Store の更新が元の方法より遅いという報告があり、速度も見直しました。Dock から起動した Mole がプロキシ設定を引き継いでいない場合、Homebrew のダウンロードはシステムのプロキシを使うようになりました。実行中のアプリは cask のダウンロード中は開いたままにし、インストール時だけ終了します。「すべて更新」では、App Store の更新を 1 件ずつではなく最大 3 件同時に進めます。
一括で更新するかどうかは自分で判断します。Mole は入手先、進捗、失敗の理由を各アプリの横に表示します。コマンドや App Store と Homebrew の違いは Mac アプリの更新ガイド を参照してください。
よくある質問
すべての自動アップデータを有効にすべきですか？
ベンダーチャネルを信頼できるなら、ブラウザやその他の高リスクなネットワーククライアントには自動更新が妥当です。大型のクリエイティブツール、オーディオプラグイン、プロジェクトでバージョンを固定しているものは、内容を確認してから手動で更新してください。
HomebrewはウェブサイトのDMGより安全ですか？
どちらも万能に安全ではありません。Homebrew では formula の中身を確認でき、アップグレードのコマンドも決まっています。ベンダーの DMG も、署名があり、手順が文書化され、同じアプリを置き換えるものなら同じように問題ありません。問題は、両方のチャネルが同じインストールを管理し始めたときに起きます。
インストールしたのに更新が表示され続けるのはなぜですか？
よくある原因は、古いカタログのままチェックが完了した、ディスク上のバンドルが変わっていない、ヘルパーがまだ古いビルドのまま、フィードが Mac 以外やプレリリースのビルドを案内している、などです。再試行する前にアプリの「このアプリケーションについて」でバージョンを確認してください。
MoleはApp StoreやHomebrewを置き換えますか？
いいえ。Mole は更新を探し、対応する方法でインストールします。App Store のアカウント要件や Homebrew の管理ルールはそのまま適用されます。