tf-lite-unity-sample: Running TensorFlow Lite and MediaPipe Models Inside Unity

The gap this fills: native inference libraries with no Unity binding

TensorFlow Lite ships as native libraries per platform. Unity ships as a C# runtime. Nothing in either project bridges them, so a Unity developer who wants on-device inference has to write the P/Invoke layer, marshal tensors across the boundary, manage the interpreter lifetime, and then handle the fact that the delegate story differs on every platform. This repository is that bridge, plus a set of worked examples. The README describes it as a port of the TensorFlow Lite Examples and some utilities for Unity. The examples span classic vision and audio tasks (MNIST, EfficientDet object detection, DeepLab, MoveNet, style transfer, text classification, BERT question answering, super resolution, audio classification) and five MediaPipe graphs (hand tracking, Blaze Face, Face Mesh, Blaze Pose, selfie segmentation). The audience is narrow and specific: Unity developers who have already decided that inference runs on the device rather than on a server, and who want to see a working pipeline before writing their own.

Three UPM packages, and the UniTask dependency that changes the API

The distribution model is the most consequential design decision here. Rather than a single monolith, the code is split into com.github.asus4.tflite (the core libraries), com.github.asus4.tflite.common (utilities), and com.github.asus4.mediapipe (MediaPipe utilities). They are resolved from the public npm registry through a scoped registry entry in Packages/manifest.json, with the scope com.github.asus4. That means you can take the core package without pulling in MediaPipe, which matters if your project only needs object detection. The fourth dependency is the interesting one. The README states that async methods are available only when UniTask is installed, and UniTask comes from a separate registry (package.openupm.com, scope com.cysharp.unitask). So the same package exposes a different surface depending on whether a third-party async library is present. That is a pragmatic choice for a sample, but it is also a hidden branch: a bug report that says "the async API is missing" is really a report about a manifest entry. If you vendor these packages, pin all four versions together.

Delegates are the real portability story, and the matrix is uneven

The prebuilt library table is where you should spend your attention before anything else. Core CPU is available on all five platforms: iOS, Android, macOS, Ubuntu and Windows. Beyond that it fragments. Metal Delegate covers iOS and macOS only. GPU Delegate covers Android and Ubuntu, and the README marks the Ubuntu build Experimental. NNAPI Delegate is Android only. So a project targeting Windows gets CPU and nothing else, and a project targeting Linux desktop gets CPU plus an experimental GPU path that the README says requires installing OpenGL ES and OpenCL, pointing at the MediaPipe GPU support documentation for the setup. There is no Vulkan delegate listed, no Windows GPU path, and no NNAPI equivalent on iOS. If your performance budget assumes hardware acceleration, the platform you ship on determines whether that assumption survives. The README does not publish latency figures for any delegate, so treat the table as a capability list, not a speed ranking.

Getting it running: clone with Git-LFS, or add the registry entries

There are two entry paths and they serve different purposes. To run the samples, clone the repository with Git-LFS installed; the README flags this as an important requirement, which makes sense because model files and native binaries are large. If you only want the libraries, edit Packages/manifest.json and add the scoped registries and dependencies. The README gives the exact block: a scopedRegistries array containing package.openupm.com scoped to com.cysharp.unitask and registry.npmjs.com scoped to com.github.asus4, plus a dependencies object with com.github.asus4.tflite, com.github.asus4.tflite.common, com.github.asus4.mediapipe and com.cysharp.unitask. The versions shown in the README track the release tags, currently 2.21.0-rc1 for the TFLite packages and 2.5.11 for UniTask. Note the rc suffix. The most recent tags are release candidates, and the previous stable-looking tag is 2.19.0-p3 from September 2025. If you need a version you can defend in a code review, that distinction matters.

Building the native libraries yourself, and why you probably will not

