Comparisons of mobile Face Filters SDK options are easy to write and hard to act on, because most of what decides the outcome is not in the comparison. Two teams pick the same engine and get very different results; the difference is almost always the sequence of decisions between evaluation and production.
This article gives you that sequence as seven stages, each with what must exist before the next begins and what “done” means. It is written for mobile teams specifically, where permissions, package size, and device diversity impose constraints no other target shares.
Meishe specifics appear where they constrain a stage; everything else applies whatever you are shipping.
1. Product Positioning
Meishe Face Filters SDK is the filter and effects layer of the Face AR SDK family, evaluating real-time effects without pre-processing on the cross-platform audio/video processing engine used across the product family. One stack serves capture, timeline editing, and live streaming on iOS and Android, and on cross-platform targets including React Native and Flutter (supported through the short-video solution, for cross-framework teams).
Content ships as data: individual elements and complete looks, with per-element intensity control, delivered as packages rather than compiled behaviour.
No camera UI ships with it. Stages three and seven exist largely because of that.
2. Seven stages at a glance
| Stage | Must be delivered | Acceptance test |
|---|---|---|
| 1. Scope lock | One scenario, one surface, one seed look corpus | Written scope nobody argues about |
| 2. Module trim | Only the modules that scenario needs | Module list reviewed and justified |
| 3. Permissions and privacy | Prompts, fallbacks, disclosure copy | Denial path usable end to end |
| 4. Package budget | Engine base plus the share your look packages take | Size tracked per release |
| 5. Device matrix | Three tiers plus your median device, full corpus | Every look runs on the floor device |
| 6. Staged release | Gates, monitoring, rollback trigger | One deliberate rollback rehearsed |
| 7. Upgrade ownership | Named owner for engine updates, separate content cadence | A dated cadence exists |
Read it as gates rather than phases: each row is complete before the next is funded. Teams that skip rows usually skip row two, then wonder why launch numbers look unremarkable.
One thread runs through all seven and is specific to a content-shaped library: the corpus is a deliverable in every stage, not just in the last one. Stage one decides which ten looks you begin with, stage four budgets the packages they require, stage five proves every one of them runs on the floor device, stage six rehearses reverting one, and stage seven separates their publishing cadence from your release train. Teams that treat the corpus as something to figure out after integration usually meet it again during a seasonal drop, at worse cost.
The snippet below is schematic. Names and signatures are illustrative and are not the shipped API surface.
// Illustrative stage-two gate: load only what the scenario needs.
import { createEffectEngine } from "@meishe/effects-core"; // placeholder name
const engine = await createEffectEngine({
modules: ["filters.core"], // nothing here loads "just in case"
// Optional capability arrives later, through one explicit call:
// await engine.modules.load("segmentation.portrait");
});
// Stage four companion: the base is small; the library is content.
export const budget = {
base: "engine module set only",
assets: "delivered as packages, not compiled in",
growth: "tracked per release, ceiling agreed before launch",
};3. Stage three: permissions and privacy this time
Mobile camera work now carries obligations that predate your feature and outlive it.
Write the disclosure copy before building the prompt. Users are asked for camera access with increasing scepticism, and the explanation — what is captured, what leaves the device, what is stored — belongs inside your product rather than in a policy nobody opens.
Build the denial path as deliberately as the happy path. Permission can be refused, granted once, or withdrawn later from system settings, and each state needs its own UI. Then confirm what your deployment actually requires: keeping all processing on-device where regulation demands it is supported, and no user authorisation step is required by the SDK itself.
Because no finished camera UI is shipped, every screen in this stage is yours to build — which is the reason this row has more work in it than teams expect.
4. Stage four: package budget, agreed before launch
Two numbers matter, and they behave differently.
The engine base is what loads at startup. The SDK core is around 3 MB, and everything else — additional AR, beauty, or AI capability — loads on demand through an explicit call. That keeps the initial footprint predictable and makes later additions a decision rather than a side effect.
The library is content, not code, so its growth is governed by what you publish rather than by what you compile. That is a relief and a trap: nothing stops a corpus from growing indefinitely except a ceiling you agreed in advance. Decide what share of your total size budget look packages are allowed to take, separate that number from the engine base in your dashboard, and track it per release — remembering that fetched packages consume cache rather than install size, so both figures belong there.
What keeps that number healthy is structure: because a look references elements rather than containing them, twenty looks sharing ten elements cost far less than twenty independently authored ones. Auditing that sharing ratio belongs in this stage, and it is the cheapest size reduction available.
5. Stage five: a matrix with a floor
Pick four device slots and refuse to add more mid-project: current flagship for the ceiling, your median analytics device for reality, your oldest supported model for the floor, and whatever your developers use daily as a reference.
The floor slot is where this stage earns its cost. Run your whole look corpus on it — not a subset chosen for politeness — because the outcome you are looking for is whether it degrades gracefully. Everything eventually meets a device it cannot fully serve; the acceptable answer is controlled degradation, not failure.
Two limits belong in this stage’s notes rather than in a bug backlog. Compression sets a ceiling that many lower-tier devices reach quickly, and fine detail degrades first around the eyes and along the lip line. Occlusion behaves the same everywhere: hair, hands, and accessories cross faces, and the rendered layer follows detected structure rather than object permanence. Both are properties of mobile capture, not defects introduced by any particular device.
6. Stages six and seven: release, monitoring, ownership
Stage six is the one most teams improvise. Define the gates before the first rollout: which cohort, which metrics, which signal triggers rollback, and who decides.
Instrument what actually fails in the field rather than what is easiest to collect: permission state transitions, look application failures, asset resolution failures, background-resume recovers, and library size at startup. A dashboard that shows none of those will not tell you why retention dipped after release.
One decision belongs in this stage rather than in an incident: what a floor-device failure entitles you to do. Degrade the stack, suppress animated elements, or fall back to a plain camera — choose now, because deciding under pressure tends to produce the rollback nobody tested.
Then rehearse rollback once, deliberately. With content delivered as packages, reverting a look is an operation on artefacts; discovering that during an incident is not when you want to learn it.
Stage seven is ownership. Engine-level updates require an engineering decision with a named owner and a dated cadence, while content changes move on their own schedule through your channel. Confusing those two cadences is how a content fix becomes a release argument.
FAQ
Do we have to load every module at startup?
No, and doing so makes every later number worse. Load the set your scenario needs and request optional capability through an explicit call when a feature actually requires it.
Is it acceptable to bundle some packages and fetch others?
Yes, and it is common. Bundle a core set so the camera works on first launch offline, then fetch seasonal additions. The cost is two delivery paths to test, which stages five and six should cover explicitly.
What should we tell users about captured frames?
Whatever your deployment truly does. If processing stays on-device for regulatory reasons, that model is supported; if frames leave, say so in language someone other than a lawyer wrote.
How many devices is enough for the matrix?
Four slots, chosen deliberately. Additional devices rarely change a decision, and an ever-growing matrix mostly delays one.
Who should own engine upgrades after launch?
A named engineer with a dated cadence, distinct from whoever owns content publishing. Those two calendars should never be conflated.
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.