「ゲームを作るならゲームエンジン（Unity）？それともネイティブ（Xcode）？」——iPhone向けの2Dゲームなら、実はどちらでも作れます。そこで今回は、落ちてくる玉をタップして得点する全く同じミニゲームを、Unity（C#）とXcode（Swift／SpriteKit）の両方で作り、見た目・操作感・アプリの軽さ・開発の手間を比べてみました。

作るゲーム：タップキャッチ

題材は「タップキャッチ」。シンプルですが、ゲームらしい要素が一通り入っています。

• 上から色つきの玉が落ちてくる（だんだん速く・多くなる）
• 玉をタップすると消えて＋1点＋弾けるアニメ
• 20秒の制限時間、スコアと残り時間を表示
• スタート画面 → ゲーム → リザルト画面、ハイスコア保存

両環境で全く同じ仕様・同じ見た目を目指して作りました。

今回の環境

※ 動作確認は両方とも iPhone 17 Pro シミュレータ。Bundle ID は com.eight.tapcatch / com.eight.tapcatchswift。

① Unityでの作り方

Unityは「2D」テンプレートで新規プロジェクトを作り、エディタ上にゲームを組み立てます。今回は落下する玉やスコア表示などをC#スクリプトでまとめて生成し、メニューから配置する形にしました。玉の落下・タップ判定・スコアはすべてC#で書きます。

// 落下＆当たり判定（イメージ）
void Update() {
  timeLeft -= Time.deltaTime;
  foreach (var t in targets)
    t.anchoredPosition += Vector2.down * speed * Time.deltaTime;
}
// 玉をタップ → 加点
btn.onClick.AddListener(() => { score++; Destroy(target); });

Unityの強みはエディタで見た目を確認しながら作れること、そして物理・アニメ・エフェクトなどゲーム機能が最初から豊富なことです。

Unity特有の設定（iPhone向けに出すとき）

UnityでiPhone（シミュレータ）向けに動かすには、いくつかUnity独自の設定が必要です。ビルドプロファイルでプラットフォームをiOSに切り替え、プレイヤー設定でシミュレータ向け（Simulator SDK／アーキテクチャ ARM64）を指定します。下が実際の設定画面です。

ポイントは「ターゲットSDK」を Simulator SDK に、「Simulator Architecture」を ARM64 にすること。Apple Silicon搭載Macのシミュレータはこの組み合わせで動きます（ここを実機用のままにすると、シミュレータで起動できません）。あわせて入力処理は「入力システムパッケージ（新）」、バンドル識別子も忘れず設定します。

② Xcodeでの作り方

Xcodeでは、Appleの2Dゲーム用フレームワークSpriteKitを使います。SKSceneのゲームループ（update）で玉を動かし、touchesBeganでタップを判定します。SwiftUIのSpriteViewに載せるだけでアプリになります。

// SpriteKitのゲームループ
override func update(_ t: TimeInterval) {
  timeLeft -= dt
  for n in targets { n.position.y -= speed * dt }
}
// タップした位置の玉を判定して加点
override func touchesBegan(_ touches: Set<UITouch>, with e: UIEvent?) {
  for n in nodes(at: loc) where n.name == "target" { score += 1; n.removeFromParent() }
}

SpriteKitはiOS純正なので、アプリがとても軽く・起動が速いのが特徴。2Dゲームに必要な機能はひと通り揃っています。

Xcode特有の設定（プロジェクトと署名）

Xcodeでは、プロジェクトの「General」タブで表示名・バンドルID・対応OS（最低iOS 15.0）・画面の向きなどをまとめて指定します。Unityのプレイヤー設定にあたる部分です。

もうひとつXcodeらしいのが「Signing & Capabilities（署名）」です。実機に入れるにはApple開発者アカウント（チーム）の署名が必要ですが、シミュレータで動かすだけなら署名なし（チーム＝None）でもOK。下の画面では「実機にはチームが必要」という警告（⚠️）が出ていますが、シミュレータ確認はこのまま進められます。

③ 見た目・大きさを揃えるコツ

「同じゲーム」を名乗るなら、玉や文字の大きさ・落ちる速さもそろえたいところ。実はここに、エンジンとネイティブの“座標の基準”の違いという落とし穴があります。最初に作ったときは、Xcodeのほうが玉が大きく・速く見えてしまいました。

