Flutter rewards a particular way of thinking: widgets describe what should be on screen, and the framework works out when to rebuild them. A Face Filters SDK is half that kind of thing. The pipeline under it is not — it owns a camera session and per-frame work that must survive rebuilds — but the catalogue above it is exactly the sort of data Flutter is good at rendering.
This article is about that upper half. Meishe effects reach Flutter as Flutter (supported through the short-video solution, for cross-framework teams), so what you integrate is a hosted pipeline with a catalogue your Dart code owns. Three properties of the arrangement are assumed rather than argued here: the preview is a hosted surface rather than a widget, teardown is a route-level operation rather than a widget-level one, and nothing per-frame crosses into Dart. What remains is the part teams actually spend their time on — how a library of looks and elements is presented, updated, and kept honest inside a declarative tree.
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.
Content ships as data: individual elements and complete looks, with per-element intensity control, delivered as packages that update without a new binary. Flutter appears as Flutter (supported through the short-video solution, for cross-framework teams), alongside iOS, Android, Web, Desktop (Windows), smart hardware, and React Native.
The SDK provides no finished camera UI, so your widget tree owns permissions, controls, navigation, and upload, while the hosted pipeline owns capture, evaluation, and preview.
2. What Dart owns
Most integration pain comes from state drawn in the wrong layer, and the effects catalogue is where the line is easiest to get wrong.
| Piece of state | Lives in | Why |
|---|---|---|
| Look manifest and grouping | Flutter | Rendered from data, rebuilt on refresh |
| Selected look identifier | Flutter | A user choice reflected across the UI |
| Per-element intensity level | Flutter, sent down as commands | Authored levels are discrete, not per-frame data |
| Package availability | Flutter | Drives your own placeholder and fallback UI |
| Family labels and ordering | Flutter | Editorial, and changed between seasons |
| Preview surface handle | Below Dart | Cannot be recreated by a rebuild |
| Applied element resolution | Below Dart | Reference resolution, not user state |
| Per-frame tracking quality | Below Dart | Per-frame information with no business meaning |
The rule behind the table: anything the user chose or the catalogue editor wrote stays above Dart’s seam; anything per-frame or per-surface stays below it. Look identifiers and intensity levels cross downward as coarse commands.
3. A catalogue renders declaratively
The catalogue is the one part of an effects stack that genuinely benefits from Flutter’s model, because it is mostly a list of things that change between releases rather than between frames.
A look is a combination of elements, and it is not a flattened image — it is a structure that references them. That shape is what makes a declarative presentation work at all: your tree can render one entry per look without knowing how the look is composited, and a manifest refresh rebuilds the list without touching any individual entry’s identity.
What follows from it is worth designing for explicitly. Because one element can appear in many looks, an element change is a catalogue-wide event rather than a per-card edit, so your manifest should be a single source that the tree renders from — not a set of card-level states that each learn about changes independently.
4. Per-element controls and repaint granularity
A control surface for a look is a small tree: the look, the elements it references, and the level chosen for each. That tree is ordinary Flutter, and how finely it rebuilds is a decision you make.
The snippet below is schematic. Class names and signatures are illustrative and are not the shipped API surface.
// Illustrative: the control tree renders from the manifest and sends commands down.
class LookControls extends StatelessWidget {
final LookDescriptor look; // data, from the manifest
final EffectsController controller;
const LookControls({required this.look, required this.controller});
@override
Widget build(BuildContext context) {
return Column(
children: look.elements.map((element) {
return LevelSelector(
label: element.label,
levels: element.authoredLevels, // light / standard / strong
selected: element.currentLevel,
onChanged: (level) => controller.setElementLevel(element.id, level),
);
}).toList(),
);
}
}The granularity point is the one that bites later. Rebuilds above the preview are cheap and should happen freely — a level tap, a scroll, a manifest refresh. Rebuilds triggered by a frame are the opposite, because they couple your tree’s reconciliation to a loop you do not control. Keep the two sources of change separate and the architecture stays stable across Flutter releases.
Elements are also where the honest limit sits. The same asset at the same level reads differently across faces and lighting conditions, which is why authored levels exist as a small reviewed set rather than a continuous slider. It is a preview, not a colour measurement, and a control tree that implies otherwise sets expectations the medium will not meet.
5. Availability as ordinary state
Because packages are data rather than code, delivery is an application concern you can design rather than a constraint you inherit.
Two arrangements are common, and the split is usually dictated by release cadence. Bundled packages travel inside the application binary, which keeps first launch deterministic and offline-friendly. Fetched packages arrive through a channel you control, letting seasonal work ship on its own calendar without another review cycle.
Either way the widget tree should treat availability as state with honest branches: cached, resolving, unavailable. A look that is still fetching renders a placeholder rather than nothing, and a look whose packages failed should never leave the camera black. Treating absence as a first-class case removes a whole category of black-screen reports.
One more case belongs here, because it is where availability and navigation meet. When the screen is left, the controller releases what it was holding and the availability states your tree was rendering go with it. On return, re-read the manifest from cache rather than re-resolving every look: a warm cache restoring its previous states is what makes a resumed screen feel immediate, while re-resolving walks the user back through placeholders for content the device already has.
6. Where the seam shows
Every catalogue integration eventually reveals the same three places.
The first is a race rather than a bug. A manifest refresh can arrive while a look is applied, and a fetched package can resolve after the user has moved on. Decide what wins — usually the applied look keeps rendering and the new content appears on next selection — and encode it once instead of per screen.
The second is occlusion, which no amount of widget structure changes. Hair, hands, and accessories cross faces constantly, and the rendered layer follows detected structure rather than any notion of object permanence. What you can change is how conservative your default looks are for audiences who move.
The third is preview absence. The surface will occasionally be unavailable — during a permission prompt, a background transition, or a device-specific camera handover. Modular Flutter code handles this well because it is just another state to render; the teams that struggle are the ones who assumed the preview would always be there and wrote no branch for absence.
FAQ
Can the catalogue live in Dart while the pipeline does not?
Yes, and it should. Manifests, look identifiers, element levels, and availability are all coarse, user-facing data. Per-frame work and the preview surface stay below Dart.
Should the control tree rebuild on every frame?
No. Rebuild in response to user input and manifest changes, never in response to the render loop. Coupling the two makes your tree’s behaviour depend on frame timing you do not control.
How granular should element controls be?
Per element, with the authored levels the library shipped. A continuous slider moves variance the cataloguers already reviewed into the hands of whoever is holding the phone.
How should we model an unavailable package?
As state with three honest branches — cached, resolving, unavailable — each rendering differently. Render a placeholder rather than a blank surface.
What breaks most often in production?
Manifest refreshes landing mid-selection, and fetched packages resolving after the user navigated away. Script both early; neither appears in a happy-run demo.
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.