Skip to content

How to Choose an AR SDK: ARKit vs ARCore vs AR Foundation

How to choose an AR SDK: ARKit, ARCore, and Unity AR Foundation compared on device support, tracking features, and cross-platform development trade-offs.

Roundup of AR mobile development tools: ARKit, ARCore, Unity AR Foundation, and Vuforia.

An AR SDK is a software development kit that provides the APIs, tracking engines, and device integrations needed to overlay digital content on real-world camera feeds in mobile applications.

Three augmented reality SDK options dominate mobile development: ARKit for iOS, ARCore for Android, and AR Foundation as the Unity abstraction layer that sits above both. Each imposes different platform constraints, hardware prerequisites, and deployment trade-offs. Picking the wrong one costs weeks of refactoring when the target audience spans both operating systems, or when depth-sensing hardware becomes a hard requirement mid-project.

What an AR SDK Does

Comparison diagram of ARKit, ARCore, AR Foundation across Rendering, Scripting, Asset store

An AR SDK bridges your application code and the device sensors that make augmented reality work: the camera, motion coprocessor, and on supported hardware the LiDAR Scanner. The kit abstracts the raw sensor data into higher-level primitives: tracked planes, anchor points, depth maps, and light-intensity estimates. Without that abstraction, a developer would need to write platform-specific sensor fusion code for every device family, then validate it against each operating system version separately.

Beyond sensor access, an augmented reality SDK handles the frame-by-frame rendering loop that keeps virtual objects locked to real-world coordinates. As the device moves, the SDK recomputes the pose matrix and updates object positions so overlaid content does not drift. Device integration covers camera intrinsics calibration, IMU data fusion, and, on compatible hardware, structured-light or time-of-flight depth feeds. The result is a stable, positioned camera feed overlay that an app's rendering engine can composite with 3D content.

For broader context on how AR relates to other immersive formats, see the mixed reality concepts explained article, which covers the spectrum from passthrough AR to fully synthetic VR.

ARKit: Apple's Native SDK for iOS

AR Foundation is a Unity abstraction layer that routes AR calls to platform-specific provider plug-ins, letting a single codebase target both iOS via the Apple ARKit XR Plug-in and Android via the Google ARCore XR Plug-in. The framework is maintained by Unity and documented at unity.com/solutions/xr/ar. Developers write against the AR Foundation C# API; the plug-ins translate those calls to native ARKit or ARCore calls at runtime.

What AR Foundation provides for cross-platform AR development:

  • Unified session management: A single ARSession component initializes the correct native runtime (ARKit or ARCore) based on the build target, with no platform branching in application code.
  • Subsystem abstraction: AR Foundation exposes subsystem interfaces for plane detection, raycasting, image tracking, face tracking, and depth. The Apple ARKit XR Plug-in and the Google ARCore XR Plug-in implement these subsystems for their respective platforms.
  • Feature availability query: The framework provides runtime feature-detection APIs so code can check whether, for example, the LiDAR Scanner depth subsystem is available on the current device before attempting to use it.
  • Shared prefab system: ARPlaneManager, ARAnchorManager, and AROcclusionManager components work the same way in the Unity Editor regardless of build target, reducing the surface area of per-platform bugs.

The important constraint: AR Foundation is not a standalone runtime. It requires the native SDK installed on the device, either via iOS system frameworks for ARKit or via the ARCore runtime for Android. A Unity project with AR Foundation enabled must still ship with the Apple ARKit XR Plug-in enabled for iOS builds and the Google ARCore XR Plug-in enabled for Android builds. Teams adopting this cross-platform AR path trade some access to advanced native features (which may appear in ARKit or ARCore before the corresponding AR Foundation subsystem ships) for the productivity benefit of a unified codebase. For teams weighing Unity against other engine options, the Unity vs Unreal Engine for immersive development comparison covers the engine-level trade-offs in depth.

How to Choose the Right AR SDK for Your Project

