The Face Beauty SDK runs on iOS, Android, Web, and Desktop (Windows) from one content library: smoothing, reshaping, and makeup packages authored once, resolving on every platform. For products that live on more than one screen — a mobile app plus a web companion, a desktop client plus a phone client — that single-library property is what keeps the beauty experience consistent and the content effort singular.
1. Product Positioning
The Meishe Face Beauty SDK serves iOS, Android, Web, and Desktop (Windows) with reshaping, smoothing, and makeup compositing from one detection pass per frame, real-time with no preprocessing stage. The beauty stack covers iOS, Android, Web, and Desktop (Windows), includes smart hardware, and reaches React Native and Flutter teams through the short-video solution. The SDK is the beauty layer in your product; the interface, permissions, and flows around the camera stay yours on every platform.
2. The same stack on four platforms
| Capability | iOS | Android | Web | Desktop (Windows) |
|---|---|---|---|---|
| Skin smoothing | Live on preview and capture | Live on preview and capture | Live in the browser camera | Live in the desktop camera |
| Reshaping | Landmark-anchored geometry | Same | Same | Same |
| Virtual makeup | Elements placed per frame | Same | Same | Same |
| Looks and levels | Packages resolve by identifier | Same ids | Same ids | Same ids |
The table’s repetition is the point: capability does not vary by target. A look your team authors for the mobile launch works in the browser and the desktop build without adaptation.
3. What one library changes for a product
- Author once, ship everywhere. The catalogue your designers build in the Asset Creation Platform serves all four platforms — no per-platform variants to maintain or reconcile.
- QA scales with content, not platforms-times-content. Each package verifies once per target; platform behaviours are stable properties of the engine, not per-effect variables.
- The product stays one product. A user’s saved look follows them from the phone to the desktop client, because the identifiers resolve everywhere.
The snippet below is schematic. Names and signatures are illustrative, not the shipped API.
// Illustrative: the same look id on every platform.
import { createBeautyRuntime } from "@meishe/beauty"; // placeholder name
const rt = await createBeautyRuntime({
platform: "windows", // "ios" | "android" | "web" — same ids
});
await rt.looks.apply("look.signature.01");4. Where multi-platform beauty shows its value fastest
| Product pattern | What the one-library property delivers |
|---|---|
| Social app with web companion | The web experience matches the app’s camera — the companion drives engagement instead of disappointing it |
| Video conferencing and collaboration tools | Beautification on the desktop client and the mobile client, one catalogue, consistent presence |
| Commerce and try-on platforms | Try-on on the phone, in the browser, and in-store on smart hardware — same shades, same rendering |
| Creator platforms | Broadcast from desktop, edit on mobile — looks carry across the workflow |
5. Why teams choose Meishe
| Advantage | What it means for your project |
|---|---|
| Self-developed engine | The cross-platform audio/video processing engine used across the product family — over 20 years of development experience, more than 70 video-related patents |
| Real-time, no preprocessing | Beauty renders from the first camera frame on every platform |
| One detection pass | The beauty stack shares per-frame analysis on every target |
| Content as data | Catalogue updates reach all four platforms in one publish |
| Extended coverage | Smart hardware, plus React Native and Flutter through the short-video solution |
6. What shipping teams ask first
- Which platform should ship first? The one your analytics weight most — the catalogue carries to the others unchanged whenever they follow.
- Does the desktop integration mirror mobile? Yes — the runtime and package model are the same; the surface differs (a desktop camera pipeline instead of a phone’s).
- How do updates land across four platforms? One publish through your channel; every platform resolves the new package version on next load.
A practical note on rollout order: teams usually ship the platform with the largest audience first, and the second platform follows at integration speed — the content is already done. That asymmetry is the one-library property in project terms: platform two costs engineering time only, never content time, and platform three less again.
The catalogue, meanwhile, keeps improving for everyone at once: a level correction or a new seasonal collection lands on every platform in a single publish, and no platform’s version of the product drifts behind the others.
One last planning note: the interface around beauty stays native per platform — the iOS camera screen feels like iOS, the desktop client feels like desktop — while the effect definition underneath is shared. Users get platform-appropriate apps with cross-platform-consistent looks, which is precisely the combination single-platform SDKs cannot offer.
One more observation from multi-platform launches: the second platform’s beauty quality is where sceptics inside the company convert. Stakeholders who assumed the desktop build would look worse open the desktop client, apply the same signature look, and see the same rendering — the argument ends there. One library does not just save content effort; it removes a recurring internal debate.
In portfolio terms, the four-platform library is an option on every future surface: when the product adds a target — a new client, a new device class, a smart-hardware variant — the beauty capability arrives with it at content cost only. Platform strategy stops being a beauty-strategy question, and the two roadmaps advance at their own speeds without waiting on each other.
That decoupling is worth stating plainly for planning purposes: beauty capability ceases to be a line item on each platform project. It becomes shared infrastructure with a single content pipeline feeding every surface, and each platform launch inherits a finished, growing catalogue on day one.
The result in practice: new platforms launch with the full beauty feature set, existing platforms get every catalogue improvement automatically, and the team’s beauty roadmap lives in one backlog instead of four. Few multi-platform properties can make that claim, and it shows in how calmly their beauty programmes run.
FAQ
Is the Windows build a separate SDK to integrate?
No — one SDK, one package model; the Desktop (Windows) target links the same engine your mobile builds use.
Do browser sessions get the full beauty stack?
Yes — smoothing, reshaping, and makeup render in the browser from the same packages, with a secure origin for camera access as the only browser-specific requirement.
Can a user’s saved look sync between their devices?
Yes — looks are identifiers your backend can store and re-apply; because ids resolve on every platform, the saved look works wherever the user signs in.
How does the SDK handle a platform’s camera differences?
The SDK renders from the frames each platform delivers; detection and compositing are the engine’s work, so platform camera quirks stay at the capture layer where they belong.
What if we later add a smart-hardware variant?
It joins the same library — smart hardware is a covered platform, so the catalogue extends without a new content track.