原因は、サイズを測る「ものさし」が違うこと。Unityは基準解像度（参照解像度）を決めて、その中の数値でサイズを指定します。今回は横1080を基準にしました。設定はCanvasの「Canvas Scaler」で行います。

一方Xcode（SpriteKit）は、何もしないと端末の論理ポイント（iPhoneで約390）が基準になります。Unity（1080基準）と同じ数値「55」を指定しても、ものさしが約2.7倍ちがうので、実機では大きさも速さもズレてしまうわけです。

解決はシンプルで、SpriteKit側のシーンもUnityと同じ「横1080基準」で作ること。コードでGameScene(size: CGSize(width: 1080, ...))のようにシーンの幅を1080に固定し、玉の半径・文字サイズ・落下速度をUnityと同じ数値にすれば、両者の見た目・動きがピタリと一致しました。

見た目・動きを並べて比較

同じ仕様で作ったので、見た目はほぼそっくりに仕上がりました。左がUnity、右がXcodeです。

プレイ感（玉の落下・タップの反応・画面遷移）も、どちらも実用上じゅうぶん滑らかでした。単純な2Dゲームでは、完成した画面だけ見るとほとんど区別がつきません。違いは「中身」に出ます。

実機の動きを並べて

同じ「玉が落ちてくる」プレイの様子です。左がUnity、右がXcode。動き・反応はどちらも自然で、見た目だけでは違いがほとんど分かりません。

比較表：ここが違う

動作中のCPU負荷も測ってみた

せっかくなので、動かしている間のCPU負荷も計測してみました。同じMac上のシミュレータで、同じゲームを動かしたときの数値です。

はっきり差が出たのは待機画面です。SpriteKit（ネイティブ）は「画面に動きがなければ描画を止める」ため、止まっている間はCPUをほとんど使いません（約1%）。一方Unityは動きの有無にかかわらず毎フレーム描き続けるので、止まっていても約8%かかります。プレイ中もネイティブの方が軽め（約6% vs 約11%）でした。軽さ＝省電力＝バッテリー持ちに直結するので、シンプルなアプリほどネイティブが有利です。

結論：どっちで作る？

• 演出やゲーム性を重視／いずれAndroidにも出したい → Unity。物理・アニメ・エフェクトが最初から揃い、1つ作れば複数プラットフォームに展開できます。
• とにかく軽く・起動を速く／iPhoneに専念・ネイティブUIと組み合わせたい → Xcode（ネイティブ）。SpriteKitなら2Dゲームは十分作れて、アプリは驚くほど軽量です。

今回いちばん驚いたのはアプリサイズの差でした。同じ見た目・同じ遊びでも、中身（土台）の大きさはまるで違う——これがエンジンとネイティブの本質的な違いだと実感しました。簡単な2Dなら気軽にネイティブ、本格的なゲームや複数展開ならUnity、と覚えておくと選びやすいです。

2Dは互角。でも3Dになると話が変わる

今回のようなシンプルな2Dアプリでは、UnityでもXcodeでも“ほぼ同じように”作れました。見た目も操作感もそっくりで、難易度の差もそれほど感じません。

ところが3D、とくにリッチな表現（リアルな光・影・反射、大量のパーティクル、物理演算、滑らかなアニメ）になると、難易度の差は一気に開きます。Unityはこうした機能を最初から備えていて部品を置くだけで形になりますが、ネイティブ（Xcode）で同じ画を出そうとすると、3Dの土台づくりから自分で組む必要があり、作業量・専門知識ともに跳ね上がります。「2Dなら互角、3D（特にリッチ表現）はUnityが圧倒的にラク」——これが今回の率直な実感です。

それぞれの「しかできない・できない」を整理

ゲームやアプリ作りで迷ったとき用に、4つの観点でまとめておきます（あくまで“一般的な傾向”で、工夫すれば例外もあります）。

ざっくり言うと、「いろんな機種に出したい・派手な3Dを作りたい」ならUnity、「iPhoneに専念して、とにかく軽く・OSの機能をフルに使いたい」ならXcode（ネイティブ）。作りたいものに合わせて選べば失敗しにくいです。

それでは、今回はここまで。最後までありがとうございました😊