以前書いた記事のアクセス数が多いことと、最近注目されているARKitを使って、XCodeでいつかiOSアプリを作ることを想定し、Unityで作る場合との違いを比較してみました。
Unityは使っているけど、XCodeはあまり知らない(私のことです、、)という方の参考になれば幸いです。
以下の環境で確認しています。
- MacOS X 12.12.6
- XCode 9.0
- Unity 5.6.3p1
ちなみに、今回は同じ内容のプロジェクトで比較したわけではなく、XCodeでこうだけどUnityだったらどうか、という観点で書いています。
1. プロジェクトサイズ
たとえば、XCodeでは3DCGを描画できる機能のサンプルプロジェクトのサイズは、1.2MBです。
(本ブログ後半に出てくる、飛行機のモデルを表示するだけのやつです)
また、ARKitのサンプルコードは21.8MBでした。
同じものを比較してないので参考程度という位置づけですが、Unityだとシンプルなものでも数十MB、CGモデルのアセットを入れるとあっという間に数百MBを超えるので、ここはだいぶ違うところかと思います。
2. ワイヤレスデバッグ、デプロイ
XCode9以降、ワイヤレスデバッグができるようになりました。XCodeを搭載したPCとiOSデバイスが同じネットワークにあれば利用できます。
まず、ライトニングケーブルでiOSデバイスとPCを接続してからXCodeでプロジェクトを開き、Window / Device and Simulatorsを選択します。
このように、Deviceに関する画面が表示されます。
Connect Via Networkにチェックを入れます。あとはケーブルを抜いてもデプロイができますし、端末のログが表示されるようになります。
(HoloLensでもワイヤレスデプロイができますが、3DCGが少ない分、iOSアプリの方がデプロイ時間が短いです)
ケーブルを気にしなくてよいのでけっこう楽です。また、自分で作ったアプリがクラッシュしてもちゃんとログを残してくれるので、デバッグするときにとくに困ることもありません。
ちなみに、私は試したことがなかったのですが、Unityには「Unity Remote5」という仕組みがあります。こちらでは、使い方がとても詳しく書かれており、大変参考になります。
https://vracademy.jp/blog/?p=750
Unity Remoteは、Unityでのリモートデバッグには非常に便利ですが、専用アプリのインストールが必要であり、環境構築に若干時間がかかるようにみえました。そういう意味では、XCodeの方が便利と想いました。
3. ビルド速度
感覚的には、同程度の内容であればXCodeの方がビルドからデプロイまでが速い印象です。一方、実機にデプロイする前に動作を確認するのは、Unity Editorの方が圧倒的に速いですね。
4.シミュレータ(実機を使わない確認）
XCodeはiOSシミュレータがあります。基本的な動作はこれで確認できますが、GPUを使うものはMacの実機の性能にかなり左右されます。
GPUを使うものとして、Scenekitがあります。Scenekitとは、UnityのようにXCodeで3DCGアプリを作るためのフレームワークで、この後少し紹介しています。
飛行機モデルを回転表示させる、というサンプルが付いているのですが、私のMac(注) では下記の動画の通り、Scenekitのサンプルプロジェクトがまともに動きませんでした。
（３種類のiOSシミュレータを動かす＋iPadAir2で動かす、をキャプチャして１つの動画にしています）
デバイスを選択すると、若干描画性能が変わることはわかりましたが、CGの動きをシミュレータで確認するのはつらそうです。
この点はUnity Editorの方が確実ですね。
(実機より性能が高いので後で、実機で思ったように動かないという懸念はありますが)
(注) Macbook Pro Late2016 2.9 GHz Intel Core i5
5. 3DCG
XcodeではSceneKitという仕組みを使います。試しに、New ProjectでGame〜を作ると、サンプルとして飛行機(ship)モデルをタッチ操作でいろいろな角度から見る仕組みが入っています。
これを表示させるコードは下記です。
(長いため下記のリンクよりご確認ください)
gist9c38a2f13a6aa7f1dee988ce5736be17
このように、オブジェクト設定、ライト設定、位置調整を基本的に全てコードで書くことになります。ここだけをみると、Unityの方が簡単と想います。
ちなみに、これはXCodeプロジェクトにCGモデルデータを含ませておいた場合の書き方ですが、UnityのResources.Loadのようにアプリの保存ディレクトリのモデルを表示、あるいはネットワーク経由でモデルを表示させようとすると、別の記述方法が必要です。そちらもUnityの方が簡単でした。
6. ログ出力
XCodeではObjective-CまたはSwiftでコードを書きます。ログを出したいときは、NSLogという関数を使います。これは出力したい文字の型を宣言しておく必要があります。たとえば、int var1 = 3; のとき、var1の値を出力したいとします。いずれも「var1の値は 3 です 」という結果が出力されます。
Unity のC#の場合
Swiftの場合 (Swiftの場合、let型で書いておくことで自動識別されます)
7. 画面遷移
Unityで実現したい場合、Sceneを変えるか、表示されているオブジェクトを消す、Cameraにフェードアウト/インをつける、などで画面遷移を表現することができます。
一方、XCodeの場合、一つずつ画面を定義していく必要があります。(例外があるかもしれませんが、ざっと調べて試した限りではそうでした)
昔は、Interface Builderという仕組みを使っていました。アプリの画面別にGUIで部品を配置し、ソースコード上のメソッドとつなげることで、プログラムに応じて画面を変化させることができます。
その後、2012年頃より、Storyboardという機能が追加されました。見た目はInterface Builderに似ていますが、複数の画面を一つの画面で表示させることができて、segue(セグエ)という手法によって、簡単な遷移ならばコードなしで可能です。
Interface Builder (１つの画面につき、１つのxibファイルを使う）
Storyboard (複数の画面を管理可能）
ここに書かれている矢印でsegueを使っていることを示しています。また、左側の矢印は起動後に最初に表示される画面に対して発行されます。
Interface BuilderのときはAppDelegeteクラスの中でコードとして指定していたので、Storyboardの方が楽にできます。
こちらも好みはありますが、Unityの方が楽だと感じました。
8. 情報量
私は何か困ったことがあると、対象となるキーワードかエラーログをきっかけに対処方法を探します。Unityの場合、大抵は誰かが解決策を書いてくださっています。
しかし、iOSの場合はUnityに比べると情報量が少ない印象です。Unityとカテゴリが近いScenekitについても、最初の飛行機を動かす、追加でオブジェクトを配置する、以上の記事は数が少なかったです。Unityは使用者による情報交換が活発なのが強みだと、改めて感じました。
9. 終わりに
冒頭に述べたきっかけからXCodeについて調べてみましたが、Unityがいかに開発者が使いやすいように構成されているかがよくわかりました。ソースコード記述とStoryboardにも利点はあるのですが、3DCGという１点においてはUnityが便利です。
3DCGアプリを作る限りはXCodeを使ったアプリ開発の機会はあまりないかもしれませんが、最近はいつ何が必要になるかわからないので、今回調べたことが何かの役に立てばよいなと想います。
次回は、並行して調べているMeta2について整理する予定です。
