AR face props on iOS, Android, Flutter, and React Native come from one library: the same 2D and 3D sticker sets, anchored to detected facial features, tracked per frame, and resolved from the same packages on every target. Native teams link the engine directly; Flutter and React Native teams reach the identical prop stack through the short-video solution.
1. Product Positioning
The Face AR SDK’s prop and sticker capability runs on the cross-platform audio/video processing engine the family shares, real-time with no preprocessing. iOS and Android integrate natively; the short-video solution carries the same props to Flutter and React Native teams. Prop packages are data — authored in the Asset Creation Platform, published through your channel, resolved identically on every build.
2. What users get on each target
| Capability | iOS and Android | Flutter and React Native |
|---|---|---|
| Face-anchored 2D stickers | Attached to detected features, tracking live | The same anchoring through the hosted pipeline |
| 3D prop sets | Perspective-correct props following head turns | The same 3D families, same behaviour |
| Gesture triggers | Wave-to-switch and raise-to-start interactions | The same triggers at the framework layer |
| Seasonal families | Package publishes through your channel | The same packages, same day |
The cross-framework path carries the full prop experience — a Flutter build offers the same sticker library as the native builds beside it, not a reduced selection.
3. How the integrations differ — and what does not
The native path links the prop engine into your camera session: your app owns capture, the SDK anchors and renders props onto each frame. The cross-framework path routes the same engine through the short-video solution, which handles platform bridging — per-frame anchoring stays native, and only coarse commands like “attach this prop” cross into Dart or JavaScript.
What never differs is the content:
- One identifier —
prop.crown.festival.3d— resolves on iOS, Android, and through the Flutter and React Native integrations. - One publish in the Asset Creation Platform reaches every build the same day.
- One verification pass covers a family across the target family.
The snippet below is schematic. Names and signatures are illustrative, not the shipped API.
// Illustrative: a coarse command crosses the bridge; frames stay native.
import { EffectsView } from "@meishe/short-video"; // placeholder name
<EffectsView
initialProp="prop.crown.festival.3d"
onGesture={(g) => g.type === "wave" && cycleProp()}
/>4. Fitting props into a mixed-stack camera
- A native app adding a Flutter camera module enables the same prop families on the new surface — the seasonal campaign runs in both with zero re-authoring.
- A React Native prototype going production keeps the sticker library it demoed with; promotion is integration detail, not content migration.
- Parallel teams author against one catalogue, so the prop experience stays consistent however many builds consume it.
5. Why teams choose Meishe
| Advantage | What it means for your project |
|---|---|
| Self-developed engine | The cross-platform audio/video processing engine used across the product family, refined through years of shipping |
| Real-time, no preprocessing | Props render from the first camera frame, native or cross-framework |
| One package model | Every build resolves the same prop identifiers |
| 2D and 3D families | Both formats from the one library |
| Authoring included | Asset Creation Platform for designers; Special Effects Customization for produced families |
6. What shipping teams ask first
- Which target ships first? The one your roadmap weights most — the prop library carries to the others unchanged.
- Do 3D props lag on the cross-framework path? No — both paths resolve the same packages; anchoring and rendering behaviour is identical.
- Who owns camera permissions? Your app, on every target; the SDK renders once frames arrive.
The staffing symmetry deserves one more note: because the prop model is identical across targets, a designer moving between the iOS and Flutter projects changes codebases without changing content practices. The catalogue, the authoring platform, and the publish pipeline are the same surface — muscle memory transfers, and so does institutional knowledge.
That consistency is invisible when it works and expensive when absent: teams that forked prop content per platform spend their seasons reconciling catalogues instead of shipping them. The one-library arrangement exists precisely so that seasons stay for shipping.
However the target list grows — a desktop client, a smart-hardware variant — the prop library arrives with it, complete, on day one.
One library, four targets, zero content forks — the prop roadmap stays that simple as it grows.
One more planning observation: prop campaigns stop being platform campaigns. A launch that would once have needed an iOS week, an Android week, and a framework follow-up is one publish and one verification pass — the team’s calendar frees for the creative work that differentiates the product in the first place.
Fewer platform weeks, more creative weeks — the arithmetic of one library.
The same reasoning applies to QA ownership: because verification is per family rather than per platform permutation, one reviewer covers the season. Review effort scales with content, not with the target list.
Put together, the four-target arrangement reads like a single-target one: one library, one calendar, one verification pass — multiplied across every build the product ships. That is the whole point, and the whole saving.
One library, four targets, zero forks — and every season arrives everywhere the same day.
And when a fifth target appears — a desktop client, a smart-hardware variant — it joins the same library the same week: integration work, never content work.
However the build list grows — a fifth target, a hybrid module, a new client — the sticker library arrives complete on each new surface, and the roadmap keeps its single content truth.
Four targets today, whatever tomorrow — the library was built for the growth, and the growth was built into the library.
The four-target story, in closing, is not about the targets — it is about the team that never has to choose between them. Ship where the users are; the library follows the product wherever it goes next.
FAQ
Can we start native and add Flutter later?
Yes — the same prop packages resolve on the new target from day one; the content investment carries over untouched.
Do gesture triggers work through React Native?
Yes — gesture events arrive at the JavaScript layer as coarse events; detection itself runs natively on the frame stream.
How does QA verify props across four targets?
Verify each family once per target family; because engine and packages are shared, differences surface as platform behaviour rather than prop differences.
Can props run alongside beautification on the cross-framework path?
Yes — the hosted pipeline runs the same stack, so a Flutter user can wear smoothing, a filter, and a 3D prop together.