ARKit vs ARCore: Which Is Best for AR Apps in 2026

You are scoping an AR app, maybe a furniture placement view or a room planner, and one question keeps stalling the plan: build on Apple’s ARKit, Google’s ARCore, or both. It sounds like a small engineering choice. It is not. It decides which customers can use the feature on day one, how much the build costs, and how much of the 3D work you can reuse later.

This is the fair arkit vs arcore comparison that most of the search results avoid. The typical article names both platforms and moves on "without getting too techie". We have shipped AR, so this goes into the parts that actually move your budget: tracking, occlusion, device reach, and the LiDAR features that only some iPhones have.

What are ARKit and ARCore?

ARKit is Apple’s AR framework for iPhone and iPad. ARCore is Google’s AR SDK for Android, with some support on iOS. Both track the phone as it moves, find real surfaces, estimate light and anchor 3D objects to the room. They are the engines under most native AR apps, including furniture placement and room planning.

Three terms explain how they work. SLAM means simultaneous localisation and mapping: the phone works out where it is while it builds a rough map of the space. Google states that ARCore "uses simultaneous localization and mapping, or SLAM, to understand where the phone is relative to the world around it" in its ARCore fundamentals docs. Plane detection is how the SDK finds the floor, a table or a wall so your model can sit on it. Anchors pin a virtual object to a real spot so it stays put as you walk around.

ARKit does the same jobs with the same ideas. The differences that matter for a product are not the concepts. They are the hardware each one runs on and the extra sensors some devices carry.

ARKit vs ARCore: how they compare job by job

Job by job, ARKit and ARCore are close on tracking, plane detection and light estimation. They separate on depth and occlusion, where ARKit can call on LiDAR, and on device reach, where ARCore covers far more phones. This is the part any real ar sdk comparison has to get right, so here it is laid out plainly.

Tracking and plane detection

Both platforms track well in a normal room with steady light and some texture on the surfaces. ARCore finds "clusters of feature points that appear to lie on common horizontal or vertical surfaces" and also estimates angled surfaces through oriented points, per its developer documentation. ARKit detects horizontal and vertical planes in much the same way. Both drift in blank, dark or shiny spaces, because a camera with nothing to lock onto cannot tell that it has moved. That failure mode is the same on either platform, and it is why measurement accuracy is its own topic, covered in our guide on getting accurate AR measurements.

Depth and occlusion

Occlusion is the effect that makes a virtual sofa look like it is really behind your coffee table instead of floating over it. It needs the app to know how far away real surfaces are. ARCore builds this from ordinary cameras: its Depth API "uses a depth-from-motion algorithm to create depth images" and, "if the device has a dedicated depth sensor, such as ToF, the algorithm automatically merges data from all available sources", according to the ARCore Depth API docs. ARKit reads scene depth too, and on iPhones with a LiDAR scanner that depth is instant and sharper, which makes occlusion and floor detection more reliable in a cluttered room.

Read the table as a map of strengths, not a scoreboard. For most furniture use, the honest reading is that ARCore gives you good enough depth on a huge range of phones, while ARKit gives you excellent depth on the smaller set of iPhones that carry LiDAR.

Device reach: iOS vs Android AR

Device reach is the biggest practical split in the ios vs android ar question. ARKit runs on every recent iPhone and iPad, one narrow hardware family that Apple controls end to end. ARCore runs on a certified list of Android devices, which is large but does not include every Android phone in the market. Reach and consistency pull in opposite directions here.

Google certifies each model before it joins the arcore supported devices list. It states that "to certify each device, we check the quality of the camera, motion sensors, and the design architecture to ensure it performs as expected", and that a device also "needs to have a powerful enough CPU", per the ARCore supported devices page. That page also reports broad support for newer features, noting that a large majority of active devices support the Depth API. The takeaway for planning: check the live device list against your own audience before you promise AR to every Android user, because a cheaper handset may not qualify.

On iOS the story is simpler. If a customer has a recent iPhone, ARKit is there. That consistency is why some teams that skew heavily to iOS buyers start on ARKit even when their long term plan covers both platforms.

The LiDAR only features on Pro iPhones

LiDAR is a small depth scanner on Pro iPhones and iPad Pro that measures distance directly with light, rather than guessing it from camera motion. It is not required for basic AR, but it enables features that ARCore has no direct match for, and it sharpens the ones both platforms share. If your product depends on precise room capture, this is where ARKit pulls ahead.

