Duix Mobile: an on-device AI avatar SDK for Android and iOS

What Duix Mobile solves, and who it is aimed at

Rendering a talking avatar on a phone is normally a cloud problem. You send audio upstream, a server drives a face model, and video comes back. That round trip costs latency and it means the user's voice leaves the device. Duix Mobile takes the opposite position: the README describes an SDK for creating real-time interactive AI avatars "directly on mobile devices or embedded screens", designed for on-device deployment with "no dependency on cloud servers". The stated targets are Android, iOS, tablets, automotive, VR, IoT and large-screen interaction.

The intended builder is an application developer who already has a conversational stack. The README is explicit that you bring your own or third-party LLM, ASR and TTS services and integrate them through the SDK. Duix Mobile is the face and the synchronisation layer, not the brain. Named scenarios are intelligent customer service, virtual doctors, virtual lawyers, virtual companions and virtual tutors. The privacy angle is the strongest argument here: for finance, government and legal deployments, the README claims core functions run locally with low network dependence, which is a different proposition from a cloud avatar API. If your product can tolerate a server round trip and you do not want to own a native build, this SDK is more machinery than you need.

How the SDK is put together

The repository is organised as two parallel platform trees plus shared assets. At the top level you find duix-android/, duix-ios/, res/, LICENSE, PRIVACYSTATEMENT.md and the two README files. There is no shared build system at the root and no single entry point: the Android work lives under duix-android/dh_aigc_android/ and the iOS work under duix-ios/GJLocalDigitalDemo/, and the README points developers at a separate README inside each of those directories.

The primary language is C++, which tells you where the avatar rendering and audio pipeline sit: in a native core that both platform wrappers call into. The platform directories are the integration surface, and the native layer is what you do not rewrite. Audio flows in from your TTS component, the SDK drives the avatar's mouth and expression, and streaming audio support means synthesis and playback overlap rather than waiting for a complete file. The README states that streaming audio with barge-in arrived in the July 17, 2025 release, and that voice start and end callbacks are documented. Barge-in is the part that matters in conversation: the user can interrupt the avatar mid-sentence instead of waiting for it to finish.

The latency claim in the README is "under 120ms", with the note that it was tested on a Snapdragon 8 Gen 2 SoC. Treat that as a ceiling measured on one high-end chip, not a floor you can expect on a mid-range phone. The repository does not publish a latency table across devices, so the number is useful mainly as evidence that the pipeline is designed for interactive timing rather than batch playback.

Getting the Android and iOS demos and a first avatar

There is no published package on a registry. The README routes you to the platform README files, so the first step is to go to the repository and read the one for your target. The README gives the Android SDK path as duix-android/dh_aigc_android/README.md and the iOS SDK path as duix-ios/GJLocalDigitalDemo/README.md.

The README for that directory is the source of truth for build requirements, and it is where you should check the toolchain expectations before opening the project. Next, fetch an avatar model. The README lists four public avatars (Leo, Oliver, Sofia and Lily) as zip downloads attached to the v2.0.1 release, for example:

https://github.com/duixcom/Duix.mobile/releases/download/v2.0.1/Leo.zip

That URL is the download link the README gives for the Leo avatar. Expect a model directory rather than a single file: the avatar assets are what the native layer loads at runtime. After that, open the Android project in your IDE, point the demo at the extracted avatar directory, and supply your own ASR, LLM and TTS implementations through the interfaces the platform README describes. The iOS path is the same shape with a different starting point, under duix-ios/GJLocalDigitalDemo/.

One caveat worth stating plainly: neither the root README nor the platform documentation here lists the required Android API level, minimum iOS version, or the size of the avatar archives. Those are the first things to confirm in the platform READMEs, because avatar assets are usually the largest single item in an app that ships one.

The custom avatar path runs through email, not a pipeline

The four public avatars are enough to evaluate the SDK, but almost nobody ships a product with a stock face. The README's answer to custom avatars is a support address: "For custom avatars, please contact us via the email address above", which is [email protected]. The FAQ adds one useful detail, that a 15-second to 2-minute video is usually sufficient for customisation.

That is a vendor-mediated process, not a self-service tool. There is no documented script in this repository for turning a video into an avatar, and no description of the training or fitting step. For an engineering team, this is the biggest unknown in the whole project: you can evaluate rendering, latency and integration on your own, but you cannot evaluate custom avatar quality without going through Duix. If your roadmap assumes you will produce dozens of avatars internally, budget for a conversation with the vendor before you commit, and ask what the turnaround and the per-avatar cost look like. The README is silent on both.

