はじめに
私のチームでは今年 Apple から発売された空間コンピューティングデバイスの Apple Vision Pro を購入し、デモアプリを作っています。

Apple Vision Pro は現在 Swift、Unity、Unreal Engine、Web などで開発ができます。
私は Unity に慣れているため、最初は Unity で開発をしていましたが、「Apple Vision Pro アプリ開発ガイド〜visionOS ではじめる空間コンピューティング実践集」という本(以後参考本)を読み、Xcode 内にある Reality Composer Pro というUnityのような見た目のツールを使えば、簡単なものなら Swift のコードをほとんど書かずに作れるということが分かりました。
そこで今回は Unity と Reality Composer Pro で同じようなものを作ってみて、開発のポイントを比較しました。
比較項目と結果の概要は以下の表のとおりです。それぞれの項目についての詳細は後述します。
比較項目 | Unity | Reality Composer Pro |
---|---|---|
ライセンス | 有償ライセンスが必要 | 不要(Xcodeに付随) |
アセット | Unity Asset Store の利用が可能 | 内蔵アセットまたは usdz 形式が必要 |
パーティクル | Editor と実機での見た目に差がある | 見た目の差はなし。プリセットあり |
手の実装 | XRHandSubsystem で高度な制御可能 | Anchoring で追随だけなら手軽に実装可能 |
AI サポート | GitHub Copilot の利用が可能 | Xcode 内で Swift Assist が今後利用可能? |
実機確認 | Play to Device で迅速に確認可能 | インタラクティブなものは Xcode ビルドが必要 |
(Unity ユーザ目線の)メリットデメリット
Unity
メリット
- アセットの種類が豊富
- Unity に慣れている場合、効率的に開発が可能
デメリット
- 有償ライセンスが必要(Pro ライセンス以上)
- パーティクルやマテリアルなど実機と Editor で見た目の違いが多い
Reality Composer Pro
メリット
- Apple Vision Pro 専用に最適化されている
- 内蔵の高品質アセットが利用可能
デメリット
- 細かい制御が必要な場合、Swift のコードを書く必要がある
対象
本記事は、以下のような方々を対象としています
- Apple Vision Proの開発に興味があり、UnityとSwiftの選択で迷っている開発者
- Unityの経験があり、Swiftでの開発にも挑戦してみたい方
作ったもの
ランプをさわると、パーティクルとともに猫魔人が現れます。
Unity
ピンチ動作でランプを持てます。どちらかの手を近づけると反応して猫魔人が現れます。
Reality Composer Pro
ランプは最初から左手にくっついています。右手をランプに触れると猫魔人が現れ、しばらくすると消えます。
開発環境
- Apple M1 Pro
- Vision OS:2.1
- Xcode:16.1
- Unity:6000.0.22(Pro ライセンス以上が必要です)
- PolySpatial:2.0.4
- RealityComposerPro:2.0
比較
ベースシーン
Unity
UnityでVision Proの3Dアプリケーション開発を行うにはPolySpatialというアセットが必要です。
オブジェクトをつかむ「Manipulation」というサンプルがあるので、これをベースとしました。

他にも機能に応じてシンプルなサンプルシーンがあるので、用途に応じてサンプルシーンを改変して作成していきましょう。
RealityComposerPro
Xcode&SwiftのVisionOSで使えるサンプルプロジェクトもApple公式から50個以上提供されています。
公式のサンプルプロジェクトの種類については以下の記事が参考になります。
ただ、今回の用途に合っているRealityComposerProを使ったシンプルなサンプルがあるか把握できていないため、Xcodeのデフォルトのシーンをベースとしました。
Xcode で Window 形式でプロジェクトを作り、Packages フォルダの下の Package.realitycomposerpro を RealityComposerPro で開いて、球体のシーンを置き換えていきます。

アセット
Unity
Unity にはUnity Asset Storeというアセットストアがあり、無料有料を含めたくさんの 3D モデルなどのアセットがあります。これが Unity の強みですね!
ただし今回は Unity と Swift で共通化するために生成 AI で作成した 3D モデルを使います。
Unity 向けには FBX で書き出して読み込みました。

余談ですが、Swift などでよく使われる usdz 形式や Web でよく使われる glb 形式は Unity はデフォルトではサポートしていません。 普段 Web でも XR 開発をしている身としては、Web は glb、Swift は usdz、Unity は fbx・・・と様々な形式を使うことになり、やや面倒です。
RealityComposerPro
今回は生成 AI で生成したものを使いますが、RealityComposerPro 内にも高品質な 3D モデルがいくつか用意されています。