The clearest example is RoomPlan. Apple describes it as "a new Swift API that utilizes the camera and LiDAR Scanner on iPhone and iPad to create a 3D floor plan of a room, including key characteristics such as dimensions and types of furniture", on its RoomPlan page. That is a genuine room planner built into the platform, and it needs the LiDAR scanner to work. Whether your app actually needs it is a real decision, which we work through in our explainer on Apple RoomPlan and in the wider question of whether you need LiDAR for an AR furniture app at all. For a lot of single item placement, you do not.

Why a furniture app usually needs both

A furniture or room planning app that wants the whole market usually needs both ARKit and ARCore, because your customers are split across iOS and Android and neither platform reaches the other. The real work is not choosing one SDK. It is deciding how to serve both without building everything twice. This is the heart of the arkit vs arcore for furniture question.

Most of the shared effort is the 3D content, not the AR code. Every product model has to exist in two formats. Apple’s AR Quick Look shows models "using the USDZ file format" directly in Safari and built in apps, per Apple’s AR Quick Look page, while Android’s Scene Viewer expects glTF or glb. So a single sofa needs a USDZ and a glTF export, both under a tight size budget. That dual export, plus the catalogue work behind it, is the part that quietly eats a furniture AR budget. We cover the formats in USDZ and glTF explained and the production side in how to make 3D models for an AR furniture app.

For the app itself you have two routes. Build two native apps, one on ARKit and one on ARCore, which gives the tightest fit with each platform and the smallest apps, at the cost of two codebases. Or build one cross platform app in Unity or Unreal, which wrap both engines through a shared layer so you write the AR logic once. Cross platform AR trades some platform polish and app size for a single codebase and faster reach. There is no universally right answer, only the one that fits your team and your timeline.

The flow above is the order we suggest to most clients. Do not build both platforms at the same time on a first release. Ship the platform your buyers use most, measure whether AR actually lifts placement and cuts returns, and only then fund the second. If you are still shaping the idea, our guide on how to turn an idea into an app covers the steps before this one.

What it costs to build

Cost is driven by five things, not by which SDK you pick: how many platforms you ship, the size and quality of your 3D catalogue, whether you need LiDAR grade precision, how deep the app goes beyond simple placement, and the ongoing catalogue upkeep. The AR engine itself is free. The content pipeline and the second platform are where the money goes.

For a sense of scale, appico’s published starting prices put a mobile app build from $12,000, with larger, multi feature builds ranging up to about $150,000 depending on scope. A single platform placement feature sits near the lower end. A two platform app with a large product catalogue, custom room scanning and analytics sits higher. Maintenance is a separate monthly plan, which matters here because a furniture catalogue changes constantly. You can shape a rough range for your own scope with our cost calculator, and it is worth reading alongside a real world AR case like the cost and time to develop a virtual try on app, which shares the same 3D and tracking challenges.

When you do not need native AR at all

Native ARKit or ARCore is not always worth it. If your goal is a simple "see it in your room" view with no install, no offline use and no precise measurement, WebAR can do the job from a plain web link on both platforms at once. You skip two native builds and two app store reviews. That is a real saving, and for a lot of retail sites it is the right first step.

The honest limits of the native path are worth stating. Native AR means more device support work, larger apps, app store review and, for a furniture catalogue, a heavier 3D pipeline than a website usually carries. It pays off when you need reliable tracking, occlusion, offline capture or the deeper platform features like RoomPlan. It does not pay off when a link driven preview would satisfy the customer. We compare the two paths in full in WebAR vs a native AR app, and that is the post to read before you commit to either ARKit or ARCore.

Our take

After building this kind of app, our rule is simple. Do not choose ARKit or ARCore in the abstract. Choose the platform your paying customers are already on, build it native and well, and prove that AR changes a number that matters before you spend on the second platform. Keep your 3D models in both USDZ and glTF from day one so the second platform is an addition, not a rebuild.

ARKit and ARCore are both mature, and both will serve a good furniture app. The projects that struggle are not the ones that picked the wrong SDK. They are the ones that underestimated the 3D catalogue and tried to ship both platforms at once. If you want a second opinion on scope, our app development team is happy to look at your specific case and tell you honestly which platform to build first.

Frequently asked questions