Limitations, and where the documentation stops

The licence is the first thing to resolve. The repository carries a LICENSE file and a PRIVACYSTATEMENT.md, but the licence is recorded as NOASSERTION, meaning GitHub could not map it to a recognised SPDX identifier. For a commercial mobile app, that is not a detail you can skip: a non-standard licence may carry field-of-use restrictions, attribution requirements, or limits on redistribution of the avatar assets. Read the file itself rather than assuming it behaves like MIT or Apache-2.0.

Second, the performance claim is narrow. Under 120ms on a Snapdragon 8 Gen 2 is a statement about one flagship SoC. The README makes no claim about mid-range Android hardware, older iPhones, or the automotive and IoT targets it lists as supported platforms. If your product ships on cheap tablets, measure before you promise anything.

Third, the repository is a distribution point, not a development log. It contains platform directories, resources and documentation; the README does not describe a contribution process, an issue triage policy, or a release cadence beyond the three versions listed. The last push was on 2026-08-05, and the most recent release is v2.0.1 from 2025-10-13. If you need to patch the native layer yourself, you are depending on a codebase whose internal structure is documented only through the platform READMEs.

Finally, this is the wrong tool if you want a managed service. The README explicitly contrasts Duix Mobile with the cloud offering at duix.com, and if your product runs in a browser or on a desktop, the mobile SDK is not the right layer.

How it differs from cloud avatar APIs and from Duix.Avatar

The obvious alternative is a cloud avatar API, and the difference is architectural rather than cosmetic. A cloud service owns the model, the GPU and the scaling, and you send audio over the network for every turn. Duix Mobile inverts that: the model runs on the device, core functions work locally, and the network dependency drops to whatever your LLM and ASR need. The trade is that you own the integration, the app size and the device compatibility matrix. Cloud wins when you need to support many platforms from one codebase; on-device wins when latency, privacy or offline operation are the constraint.

Within the same vendor there is a second comparison worth making. Duix.Avatar is described in the README as "the true open-source AI avatar video production" project, and Duix-Reface as a real-time face-swap engine. Those are different products with different outputs: Duix.Avatar is about producing avatar video, while Duix Mobile is about driving an interactive avatar in a live conversation on a phone. If your requirement is generating clips, the mobile SDK is the wrong branch of the family tree. If your requirement is a face that answers a user in under a second on a handset, the video-production project does not address it.

Maintenance, licence and upgrade cost

Three releases are listed: v1.0.0 on 2025-04-24, v2.0.0 on 2025-07-21 and v2.0.1 on 2025-10-13. The last push to the repository was on 2026-08-05, roughly ten months after the most recent release. That pattern suggests the repository is maintained, but the release line is not moving quickly, so plan for the SDK version you pin to be the version you live with for a while.

Upgrade cost is dominated by the native core. Because the platform directories are wrappers around a C++ layer, a major version bump can change the interfaces your ASR, LLM and TTS adapters implement. The README notes that streaming audio and barge-in arrived in a July 2025 release, which is exactly the kind of feature that lands with API changes. Pin a version, keep your adapter code behind a thin interface of your own, and read the platform READMEs before moving between major versions.

On licensing, the practical step is to read LICENSE and PRIVACYSTATEMENT.md in the repository and have someone qualified assess them against your distribution model. The privacy statement matters as much as the licence here: an on-device SDK that processes voice and video locally still needs a story for what your app stores and transmits, and the repository provides the statement but this article cannot interpret it for you. Nothing here is legal advice.

Editorial conclusion

Adopt Duix Mobile if you are building a mobile or embedded avatar interface and you already have an LLM, ASR and TTS stack you are willing to wire in yourself; the repository gives Android and iOS demo projects and four downloadable avatars to start from. Do not adopt it if you need a hosted service, a documented licence, or a custom avatar without contacting the vendor, because the licence file is not a standard SPDX identifier and the README routes custom avatar work to [email protected]. Before committing, verify three things in the repository: that the Android and iOS demo READMEs name the exact build tooling your team uses, that the avatar zip for your chosen model is small enough for your app bundle, and that the streaming audio and voice callback behaviour described in the FAQ is present in the SDK version you pin.

Frequently asked questions

Official sources

1. duixcom/Duix-Mobile on GitHub
2. Issues
3. Project website
4. README
5. Releases