“Tested & Compared” usually means a grid of vendors. This article sets up something narrower and more useful: it takes one React Native Face Filters SDK and weighs the two arrangements any team has for owning its look library, then describes how to run both long enough to make a decision you can defend in a design review.
Those arrangements are bundled packages and runtime-fetched packages. Every face AR team eventually faces this fork, because it decides your failure modes rather than your feature set: whether a bad seasonal package can be rolled back this afternoon, whether the newest looks work offline, and whether your content calendar inherits your release train.
Note what is deliberately absent below. There is no cross-product ranking here, because a choice like this is shaped by your team’s release rhythm and storage budget rather than by any property worth putting in a scorecard.
1. Product Positioning
Meishe Face Filters SDK is the filter and effects layer of the Face AR SDK family. It evaluates real-time effects without pre-processing on the cross-platform audio/video processing engine used across the product family, serving capture, timeline editing, and live streaming from one effect stack. React Native is one target alongside iOS, Android, Web, Desktop (Windows), smart hardware, and Flutter (supported through the short-video solution, for cross-framework teams).
Effect libraries ship as data: individual elements and complete looks, with per-element intensity control. Both arrangements below consume exactly those packages.
The SDK ships no finished camera UI, so permissions, recording controls, and upload remain yours in either case.
2. Two ownership arrangements
Packages are data rather than compiled behaviour, which is what makes the fork possible at all. Where those packages live at runtime is your decision.
Arrangement one — bundled with the build. Packages ship inside the application binary. First launch works with no network, every user gets the same set, and nothing about your content can break without a release you approved.
Arrangement two — fetched at runtime. Packages live behind a channel you control and are resolved on demand. Publishing a look no longer waits on an app review cycle, and retiring one is a content operation rather than an engineering ticket. In exchange, you own availability, caching, and rollback.
| Concern | Bundled packages | Runtime-fetched packages |
|---|---|---|
| First-run availability | Works with no connectivity | Depends on your cache and channel |
| Update path | Follows your release train | Independent of app releases |
| Rollback granularity | Whole application | Single package or look |
| Storage growth | Counts against app size | Counts against cache budget |
| Who owns delivery risk | Nobody at runtime | Your team |
Neither column is inherently stronger. Teams whose content changes monthly tend toward fetched; teams shipping a fixed set into constrained environments lean bundled; plenty run a hybrid with a bundled core and fetched seasonal sets.
3. Arrangement one: bundled with the build
The appeal is determinism. Whatever you tested is what ships, and there is no runtime dependency standing between a user opening the camera and the look resolving.
The snippet below is schematic. Names and signatures are illustrative and are not the shipped API surface.
// Illustrative bundled-package integration sketch.
import { EffectPreview } from "@meishe/react-native-effects"; // placeholder name
import { BUNDLED_LOOKS } from "./catalog/manifest"; // whatever your build produces
export function CaptureScreen({ lookId }: { lookId: string }) {
const preview = useRef<EffectPreview>(null);
const look = BUNDLED_LOOKS[lookId];
return (
<EffectPreview
ref={preview}
style={{ flex: 1 }}
captureMode="video"
look={look}
onReady={() => preview.current?.setElementLevel("lip.satin.maple", "standard")}
/>
);
}What you are really choosing here is release coupling. Adding a look means building and distributing the app, and correcting a look that reviewed badly means doing it again. Budget for the fact that marketing calendars dislike this conversation.
4. Arrangement two: fetched at runtime
The appeal is independence. Content moves at its own pace, and because a look references elements rather than containing them, a single element edit propagates to every look that uses it without re-exporting anything individually.
The snippet below is schematic. Names and signatures are illustrative and are not the shipped API surface.
// Illustrative runtime-fetched integration sketch.
import { EffectPreview } from "@meishe/react-native-effects"; // placeholder name
export function CaptureScreen({ lookId }: { lookId: string }) {
const preview = useRef<EffectPreview>(null);
const [state, setState] = useState<"idle" | "resolving" | "ready" | "failed">("idle");
useEffect(() => {
let cancelled = false;
(async () => {
setState("resolving");
try {
await preview.current?.assets.resolve(lookId); // fetch and cache
if (!cancelled) setState("ready");
} catch {
if (!cancelled) setState("failed"); // show a fallback, never a blank frame
}
})();
return () => { cancelled = true; };
}, [lookId]);
return (
<EffectPreview
ref={preview}
style={{ flex: 1 }}
captureMode="video"
look={state === "ready" ? lookId : null}
/>
);
}The failed branch is the whole point of this arrangement. Once delivery stops being your vendored build step, it becomes a runtime condition with three honest states: cached, resolving, unavailable. Applications that omit the third one ship black frames.
5. Running both without guessing
A week of argument can be replaced by one afternoon of evidence if the protocol is written first.
Shared corpus. Ten looks drawing on twenty shared elements, including two you intend to retire. Run it identically through both arrangements.
Scripted sequence. Cold start with a cleared cache, then a warm start, then a cold start with no connectivity. Apply every look, step each element through light, standard, and strong, and record clips at every step.
Rollback drill. Publish a deliberately poor look, then roll back to the previous one. Time how long it takes for users to stop seeing it under each arrangement. This single drill usually settles the argument.
Storage and startup accounting. Measure app size growth for bundled, and cache growth plus first-frame latency for fetched. Both numbers describe real user-facing costs, and neither is visible from a demo.
What stays constant across both: coarse commands go down, frames do not come up. Look identifiers and element levels are declarative, and no pixels cross into JavaScript in either arrangement.
6. What neither arrangement changes
Colour fidelity is untouched by delivery choices. Rendered pigment lands inside the exposure and white balance of each frame, so the same shade reads differently in daylight, indoors, and under mixed sources, and tone, undertone, and texture vary person to person. Whatever brings the package to the device, the result is a preview, not a colour measurement.
Occlusion behaves identically too. Hair, hands, and accessories cross faces constantly, and a rendered layer follows detected structure rather than object permanence. Fetching content later does not make tracking more aware of intent.
Finally, both arrangements leave you owning the same interface. Someone builds recording controls, permission flows, gallery picking, and upload whether packages come from your bundle or your channel — which is why this decision is usually settled by your release rhythm and risk tolerance rather than by anything visible in a look gallery.
FAQ
Can we mix the two arrangements?
Yes, and it is the common endpoint. Many teams bundle a core library so the camera works offline on first launch, then fetch seasonal additions through their own channel. The cost is two delivery paths to test.
Does fetching packages at runtime mean users need the network every time?
No, provided you implement caching. Resolution writes to a local cache, so ordinary launches read from disk. The first look after a fresh install is the case worth testing explicitly.
Who fixes a look that reviewed badly?
Depends entirely on the arrangement. Bundled packages require a release; fetched packages let you republish or revert from your own channel, which is why teams with monthly content cycles usually want the second path.
Do the two arrangements use different asset formats?
No. Elements and looks are the same data either way, including the relationship where looks reference elements rather than embedding them. Only the retrieval strategy differs.
What is the most telling failure we should script?
The no-connectivity cold start followed by a failed fetch. Whether your app degrades to a usable camera or shows a blank preview tells users more about your engineering standards than any effect in the catalog.
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.