確認日：2026年10月4日。対象は 3a8d74d のソースと、その後のローカル準備差分。Apple のアカウント・契約、署名済み配布パッケージ、TestFlight での実機動作は、この記録だけで確認済みとは扱わない。

アプリターゲットに直接指定した DEVELOPMENT_TEAM は、プロジェクトの Configs/Signing.xcconfig より優先される。ローカルの Team を反映させるには、ターゲットで $(inherited) を使い、Git 管理外の Configs/Signing.local.xcconfig に Team を設定する。Xcode で実効値を確認する。新しいローカル xcconfig を外部から作成した直後は、プロジェクトを開き直してから確認する。

配布対象の最低 OS は、macOS 26.5、iOS／iPadOS 27.0 として準備した。Music Understanding の音楽解析は OS 27 以降に限られる。最低 OS は最終 Archive の LSMinimumSystemVersion／MinimumOSVersion と照合する。macOS の著作権表示はソースの MIT 表記に合わせ、アプリカテゴリを Music に設定した。

アプリ本体の API 使用を調べ、UserDefaults は CA92.1、システム起動時間は 35F9.1、ファイル日時は表示・アプリ管理ファイル・ユーザー選択ファイルの用途に応じて DDA9.1、C617.1、3B52.1 を申告する。Manifest を置くだけでは同梱の証明にならないため、実際のアプリのリソースから読み出して元ファイルと比較する。Apple の承認理由

依存 SDK 自身の申告は別に確認する。解決済みの SFBAudioEngine 0.14.0 は fstat／mach_absolute_time、CXXMonkeysAudio 12.13.0 は stat を使用し、確認したパッケージには manifest がない。アプリ本体の申告を SDK の申告の代わりにしない。SDK 側の申告、最終リソース、Organizer の Privacy Report と Validate の結果をそろえる。Manifest の追加

この2つはソースから静的リンクする Swift package である。固定 revision の source snapshot に最小パッチを加え、対象の Clang／C++ target 自身が manifest を resource として所有する構成を組み込んだ。既存の音声処理ソースは固定した上流と byte 単位で一致し、変更は2件の Package.swift と2件の manifest に限る。macOS／iOS の Release Archive と配布用 pkg／IPA に、アプリ本体と SDK 2件の計3 manifest が含まれ、各ソースと内容が一致した。アプリが独自に SDK 名の bundle を置く方法で申告済みとは扱わない。

ビルドには SimpleMediaPlayer.xcworkspace を使う。project と Vendor/SFBAudioEngine を同じ workspace に参照させ、既存の remote package を同名の local package で置き換える。SFBAudioEngine から CXXMonkeysAudio を相対 path で参照する。解決ログとコンパイル元が Vendor 配下であることを確認し、元の23件の pin 情報が変わっていないことを照合した。start.sh、lint.sh、CI、日英 README のビルド・Archive 手順も workspace に統一した。Apple の local package override

日英のポリシー原稿と、設定から読めるオフライン表示を準備した。曲の削除はアプリ管理用のコピーと曲情報を対象とするが、音楽解析キャッシュ・音量測定結果・設定まで一括削除する操作ではない。TestFlight によるクラッシュ・利用情報の共有も、アプリ独自のメディア送信とは分けて説明する。外部審査前に原稿を確認して公開 URL を用意する。TestFlight とプライバシー

固定した全23パッケージの revision を解決済みキャッシュと照合した。新たに24件のライセンス文書を準備したが、文書の同梱だけで LGPL／MPL の条件が完了するとは判断しない。実際に配るバイナリと一致するソース、パッチ、ビルド手順、利用者への告知、改変・再リンクに関する提供方法をそろえる。特に tta-cpp は LGPL 3 であり、署名付き配布方法に対して条件を検討する。FFmpeg の配布条件、固定した tta-cpp のライセンス

FFmpegBuild 3.6.0 の macOS／iOS バイナリでは、AES、DES、RC4 等の関数を確認した。ビルド設定の --disable-network やアプリ本体の SHA256 使用だけでは、含まれる暗号化処理を分類できない。関数の存在は非免除という結論にも直結しないため、配布地域・用途・SDK の情報を使って輸出申告を確定してから ITSAppUsesNonExemptEncryption を設定する。Apple の輸出コンプライアンス

アプリの FFmpeg 経路は ASF signature を確認した WMA 入力で、復号鍵を渡していない。FFmpeg n8.1.3 の ASF 復号呼び出しは、入力 context に20バイトの鍵がある場合に限られる。ただし利用経路の確認と、同梱する暗号機能の申告は別であり、通常の WMA 再生だけを根拠に免除を決めない。FFmpeg の ASF 実装

同じ配布用 macOS／iOS バイナリに、ASF の MultiSwap 処理も確認した。独自・非標準の項目を「念のため」追加するのではなく、実装の存在、申告上の分類、書類免除をそれぞれ根拠で判断する。Apple／BIS の非標準暗号の説明は公開されているかにも言及するため、歴史的な独自方式という情報だけでは現在の分類を確定できない。FFmpeg の実装、BIS の定義

BIS の現行 5A002.a Technical Note 1 は、整合性・DRM・娯楽目的の暗号処理を data confidentiality 暗号から除外し、音楽・動画の専用プレーヤーを例示している。メディア用途の除外を検討する具体的な根拠になるが、同庁は他の CCL 区分も確認するよう求めている。これだけで Apple の書類免除、EAR99、フランスの免除を確定したとは扱わない。BIS の用途説明

