（的外れなことを言ってるかもしれませんが）
別のjobで、build_and_deployの成果をダウンロードして、fat binary化とXCFramework作成するのはどうでしょう？

具体的には：
matrixにupload-artifactみたいな変数を追加し、
x86_64-apple-ios、aarch64-apple-ios-sim、aarch64-apple-iosだけtrue（他はfalse）にし、
upload-artifactがtrueならactions/upload-artifactで適当な名前でアップロードし、
build_and_deployに依存した（needs）build-xcframeworkというjobを作成し、
その中でlipoやxcodebuildを行うのはどうでしょう？

別のjobで、build_and_deployの成果をダウンロードして、fat binary化とXCFramework作成するのはどうでしょう？

なるほど、upload / download artifactは他のjobにファイルの受け渡しをするために使えるのですね。
これを使えばおっしゃる通り、もとからあるjobに新しいjobを加える形にできそうです。
一旦このPRはDraftに戻して追加したいと思います。
ご指摘ありがとうございます。

@sevenc-nanashi に紹介していただいた方法を参考に改良しました。
レビューよろしくお願いいたします。

提案が１点だけ！ onnxruntimeのframeworkのビルドをonnxruntime-builder側でやるのはどうでしょう？ 役割を考えると、voicevox_coreのリリースにonnxruntime.frameworkが含まれる形より、onnxruntime-builder側のが適してるかもとちょっと思った次第です！

確かにその方がわかりやすそうです。
ただ、そうなるとiOS向けXCFrameworkを利用するユーザー向けに、onnxruntime-builderのXCFrameworkが必要となる旨を案内する必要が出てきそうです。

ひとまず、こちらのPRからはonnxruntimeのXCFrameworkをビルドするstepを取り除き、onnxruntime-builderへIssueを出します。

PR ありがとうございます！　見たところ、voicevox_core.xcframework のみをリリースする感じでしょうか？　onnxruntime.xcframework も作ってアップロードするようにすると良い気がしました。公式には iOS 向けの onnxruntime の dylib 配布はないので、VOICEVOX 側で用意しないと準備が大変になると思いました。

すみません、こちらを見落としていました。了解です！ #485 (comment)

もう１つ思いついたことがあるのですが、xcframework にまとめたものを releases で公開するなら、iOS 向けの個別の dylib は releases で公開しなくても良いかも？　と思いました。build_and_deploy ジョブの Upload to Release ステップは iOS 向けビルドの場合には行わないように条件を付け足すと良いかもしれません。

もう１つ思いついたことがあるのですが、xcframework にまとめたものを releases で公開するなら、iOS 向けの個別の dylib は releases で公開しなくても良いかも？　と思いました。build_and_deploy ジョブの Upload to Release ステップは iOS 向けビルドの場合には行わないように条件を付け足すと良いかもしれません。

そうですね、XCFrameworkが対応できないシーンとしてはXcode 11より前の環境が挙げられますが、Xcoode 11のリリースからすでに3年ほど経過しているので問題なさそうです。
32218f0 で対応しました。