Reality Check: Building AR in Unity vs in Apple RealityKit

March 30, 2026

As an experiment, I built the same mobile AR experiences in RealityKit and in Unity. Here's what I learned.

I've been building Augmented Reality (AR) apps for iPhone using RealityKit for a few years now. The average developer doesn't really have a lot of faith (or interest) in the AR scene, and it gets a lot of flack, but I don't care - I love it. Bringing 3D things into the real world!

But in 2025, I started learning (and learning to love) Unity for building iPhone apps. Luckily for me, Unity has its own platform for AR experiences called AR Foundation, and it allows you to build your mobile AR experiences to both iOS and Android devices.

Since both platforms deal with AR concepts, I thought it should be pretty easy to jump over from one to another - from RealityKit to Unity AR Foundation. But, I was (mostly) wrong.

Here are the ways I find that AR Foundation and RealityKit differ the most:

1. Bundle Size
2. File Types for 3D Models
3. The Development Experience
4. On-screen Gestures
5. Multiple AR Experiences in One App
6. The Testing Experience
7. Gamifying Your AR Experience
8. Building & Deploying

Bundle Size

RealityKit: Amazingly small and light.

Unity: Bloated, but for good cause.

RealityKit utilizes Apple's native frameworks and can talk directly to the OS without a translator. Unity... is a game engine. Naturally, your final bundle is gonna be much larger - but there are reasons that it might just be necessary, explained further in this article!

File Types for 3D Models

RealityKit: USDZ is super cool but can be troublesome and less convenient for 3D artists.

Unity: FBX is widely known and supported.

RealityKit requires USDZ, AR Foundation - and Unity in general - requires FBX.

USDZ is actually a pretty cool file format that blends pretty well into Apple's ecosystem. It was developed by Pixar together with Apple, and aims to be a "universal scene description" - hence "USD."

The issue for most 3D artists is that USDZ doesn't have a lot of built in support in programs like Blender and Maya. It compresses insanely well and keeps filesize small, but if you're modeling in Blender for a RealityKit scene, there are a few hoops you have to jump through in order to get your model into USDZ. Add in a few more hoops if your model has animations or complex materials.

By contrast, FBX is widely supported and is easy to export directly from your 3D editor programs.

The Development Experience

RealityKit: It's All Code... It's Only Code.

Unity: There's a visual editor! ...But you better know how to use it.

I've written before about my experience with Swift and how pretty and fun it is to write with. RealityKit is made in the XCode IDE and is only written in Swift.

But that's kinda the thing - it's only code. And that's either a good thing or bad thing depending on your skill level and development preferences.

One distinct positive of RealityKit being all code is that LLMs and vibecoding excel greatly here - If you have your 3D models put together already, it's pretty quick to have Claude or GPT spin up an AR iPhone experience for you. One negative is that to see what you've been building, you have to actually run it on your iPhone, iPad, or Vision headset.

By contrast, Unity is a visual video game editor program that has you write scripts in C# to program actions... but it does require you to click and drag around its editor to get things hooked up and working.

Effectively what this means is that, instead of just needing to know how C# works (or having an LLM handle it for you), you'll also need to know the how and why of Unity's game engine system and editor in order to get stuff like UI, sounds, and core game loops working. Asking your LLM to clarify it can certainly help you, but they cannot click around in the editor for you... yet.

On-screen Gestures

RealityKit: Apple makes pinching, zooming, and swiping super easy.

Unity: XR Interaction Toolkit is great! For headsets...

Want to set up a pinch-to-scale gesture in RealityKit? Easy - just call it via code.

In Unity, you get a super powerful add-on called XR Interaction Toolkit (XRIT) - but it's largely built for headset AR experiences.

XRIT does have support for mobile gestures, but I've found that it's almost easier to just write your own scripts for on-screen gestures. For example, Unity's new Input System allows you to detect if an object is being tapped or touched currently, and it also allows you to count how many figures on the screen so you can define your own gestures.

It's also worth noting that testing mobile AR experiences within Unity's simulator can get kinda wonky - especially with XRIT.

I think overall, RealityKit wins when it comes to on-screen mobile gestures for AR.

