前段
Unity as a Library （以下UaaL）は、UnityでビルドしたプロジェクトとObjectiveC/Swift/SwiftUIのプロジェクトを悪魔合体できるという変態的な素晴らしい仕組みだ。
基本的な仕組みは他のブログを参考にしていただけると良い。
https://jpdebug.com/p/2469679 (リンク切れ 2025/7/12 追記)
https://www.tattichan.work/entry/2021/06/25/Unity_as_a_Libraryと_SwiftUI_で作るARアプリ_%28前編%29 (リンク切れ 2025/7/12 追記)
ちなみに今回、当方で実践したのはUnity+SwiftUIであり、比較的参考文献が少ないが以下のブログが大変役に立った。
https://davidpeicho.github.io/blog/unity-integration-swiftui/
↑のリポジトリ
https://github.com/DavidPeicho/unity-swiftui-example/tree/old/unity2020
最近（2025/7/12 現在）だと以下のリポジトリが更新されていて助かった。
https://github.com/bdeweygit/unity-swiftui
このブログでは当方でUaaLでハマったことをツラツラと書いていく。
Q. 最新版の Xcode で UaaL を構築してみたら起動時にクラッシュする (2025/7/25 更新分)
Uaalを構築する手順は基本的には以下の通りである
- Unityプロジェクトをビルドする
- xcworkspace を作り、SwiftUIで作られているプロジェクト（例：SwiftUIProj.xcodeproj）とUnityで作られているプロジェクト（例：Unity-iPhone.xcodeproj）を二つ入れる
- Unity-iPhone.xcodeproj の "Data" フォルダのTarget Membership (右のプロパティに表示される)をUnity-iPhoneを外し、UnityFramework にする
- SwiftUIProj側でUnity起動プログラムを入れる
基本的にはそれだけである。
ただし双方がコントロールする場合は NativeCallProxy.mm/h のような仕組みが必要）
なのに、それをしてビルドしたところ以下のような画面でクラッシュする
厄介なのが以下のエラーメッセージが出るか、それ自体に意味はない。
Can't show file for stack frame : - stackNumber:4 - name:UnityClassic::Baselib_SystemSemaphore_CreateInplace [inlined]. The file path does not exist on the file system: /Users/bokken/build/output/unity/unity/External/baselib/baselib/Source/Darwin/Baselib_SystemSemaphore_DarwinApi.inl.h
わかるのはただ単に、UnityClassic::Baselib_SystemSemaphore_CreateInplace で落ちているということだけ。
A. スキーマ設定の「Debug executable」をオフにする
まさに同じ状況が stackoverflow で見つかった。
Unity framework for SwiftUI "Oddly Stepping" error in iOS 16.1
ここに解決法が書いてあった。
- Xcodeの上部にあるスキーマをクリックし "Edit Scheme..." を選択する
2. "Debug executable" のチェックを外して、Closeする
3. 再度ビルドすると、動くようになる
一時的な不具合のような気もするが、同じようなことで悩んでいる人がいたら一度やってみることをお勧めする
Q. Unity側を再ビルドしたら、Swift側でビルドできなくなった
Unityで再ビルド（Replace）すると
UaaLで全体ビルドがなぜか通らなくなる
A. Build System を「New Build System」に変更しなおす
UnityでiOSビルドを作ると、「Xcode Legacy Build system」で作ってしまう（Unity2021.1.6f1で確認）。これだとそもそもiOSビルドができない。
2022.5.21 追記
@mao_ さんのコメントでUnityバージョンアップによって、こちらが修正されているとの指摘をいただきました。
実際に最新版の 2021.3.3f1 で試したところ「New Build System」でビルドできました。
File → Project Settings で Build System を「New Build System」に変更すればビルドしてくれるのだが、一回リビルドしてしまうと再び「Legacy Build System」になってしまうので注意。
なお、通常の単体ビルドをすればエラーメッセージですぐに気づくのだが、UaaLでビルドしているとそれに気づかない。
Q. Unity側で起動時に「[libil2cpp] ERROR: Could not open」と出て、落ちる
こんな感じのログがコンソールに出てくる
[libil2cpp] ERROR: Could not open
/var/containers/Bundle/Application/
****/ZZZZ.app/Frameworks/UnityFramework.framework/Data/Managed/Metadata/global-metadata.dat
IL2CPP initialization failed
A. Unity側のプロジェクトで「Data」フォルダのTarget Membershipを「UnityFramework」にチェックを入れる
Unity側をビルドすると、「Data」フォルダが↓このように「Target Project」が「Unity-iPhone」になっているが（これはUnityでアプリを作るので当たり前）
↓
Swift側でビルドするのであれば、以下のように「UnityFramework」にしておかないとリンクされない（のでクラッシュする）
Q. なぜか以下のエラーが出てリンクができなくなる
/aaaa/bbb/NativeCallProxy-Bridging-Header.h:13:10: error: 'UnityFramework/NativeCallProxy.h' file not found
#include <UnityFramework/NativeCallProxy.h>
^
1 error generated.
<unknown>:0: error: failed to emit precompiled header
'/Users/myUser/Library/Developer/Xcode/DerivedData/XXX-
ahqzulzcsrizsffdoonndkyblpuk/Build/Intermediates.noindex/PrecompiledHeaders/
NativeCallProxy-Bridging-Header-swift_18V7S09DN9EIS-clang_7WH5WTMDIV2M.pch'
for bridging header 'NativeCallProxy-Bridging-Header.h'
A. Simulator用にビルドしようとしている
Unityだけで開発するときはほぼ実機でしかビルドしないだろうが、SwiftUIを使っているとついシミュレーターでもビルドしてしまうことがある。その際UaaLだとUnity側が実機ビルドにしか対応していないためビルドできない。
なお、Unityでも以下のブログのようにシミュレーター用にビルドすれば、UaaLもシミュレーター用にビルドできるかと思う。（が、今度は実機用にビルドできなくなる）
https://develop.hateblo.jp/entry/unity-ios-simulator
Q. なぜかBridging-Headerが見つからないと出てくるようになる
<unknown>:0: error: error opening input file 'XXX/YYY/NativeCallProxy-Bridging-Header.h'
(No such file or directory)
A. Bridgingファイルはプロジェクト管理されているので、移動したり名前変更すると見つからなくなる
例えば、「Bridging-Header.h」 の場所を「ObjC/Bridging-Header.h」 とかに再配置してみる。すると上記エラーが出てビルドができなくなる。
これは「Build Settings」の「Objective-C Bridging Header」という項目にファイルパスを書き込んであるからである。
つまりファイルを再配置や命名変更した場合は、忘れずにこの項目も変更しなくてはいけない。
参考ブログ