macOS の Music の SDEF は com.apple.Music.library.read を公開し、既存の scripting-targets はこれと一致する。一時例外を外せるかは、署名済み Sandbox アプリで Music の起動・一致曲・空ライブラリ・許可・拒否を試して判断する。現在は例外を維持し、読み取る項目と操作を審査メモに記載した。外部 LAME のパスに実行ファイルがあることも、Sandbox 下での MP3 変換成功を保証しないため、配布版とクリーンな Mac で別に確認する。

今回の署名前 Release Archive は macOS／iOS とも作成に成功した。本体と19 framework のアーキテクチャ、アプリ dSYM、日英リソース、manifest、新旧ライセンス文書の同梱と内容一致、quarantine の不在を確認した。macOS の既存 LocalizationTests は6件成功し、追加した設定画面は日英で開く・スクロール・戻る・閉じる操作を手動確認した。変更ファイルの strict lint は成功した。iOS の画面操作、実機、署名後の Validate／Upload は未実施である。

• macOS の本体と全 framework に arm64／x86_64、iOS に arm64 が含まれること。
• Bundle ID、Version／Build、最低 OS、macOS の著作権・カテゴリ、iOS の不透明な1024pxアイコン。
• Privacy Manifest、日英リソース、追加・既存のライセンスとフォントの告知、アプリ dSYM。
• macOS の本体・組み込み framework を含む全ファイルに quarantine が残らないこと。
• 配布署名後の embedded.provisionprofile／embedded.mobileprovision。署名前の検証用 Archive はアップロード用として扱わない。

新規インストール時はライブラリが空なので、ログイン不要の審査サンプル URL と取り込み手順を用意する。準備した合成 WAV／M4A／MP4 は取り込み・再生・シーク用で、音楽の KEY／BPM 精度を評価する素材ではない。

Developer Portal の Bundle ID 登録と、App Store Connect のアプリレコード作成は別の操作である。アプリの表示名は登録時の検証で重複が判明することがある。名前のエラーでは Bundle ID まで変更せず、表示名を決めて登録を再開する。

開発証明書と開発 profile で署名した Release Archive は、配布時の再署名に使えるが、それ自体は App Store Connect 向けの配布パッケージではない。署名の Team、Bundle ID、profile の期限・種別、get-task-allow、組み込み framework の署名を確認し、App Store Connect 用に export した最終成果物を再確認する。制限された実行環境では codesign の信頼検証が失敗する場合があるため、信頼情報を読める環境での再確認と、実際の署名不良を区別する。

今回の両 platform のローカル export は App Store Connect 用の配布署名で成功した。macOS の installer 署名と、取り出した本体・19 framework の署名、profile、アプリ識別子を確認した。iOS IPA では配布 profile、get-task-allow=false、開発用端末一覧の不在、本体・19 framework の署名を確認した。両者の3 manifest は再署名後もソースと一致した。export 成功は Apple サーバーによる Validate／Upload、輸出申告の受理、TestFlight 審査の成功を意味しない。

SDK 組み込み後の macOS の既存 LocalizationTests、ExtendedAudioSourceTests、ExtendedAudioValidationTests は24件成功し、失敗・skipはなかった。APE decode、WavPack metadata、前置 ID3v2、部分出力後の破損検出など、関連する既存の確認経路を対象にした。lint は既存警告43件で成功し、baseline を増やしていない。iOS の実機操作、署名済み Sandbox の Music／外部 LAME、他 SDK 全体の申告・ライセンス・暗号化分類は別に確認する。

Prepare and submit your apps for iPhone Duo（2026年10月5日）によると、iPhone Duo の発売日は2026年10月23日である。Xcode 27.1 で再コンパイルし、Device Hub で全ポーズ・全方向の挙動を確認するよう求めている。App Store Connect に Duo のスクリーンショットを登録すると、製品ページに Duo 向けに最適化されたことを示すバッジが表示される。2027年4月以降に提出するアプリでは Duo のスクリーンショットが必須になる。スクリーンショットの仕様は、この必須条件を iOS 27.1 以降の SDK を使うアプリに限定している。

仕様の画素数は外側画面と内側画面で異なる。

画面	縦	横
外側（Closed）	1398 × 2034	2034 × 1398
内側（Open）	2007 × 2853	2853 × 2007

他の iPhone の行と異なり、Duo の行には不足時に代わりに使うサイズの記載がない。他機種の画像の縮小で代用できるとは扱わない。形式は他機種と同じで、1サイズにつき10枚まで、.jpeg／.jpg／.png、アルファチャンネルなし。

Simulator で撮影するときは、xcrun simctl io <device> enumerate で表示先を確認する。外側画面は既定の LCD、内側画面は --display=LCD-1 で撮影する（実装記録を参照）。撮影した画像の画素数を上の表と照合し、合わない場合は縮小や切り抜きではなく撮影条件を見直す。

App Store Connect には、スクリーンショット・製品ページのヘッダー・その他のメタデータを Duo の製品ページで確認するプレビューツールが追加された。提出前にこのツールで外側・内側の見え方を確認する。現時点で Duo の撮影、App Store Connect への登録、プレビューツールの確認はいずれも未実施である。