®If you want an augmented reality app on phones, you will meet two names early on. ARKit is Apple's AR framework for iPhone and iPad, and ARCore is Google's equivalent for Android. Comparing ARKit vs ARCore helps you decide whether to build natively for each platform or use a cross-platform engine such as Unity with AR Foundation.
What ARKit and ARCore do
Both frameworks solve the same core problem. They use the camera and motion sensors to understand where the phone is and what the space around it looks like, so digital objects can stay fixed in the real world as the user moves.
The shared building blocks include:
- Motion tracking that follows the phone's position and orientation
- Plane detection for floors, tables and walls
- Anchors that pin content to a real-world spot
- Light estimation so virtual objects match the lighting in the room
- Image tracking that recognises a printed picture, poster or packaging
- Hit testing to place an object where the user taps
For most business apps, such as placing a product in a room or showing an animated model on a brochure, both platforms can deliver a similar result.
Where they differ
The differences are mostly about hardware, extra features and how the frameworks fit into each ecosystem.
ARKit runs on a wide range of recent iPhones and iPads. Because Apple controls the hardware, behaviour is fairly consistent across devices. Some Pro models include a LiDAR scanner, which gives faster and more accurate depth sensing, scene reconstruction and better occlusion, where real objects can hide virtual ones. Face tracking uses the front camera system on supported devices. ARKit works closely with Apple's RealityKit for rendering and with the USDZ 3D format, which also allows simple AR previews through Quick Look without a full app.
ARCore runs on a large list of certified Android phones, as well as on iOS for some features. Because Android hardware varies so widely, Google maintains a list of supported devices, and quality can differ between models. ARCore offers a Depth API that works on many phones without special sensors, Augmented Faces for face effects, and a Geospatial API that uses Google's visual positioning data to place content at real-world locations outdoors. Cloud Anchors let users on both iOS and Android share the same AR scene.
| Area | ARKit (Apple) | ARCore (Google) |
|---|---|---|
| Platforms | iPhone and iPad | Supported Android devices, some features on iOS |
| Device consistency | High, limited set of hardware | Varies by phone maker and model |
| Depth sensing | LiDAR on some Pro models, camera-based on others | Depth API on many devices without special sensors |
| Location-based AR | Location anchors in supported areas | Geospatial API in areas with visual positioning coverage |
| Shared experiences | Collaborative sessions between Apple devices | Cloud Anchors across Android and iOS |
| Native tools | Swift, RealityKit, Reality Composer | Kotlin or Java, with a separate 3D rendering library |
Feature details change with each yearly release, so check the current documentation for any capability your idea depends on.
Unity AR Foundation for both platforms
Unity's AR Foundation is a package that sits on top of ARKit and ARCore. You write your AR logic once, and AR Foundation calls the right native framework on each device. It also supports headsets through OpenXR and other plug-ins, which helps if you may later expand to mixed reality devices.
AR Foundation is a good fit when:
- You need both iOS and Android from one codebase
- The experience is visually rich, with 3D models, animation or game-like interaction
- Your team already works in Unity
- You may want to reuse the content on headsets later
Native development is often the better choice when:
- You only need one platform
- AR is a small feature inside a larger native app
- You need a platform-specific feature as soon as it is released
- App size and start-up time are critical, since Unity adds its own runtime
A third route is web-based AR, which runs in the mobile browser with no install. It reaches people quickly through a link or QR code, but tracking quality and features are more limited than in a native app.
Planning an AR app that works
AR projects tend to succeed or fail on details that have nothing to do with the framework.
- 3D content quality. Models need to be accurate, light enough for phones and correctly scaled. Budget time for this.
- Real environments. Test in dim rooms, on shiny or plain floors and outdoors. Tracking struggles on surfaces with little texture.
- Onboarding. Users need clear prompts, such as moving the phone slowly to scan the floor.
- Device range. Test on older and mid-range phones, not only the latest models.
- Fallback. Offer a normal 3D viewer or photo for devices that cannot run AR.
How to choose
Ask these questions before picking a technical route:
- Which platforms do your users actually use?
- Is AR the main product or one feature of a larger app?
- Does the idea depend on a special capability, such as LiDAR, face tracking or outdoor location?
- Who will create and update the 3D content?
- Could a browser-based AR link do the job without an app download?
Frequently asked questions
Is ARKit better than ARCore?
Neither is better overall. ARKit benefits from consistent Apple hardware, while ARCore reaches a much wider range of Android phones. The right choice depends on your audience and the features you need.
Can one app use both ARKit and ARCore?
Yes. A cross-platform engine such as Unity with AR Foundation uses ARKit on iPhone and ARCore on Android from a single project. Flutter and React Native also have AR plug-ins, though their feature coverage varies.
Do users need a special phone for AR?
Most recent mid-range and flagship phones support AR. Some older or lower-cost Android phones are not certified for ARCore, so plan a fallback for them.
For ideas on where AR adds real value, see our article on AR and VR business use cases. When you are ready to build, our AR and VR development team can help you choose between native and Unity and test on the devices your users own.