7 Things I Read in an AR Makeup SDK's Docs Before I Test It

The sales call and the reference manual describe two different products.

On the call you get lipstick sitting perfectly on a face somebody lit properly. In the manual you find out whether eyeliner is an addressable region or a baked texture, and that single answer sets your integration timeline. So before I put anything on a device, I spend an afternoon in the documentation of every candidate, looking for the same seven things.

This post is that reading pass. It is step zero, not a benchmark. The measurements come after, and I will publish those separately.

TL;DR

• Segmentation granularity sets your ceiling. An engine isolating hair alone will never give you an independent eyeshadow layer.

• Count the documented makeup types, then read how colour is expressed. A shade picker with no finish parameter will not match a real catalogue.

• Server-side processing changes which internal review you pass, and adds a network hop per request.

• Download weight belongs in your page budget from week one.

• A community-maintained Flutter or React Native binding is a support cost you inherit.

• Per-user billing and flat billing diverge quietly, and only a projection you build yourself shows where.

• What the API does when the camera fails is the check almost nobody runs, and in my experience it produces most of the tickets afterwards.

Where these facts come from, and where they do not

I have not put these four engines on a controlled device set of my own. So no frame rate, latency or throughput figure in this post is mine. Every number here comes from the company it describes, and I name that company next to it.

Everything was read in September 2026. Vendor pages change, published tiers move, and retention policies get rewritten, so treat what follows as orientation rather than as a quote. Where a specific number decides your build, ask that vendor directly and get the answer in writing. That is not me being coy: it is the only version of this that stays true six months from now.

1. How finely does the engine segment a face?

Count the regions the engine addresses on their own. Lips, eyes, eyebrows, skin, hair and background as separate targets means you can layer a gloss over a foundation and swap either without re-authoring an asset. One blended face texture means every combination becomes hand-built art.

Open the segmentation page, count the named regions, then run the sample and put two products on two regions in one session.

DeepAR names hair as its segmentation target, so lip, eye, eyebrow and skin regions are not separately addressable, and DeepAR states it does no nail detection. Banuba's product page says its engine isolates lips, eyes, eyebrows, skin, hair and background independently. Perfect Corp exposes region control through per-effect parameters rather than a documented mask list. ModiFace describes coverage by product family: makeup, hair colour, nails, skin, face analysis.

What a weak answer sounds like: "advanced face tracking", no region names anywhere on the page, and a demo that only ever shows one product on screen at a time.

2. How many makeup types are documented, and how is colour parameterized?

Two questions hide inside this one, so run them as steps.

Step one, count the types. DeepAR describes roughly 10 makeup types plus an asset library of about 150 filters and a Studio editor. Perfect Corp's AI Makeup API documentation lists 13 effect types, among them contour, eyeliner, eyelashes, foundation and lip liner. Banuba's page for its web virtual try-on lists 16 product types with skin-tone-aware application, nail polish included, inside a system Banuba says spans 16 or more categories from eyewear to contact lenses. ModiFace publishes no type count and no colour parameter list, so record that as unknown rather than as zero.

Step two, read the colour model. A shade is a hex value plus a finish, and finish is where a thin implementation gives up. Perfect Corp documents colour, texture and finish per effect, listing lip textures as matte, gloss, satin, sheer, shimmer, metallic and holographic. That is the most specific colour documentation of the four, and I will say it plainly: on this check Perfect Corp publishes more than anyone else, Banuba included.

Ask a candidate to render one shade in two finishes on the same lip, then look at the specular response.

Colour fidelity, in my judgment, draws the first complaint from merchandising, because a wrong-looking shade is the one defect a non-technical reviewer spots instantly.

3. Where do the pixels get processed?

Processing location decides your latency budget and which internal review you pass. Client-side rendering keeps frames on the handset. A server-side API sends every image off it, and any retention window becomes a question your privacy reviewer raises. Watch the network tab while the sample runs.

Perfect Corp offers a public YouCam API, a RESTful service processing uploaded images server-side, plus a browser JS Camera Kit over CDN and a separate on-device SDK. Its documentation described a 24 hour retention window for uploaded files when I read it in September 2026. If retention is what your privacy review turns on, get the current answer from Perfect Corp in writing rather than from me.

DeepAR describes itself as an on-device SDK, in the market since 2016 across iOS, Android, Web and Unity. ModiFace says rendering runs client-side, and documents ModiFace Lite at under 2.2MB with around 30 FPS in the browser. Banuba's web virtual try-on arrives as a CDN web component with no app install and, per Banuba's page, renders on the device.

