macOS 27 へのアップグレード

要点

旧版やテスト版の AppPorts で再署名を許可した後、macOS 27 で WeChat などが Finder / Dock から開けなくなった場合は、以下の修復手順に進んでください。古いコンテナリンクを復元してから、元のアプリを復元するか公式版を再インストールします。データフォルダを削除したり、再び署名し直したりしないでください。 署名エラーだけでデータ破損とは判断できません。

修復

アプリ一覧の 「修復」 を直接クリックするか、右クリックで「修復手順を表示」を選びます。ターミナル操作は不要です。この説明は現在の開発版に対応しています。修復パネルがない旧版でも、以下の手動手順を利用できます。元の外部ドライブを接続し、アプリを完全に終了して、データとバックアップを保管してください。

ログイン時の自動再署名

現在の開発版では、macOS 27 以降でログイン時の自動再署名を無効にし、以前のログインタスクを停止して削除します。処理が完了していない場合は、設定画面から再試行できます。

macOS をアップグレードする前に、AppPorts を更新して一度開いてください。 インストール済みのバックグラウンドタスクにバージョンチェックが追加されます。新版をダウンロードしただけでは、以前のタスクは更新されません。

1. 古いリンクで移行したコンテナデータを復元する

外部ドライブへのコンテナリンクが見つかった場合は「すべて復元」を選びます。なければこの手順は不要です。手動では「データディレクトリ」→「アプリデータ」でアプリを選び、リンク済みのコンテナを復元します。APFS マウント移行済みのデータは、署名修復のためだけに戻す必要はありません。

2. 元のアプリを復元するか公式版を再インストールする

• 完全な元アプリのバックアップがある場合：「元の署名を復元」を使います。外部ドライブ上の実際のアプリも直接復元できます。先にローカルへ戻す必要はありません。AppPorts は現在のアプリとバックアップの一致を確認します。更新や内容の変更がある場合は、対応する公式の元アプリが必要です。
• 古い署名情報だけの場合： 同じバージョンの公式 .app を指定するか、App Store / 開発元サイトから再インストールします。証明書名だけでは元の署名は再作成できません。
• 外部アプリに上書きインストールする場合： 先に「ローカルに戻す」を使い、ローカルの起動用アプリだけが置き換わる状態を避けます。

コンテナのデータフォルダは削除しないでください。 重要なデータは別途バックアップします。履歴やログイン状態の利用可否は、バージョン、権限、データの状態にも依存します。署名のバックアップと復元も参照してください。

3. 再確認して Finder / Dock から開く

「再確認」で署名を確認した後、Finder / Dock から開き、元のデータが使えるか確認します。「署名を確認できません」は、置換済みとも修復済みとも判断できない状態です。ドライブを接続して再試行してください。スキャンで復元用バックアップは削除されません。現在開けるアプリは後で対応できますが、それだけで元の署名が復元されたとはいえません。

4. 任意：データの移行を続ける

修復後、「アプリデータ」で対象を選び「移行」をクリックします。AppPorts は保存先を確認し、コンテナには署名を保持する APFS マウント移行を使用します。現在は暗号化されていない APFS 外部ドライブが必要です。別のドライブを選ぶか、ローカルに残すこともできます。macOS がリムーバブルボリュームへのアクセスを求めたら許可し、以後はアプリ使用前にドライブを接続してください。APFS の準備を参照してください。

影響を受けるケース

項目	説明
発生条件	macOS 27 へのアップグレード
対象アプリ	~/Library/Containers/ または ~/Library/Group Containers/ のデータを移行し、Ad-hoc 再署名を行ったアプリ。または右クリックから手動で再署名したサンドボックスアプリ
典型的な症状	Finder / Dock から開いても反応せず、アイコンが一瞬表示されて消え、エラーダイアログも出ない。ただし、再署名したすべてのアプリで起きるわけではなく、同じ macOS 27 で QQ Music は正常に動作した
データ	署名エラーだけでデータ破損とは判断できません。元データとバックアップを保管してください
確認済みの例	WeChat 4.1.15、macOS 27.0 (26A428)

再署名によってアプリのサンドボックス ID が取り除かれたことが原因です。macOS 27 が「このアプリにこのコンテナを使う資格があるか」を確認するとき、システムに元の署名の許可記録が残っていると、新しい署名が一致せず拒否されます。WeChat のログには Failed to match existing code requirement と出ます。QQ Music など、古い記録がないアプリは現在は許可されますが、キーチェーンのログイン状態など、失われたエンタイトルメントは同様に戻りません。仕組みはコンテナデータ、サンドボックスと署名 IDを参照してください。