Multiple AR Experiences in One App

RealityKit: Very easy out of the box.

Unity: Not impossible, but requires much more management of the AR Session.

Lets say you want to build a mobile app that allows users to switch between multiple AR effects or games. This is where understanding what an AR session is and does becomes crucial.

In RealityKit, it's quite easy to call some code to manage, reset, and flush out a given AR session so you can load in a new one. But as Unity is a game engine not primarily focused on AR, it presents you with a bunch of different paths and options that aren't quite clear for AR.

When I first attempted creating a multi-scene AR app in Unity, I began by implementing a new "scene" for each experience. This quickly became a pain because each AR app should truly only have 1 AR session and 1 XR origin. With that in mind, I tried a solution where the app had one undestroyable prefab object called the "session manager." This prefab would contain the AR session components on it and would persist across each scene, changing as needed. This forced me to get a really strong understanding of how the AR Session lives and dies in an AR Foundation app, but it honestly presented more bugs and headaches than it was worth.

In the end, I found that it was better to just have 1 - and only 1 - scene in an AR Foundation app, keeping the same 1 AR Session and XR Origin across the entire app, and reset your objects, code, and gestures when the user selects a different experience.

Even though I was able to figure it out in the end, I think RealityKit earns the victory on this one. Unity can for sure handle it, though.

The Testing Experience

RealityKit: You gotta port 'em directly to your device to see what's going on.

Unity: You can test the AR experience right in the editor! For the most part.

ABT: Always Be Testing.

And if you're building stuff that's gonna run on something other than a desktop or laptop computer, it's more like ABTAOTTD: Always Be Testing Also On The Target Device.

The fact that you can test your AR experiences directly in the Unity editor is insanely cool and helpful. You can even download simulated environments to test in - like a backyard barbecue or a living room. But even Unity's own docs mention that the simulated AR testing experience is limited and not 1-to-1 with testing on an actual device.

Still, I love it and I think Unity gets the dub (victory) on this one.

With RealityKit, you have to run the compiled AR experience directly on your device to see what's going on. In one way, it forces you to test on the actual device itself, but in another way, it's kinda crazy to not be able to see what you're coding when you're coding it.

Luckily, XCode compiles and runs crazy quick on iOS devices in my experience, so it's more of an annoyance than it is a roadblock.

In any case, you'd better be testing these experiences on the devices themselves as you develop, or else you're in for several surprises later down the line.

Gamifying Your AR Experience

RealityKit: Not impossible, but a bit tougher than you'd like.

Unity: The clear victor on this one.

This one's pretty easy to explain: Unity is a time tested game development platform with its own engine. Even though you do need to learn how to add audio, UIs, and more the Unity way, there are plenty of non-AR tutorials to help you get there.

RealityKit has far fewer resources and is mostly code-focused, forcing you to really have to understand and keep a strong mental model of all your game loop mechanics.

For me, Unity's new InputSystem is super cool and easy to use for controlling and transforming objects about an AR scene - like using an on-screen joystick to control a UFO or an airplane.

Building & Deploying

RealityKit: The clear victor.

Unity: It works!

Anyone who has ever shipped a mobile app of any kind knows that there are pain points of deploying to either the Apple App Store or the Google Play Store. But its hard to argue that building, compiling, and submitting apps entirely within the Apple ecosystem is harder than the Unity experience.

To be fair to Unity, the whole point of their platform is to be able to build your project down to a multitude of targets, which it does well. But the experience can still be kinda janky what with all the configurations and whatnot. And that's not even getting into the pricing and royalty conversation that Unity introduces. Unity is a totally free program so you know they've got to be making their money elsewhere within the development pipeline...

Building an Apple app for Apple devices within an Apple framework - and then shipping to the Apple store - is just a streamlined process that is hard to beat in my opinion.

(We'd all love to see those App Store review times get a little faster, though...)

My Final Verdict

Look... I'm gonna use both because I love both. But I think overall I'm going with Unity just because of the testing and development experience.

Overall, I think RealityKit wins on performance, but Unity wins on flexibility and gamification.

In any case - keep making AR however you do it, because I love this space and want to see it win!

Your AR pal,
- Davey ✌️