Contents
Figure 1: Deploying machine learning models to mobile and edge devices with TensorFlow Lite and LiteRT
Quick, important correction before we go any further: TensorFlow Lite doesn't really exist under that name anymore. Google rebranded it to LiteRT (Lite Runtime), and while it still reads and runs the exact same .tflite file format you've seen throughout this series, the name change reflects something genuinely bigger than marketing — it now treats PyTorch and JAX as first-class citizens, not just TensorFlow.
This is genuinely the connective-tissue article for this whole series. The Arduino tutorial's Optimize.DEFAULT conversion, the Raspberry Pi's tflite_runtime.Interpreter, the Coral's Edge TPU delegate — all of it is this same underlying framework, just used at different points along the hardware spectrum. This tutorial zooms out and shows the full picture, plus what's changed now that it's LiteRT.
By the end of this guide, you'll understand the rebrand, the actual conversion and deployment pipeline for both Android and iOS, and how the framework's ambitions have expanded well past the mobile-classification use case it started with. IMO, it's worth understanding this transition now — most existing tutorials online still say "TFLite" and haven't caught up :)
TFLite → LiteRT: What Actually Changed
Since its 2017 debut, TFLite powered ML in over 100,000 apps running on 2.7 billion devices — genuinely one of the most widely deployed ML runtimes ever shipped. The rebrand to LiteRT reflects a real expansion in scope, not just a fresh coat of paint.
Multi-framework support is the headline change. LiteRT now supports models authored in PyTorch, JAX, and Keras with the same leading performance TFLite was known for — not just TensorFlow-originated models anymore.
The model format itself hasn't changed. LiteRT still runs .tflite files, plus a newer .litertlm format specifically for generative models like LLMs — your existing production apps and models are not broken by this rename.
The scope has expanded toward GenAI. Where TFLite's reputation was built on image classification and object detection, LiteRT explicitly targets deploying LLMs and diffusion models on-device too, with GPU and NPU acceleration across platforms.
If you're reading an older tutorial that says "TensorFlow Lite," mentally substitute "LiteRT" and understand the model format is identical. The Arduino and Raspberry Pi work from earlier in this series is completely unaffected by this rename — you were already using the technology that's now called LiteRT.
The Automated Hardware Selection: A Genuinely Useful New Feature
One of the more practically important additions is the Compiled Model API, which automatically selects the optimal hardware backend — CPU, GPU, or NPU — based on the specific device it's running on.
No explicit delegate configuration required — recall from the Raspberry Pi tutorial how you had to manually specify the Edge TPU delegate for Coral hardware. This newer API handles that selection automatically instead.
By leveraging mobile GPUs and NPUs, this can achieve up to 25x faster performance compared to CPU-only inference, while simultaneously reducing power consumption — a genuinely significant gain for battery-powered mobile deployment.
The TensorBuffer API manages high-performance data flow, eliminating costly memory copies between something like a live camera feed and whatever hardware accelerator ends up handling inference.
This is genuinely the mobile equivalent of what the Raspberry Pi tutorial's Hailo/Coral setup solved manually — automatic acceleration instead of hand-picking a delegate for your specific hardware.
The Conversion Pipeline: From Trained Model to Deployable File
Regardless of which framework you trained in, the deployment pipeline follows the same basic shape you've already seen in the Arduino tutorial, just with more format flexibility now.
import tensorflow as tf
model = tf.keras.models.load_model("my_trained_model.h5")
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
litert_model = converter.convert()
with open("model.tflite", "wb") as f:
f.write(litert_model)This should look genuinely familiar — it's the exact same conversion pattern from the Arduino TinyML tutorial, just deploying to a phone instead of a microcontroller. The Optimize.DEFAULT flag triggers the same quantization principles covered in the previous article — smaller file, faster inference, a small and usually acceptable accuracy cost.
Converting From PyTorch or JAX
Since LiteRT explicitly supports non-TensorFlow frameworks now, models trained elsewhere follow a comparable, streamlined conversion path into .tflite or .litertlm format through Google AI Edge's conversion tooling — genuinely useful if your training pipeline (like several projects in the RL series) was built entirely in PyTorch rather than Keras.
Deploying to Android
Android remains LiteRT's most mature deployment target, with the most direct tooling.
val model = FileUtil.loadMappedFile(context, "model.tflite")
val options = InterpreterApi.Options()
val interpreter = InterpreterApi.create(model, options)
val input = TensorBuffer.createFixedSize(intArrayOf(1, 224, 224, 3), DataType.FLOAT32)
// ... populate input buffer with preprocessed image data ...
val output = TensorBuffer.createFixedSize(intArrayOf(1, 1000), DataType.FLOAT32)
interpreter.run(input.buffer, output.buffer)Notice the same fundamental interpreter pattern from the Raspberry Pi tutorial — load model, prepare input tensor, run inference, read output tensor. The actual mechanics genuinely don't change between a Pi running Python and an Android app running Kotlin; only the language and surrounding app scaffolding differ.
Real-Time Camera Inference on Android
For live camera-feed use cases — the mobile equivalent of the Pi's real-time video classification project — the CompiledModel API handles hardware selection and buffer management together:
val compiledModel = CompiledModel.create(context, "model.tflite")
val result = compiledModel.run(cameraFrameBuffer)This is genuinely simpler than the manual delegate configuration from the Raspberry Pi Coral setup — the automated hardware selection means you're not hand-picking GPU versus NPU versus CPU the way you had to specify the Edge TPU delegate explicitly before.
Deploying to iOS
iOS deployment follows the same conceptual pipeline, with Swift or Objective-C bindings instead of Kotlin.
import TensorFlowLite
let interpreter = try Interpreter(modelPath: modelPath)
try interpreter.allocateTensors()
try interpreter.copy(inputData, toInputAt: 0)
try interpreter.invoke()
let outputTensor = try interpreter.output(at: 0)allocateTensors() is genuinely the same tensor arena concept from the Arduino tutorial, just handled with iOS's abundant memory rather than a microcontroller's kilobytes — you rarely need to think about it failing the way you would sizing an Arduino's arena by hand.
If you're building mobile ML apps, a modern phone like the Google Pixel 9 with its Tensor G4 chip has excellent NPU support for on-device inference, making it a great development and testing device for LiteRT deployments.
Where LiteRT Sits in This Series' Hardware Spectrum
This is worth mapping explicitly against the edge AI hardware guide from earlier in this series, since LiteRT genuinely spans nearly the entire spectrum covered there.
Arduino/TinyML tier: LiteRT for Microcontrollers, the exact library from the Arduino tutorial, handling kilobyte-scale models with hand-managed tensor arenas.
Raspberry Pi tier: tflite_runtime, the lightweight inference-only package, running considerably larger models with automatic tensor allocation.
Mobile tier (this article): Full LiteRT with automated hardware selection across CPU/GPU/NPU, supporting real-time camera inference and now, increasingly, on-device generative models.
Beyond mobile: LiteRT explicitly targets desktop and web deployment too, plus GenAI workloads that historically needed Jetson-tier hardware from the edge AI hardware guide.
The genuinely notable shift is that last point — LiteRT is explicitly expanding into the generative AI territory the hardware guide reserved for Jetson-class devices, meaning the line between "mobile inference framework" and "edge LLM runtime" is actively blurring.
Quantization's Role in Mobile Deployment
Everything from the quantization article applies directly here, with one mobile-specific wrinkle worth flagging: model size directly affects app download size and update bandwidth, not just inference speed.
A quantized INT8 model isn't just faster — it's a smaller app bundle, which matters for app store size limits and user download friction in a way it doesn't for a server-side deployment.
The same PTQ-first, QAT-if-needed decision framework from the quantization article applies directly — start with post-training quantization, and only invest in quantization-aware training if the accuracy hit genuinely matters for your specific use case.
NPU-targeted deployments benefit even more from correct quantization — mobile NPUs, like the microcontroller and Coral hardware covered earlier, generally accelerate specific precision formats natively rather than every possible bit-width equally.
Common Mistakes People Make
Following outdated "TensorFlow Lite" tutorials without realizing the rebrand. The model format is unchanged, but newer APIs (Compiled Model, automated hardware selection) won't appear in pre-rebrand documentation.
Manually configuring delegates when the newer Compiled Model API would handle it automatically. This is genuinely simpler now than the explicit Edge TPU delegate setup from the Raspberry Pi tutorial required.
Assuming mobile deployment needs a completely different mental model from microcontroller or Pi deployment. The interpreter pattern — load, allocate, set input, invoke, read output — is genuinely identical across every tier in this series.
Skipping quantization because mobile devices "have enough compute." Model size still affects app download size and battery consumption regardless of raw compute headroom.
Not checking whether your target device's NPU is actually being used. As with the vendor tooling caveat from the local LLM tools article, confirm hardware acceleration is genuinely active rather than assuming it by default.
Next Steps: Deploy to Production
Ready to ship ML models to millions of users? Educative offers interactive courses on mobile ML deployment, TensorFlow Lite optimization, and building production edge AI applications — practice in real sandboxed environments and learn by building actual deployment pipelines.
Wrapping This Up
TensorFlow Lite's rebrand to LiteRT reflects a genuine expansion beyond its TensorFlow-only, mobile-classification roots — the same .tflite format and interpreter pattern you used on Arduino and Raspberry Pi now extends across Android, iOS, desktop, and web, with PyTorch and JAX support and an eye toward on-device generative AI. The core mental model — convert, quantize, load, invoke — hasn't changed at all; what's changed is the framework's ambition and the automation around hardware selection.
Remember that existing production apps and models aren't affected by the naming change, and that the automated Compiled Model API genuinely simplifies hardware acceleration compared to the manual delegate configuration earlier tutorials (including the Raspberry Pi one from this series) required. FYI, if you've followed this series from Arduino through Raspberry Pi through quantization, you've genuinely already learned LiteRT — this article just gave the complete framework its current name and showed you the top of its hardware range :)
Now go take a model you quantized in the previous article's exercise and actually run it through this same interpreter pattern on whatever mobile device you have on hand. Watching the identical conceptual pipeline work across three completely different hardware tiers is genuinely the best way to internalize how much of this series has actually been one consistent idea underneath.