Try it on before you buy it:
on your own app, not a borrowed camera effect
Virtual try-on and AR filters live or die on the camera pipeline. Frame rate, tracking stability, and how a 3D asset sits on a moving face or body in real light. We build this with native modules where the platform's AR framework needs direct access. That is the same native Kotlin and Swift work behind other camera and rendering features we shipped before.
What this feature actually is
AR filters and virtual try-on overlay a 3D asset onto a live camera feed in real time. A pair of glasses. A shade of lipstick. A piece of furniture. It tracks against a face, body, or surface as it moves.
The engineering center of gravity is the tracking and rendering pipeline. Getting a 3D asset to sit convincingly, and stay stable at a usable frame rate, on real-world phones, not just the newest flagship model.
When seeing it on yourself actually matters
You need this when a purchase decision genuinely benefits from seeing the product on yourself or in your space before buying: eyewear, cosmetics, apparel, furniture. It matters most when your return rate or cart abandonment data suggests “I was not sure how it would look” is a real blocker. It is a strong fit for e-commerce categories where fit and appearance drive returns.
You do not need this for products where appearance in context is not the deciding factor. The same goes if your volume does not justify the build cost against the realistic conversion lift. We will say so if an AR feature looks more like a novelty than a conversion lever for your specific catalogue.
How we build it
Tracking runs on ARKit for iOS and ARCore for Android, the platform-native frameworks for face, body and surface tracking. We integrate through React Native where most of the app is cross-platform. Native Kotlin and Swift modules step in where the AR framework needs direct, low-level camera and rendering access that a cross-platform bridge cannot provide efficiently.
That is the same kind of native module work behind other camera and rendering-heavy features we have shipped. It includes a custom Kotlin wallpaper-rendering pipeline we reviewed specifically for race conditions and memory issues on real devices.
Rendering is tuned for frame rate stability on mid-range devices. A filter that only runs smoothly on a flagship phone fails for a meaningful share of a real audience. This tuning, not the initial tracking integration, is usually where most of the engineering time goes.
A capture-and-share flow lets users save or post what they tried. That often matters as much for organic reach as for the purchase decision itself. WebAR is available as a no-install alternative for broader reach, with the tradeoff of weaker tracking stability than a native app.
What to watch
AR performance varies a lot across real devices. That is true between iOS and Android, and across price tiers within each. A filter that looks great in a demo on a new phone can lag on an older or budget device. It can even fail to track there, and a real share of your customers use exactly that kind of device. We test and tune against that real spread of hardware, not only a development device.
3D asset quality sets the ceiling on realism more than the tracking code does. A low-quality 3D model of a product will look unconvincing no matter how good the tracking is. Asset creation is usually a separate line item from the engineering, worth planning for honestly before the project starts.
What it costs
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Single try-on experience | from $5,000 | One tracking type, one product category, capture and share | 5 to 7 weeks |
| Multi-category AR suite | from $10,000 | Several product categories, conversion tracking, WebAR fallback | 7 to 14 weeks |
Running cost is usually low, under $20 a month, since AR processing runs on-device rather than server infrastructure. Cost mainly scales with 3D asset production, not hosting.
Where this connects
Pairs with QR and NFC experiences for in-store AR activation, and with the native iOS and native Android development covered on our development page.
For real native mobile rendering work with the same Kotlin and Swift discipline this needs, see the TaskWall wallpaper app case study. For a mobile app with camera-based AI scanning features, see the fitness app AI coach case study.
Wondering if try-on would actually move your conversion rate? Get in touch and we will look at your return and cart data first.
FAQ
How much does an AR filter or try-on feature cost?
From $5,000 for a single try-on experience integrated into an existing app: one product category, one tracking type (face, body or surface). Multiple product categories, a capture-and-share flow, and purchase-conversion tracking typically run $9,000 to $16,000.
Does this work in a web browser or does it need an app?
Both are possible. WebAR runs in a mobile browser with no install, which maximizes reach but has more device and performance limits. A native app with ARKit or ARCore gives more stable tracking and better performance, at the cost of needing an install. We will recommend based on your actual use case and audience.
What products work well for virtual try-on?
Face-based items, glasses, makeup, hats, track reliably on current phone hardware. Apparel on a full body and furniture placement in a room are solvable too. They need more tracking precision, and usually a native app rather than WebAR for a good result. We will tell you honestly which tier of experience your product category can support.
Can we measure if try-on actually increases purchases?
Yes. We wire in analytics on try-on session starts, completions, and the resulting purchase or add-to-cart rate. The feature's actual return becomes measurable, not assumed.
What happens on devices that do not support AR?
A fallback experience shows instead: a static preview, a size guide, a standard product view. The feature degrades gracefully, rather than breaking the page for a meaningful share of visitors on older devices.