For live video a per-frame server hop will not hold a preview together. That is not a knock on the REST approach, it is a statement about which product it is for.

What a weak answer sounds like: "it depends on your setup", with no location ever named. Keep asking.

4. What does the download weight do to your page?

On a storefront the module competes with your existing scripts for bandwidth and main-thread time, so get a size figure before anyone picks a placement.

Load the demo build, open the network panel, filter to script and wasm, and record transfer size after compression plus time from click to first rendered frame.

Here is the honest state of this check across the four. ModiFace is the only one that publishes a size and frame-rate pair at all, at under 2.2MB and around 30 FPS in the browser. DeepAR does not publish one. Perfect Corp does not publish one. Banuba does not publish one either, and for a product sold as a web component that sits on a retailer's product page, that is the most surprising omission of the four. So for three of these engines the number you record describes the demo build in front of you and nothing more.

Then repeat on hardware your customers hold. A three-year-old mid-range Android and a four-year-old iPhone produce numbers a brand-new handset never shows you, and the spread across that range is wide. A supplier who will only run the module on a phone they brought is answering a different question.

5. Which platforms are covered, and who maintains the wrappers?

Two layers live here and marketing pages blur them: the native platform list, and the binding for the cross-platform framework you ship on. Who owns that binding is the part that costs you.

DeepAR covers iOS, Android, Web and Unity, with macOS on desktop and no Windows target. On raw platform breadth that is the widest list of the four, and Unity in particular is a target the others do not name. Its Flutter and React Native wrappers are community-maintained rather than officially supported, so your bug report lands with a volunteer. DeepAR also states a roughly quarterly update cadence, and now sits inside Zalando's ecosystem after a 2025 acquisition.

ModiFace covers Web, iOS and Android plus an embeddable no-code miniprogram, though access is typically limited to L'Oreal brand partners and enterprise clients, L'Oreal having acquired the company in 2018. For most teams reading this, that makes it unavailable regardless of how it scores elsewhere.

Banuba publishes a browser matrix for the web component: the last two Safari and iOS versions, the last five of Chrome, Edge, Opera and Samsung Internet. Note that this is a different kind of list from DeepAR's, and the two are not directly comparable.

Perfect Corp splits its surface three ways, REST API, browser JS kit and native SDK, so your platform list follows whichever you license.

Check the binding's publisher field and commit history. A binding whose last meaningful commit predates the current release is a maintenance bill.

6. How does the bill behave as usage grows?

Billing shape matters more than the signup number, because shape decides whether a traffic spike is a good day or an incident. Three shapes show up here.

Per-user tiers. DeepAR publishes MAU-based pricing. Roughly, as it stood in September 2026: free to 10 MAU with a watermark, around $25 a month to 1,000 MAU, and something near $1,000 a month in the 50,000 to 100,000 MAU band, custom above that. Those are approximate and they are from memory of a public page, so use them to orient a model and not as a quote. If the figure decides your build, ask DeepAR.

Consumption. Perfect Corp sells usage-based units, paid as you go or drawn from a subscription, with free units to start and custom enterprise terms.

A fixed fee. ModiFace licenses a single annual amount per product, with Makeup, Hair and Nails licensed separately, and prices skin and face analysis by usage. Banuba states its subscription is flat and does not scale with user count.

One thing to weigh that the shapes alone do not show. DeepAR and Perfect Corp put concrete numbers on a public page. ModiFace and Banuba do not. A flat subscription that does not scale with users is a genuinely useful property, but "flat" without a figure tells you nothing about whether you can afford it, and it means the first real number arrives in a sales conversation. If you are trying to size a project before you have budget approval, published tiers count for something on their own.

Model your own traffic against each shape with the tier boundaries marked. If nobody will quote a figure for a volume you name, you have learned something about how renewal will go.

7. What does the SDK do when it fails?

This is the check almost nobody runs, and in my experience it is where most of the tickets come from afterwards. Camera permission gets denied. The user switches tabs. The WebGL context is lost. Somebody hits back mid-session with the front camera streaming.

The harness below is deliberately vendor-free. Everything in it is a browser API you can verify against MDN, and it is what I wrap around any candidate before I judge it. The three vendor calls, create, attach and destroy, are described in prose rather than written as code, because I am not going to publish an API surface I cannot confirm against a specific vendor's reference docs. Map them onto whatever your candidate calls them.