The repository ships prebuilt libraries inside the UPM package, and the README also points at DeNA's tflite-runtime-builder releases for TFLite v2.14.0 and later. If neither satisfies you, the documented path is: clone the TensorFlow repository, run ./configure inside it, then run build_tflite.py from this project against that checkout. The README gives two invocations. One updates iOS, Android and macOS in a single pass (./build_tflite.py --tfpath ../tensorflow -ios -android -macos). The other targets macOS with XNNPACK enabled (./build_tflite.py --tfpath ../tensorflow -macos -xnnpack). The script is Python 3. What the README does not describe is the toolchain each platform needs, how long a build takes, or how to keep a self-built library in sync with the C# side when the package version moves. For most teams this is a fallback for a specific need (a newer TFLite, a custom delegate, an XNNPACK build) rather than a routine step. Budget for it as a one-off engineering task, not a CI job.

Where it is the wrong tool, and what to use instead

This is a sample collection. The README calls the Assets/Samples folder MIT-licensed, which tells you the intended use is reading and adapting, not depending on. There is no documented API reference, no stability guarantee, and no versioning policy beyond the tags. The clearest case where it is the wrong choice is a project that needs a maintained inference runtime with a support contract and a predictable upgrade path. Unity's own Sentis package is the natural alternative, and the difference in approach is not cosmetic: Sentis is a first-party Unity package that imports ONNX models and runs them through Unity's own backend abstraction, so you stay inside the Unity dependency graph and get Unity's release cadence. tf-lite-unity-sample instead wraps the TensorFlow Lite C API and the MediaPipe graphs directly, which means you get access to TFLite-specific delegates (Metal, GPU, NNAPI) and to MediaPipe graphs that have no ONNX equivalent, but you also inherit the native library matrix and the model licensing surface. If your models are already .tflite and you want the delegate options, this repository is closer to what you need. If your models can be exported to ONNX and you value a single vendor, Sentis is the simpler dependency.

Licence surface: three layers, and only one of them is settled

The licensing is layered and the repository is explicit about it. The sample code under Assets/Samples is MIT, copyright Koki Ibukuro. The underlying TensorFlow and MediaPipe projects are Apache License 2.0, and the README notes that some MediaPipe C# code is based on terryky/tflite_gles_app. The third layer is the models, and this is the one that catches people. The README carries a warning that each TensorFlow Lite model might have a different licence and that you should check the licence of the model you use. The official TFLite models and the MediaPipe models are listed as separate groups, and selfie segmentation is noted as using a modified model from PINTO_model_zoo with the custom post-process removed. MIT on the sample folder does not travel to the weights. If you ship a build containing a model, the model's terms are your problem, not the repository's. This is not legal advice; it is a description of what the README states and what it leaves to you.

Maintenance cost and what to check before you commit

The upgrade cost has three moving parts. First, the package version, currently tracking TFLite 2.21.0-rc1, which the README pairs with Unity 6000.3.11f1 in its tested configuration. A Unity upgrade and a package upgrade are coupled, and the README does not describe how wide the compatibility window is. Second, the delegate matrix, which changes per platform and per release; a delegate that exists today on Ubuntu is marked Experimental, and experimental markers move. Third, the model files, which are the part you actually have to re-verify on every upgrade because their licences are independent of the code licence. The practical check before adopting: open the prebuilt library table, find your target platform, and confirm the delegate you intend to use is listed for it. If it is not, you are on Core CPU, and you should decide whether that is acceptable before writing any integration code rather than after.

Editorial conclusion

Adopt it if you need a working reference for TFLite or MediaPipe inference inside Unity and you are willing to read the sample scenes rather than an API guide. Do not adopt it if you need a supported, versioned runtime with a stability guarantee, or if your target is a platform outside the prebuilt delegate matrix. Before committing, verify three things in your own project: that the delegate you need exists for your target platform, that every model you ship has its own licence cleared, and that the pinned package versions in Packages/manifest.json match the Unity version you are on.

Official sources

1. asus4/tf-lite-unity-sample on GitHub
2. Issues
3. README
4. Releases