What a running load comparison between Unity and native Android means for a build decision.
Every team building a walking navigation app with augmented reality hits the same fork early. Build directly on ARCore in native Android, or work through Unity and lean on the engine tooling. Both routes ship an app. The question is what each costs the device.
A research team answered that with a controlled comparison. They implemented one location based AR navigation prototype for outdoor pedestrians, then built it again on the other stack. Both versions used ARCore and handled the same navigation job, so the measured difference came from the platform rather than the feature set.
The native build won on running load. It kept the AR view alive while drawing less from the phone, which is the difference between an app you can use on a twenty minute walk and one you have to close early. The engine build carried extra weight, since an engine is a general purpose runtime sitting between the app and the hardware.
Treat it as a direction, not a verdict. The comparison used one prototype and one generation of ARCore, and running load shifts with every phone model and OS update. If the audience carries mid range handsets, benchmark both stacks on those exact devices before committing.
There is also a middle path. A team can prototype in Unity to iterate quickly on look and feel, then move the parts that matter to a native build once the design settles. The study does not test that route, but it explains why the final step is worth taking.
The headline finding is simple enough to act on. For an outdoor AR walking app, the platform choice shows up directly in how much the phone has to work, and that cost lands on the user every minute the camera is on.
Komang Candra Brata et al. (2023). An investigation of running load comparisons of ARCore on native Android and Unity for outdoor navigation system using smartphone. 2023 Sixth International Conference on Vocational Education and Electrical Engineering (ICVEE).
