Choose between WebAR and a native AR app by examining how people will reach the experience, how often they will return and what the application needs to do. A short public campaign and an internal tool used repeatedly may justify different approaches, even when both display the same 3D content.
Neither route is automatically the cheapest, easiest or most capable in every project. Write the customer journey first, identify the required features and ask for a representative demonstration on the intended devices. The decision should cover distribution and maintenance as well as the initial visual effect.
Begin with the point of entry
A public visitor may arrive through a link, printed code or product page. Consider what that person knows about the experience and how much effort they are likely to invest before receiving value. Every extra step needs a reason.
A browser-accessed experience can offer a direct entry route, but "web" does not mean identical behaviour on every device. The actual AR mode, permissions and supporting software still need to be understood. Avoid promising a frictionless journey from the delivery label alone.
For an installed application, explain why installing it is worthwhile. Repeated use, an existing customer application or a managed organisational workflow may provide that reason. Asking someone to install a separate app for one minor interaction needs a stronger justification.
Decide whether this is a visit or an ongoing tool
Describe how frequently the same person will use the experience. A brief campaign might prioritise easy discovery and a clear final action. An ongoing tool might need saved work, account access or integration with an established process.
Those requirements do not dictate one answer by themselves. They provide questions for the technical proposal. Ask how each approach handles the intended return journey and what the user must repeat.
Do not assume a native app creates ongoing engagement simply because it remains installed. It still needs a useful purpose and a maintained service. Likewise, a web experience can support repeat visits when the underlying journey is designed for them.
List essential features without assuming support
Separate the features required for the task from attractive extras. Identify what must be recognised, displayed, manipulated or remembered. If the application needs a specialist capability, ask for evidence that it works in the proposed implementation.
Apple's Quick Look gallery illustrates a route for presenting 3D objects and AR content on supported Apple devices. It is an example of a specific platform capability, not evidence that every browser or custom interaction can behave the same way.
For Android, the ARCore supported-device documentation identifies compatible models and feature information. A requirement for AR should not be translated into a claim that every Android phone supports the chosen experience. Define the actual release target with the developer.
Compare distribution responsibilities
Ask who controls the domain, application accounts and release process. A project can become difficult to maintain if essential access belongs only to an individual or an external supplier with no agreed handover.
For a public web experience, clarify hosting, certificates, domain renewal and third-party services. For an app, clarify the proposed distribution channel, account ownership and release responsibilities. Do not assume submission, approval or future updates happen automatically.
If the audience is internal, involve the organisation's IT team before selecting a route. Managed devices and installation policies can change what is practical. A prototype distributed informally to a few colleagues is not necessarily a workable deployment method for the whole organisation.
Examine the content and application update separately
A new product model, revised wording and a new interaction may follow different update paths. Ask which changes can be made through content tools and which require a software release. This distinction often matters more than whether the first version opens in a browser or app.
Document the approval process and who performs each update. A marketing team may be comfortable editing text but need specialist help for assets or behaviour. The project should reflect those skills rather than assuming the internal team will become developers after handover.
The site's iOS augmented reality service and Android augmented reality service provide relevant starting points for platform-specific discussions. Bring an example of a likely future change so the maintenance conversation is concrete.
Test connectivity requirements honestly
Ask what must be downloaded, when it is downloaded and which functions depend on a live connection. Do not assume that an installed app is completely offline or that a browser experience always reloads every asset on every visit.
Evaluate the actual build from a first-time user's perspective. Previously loaded content can hide the delays a new visitor encounters. Include the device, connection and content version in test notes so the result can be understood.
If offline use is essential, make it an explicit acceptance requirement. Test the agreed behaviour under controlled conditions with the developer. Identify what remains available, what is unavailable and how the application communicates that difference to the user.
Include privacy and account needs early
Determine whether the task genuinely needs an account. A public demonstration may be useful without one. An internal application may need access controls. Collecting information because it is technically possible is not a substitute for deciding why it is necessary.
Ask for a description of permissions, third-party services and data flows in either proposal. The delivery format alone does not tell you what information leaves the device or how long it is retained.
Have the appropriate organisational specialists review sensitive requirements. Keep the visitor-facing explanation consistent with the implementation. Do not advertise a privacy advantage merely because an experience is called WebAR or native.
Compare the whole cost of the proposed route
Use the same requirements when comparing proposals. Include preparation, development, device testing, content tools, distribution, hosting or service charges, support and updates where applicable. A headline development figure may exclude work that another proposal includes.
Separate initial delivery from ongoing responsibilities. Ask what happens when an operating system changes or a supporting service is retired. No supplier can promise that a digital experience will remain unchanged forever, but the maintenance approach should be understandable.
Avoid comparing a complete installed tool with a narrowly scoped browser demo as though they were equivalent. A fair comparison asks how each option fulfils the same audience task under the same operating conditions.
Use a decision record rather than a technology preference
Summarise the choice in a short record: audience, entry route, repeat-use needs, essential features, supported devices and maintenance owner. Note which assumptions were tested and which remain uncertain.
Give each unresolved question an owner and a next action. A question about catalogue access belongs with the system owner; an uncertainty about a required gesture belongs in a technical demonstration. Set a review point for those answers before approving the full scope. This prevents a delivery decision from becoming fixed while the requirements that could change it are still unknown.
An illustrative campaign might favour link-based access because it targets first-time visitors with a single product interaction. A managed internal tool might justify installation because it supports a repeated workflow. These are starting hypotheses, not universal rules.
For a proposal, contact Augmented Reality South Africa with the journey and required capabilities. Ask to see the difficult part demonstrated before committing to a full build. The right delivery route is the one the audience can use and the organisation can sustain, not the one with the most fashionable label.