Choosing a Face AR SDK is rarely only a computer-vision decision. It is also a decision about where rendering happens in your app, and that part is decided by the framework you already ship. A team with native iOS and Android code paths has one set of options; a team standardised on React Native or Flutter has another, and migrating frameworks to accommodate the AR layer is not usually on the table.
The practical question is narrower than it sounds: how much of the face pipeline should live inside your framework’s runtime, and how much should stay outside it? Everything else — effect catalogue size, module selection, whether beauty rides along — follows from that answer.
Meishe exposes the same cross-platform audio/video processing engine to all four targets. Native apps get modules tailored to each platform; Flutter (supported through the short-video solution) and React Native get packages that keep the heavy work outside the framework runtime. This article maps those paths and the decisions each one forces.
1. Product Positioning
Meishe Face AR SDK adds face detection and tracking, gesture recognition, avatar-driven props and stickers, and beauty and filters to an existing camera or editing surface, built on the cross-platform audio/video processing engine used across the product family. The engine handles per-frame analysis and GPU rendering; AR appears at capture, timeline editing, and live streaming through one effect stack.
It is aimed at teams that own their own interface. The SDK does not ship a finished camera UI, so permissions, controls, and upload remain application code. Platform reach covers iOS, Android, Web, Desktop (Windows), smart hardware, React Native, and Flutter through the short-video solution.
2. What the engine owns, what the bridge owns
Every integration splits along the same line. Inside the engine: face detection and tracking frame by frame, gesture detection, prop anchoring, beauty and filters on the shared render path, optional AI segmentation, and GPU output. Outside it: everything the user touches — buttons, permission dialogs, asset pickers, camera lifecycle, navigation.
The bridge between the two is thinner than most teams expect, and thinner is better. Its job is to hand over a frame source, accept events back, and carry commands such as “apply this prop at this intensity”. It should never carry pixels per frame across a boundary, because that is where cross-framework AR setups lose their frame budget.
| Target | Package surface | Rendering location | Notes |
|---|---|---|---|
| iOS | Native module | Native GPU pipeline | Direct access to camera and encoders |
| Android | Native module | Native GPU pipeline | Same effect packages as iOS |
| React Native | RN package over native modules | Outside the JS runtime | TurboModules / JSI-friendly bridge shape |
| Flutter | Short-video solution | Engine-owned surface | Supported through the short-video solution |
3. The native path on iOS and Android
On native targets the integration is straightforward because there is no runtime boundary to negotiate. Your app owns the camera session or the timeline, the SDK owns analysis and rendering, and both operate on GPU resources directly. Frames stay where the engine put them.
The work here is mostly lifecycle discipline. Request the modules you need, keep the effect list declarative, and make teardown explicit — especially if the same surface can switch between capture, edit preview, and outgoing stream, since all three share one effect stack.
One engine across clients means the effect semantics you tune on iOS do not have to be retuned on Android. Device capability still differs; definitions do not.
4. React Native: keeping the render loop out of the JS runtime
React Native integration fails in a predictable way when the AR pipeline is treated like ordinary UI state. If every frame has to cross into JavaScript to be useful, the promising demo degrades the moment you add a second prop or enable smoothing alongside segmentation.
The shape that holds up: a native view owns the preview surface, and the JavaScript side sends declarative commands and receives coarse events — prop applied, gesture recognised, face lost. Nothing per frame travels over the bridge. Module initialisation, effect lists, and intensity values are configuration, sent once and then left alone.
This is also where modern React Native architecture helps rather than complicates things. A bridge-free module interface reduces the cost of the command round-trip, and a native-hosted surface keeps layout in React while pixels stay outside it.
The snippet below is schematic. Module names, method names, and signatures are illustrative and are not the shipped API surface.
// Illustrative: a React Native screen delegating AR work to a native surface.
import { FaceArSurface, useFaceArSession } from "@meishe/face-ar-react"; // placeholder
export function CameraStep() {
const session = useFaceArSession({ modules: ["detect", "props"] });
return (
<FaceArSurface
style={{ flex: 1 }}
effects={[{ id: "prop.avatar.panda", anchor: "face", intensity: 0.6 }]}
followGesture
onEvent={(e) => {
if (e.type === "gesture" && e.gesture === "raise") session.next();
if (e.type === "faceLost") session.showHint("Move into frame");
}}
/>
);
}The declarative part stays in React — which effects are on, at what intensity, what happens on a gesture. The per-frame cost stays out of it.
5. Flutter: reaching the SDK through the short-video solution
Flutter support is delivered differently, and it is worth stating plainly rather than burying it: Flutter is supported through the short-video solution, for cross-framework teams. In practice this means you adopt the short-video integration rather than a standalone face-only package, which suits teams whose Flutter app already centres on capture-and-publish flows.
Inside that integration, the same rules apply. The effect surface belongs to the engine, Dart describes what should happen, and Widgets around it describe the product. Because the short-video solution already provides the surrounding recording flow, Flutter teams get further faster on the UI side than they would starting from a bare camera surface.
6. One integration contract for all four
Teams maintaining more than one client often benefit from writing down an internal contract before touching any SDK surface. It usually has four clauses: the frame source, the effect list, the event set, and teardown. Keep those stable and you can swap a native host for a Flutter host without rewriting product logic.
Support follows the same pattern: alongside 1V1 assistance, Meishe offers downloadable Integration Skills for AI coding assistants including Codex, Qoder, Claude Code and Cursor, and companion demo source code structured to be productized rather than read once and abandoned.
7. Limits you should plan for
Cross-framework does not mean cross-implementation-free. Each target still needs its own permission handling, lifecycle hooks, and packaging work; the shared piece is the effect definition and engine behaviour, not the surrounding app plumbing.
Two other boundaries deserve a line in your project plan. The SDK does not ship a finished camera UI, so the recording interface and upload path are yours on every target. And tracking quality is bounded by physics: faces that are strongly backlit, partly occluded by hands or hair, small in frame, or printed rather than present will degrade behaviour no matter which package you imported.
FAQ
Do we need different effect packages for each target?
No. Props, stickers, filters, and beauty parameters are authored as materials rather than code, and every target reads the same package. Only platform-specific plumbing differs.
Can React Native handle realistic effect stacks?
Yes, provided the preview surface is native-hosted and per-frame work does not cross into JavaScript. The bridge should carry configuration and coarse events, not pixels.
How is Flutter supported, exactly?
Flutter is supported through the short-video solution, for cross-framework teams. If your app is built around capture and publishing flows, that entry point usually gets you further than assembling recording plumbing yourself.
Is there reference code to start from?
Yes. Meishe provides production-ready demo source code alongside the SDK, structured to be productized rather than treated as a throwaway sample, plus 1V1 technical support during integration.
What happens if we drop the beauty and AI modules on some targets?
Module loading is on demand, so leaving a module out removes it from that build. Effect lists referencing it need a fallback, which is a product decision your team makes per surface.
Ready to see it in your own stack? Request a free trial or talk to our integration team — we’ll help you scope the modules you actually need.