Most mobile retouching projects do not fail because of the face beauty SDK. They fail between selection and production: scope creeps during integration, permissions arrive late, the device matrix turns out to be three phones in a drawer, and the first version that reaches users is also the first version anyone tested under sustained load. Those are process failures, and they are largely preventable.
So this piece is not another list. It is the seven-stage checklist we hand to teams integrating Meishe Face Beauty SDK on iOS and Android, with a required deliverable and an acceptance criterion for each stage. Work through them in order; skipping stage two reliably costs more than doing it.
One framing note before starting: every stage below assumes the SDK is a processing layer rather than an application. Your team owns the camera UI, permission prompts, and export flows, and several checklist items exist precisely because that boundary needs naming early.
1. Product Positioning
Meishe Face Beauty SDK performs face reshaping, skin smoothing, and virtual makeup compositing from one detection pass per frame, rendered in real time with no preprocessing stage. Mobile targets are iOS and Android, with the same cross-platform audio/video processing engine used across the product family, support for up to 8K video editing and 16K image processing, HDR preview, and export in HLG or ST 2084. The checklist below presumes an app that already has a capture or editing surface, and it is written for teams preparing their first production release rather than evaluating prototypes.
2. The seven stages
| Stage | Must deliver | Acceptance criterion |
|---|---|---|
| 1. Scope lock | Named scenarios and success criteria | Written: which operations ship, which do not |
| 2. Module trimming | Enabled module list per build flavour | A debug build proves only intended modules load |
| 3. Permissions and privacy | Prompt copy, rationale, revocation handling | Flow works when permission is granted, denied, revoked |
| 4. Package budget | Measured footprint and download delta | Budget agreed, with headroom reserved for asset packages |
| 5. Device matrix | Named models incl. worst-supported | All scenarios run on every model in the matrix |
| 6. Staged rollout | Cohort plan with kill switch | Rollback possible without an app update |
| 7. Monitoring and attribution | Retouching events, crash grouping, version tags | Every report names SDK version and module set |
Ordering matters more than completeness. Stage 4 and stage 5 look interchangeable and are not: you cannot reason about footprint before knowing which devices constrain you, and you cannot choose devices meaningfully before knowing what you are shipping.
3. Stages one and two: scope, then modules
Scope lock starts by naming the scenarios. Live output, short-form capture, virtual try-on, and professional recording each demand different thresholds, and trying to satisfy all four in v1 guarantees satisfying none. Write down which operations ship and — more usefully — which do not. If makeup compositing is not in v1, say so explicitly rather than leaving it implied.
Module trimming follows directly. Because beauty, AR, and AI capability loads on demand, the right question is which modules your first experience actually touches. Verify with instrumentation rather than assumption: a debug build that logs module loads usually reveals one surprised dependency. Everything ships from one engine, so nothing here changes what the engine can do — only what you pay for before users ask for it.
4. Stage three: permissions and privacy
Camera permission is three states, not one: granted, denied, and revoked mid-session. Build copy and UI for all three before integrating, because retrofitting a rationale screen after review feedback costs a sprint.
Privacy posture deserves equal attention. If your deployment requires processing to stay on-device, confirm that constraint now rather than discovering it during review — it affects which modules you enable and where export goes, and those choices are far cheaper to make at stage three than at stage six.
5. Stages four and five: footprint, then devices
Package budget has two parts: what the core costs, and what arrives later as data. The resident core is around 3 MB, which keeps download and startup cost predictable, and asset packages download separately so content can grow without touching your binary. Reserve headroom explicitly — a content team that ships monthly sets will consume it steadily.
Device matrix should be declared by model identifier, led by your worst-supported device, followed by one mid-range handset and one flagship. Then tie configuration to it: detection cadence is the lever that varies by tier, since it changes per-frame cost without changing anything a user can see. Lower-cadence tiers on weak hardware, higher on flagships.
The snippet below is schematic. Field names, helpers, and thresholds are illustrative and do not represent the shipped API surface.
// Illustrative: a stage gate that must pass before a cohort can advance.
export interface StageGate {
stage: number;
deliverable: string;
passed: boolean;
evidenceUri: string; // recording, screenshot set, or log bundle
}
export function blockRelease(gates: StageGate[]): StageGate[] {
const blocking = gates.filter((g) => !g.passed);
if (blocking.length) {
console.warn("release blocked:", blocking.map((g) => `stage ${g.stage} ${g.deliverable}`));
}
return blocking;
}
export const mobileGates: StageGate[] = [
{ stage: 1, deliverable: "signed-off scenario list", passed: false, evidenceUri: "docs://scope-v1" },
{ stage: 2, deliverable: "module load trace, debug build", passed: false, evidenceUri: "logs://modules-v1" },
{ stage: 3, deliverable: "permission state matrix covered", passed: false, evidenceUri: "qa://permissions-v1" },
{ stage: 4, deliverable: "footprint measured against budget", passed: false, evidenceUri: "builds://size-v1" },
{ stage: 5, deliverable: "matrix run on worst-supported device", passed: false, evidenceUri: "fixtures://matrix-v1" },
{ stage: 6, deliverable: "cohort plan with kill switch", passed: false, evidenceUri: "ops://rollout-v1" },
{ stage: 7, deliverable: "crash grouping and version tagging", passed: false, evidenceUri: "ops://monitoring-v1" },
];6. Stages six and seven: rollout, then attribution
Staged rollout needs two things most teams skip. First, a kill switch that does not require an app update — because the failure you need to stop quickly will arrive after your submission window closes. Second, configuration carried as data rather than code, so retuning thresholds or retiring a look is possible without shipping a binary.
Attribution is what makes post-launch support possible. Tag every retouching-related report with SDK version and enabled module set, and group them accordingly. Without those two tags you cannot tell whether a defect cluster arrived with your release or with a content update, and you will spend the incident arguing instead of fixing.
The part this checklist cannot deliver
Say this plainly before you plan around it: following these stages does not eliminate the physics. Detection still trades in two directions — too strict and the effect drops on a partially turned or poorly lit face, too loose and it attaches to a poster behind the subject — and landmark motion still produces flicker most visibly at the conservative intensities users prefer. No amount of process removes those; what the process buys you is finding them at stage five rather than at stage seven.
One practical resource worth knowing before stage two: Meishe supplies Integration Skills for AI coding assistants including Codex, Qoder, Claude Code and Cursor, covering recurring wiring work such as permission flows, session lifecycle scaffolding, and module load tracing.
FAQ
Why insist on doing package budget before the device matrix?
Because which devices constrain you depends on what you ship. Once modules are trimmed and asset download is separated from the binary, the matrix becomes a meaningful test rather than a guess.
Do we need all three operations in the first release?
Usually not. Ship reshaping and smoothing first and validate them on real devices; makeup composites as an independent layer, so adding it later does not force a rebuild of either.
How do we pick which device is “worst-supported”?
Use your own analytics: the oldest model still materially represented in active sessions. A brand-new flagship tells you nothing about your median user.
Can retouching parameters be changed after release without an app update?
Yes, where they are carried as data rather than code — including asset packages. This is why stage six asks for configuration to be data-driven.
What should every crash report carry?
Two tags at minimum: SDK version and enabled module set. Without them you cannot separate a regression in your integration from a change in content or configuration.
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.