Technologies / ARKit
ARKit app development for iPhone, iPad and Apple Vision Pro
ARKit app development means building augmented reality on Apple’s own frameworks: ARKit for understanding the world through the camera and sensors, RealityKit for rendering 3D content, and visionOS for Apple Vision Pro. This page is about the technology choice, for CTOs and product leads deciding whether to build AR natively on Apple’s stack, on Unity, or on a cross-platform SDK.
It sits under our mobile app development technologies overview. If you are scoping an AR product rather than choosing a framework, start with our AR VR app development company page, or the augmented reality app development service for phone-based AR.
- ARKit plus RealityKit, written in Swift
- visionOS permissions and fallbacks planned
- Tested on real devices in real rooms
- 3D assets optimised for mobile
ARKit, RealityKit and visionOS: who does what
Apple’s AR stack has three layers, and it helps to keep them separate when reading proposals.
ARKit is the sensing layer. It tracks the device’s position, detects surfaces, and on supported devices builds a mesh of the room or tracks hands. It tells your app where things are, but it does not draw anything.
RealityKit is the rendering and simulation layer. Apple calls it an “AR-first” 3D framework, available on iOS and iPadOS 13 and later, macOS 10.15 and later, visionOS 1.0 and later, and tvOS 26 and later. It works with ARKit and Reality Composer Pro, Apple’s tool for preparing 3D scenes.
visionOS is the operating system on Apple Vision Pro. The same RealityKit content can run there, but the way an app gets ARKit data is different, which matters for scope and design.
ARKit on Apple Vision Pro: Full Space and permissions
Apple Vision Pro went on sale in the US on 2 February 2024, from $3,499, running visionOS. On visionOS, ARKit data such as hand tracking, plane detection and scene reconstruction is available only when the app presents a Full Space. In a shared space alongside other apps, your app does not get that data.
Hand tracking needs an NSHandsTrackingUsageDescription entry, and world sensing needs NSWorldSensingUsageDescription. People can refuse or revoke either, so the app must still work without them. That means a non-immersive mode, clear explanations before the permission prompt, and testing every flow with permissions denied.
For buyers, the practical point is that a Vision Pro app is not a phone AR app on a bigger screen. Interaction is by eyes and hands, sessions switch between windows and full immersion, and the design work is larger. We scope visionOS as its own target, sharing RealityKit assets and business logic with the iPhone app where it makes sense.
When we choose ARKit, and when we do not
We choose native ARKit and RealityKit when the product is Apple-first, when it needs the closest integration with iOS features (Quick Look, SwiftUI screens, App Clips, Vision Pro), or when the AR view is one part of a larger native app rather than the whole product.
We look elsewhere when the AR experience must be identical on Android, when it is closer to a game with heavy 3D logic, or when the client already has a Unity team. Unity Pro adds Apple Vision Pro support, which makes Unity for mobile apps a sound choice for content-heavy cross-platform experiences. For Android, Google’s ARCore is the equivalent, and a product on both platforms usually ends up comparing a native pair against one Unity project.
Choose ARKit if
- Your audience is mostly on iPhone and iPad
- AR is one feature inside a native Swift app
- You plan a Vision Pro version
- You want Apple’s Quick Look and SwiftUI integration
- The 3D content is moderate, not game-scale
What we build with ARKit and RealityKit
Typical Apple AR features, each tested in the kinds of rooms your users have.
Product placement
Furniture, appliances or fixtures placed on floors and walls at true scale, with lighting that matches the room.
Measurement and planning
Room and object measurement for quotes, installs and renovations, with clear accuracy limits shown to users.
Guided procedures
Step-by-step overlays on machines or equipment for training, maintenance and field service.
Property and space previews
Walkthroughs and furnishing previews for real estate and interior design.
Learning experiences
3D models students can walk around, label and take apart, for science, anatomy and engineering.
Vision Pro companions
Immersive visionOS versions of an existing iPhone experience, sharing assets and logic.
Not sure your AR idea will track well in real rooms?
Send us the use case and a few photos of where users will be. Within one business day we will tell you whether ARKit fits, what could break tracking, and what to prototype first.
ARKit compared with the alternatives
Four routes we weigh for an AR product.
| ARKit + RealityKit | ARCore | Unity | WebXR | |
|---|---|---|---|---|
| Platforms | iOS, iPadOS, visionOS | Android; some features on iOS | iOS, Android, headsets | Browsers that support it |
| Language | Swift | Kotlin / Java; Unity; Unreal | C# | JavaScript |
| Best for | Apple-first native apps | Android reach, Geospatial | Game-like, cross-platform 3D | No-install demos |
| Vision Pro | Native | No | Pro plan required | Depends on browser |
| Watch out for | Apple-only code | Certified devices only | Larger app size, licence tiers | Draft standard, uneven support |
WebXR is a W3C Candidate Recommendation Draft (latest 9 June 2026). Unity plan details per Unity’s current plans page.
How ARKit fits the rest of your stack
The AR view usually lives inside a normal app. We build the surrounding screens in SwiftUI and the AR view with RealityKit, all in Swift, so one iOS team owns the whole product. Shared logic such as product catalogues and user accounts sits behind the same API the rest of the app uses.
3D content is the hidden cost. Models from a manufacturer’s CAD files are often far too heavy for a phone. We budget for asset optimisation (reducing polygons, compressing textures, setting real-world scale) and for a content pipeline so new products can be added without an app release.
Privacy matters too. Camera and world-sensing data can reveal the inside of someone’s home, so we process it on the device and send nothing to the server unless the feature requires it and the user is told.
Hiring and maintenance implications
ARKit and RealityKit are Apple platform skills, and a strong Swift developer can learn them, but AR experience shortens the path a lot: knowing how lighting, textureless surfaces and fast movement break tracking saves weeks of trial and error. If you need iOS engineers with AR experience on your own team, you can hire iOS developers with a two-week trial.
Apple ships new AR capabilities each year, previewed at WWDC in June. Maintenance means re-testing tracking and rendering on each new OS, keeping 3D assets in formats current tools support, and reviewing permission text when Apple changes its rules.
Code-quality practices on our ARKit projects
What you can check in your repository and test reports.
- Tracking tested in low light, on plain surfaces and while walking
- Device-capability checks with a non-AR fallback screen
- Usage descriptions written in plain language before prompts
- visionOS flows tested with hand tracking and world sensing denied
- 3D assets budgeted for size and polygon count per device class
- Frame rate and thermal behaviour measured in long sessions
- Camera data processed on-device by default
ARKit app development: frequently asked questions
What is the difference between ARKit and RealityKit?
ARKit senses the world: it tracks the device, finds surfaces and, on supported hardware, maps the room or tracks hands. RealityKit renders and simulates the 3D content you place in that world. Apple describes RealityKit as an AR-first framework that works with ARKit and Reality Composer Pro. Most native Apple AR apps use both together.
Can our iPhone AR app run on Apple Vision Pro?
Parts of it can. RealityKit content and Swift business logic can be shared, but visionOS works differently. ARKit data such as hand tracking and scene reconstruction is available only in a Full Space, needs its own permission prompts, and users can refuse it. We scope Vision Pro as a separate target with its own interaction design and testing.
Should we build with ARKit or Unity?
Choose ARKit and RealityKit when the product is Apple-first and AR is one feature in a native app. Choose Unity when the experience must be identical on iOS and Android, behaves like a game, or your team already knows Unity. Unity Pro adds Apple Vision Pro support. Both are sound; the deciding factors are platforms and team skills.
Does ARKit work on Android?
No. ARKit is Apple-only. Android apps use Google’s ARCore, which runs on certified Android devices. Some ARCore features, Cloud Anchors and Augmented Faces, also work on ARKit-compatible iOS devices on iOS 12 and later, which helps when shared anchors must work across both platforms. Cross-platform AR often uses Unity on top of both.
Why does AR tracking sometimes drift or fail?
Tracking depends on what the camera can see. Dim light, plain white walls, glossy floors and fast movement give it too little to lock onto. We test in conditions like your users’ spaces, show clear guidance when tracking is weak, and design the experience to recover gracefully rather than leaving objects floating in the wrong place.
What makes an ARKit app expensive?
Usually the 3D content and the testing, not the AR code itself. Heavy models need optimising for phones, each product may need its own asset, and tracking must be tested across devices and rooms. A Vision Pro version adds its own design work. We size these separately in discovery so the fixed price shows where the effort goes.
Prototype your Apple AR experience on real devices first
Book a 30-minute scoping call. We will review your use case and 3D content, recommend ARKit, Unity or a mix, and propose a short prototype to test tracking where your users are.