How to Create Marker-Based AR for the ARLOOPA App

Choose the app destination when the project benefits from a stronger in-app environment than a browser page can usually provide. That can matter when the audience already expects to use the ARLOOPA app, when the project is part of a recurring program, or when stakeholders want the experience tied to a broader app ecosystem rather than a lightweight browser moment.

It can also make sense when the scan is only one step in a longer audience journey. In those cases, the app context may be more valuable than the reduced friction that WebAR brings.

This version uses the ARLOOPA app instead of the browser. The setup is still simple, but the real app check comes after you publish.

If your audience only needs one quick interaction, WebAR may be easier. If the experience belongs in the app, follow the steps below.

Because the phone check happens after publishing, use the Studio preview first to make sure the setup is correct.

The practical difference here is less about asset format and more about distribution expectations. Teams should be clear about where the user learns to scan, why the app is part of the interaction, and whether the audience is likely to return for multiple experiences or only one.

That means app-destination planning should include onboarding, not only marker design. If the experience depends on a series of scans, repeated use, or a wider content ecosystem, the app route becomes easier to justify.

This route is strongest in longer-running programs, museum or education deployments, repeat-use consumer programs, or environments where the audience is already comfortable entering through the ARLOOPA app. It also fits situations where a business wants more continuity between multiple AR experiences rather than a single browser-led moment.

The main tradeoff is acquisition friction. If that tradeoff is acceptable, the app route can be the cleaner long-term operating model.