元の開発者署名のバックアップ記録があり、実際のアプリが現在 Ad-hoc と確認できた場合にだけ署名の置換を表示します。タイムアウトやドライブへのアクセス失敗は再確認が必要です。元から Ad-hoc のアプリ、移行済みであること、ローカルの起動用アプリは、再署名が必要な根拠にはなりません。

避けるべき対処

対処	解決しない理由
データをローカルに戻すだけで修復完了とする	復元は外部データを読めない問題だけを解決し、署名は直さない。再署名したアプリは復元後もすぐ終了する
「Resign This App」をもう一度実行	再署名自体が原因であり、エンタイトルメントを再び消すだけ
アプリにフルディスクアクセスを付与	コンテナの検証を回避できる場合もあるが、キーチェーンの権限は失われており、ログイン状態の問題は残る。一時的な手段にすぎない
ターミナルから開ければ修復済みと判断	ターミナルの権限を借りて起動しているため、修復できたように見えるだけ。Finder / Dock から開けるかで判断する

アップグレード前の確認

まず AppPorts の「署名置換済み」を確認し、修復に進みます。表示がないことは macOS 27 対応の保証ではありません。補助スクリプトは古いバックアップに残るアクセス可能なパスだけを確認するため、移動済みアプリ、未接続ドライブ、起動用アプリでは見落とすことがあります。

詳細：任意の技術的な確認

BACKUP_DIR="$HOME/Library/Application Support/AppPorts/signature-backups"
for plist in "$BACKUP_DIR"/*.plist; do
  [ -f "$plist" ] || continue
  original=$(/usr/libexec/PlistBuddy -c "Print :signingIdentity" "$plist" 2>/dev/null)
  app=$(/usr/libexec/PlistBuddy -c "Print :originalPath" "$plist" 2>/dev/null)
  case "$original" in ""|ad-hoc) continue ;; esac
  [ -d "$app" ] || continue
  if codesign -dv "$app" 2>&1 | grep -q "Signature=adhoc"; then
    printf "%s\n    %s\n" "$app" "$original"
  fi
done

アップグレード後の症状確認

まず Finder / Dock から開きます。失敗し、署名の置換も確認できた場合は修復に進んでください。それ以外はアプリの互換性、権限、ドライブも確認します。

詳細：任意の技術的な確認

例を実際のアプリのパスに置き換えてください。ローカルの起動用アプリは使いません。以下は情報の読み取りだけです。Ad-hoc は元の署名と比較し、アクセス拒否のログは原因を確定する証拠ではなく手がかりとして扱います。

codesign -dv --verbose=4 "/Applications/WeChat.app" 2>&1 | grep -E "Authority|TeamIdentifier|Signature"
log show --last 1m --style compact 2>/dev/null | grep -i "rejected approval request"

AppPorts 1.9.0 の変更点

以下は現在の開発版の動作です。

• 標準モードではコンテナに APFS マウント移行を使用し、サンドボックスアプリの再署名を拒否します。
• 完全なバックアップから元のアプリを復元できます。旧記録には対応する公式アプリが必要です。
• 確認できた署名の置換と、確認できなかった状態を区別し、復元用データを保持します。
• 従来のデータ移行モードは標準で無効です。AppPorts の更新だけでは置換済みの署名は復元されません。

よくある質問

チャット履歴は失われますか？

署名エラーだけでは履歴の破損を意味しません。コンテナ、外部データ、バックアップを保持し、データを消すアンインストーラーは使わないでください。修復後に確認が必要で、ログイン権限の再設定が必要な場合もあります。

データを復元しても開けません

パスの復元だけでは開発者署名は戻りません。完全なバックアップか公式版を使って復元し、再確認してください。署名が正常でも失敗する場合はバージョンと権限を確認します。

WeChat だけで起きる問題ですか？

限りません。既存のテストでもアプリごとに結果が異なります。警告は確認すべきリスクであり、必ず失敗するという意味ではありません。

AppPorts がデータを壊したのですか？

観察された起動障害は以前の再署名方式に関連し、データ破損の証拠ではありません。他の問題を調べる際も元データを保管してください。標準の APFS コンテナ移行ではアプリ署名を保持します。

関連ドキュメント

• コンテナデータ、サンドボックスと署名 ID：仕組み
• マウント移行：新しい方式
• 外部ドライブに APFS が必要な理由
• 再署名とクラッシュ対策