{"id":375,"date":"2026-10-16T18:19:42","date_gmt":"2026-10-16T10:19:42","guid":{"rendered":"https:\/\/en.meishesdk.com\/blog\/?p=375"},"modified":"2026-10-16T18:19:42","modified_gmt":"2026-10-16T10:19:42","slug":"built-an-open-source-react-face-ar-sdk","status":"publish","type":"post","link":"https:\/\/en.meishesdk.com\/blog\/375.html","title":{"rendered":"Built an open-source React Face AR SDK"},"content":{"rendered":"\n

Titles containing “open source” tend to promise more than a vendor intends. This one deserves a plain statement in the first paragraph, so nobody has to infer it:<\/p>\n\n\n\n

We did not open-source the engine. What we publish alongside the SDK is companion source code \u2014 a reference React integration layer \u2014 structured to be productized rather than read once and abandoned. It is not a rewrite of the engine, and it is not a distributable package you pull from a registry. The core remains a commercial product. Both halves of that sentence matter, and the rest of this article explains why we drew the line where we did.<\/p>\n\n\n\n

For the product context: Meishe Face AR SDK provides face detection and tracking frame by frame, gesture detection, avatar-driven props and stickers, and beauty and filters on one render path, built on the cross-platform audio\/video processing engine used across the product family, with AR running at capture, timeline editing, and live streaming through one effect stack.<\/p>\n\n\n\n

1. Product Positioning<\/h2>\n\n\n\n

Meishe Face AR SDK is the face analysis and AR rendering module of the cross-platform audio\/video processing engine used across the product family. Integration into React happens through a package exposing a native-backed surface, with analysis and rendering executed outside JavaScript.<\/p>\n\n\n\n

The SDK does not ship a finished camera UI, and it does not ship as a package you install from a public registry. Integration includes 1V1 support, production-ready demo source code, and authoring tools and training for the designers producing effect content.<\/p>\n\n\n\n

2. What “open source” is and is not in this context<\/h2>\n\n\n\n

The ambiguity is usually one of four expectations, so it is worth answering each directly.<\/p>\n\n\n\n

Expectation<\/th>Reality<\/th><\/tr><\/thead>
The engine source is public<\/td>No \u2014 it is a commercial product<\/td><\/tr>
Companion code ships with the SDK<\/td>Yes \u2014 production-ready demo source code<\/td><\/tr>
It can be pulled from a package registry<\/td>No \u2014 distribution runs through Meishe<\/td><\/tr>
It is a throwaway sample<\/td>No \u2014 it is structured to be productized<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Everything below assumes those four answers. Teams evaluating on the assumption that they will read and modify the detector will want to adjust their plans early; teams evaluating on the assumption that they will build their own React layer around a stable engine are looking at roughly what exists.<\/p>\n\n\n\n

\n

Distribution, licensing terms, and version availability are matters handled directly with Meishe rather than through a public repository.<\/p>\n\n\n\n

\"Built<\/a><\/figure>\n<\/blockquote>\n\n\n\n

3. What ships alongside the engine<\/h2>\n\n\n\n

Three things arrive with an integration, and only one of them is source code.<\/p>\n\n\n\n

Production-ready demo source code.<\/strong> The reference React integration layer demonstrates the contract that matters: how a surface is mounted, how effects are declared, how events come back, how teardown happens. It is written so a team can carry its structure into production rather than discard it after reading.<\/p>\n\n\n\n

1V1 technical support.<\/strong> Integration questions get answered by people who know both the engine and your target, which shortens the period where every issue looks like either your bug or ours.<\/p>\n\n\n\n

Authoring tools and training.<\/strong> Designers produce props, stickers, filters, and beauty looks in an authoring environment, rather than filing tickets for engineers to hand-code effects. This is the piece most underestimated during planning.<\/p>\n\n\n\n

4. Inside the reference React layer<\/h2>\n\n\n\n
\n

The snippet below is schematic. Module names, method names, and signatures are illustrative and are not the shipped API surface.<\/p>\n<\/blockquote>\n\n\n\n

\/\/ Illustrative structure of a reference React integration layer.\nimport { FaceArSurface, useFaceArSession } from \".\/face-ar\/faceArBridge\"; \/\/ local module\n\ntype EffectSpec = { id: string; anchor: \"face\" | \"frame\"; intensity: number };\n\nexport function EffectScreen({ effects }: { effects: EffectSpec[] }) {\n  const session = useFaceArSession({\n    modules: [\"detect\", \"props\"],       \/\/ requested explicitly, loaded on demand\n    onReady: () => session.attach(effects),\n  });\n\n  return (\n    <FaceArSurface\n      style={{ flex: 1 }}\n      effects={effects}\n      onEvent={(event) => {\n        switch (event.type) {\n          case \"gesture\":\n            if (event.gesture === \"raise\") session.startRecording();\n            break;\n          case \"faceLost\":\n            session.showHint(\"Move into frame\");\n            break;\n        }\n      }}\n      onDispose={() => session.release()}\n    \/>\n  );\n}<\/code><\/pre>\n\n\n\n
What to notice is what is absent. No per-frame code, no pixel handling, no imperative rendering instructions in React. The demo layer exists to show a clean separation, which is also why it transfers cleanly to production: any team following the same pattern has put nothing React-specific in the path between frames.<\/p>\n\n\n\n
5. Productizing companion source: the six moves<\/h2>\n\n\n\n