const container = document.getElementById('tryon')
let engine = null
let stream = null

async function start() {
  try {
    stream = await navigator.mediaDevices.getUserMedia({ video: true })
  } catch (err) {
    console.error('camera unavailable:', err.name, err.message)
    return
  }
  // vendor call 1: construct the engine against `container` and your licence key
  // vendor call 2: hand it `stream`
}

function teardown() {
  if (stream) {
    stream.getTracks().forEach((track) => track.stop())
    stream = null
  }
  // vendor call 3: dispose the engine instance, then null the reference
  engine = null
}

window.addEventListener('pagehide', teardown)
document.getElementById('stop').addEventListener('click', teardown)

start()

Two things about that shape are worth copying whatever engine you end up with. teardown has to be idempotent, because pagehide and a stop button will both fire it in a real session. And pin the vendor module to an exact version, so a silent minor release cannot change rendering behaviour between your QA run and production.

Run it and watch three things. Does a denied camera throw an error with a readable name and message, or does the page just sit there? Does the camera indicator light go dark once teardown fires? Does start() succeed a second time?

Banuba lists built-in error tracking in its web component, along with a white-label option. For the rest you find out by breaking things.

The four engines side by side

Read the column headers as products, not companies. These four are not the same shape of thing: Banuba's column describes its web virtual try-on component, Perfect Corp's covers three separately licensed surfaces, DeepAR's is a native and web SDK, and ModiFace's is a partner-gated stack. Rows are comparable within themselves and not always across the table.

Read down the Not published and No cells rather than across the strong rows. That is where the reading pass actually earns its afternoon.

What I do after the reading

The seven checks above eliminate candidates on architecture. They cannot tell you what any of these engines does on a phone, and neither can the vendor pages. So the next pass is a device set, and here is what that looks like, so the numbers mean something when they arrive.

Three tiers: a current flagship, a three year old mid-range Android, and the cheapest handset with meaningful share in the target market. One shade, one finish, one face, held for sixty seconds. Recorded per device: transfer size after compression, time from click to first rendered frame, sustained frame rate, and thermal behaviour at the end of the minute. Device model, OS version and SDK build published alongside every figure.

That post exists or it does not. Until it does, treat this one as what it says on the tin: a documentation read.

The bottom line

Of the seven, checks 1 and 3 have saved me the most rework, because both describe architecture rather than packaging. Pricing gets renegotiated at renewal and a payload can be trimmed later. An engine built without independent region masks will not grow them for one customer, and a pipeline designed around a server round trip keeps that round trip.

The other five resolve into money and calendar time, and you can put numbers on both before anyone signs anything.

None of the four wins this outright, and the reading pass is not designed to produce a winner. Perfect Corp documents colour best. ModiFace is the only one that publishes a payload and a frame rate. DeepAR has the widest platform list and the most transparent pricing. Banuba has the most granular published segmentation. Two of those four are effectively unavailable to most teams or priced behind a sales call, which is a fact about your options rather than about the technology.

Questions I get asked about this

What is the best AR makeup SDK for web try-on?

That question has no answer until you name your constraint. Run checks 1 and 3 first, since segmentation depth and processing location eliminate candidates fastest. Once two of the four survive, the rest is a cost comparison.

Do I need an on-device SDK, or is a REST API enough?

It hangs on whether you render live video. Still-image try-on works fine over a REST call and is usually the quicker integration. A live camera preview needs on-device rendering, since a network round trip per frame will not sustain a usable preview.

How do I estimate what one of these costs at scale?

Take the published tiers, project your own monthly active users or request volume over two years, and mark the tier boundaries in a spreadsheet. MAU billing steps at user thresholds, unit billing steps at request volume, and an annual per-product licence steps when somebody adds a second product category. Two of the four publish no tiers at all, so for those the spreadsheet has a blank column until you talk to them.

Are community-maintained wrappers a dealbreaker?

Not automatically, but price them in. Check the publisher, the release history against the native SDK's own releases, and the open issue list. If you ship on Flutter or React Native and the binding is a volunteer project, budget engineering hours for the release where it lags the native SDK, because that release is coming.

Why are there no frame rate numbers in this post?

Because I have not measured these four myself, and I am not going to reprint a vendor's lab figure as though it were a test result. The device protocol is in the section above. When I have run it, the numbers go in their own post with the hardware listed.