Choosing the right AR SDK starts with two questions: which platforms must your app support, and which device-level capabilities your experience actually requires. The answers collapse most of the decision tree before you reach secondary factors like team toolchain familiarity or backend cloud services.

  1. iOS only, depth-dependent features required. Choose ARKit natively. Direct access to the LiDAR Scanner depth API, scene geometry, and instant AR placement on Pro hardware is only available through ARKit or, at one layer of indirection, the Apple ARKit XR Plug-in in AR Foundation. If depth is central to the experience (occlusion, real-time mesh, surface-specific shadow casting), the native path eliminates abstraction overhead and gives access to full-resolution depth data per Apple's ARKit documentation.
  2. Android only, broad device compatibility required. Choose ARCore and account for device compatibility variance. Check the ARCore supported-devices list against your target market's device mix, then decide whether to ship with AR Required or AR Optional mode. Use the ARCore enable guide to configure the manifest and runtime availability checks correctly.
  3. Both iOS and Android, Unity codebase. Choose AR Foundation with the Apple ARKit XR Plug-in and Google ARCore XR Plug-in both enabled. Verify that every feature your experience needs has a corresponding AR Foundation subsystem. Features without a subsystem equivalent require platform-specific native plug-in code, which partially offsets the cross-platform productivity gain.
  4. Both iOS and Android, non-Unity native codebase. Maintain separate ARKit and ARCore projects. The APIs differ enough that a thin shared-logic layer in C or a cross-platform game engine is often the cleaner architecture than trying to abstract both SDKs manually.
  5. Device capability gating required. Regardless of AR SDK choice, audit device compatibility before shipping. ARKit's device-support verification API and ARCore's runtime availability check serve the same function: preventing an experience from launching on hardware that cannot sustain it. For ARCore, decide early whether the app will use AR Required (device must have the ARCore runtime installed) or AR Optional mode, as this affects Play Store listing requirements.

Teams building enterprise XR products face additional considerations around device fleet management and update control. The enterprise XR deployment considerations article covers managed device environments where ARCore runtime update cadence or ARKit OS version fragmentation becomes a production constraint.

AR Deployment Models: AR Required vs AR Optional

ARCore introduces two distinct deployment modes that determine how your app behaves on devices where the runtime is absent or outdated. Developers configure these modes in the Android manifest and must handle each case in application code.

AR Required
The app lists Google Play Services for AR as a required dependency. The Play Store filters the app so it appears only on supported devices. On install, the Play Store automatically prompts the user to install or update the runtime before the app launches. Apps using this mode can assume runtime availability and skip the manual availability check, though Google's ARCore enable documentation still recommends verifying the session state at startup. Device compatibility is enforced at the distribution layer rather than in application code.
AR Optional
The app does not require the runtime to install or run. AR features are presented as an enhancement on devices where the runtime is available, with a non-AR fallback path for devices where it is absent or where the user declines to install it. This mode maximizes distribution reach at the cost of requiring two code paths: the AR experience and the fallback. Runtime availability must be checked at startup using the ArCoreApk.checkAvailability() API, and the app must prompt the user to install the runtime on compatible devices that do not yet have it.

The choice between AR Required and AR Optional is a product decision as much as a technical one. AR Required simplifies application logic and guarantees session quality; AR Optional expands the addressable install base. Most consumer AR applications with AR as a secondary feature ship as AR Optional. Applications where the AR experience is the entire value proposition typically use AR Required to avoid supporting a degraded path that serves no user need.

References

Frequently Asked Questions

Which AR SDK should I choose for an iOS-only app?

ARKit is the correct choice for iOS-only apps. It provides native access to the LiDAR Scanner depth API, scene geometry, and instant AR placement on supported iPhone and iPad hardware, with no cross-platform overhead. Configure your Xcode project to target the ARKit framework directly and use the device-support verification API to gate features by hardware capability.

Does ARCore run on all Android devices?

No. ARCore runs on qualified Android phones running Android 7.0 (Nougat) or later as listed on the official supported-devices page at developers.google.com/ar/devices. Because Google Play Services for AR is distributed and updated separately through the Play Store, your app must check ARCore availability at runtime and handle both AR Required and AR Optional deployment modes.

What is AR Foundation and when should I use it instead of native SDKs?

AR Foundation is a Unity abstraction layer that routes AR calls to platform-specific provider plug-ins: the Apple ARKit XR Plug-in on iOS and the Google ARCore XR Plug-in on Android. Use it when your team maintains a single Unity codebase targeting both platforms. It is not a standalone runtime; it depends on the underlying native SDK versions installed on the device.

Share this guide

Kenji Sato

Kenji Sato edits techshooked's coverage of artificial intelligence and emerging technology, following the path from research to production systems. His standard is anti-hype: ask what a model actually does, what data trained it, how it fails in practice, and whether a benchmark measures what the marketing says it does.