外部から 3D モデルを import する場合は usdz 形式である必要があります。
Reality Converterという Apple が出しているツールを使って、obj や gltf などの形式のモデルを usdz 形式に変換できます。
パーティクル
Unity
Unity でのパーティクルは Unity Editor 上での見た目と、実機で実行した時の見た目がかなり異なるので扱いが大変です。またシェーダーも限られており、UnityAssetStore にあるパーティクルをそのまま使えることが少なそうです。
そのため今回は、PolySpatial のサンプルの中にあった炎のパーティクルのテクスチャを白黒にして煙っぽくしてみました。

RealityComposerPro
ParticleEmitter でパーティクルを作れます。設定内容は Unity と似ています。
プリセットとして 6 種類のパーティクルがあり、今回はこの中の Impact という煙のようなものを使いました。

手の判定
Unity
手の接触判定は Unity のXRHandSubsystemを使い、人差し指の位置を取得し、ランプとの距離で判定を行いました。
以下の記事を参考にしました。
PolySpatial で Vision Pro アプリを作ってみよう(応用編)
https://gaprot.jp/2024/04/08/polyspatial-vision-pro-application/
RealityComposerPro
Component の中にある Anchoring を使えば指定した指や手に物を追従させることができます。

ただし Anchoring コンポーネントを使うとコライダー判定などの物理シュミレーションがうまくいかないようなので、今回は参考本に載っている ARkit を用いたハンドトラッキングコンポーネントを使わせていただきました。
これをランプオブジェクトと、右手用の Transform オブジェクトにつけます。また Collision コンポーネントもつけておきます。
そして接触判定は Behaviors というコンポーネントを使いました。これでランプと右手人差し指のコライダーが接触した時に、魔人の出現アニメーションなどを設定した Timeline を流すことができました。
ちなみに Timeline は参考本にも載っていなかったため、なんとなくで使ってみましたが、オブジェクトの表示・非表示、透明度変更、移動、Billboard、強調表示アニメーションなどが設定できます。
コード生成 AI
Unity
Unity は VSCode などで開発できるためコード生成 AI ツールの GitHub Copilot を思う存分使って開発できました。
魔人がランプから出てくるアニメーションなどの動きも含め、全体の流れをほぼ自分ではコードを書くことなく実装できました。

RealityComposerPro
今回は書いていませんが、RealityComposerPro 用のコンポーネントなどのコードを書く場合、基本的に Xcode で Swift 言語を使います。
Github Copilot にはXcode 用の GitHub Copilot 拡張機能がありますが、私がよく使っている Copilot Chat や Edits などの機能はまだ使えないようです。
今後 Apple からSwift Assistという機能が出るようなので、これが使えるようになると RealityComposerPro や Swift での開発が少し楽になりそうなので楽しみです!
Swift Assist は Xcode にシームレスに統合されており、最新のソフトウェア開発キット(SDK)と Swift 言語の機能を把握しているため、デベロッパはプロジェクトと完全に一体化する最新のコード機能を常に使用できます。Swift Assist を使うと、新しいフレームワークを探求したり、新しいアイデアを試すといったタスクも 1 つのリクエストで簡単にできます。
Apple、新しいツールとリソースでデベロッパに力を与えイノベーションを推進より
実機確認機能
Unity
「Play to Device」という Unity の機能を使うと、Xcode でビルドせず、Unity から直接実機で確認することができます。
この機能、1 度目はつながっても 2 度目以降つながらないことが多く使っていなかったのですが、Apple Vision Pro をかぶり直す度に Vision OS 側の Play to Device のアプリを再起動すればいいことを最近知りました。アプリ再起動は手間ですが、毎回 Xcode ビルドするよりは断然楽ですね!
RealityComposerPro
右上のマークから直接実機へ転送することができます。
ただし、Quick Look としてオブジェクトが見えるのみで、今回のような手への追従などは動きませんでした。
そのためインタラクティブなものを RealityComposerPro で作った場合は、Xcode でビルドする必要がありそうです。
最後に
Anchoring や Timeline 機能などにより RealityComposerPro 単体でも動きのあるものやインタラクティブなものがローコードで作れました。使い方自体は Unity に慣れていればある程度分かりそうです。今回は触れていませんが ShaderGraph なども使えます。
シンプルなアプリでしたら、Unity ではなく RealityCpmposerPro を使ってみてもいいかもしれません!