ARKit VS ARCore - ZakW Comparison
Apple and Google have launched augmented reality development platforms. Apple released ARKit, and Google ARCore. (Both of which have tutorials in the wiki!)
At the very least, it is helpful to understand how the two platforms compare. Is there a clear leader in the ARCore vs. ARKit competition, or is it purely a question of which mobile OS you plan to target with your app?
ARCore vs. ARKit: Why Should You Care?
Apple and Google are clearly prepared to bank on high adoption, along with three other Facebook, Amazon, and Snapchat, who have recently invested heavily in AR development tools. With all these tech giants getting involved, it’s clear that augmented reality is moving into practical use (glasses are coming! --- my opinion). Google and Apple are both taking AR very seriously. Any developer looking to create AR apps or add AR elements to existing software need to use the SDKs released by Apple or Google---making the ARCore vs. ARKit debate one worthwhile.
Augmented Reality Origin
Apple launched its ARKit SDK in the summer of 2017, right before Google, in Apple's annual WWDC. This shocked the developer world. This allowed AR apps to be launched on any iPhone above the 6s generation. According to intelligence firm ARtillry, that's about half a billion ARKit-compatible phones.
As of February 2018, Apple’s exclusive position as a platform-specific AR tool provider ended, when Google brought its ARCore system out of beta, applying the technology to its own Pixel devices, along with a selection of other manufacturers’ flagship phones running Android 7.0 or 8.0.
The release of both SDKs allow native mobile developers to continue working on their operating system. Quite simply, the arrival of ARKit and ARCore means that AR mobile app development no longer requires a deeply specialized set of skills.
Features of ARCore and ARKit
The fundamentals of the two SDKs are very similar, based on the three main requisites for useful augmented reality software: environmental understanding, motion tracking, and light estimation. Both ARKit and ARCore have them implemented, although their approaches differ slightly.
AR requires a device to be capable of tracking its position and orientation in its real-world surroundings. ARKit and ARCore both achieve this through a technology known as visual inertial odometry (VIO). VIO relies on data from a device’s motion sensor and camera to identify spatial movement across six axes. This allows virtual objects to remain accurately positioned in the real world, which is essential for an authentic AR experience.
As well as knowing how to keep virtual objects in place, an augmented reality app must know what it’s placing them on. That’s where plane detection comes in. ARKit and ARCore apps can recognize the difference between horizontal and vertical planes in the device-camera’s field of view, so virtual items can be placed onto surfaces in a realistic way. This has been set up for developers in a similar manner, taking out all the overhead. In ARCore, this is known as environmental understanding, while ARKit calls it scene understanding. Beyond the semantic variations, there is little difference that I could find.
In order for an augmented reality experience to seem authentic, virtual objects should appear subject to the same lighting dynamics as the real-world scene in which they are placed. ARKit and ARCore solve this challenge through a process called lighting estimation, which analyses the ambient light sensed by a device’s camera to apply photorealistic rendering of virtual objects. Both of these kits do this, and again, very similar behavior.
They both incorporate 2D and 3D object tracking, which means that real-world objects can be used as markers to trigger augmented reality experiences.
They both make clever use of anchor points, which prevent AR content from being lost if the device user wanders away from the area mapped by the app. This part of the tech is fuzzy for both kits, but couldn't really expect anything less.
They can integrate with third-party tools, including Unity. ARCore is better for this.
I am positive they are for smart glasses! (Just my hunch!)
They both support facial, spacial, and geo tracking.
Differences Between ARCore and ARKit
Of course, a list of features, while useful, does not make a comparison. And if you are considering the value of ARKit and ARCore for app development, you’ll be interested to know about the advantages and limitations of each.
Differences in capability between the two SDKs are quite subtle. Both tools allow a developer to create games or more utilitarian apps that nonetheless immerse the user in an AR experience to be remembered. The tracking, motion, and lighting technologies mean users won’t feel that they are simply looking at visual data overlaid on a camera screen, but will instead be pulled into a believable alternative world when using your AR app.
When it comes to mapping, ARCore has a distinct advantage, thanks to its ability to manage larger maps. Although both SDKs use the same technique, ARKit apps store only the most recently captured location data. Older data is discarded, limiting the stability with which a scene can be re-localized after the user has directed the camera away from it (as might happen if the user drops her phone or accidentally obscures the lens). However, this allows users to take up less data space on their phone. Slight tradeoff, but ARCore seems better functionally.
Another difference is that when mapping a scene, ARCore tracks more feature points than ARKit. This means the mapped area expands more quickly in ARCore apps. However, ARKit appears to be a little more accurate with more precise points. This is a tradeoff that either side could be argued for. I am biased towards ARKit, but I also believe there is an importance to detail. That being said, there is also something to be argued for loading speed.
These small mapping issues aside, both platforms do a terrific job of placing virtual objects into AR scenes.
Give Them a Try: Examples of ARCore and ARKit Apps
Naturally, end-users of AR apps will probably not care too much about which development tool has been used, but this comparison is aimed at developers and companies planning to engineer their own apps. If that includes you, then you’ll possibly want to test some apps created with both platforms to get a feel for the experience.
Google Maps Virtual Position: Lets you explore Google Maps Street View by walking forward in physical space.
Beer Pong AR: Just for a bit of fun, place virtual red cups on your table (or any flat surface) and enjoy a game of beer pong.
IKEA Place: This is IKEA’s catalog app, which lets you try items from the retailer’s furniture range before you buy, by placing their virtual representations in the real space of your home.
Fitness AR: If you are a user of the fitness website Strava, you can use the AR Fitness app to visualize your hikes, runs, or bike rides on virtual 3D maps, which are fully detailed, and include the actual terrain and landmarks that you’ll encounter in the real world.
ARCore vs. ARKit: A Close Race So Far
If you want to build an AR app for business or consumer use, you’ll find both ARCore and ARKit to be perfectly suited to the task. The differences between them lie more in commercial dynamics than technical capability.
For example, ARKit has the advantage of greater exposure and reach, due to Apple’s vertical structure and the fragmented market in which its competitor operates. In July of 2017, Bloomberg reported that more than 80% of Apple mobile phones and tablets typically run on the latest OS version, while only 10% of Android devices do the same.
On a technical level, apart from the slightly superior mapping capabilities of ARCore, and some precision in ARKit, there’s currently little to choose between the two SDKs in terms of performance.
Verdict: It... depends!
In reality, you are unlikely to find yourself deciding between one SDK and the other purely on their merits, because you cannot build an app for Android users with ARKit, or for iOS owners with ARCore.
Therefore, your options will probably come down to working with both tools, or substituting one of them with a different SDK altogether. That’s unless of course, you choose to develop your app exclusively for one of the two mobile operating systems.
According to class feedback, ARKit is clearly easier to get used to and there are more than double the number of apps on github that use ARKit and double the number of questions of stack overflow. That being said, use what you are comfortable with! I am ARKit all the way!