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, the same native Kotlin and Swift work behind other camera and rendering features we have shipped.
What it is
AR filters and virtual try-on overlay a 3D asset, a pair of glasses, a shade of lipstick, a piece of furniture, onto a live camera feed in real time, tracked 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 you need it (and when you do not)
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, and 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, or where your volume does not justify the build cost against the conversion lift it could realistically produce; 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, integrated through React Native where most of the app is cross-platform, with native Kotlin and Swift modules where the AR framework needs direct, low-level camera and rendering access that a cross-platform bridge cannot provide efficiently, the same kind of native module work behind other camera and rendering-heavy features we have shipped, including a custom Kotlin wallpaper-rendering pipeline reviewed specifically for race conditions and memory issues on real devices.
Rendering is tuned for frame rate stability on mid-range devices, since 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, which 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 significantly across the real device landscape, not just between iOS and Android but across price tiers within each, and a filter that looks great in a demo on a new phone can lag or fail to track on an older or budget device a real share of your customers actually use. We test and tune against that real spread, not just a development device.
3D asset quality determines 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, and asset creation is usually a separate line item from the engineering, worth planning for honestly before the project starts.
Price and timeline
| 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.
Related
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, and for a mobile app with camera-based AI scanning features, 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 (one product category, one tracking type: face, body or surface) integrated into an existing app. 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 limitations; 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 but need more tracking precision and tend to need 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, so the feature's actual return is measurable rather than assumed.
What happens on devices that do not support AR?
A fallback experience, a static preview, a size guide, a standard product view, shows instead, so the feature degrades gracefully rather than breaking the page for a meaningful share of visitors on older devices.