TL;DR: For most business AR apps built in Unity, I start with AR Foundation, because it gives you ARKit on iOS and ARCore on Android from one project and keeps you close to what the platforms actually ship. I reach for Vuforia when the job is recognising specific things, printed images or physical objects, reliably and in bad conditions, and when the client accepts a commercial licence. I go fully native with ARKit or ARCore only when the app is single-platform, AR is a small part of a larger native app, or it needs a platform feature the day it ships. The wrong choice is rarely fatal, but it is expensive to undo, so make it on what the app has to recognise and where it has to run, not on which demo looked best.
I have built AR in Unity for years, including the ERIS XR platform and the AR Planes and AR Properties tools at ARCortex, plus the AR crypto and NFT viewers, and AR Foundation, Vuforia, ARKit and ARCore have all been in my toolbox at different points. Clients rarely ask me which SDK to use. They ask whether the thing they have in mind is possible, how long it takes, and why the prototype they saw last month does not work in their warehouse. The SDK decision sits underneath all three of those answers.
Here is how I make it.
Start with what the app has to recognise
Every AR SDK comparison online lists features. The more useful question is: what does your app need to find in the real world before it can show anything?
There are roughly four answers, and they point to different tools:
- Surfaces. A floor, a table, a wall. Place a product, a model or a marker on it. This is the most common business AR case, and every option handles it well.
- Known images. A poster, packaging, a page in a manual, a sign on a machine. The app recognises a specific picture and anchors content to it.
- Known objects. A particular engine, a piece of equipment, a product on a shelf. The app recognises a 3D thing, not a flat picture.
- Places. A building, a street, coordinates on a map. The content belongs to a location rather than to whatever the camera is pointing at.
Surfaces and places favour AR Foundation and the native SDKs underneath it. Known objects is where Vuforia has historically earned its price. Known images sits in the middle, and the right answer depends on how hostile the conditions are.
AR Foundation: my default for Unity
AR Foundation is Unity's cross-platform layer. You write against one set of components, planes, anchors, raycasts, image tracking, face tracking, and it uses ARKit on iOS and ARCore on Android underneath. The tracking quality is whatever Apple and Google ship, which in practice means very good world tracking on modern phones.
Why it is usually my starting point:
- One codebase, two platforms. For a business app that has to run on whatever phones the client's staff or customers carry, this is the whole argument. You build the interaction once.
- It is free and it is Unity's own package. No separate licence to negotiate, no per-app fee, and it moves with the engine rather than against it.
- It is honest about the platforms. Because it is a thin layer over ARKit and ARCore, what you test is close to what the operating system actually does. There is less magic to debug.
- It extends to headsets. The same concepts carry into XR work, which matters if a phone prototype might grow into a headset deployment later. I wrote about that boundary in choosing an XR headset for enterprise.
The trade-offs are real, though:
- It lags the platforms. When Apple or Google ship a new capability, it reaches AR Foundation later, and sometimes only on one platform. Some features exist on iOS and simply do not on Android.
- The lowest common denominator is a design constraint. If you design for one platform's best feature, you will either fork the experience or leave the other platform worse. I would rather know that before the scope is signed.
- Image tracking is fine, not exceptional. For a clean, high-contrast image in decent light, it works. For a glossy, low-detail or partly covered target in a dim room, it struggles more than a specialist would.
For location content, Google's Geospatial API plugs into AR Foundation through ARCore Extensions and works on both platforms. It does not remove the hard part, which is reconciling the camera's local world with real coordinates. That is a story of its own, and I covered it in the geospatial AR coordinate problem.
Vuforia: when recognition is the product
Vuforia's reputation comes from recognition. It has been doing image targets for a long time, and its model targets let you recognise a physical object from its 3D model, which is exactly what industrial and maintenance apps need: point the tablet at the machine, and the overlay snaps to the machine.
When I lean towards it:
- The app is about a specific object. Equipment training, guided maintenance, product demos where the anchor is the product itself. Recognising a 3D object reliably is genuinely hard, and building it yourself is a research project.
- The targets are difficult. Low-texture packaging, reflective surfaces, targets seen at an angle or partially hidden. Specialist recognition earns its keep in exactly the conditions where the free option gets flaky.
- The client already runs it. Some enterprises have existing Vuforia content and tooling. Rebuilding that to save a licence fee rarely makes sense.
What to weigh against it:
- It is a commercial product with a commercial licence. Check the current pricing and terms before you build, not after, and make sure the licence matches how the app will be distributed. A free development tier does not mean a free production app.
- It is another dependency between you and the platform. You are now waiting on two vendors for updates when iOS, Android or Unity changes. That is the same lock-in question I raise for voice platforms in voice agent platform lock-in: keep your own logic out of the vendor's layer so a change of SDK is a swap, not a rewrite.
- It can be more than you need. If the app only places objects on floors, you are paying for recognition you will never use.
Native ARKit or ARCore: when one platform is enough
Going native means writing the AR part in Swift with ARKit and RealityKit on iOS, or in Kotlin with ARCore on Android, without Unity in the middle.
I recommend it in a narrower set of cases:
- AR is a feature, not the app. If the product is an existing native app and AR is one screen inside it, adding a whole engine for that screen is heavy. A native AR view keeps the app size and the build pipeline sane.
- The audience is on one platform. An internal tool for a company that issues iPads, for example. Then cross-platform is not a benefit, and native gives you the newest features first and the tightest integration with the rest of the device.
- The feature you need only exists natively, today. Some capabilities arrive in the native SDK long before they reach any cross-platform layer. If that feature is the point of the app, you go where it lives.
The cost is that you lose Unity's strengths: the scene tooling, the asset pipeline, physics and animation, and the ability to ship the same interaction on both platforms. If the AR content is rich, interactive 3D, rebuilding that on a native renderer usually takes longer than the cross-platform tax you were trying to avoid. That is the same trade I walk through in when Unity makes sense for non-game apps.
The questions I ask before choosing
When a client brings me an AR idea, these questions settle the SDK faster than any feature table:
- What does the app have to find first? Surface, image, object or place.
- Which devices, exactly? Named models, not "phones". Older and cheaper Android devices are where tracking surprises happen.
- Where will it be used? Office lighting, a dim warehouse, outdoors in sun, a moving vehicle. Conditions decide recognition quality more than the SDK's marketing does.
- Is AR the product or a feature? This is the single biggest driver of Unity versus native.
- Who pays for licences, and for how long? Including after the build, when the app is in maintenance.
- Could this grow onto a headset? If yes, staying in Unity keeps that door open.
If the answers are "surfaces, both platforms, AR is the product", that is AR Foundation, and we can move on to the parts that actually take time.
Whatever you pick, protect the boundary
The SDK is not where most of an AR project's time goes. It goes into content, interaction design, performance on real devices and testing in the place the app will actually be used.
So I structure every AR project the same way regardless of SDK. The domain logic, what the content is, where it belongs, what state the session is in, lives in plain code that knows nothing about the tracking provider. The SDK sits behind a thin layer that answers a few questions: where is the surface, where is the target, where is the anchor. If we ever need to switch providers, we rewrite that layer, not the app. It is the same rule I learned building a cross-platform SDK at Geonode: share the logic, never the platform.
And whatever you choose, test it in the field early. The editor and the office will both tell you the SDK works. The site will tell you the truth. I wrote down my process for that in testing AR apps in the field, and it is the step I would least want a client to skip.
My short answer
- Unity, both platforms, surfaces or places: AR Foundation.
- Recognising specific objects or difficult images, budget for a licence: Vuforia, kept behind a boundary.
- One platform, AR is one screen of a native app, or a brand-new platform feature is the point: native ARKit or ARCore.
None of these is a forever choice, but switching later costs weeks, not hours. Spending an hour on the questions above before writing code is the cheapest insurance in an AR project.
I build AR, XR and Unity products for businesses, from field tools for the U.S. Fire Administration at ARCortex to clinical XR at Nystag, alongside AI agents and full-stack products for founders across the US, UK and Europe. If you are weighing an AR idea, more about my work here, or book a call.