Technologies / LiteRT (TensorFlow Lite) and ML Kit
TensorFlow Lite app development with LiteRT and ML Kit
TensorFlow Lite app development means running machine learning models on the phone rather than on a server, so features such as scanning, recognition and classification work instantly, offline and without sending images off the device. One thing changed recently: Google renamed TensorFlow Lite to LiteRT. This page is for CTOs and product leads deciding between Google’s ready-made ML Kit APIs, a custom model on LiteRT, or a cloud model.
It is one of the AI options in our mobile app development technologies hub. For the product side of AI features, scoping, data and evaluation, see our AI app development company page.
- ML Kit first, custom models when needed
- LiteRT packages on new builds
- Android and iOS from one model
- Accuracy measured on real devices
TensorFlow Lite is now LiteRT: what that means for your app
On 4 September 2024, Google renamed TensorFlow Lite to LiteRT. The .tflite model format did not change, so existing models keep working. LiteRT also runs models built in PyTorch, JAX and Keras, and the documentation moved to Google’s AI Edge site.
The practical point is packaging. Google says apps that use the TensorFlow Lite packages must switch to the LiteRT packages. For an existing app that is usually a contained change: swap dependencies, rebuild, and re-run the accuracy and speed tests on your reference devices. We do it as part of a normal maintenance release, not a rewrite.
For buyers, the rename also widens the choice of where models come from. A data science team working in PyTorch no longer has to retrain in TensorFlow to ship on mobile, which removes a conversion step from the project plan.
ML Kit: on-device features without training a model
Per Google, ML Kit is a mobile SDK for Android and iOS whose APIs run on the device. These are the ones we use most.
Text recognition
Reading printed text from receipts, ID-style documents, labels and meter readings, without a server round trip.
Barcode scanning
Fast scanning of common 1D and 2D barcodes for inventory, ticketing, loyalty and check-in flows.
Face detection
Finding faces and landmarks for camera framing, filters and photo cropping. Detection only, not identity recognition.
Image labeling
Tagging photos with general labels to sort galleries, route support tickets or suggest categories.
Custom vision
When the general models are not specific enough, we add a custom LiteRT model for your products or defects.
Cloud fallback
For tasks that need a large model, the app calls your backend instead, with clear disclosure to the user.
When we choose LiteRT and ML Kit, and when we do not
We start with ML Kit whenever one of its APIs fits, because it needs no training data and no model to maintain. We move to a custom LiteRT model when the task is specific to your business (your product catalogue, your defect types, your document layouts) and the general models are not accurate enough.
On-device is not always right. If the model is large, changes weekly, or needs data the phone does not have, a server model is simpler to update and monitor. And on an iOS-only app, Apple’s own stack can be the better fit; our Core ML for mobile apps page covers that choice. For apps on both platforms, a single LiteRT model often avoids maintaining two converted copies.
Choose on-device ML if
- The feature must work offline
- Latency matters, such as live camera frames
- Images or text should not leave the phone
- Per-request cloud cost would grow with users
- The model is small enough to ship in the app
Have a camera or scanning feature in mind?
Describe the feature and show us a few sample images. Within one business day we will tell you whether ML Kit covers it, whether a custom model is needed, and what to test first.
On-device ML options compared
A buyer’s view of the four routes we weigh for a mobile ML feature.
| ML Kit | LiteRT custom model | Core ML | Cloud model | |
|---|---|---|---|---|
| Platforms | Android and iOS | Android, iOS and more | Apple platforms | Any, via your API |
| Training needed | No | Yes, or a pre-trained model | Yes, or a pre-trained model | Usually no |
| Works offline | Yes | Yes | Yes | No |
| Data leaves device | No | No | No | Yes, needs disclosure |
| Updating the model | With SDK updates | App release or model download | App release or model download | Server-side, any time |
| Best for | Text, barcodes, faces, labels | Business-specific vision tasks | iOS-only apps | Large or fast-changing models |
How on-device ML fits your app and backend
The model is one component of the feature. Around it sit the camera pipeline, preprocessing (cropping, resizing, normalising), post-processing that turns raw scores into a decision, and a fallback when confidence is low. Most of the engineering effort in TensorFlow Lite app development is in those parts, not in calling the model.
On the backend, you need somewhere to store model versions, a way to ship a new model without a full app release where the platform allows it, and anonymised feedback so you know when accuracy drops. We wire this into your existing backend rather than adding a separate ML platform for one feature.
Privacy rules apply even on-device. If any data is later sent to a third-party AI service, Apple’s Guideline 5.1.2(i) requires clear disclosure and explicit permission. For apps on Android, the Kotlin client and the iOS Swift client call the same model through a thin wrapper, so behaviour stays consistent.
How we deliver an on-device ML feature
Consistent with our standard process: one to two weeks of discovery, then two-week sprints with a demo build each sprint.
Define the decision
Write down what the feature decides, what an error costs, and the accuracy needed for it to be useful.
Try ML Kit first
Test the closest ML Kit API on your sample data. If it meets the bar, stop there.
Train or adapt a model
If not, train or fine-tune a small model, convert it to .tflite, and measure size and speed.
Test on real devices
Run the model on a low-end and a high-end phone per platform, with real lighting and real users’ images.
Ship with monitoring
Release behind a flag, log confidence scores (not images), and review accuracy after launch.
Hiring and maintenance implications
Using ML Kit needs no ML specialist; a strong mobile developer can integrate it. A custom LiteRT model needs someone who can prepare data, train and evaluate, which is a different skill set from app development. Many teams keep that role part-time. If you want mobile engineers on your own team, you can hire Android developers with a two-week trial.
Maintenance has three parts: keeping LiteRT and ML Kit dependencies current, re-testing the model on new OS versions and new phones, and retraining when the real world drifts from your training data, such as new packaging or new document formats.
Code-quality practices for on-device ML
What you can check in your repository and test reports.
- LiteRT packages, not the old TensorFlow Lite ones, on new builds
- Model files versioned, with the training data snapshot recorded
- Accuracy test set kept separate from training data
- Speed and memory measured on a low-end reference device
- Confidence threshold and fallback path for low-confidence results
- No images or text logged from users without consent
- Model wrapper shared in behaviour across Android and iOS
TensorFlow Lite app development: frequently asked questions
Is TensorFlow Lite discontinued?
It was renamed, not discontinued. Google renamed TensorFlow Lite to LiteRT on 4 September 2024. The .tflite model format is unchanged, so existing models still work, and LiteRT also runs PyTorch, JAX and Keras models. Apps using the TensorFlow Lite packages need to switch to the LiteRT packages, which is usually a contained maintenance change.
What is the difference between ML Kit and LiteRT?
ML Kit is a set of ready-made on-device APIs for Android and iOS, such as text recognition, barcode scanning, face detection and image labeling. You call them without training anything. LiteRT is the runtime for your own models. We use ML Kit when one of its APIs fits and LiteRT when the task is specific to your business.
Does ML Kit work on iOS?
Yes. Google describes ML Kit as a mobile SDK for both Android and iOS, and its APIs run on the device. That makes it a practical choice for cross-platform apps that need text recognition or barcode scanning on both platforms. On iOS-only apps we also compare it with Apple’s own frameworks before deciding.
Will an on-device model make our app much larger?
It depends on the model. ML Kit APIs and small custom models add a modest amount; large models can add a lot. We measure the app size impact before committing, and where the platform allows, download the model after install so the initial download stays small. Model size is one of the first things we test.
How accurate will the feature be?
We cannot promise a figure before testing on your data. In discovery we agree the accuracy the feature needs to be useful, then measure on a separate test set and on real devices. If ML Kit or a small custom model cannot reach that bar, we say so and recommend a cloud model or a different design.
Can we update the model without an app release?
Often, yes. The app can download a new model version from your backend, verify it and switch over, with the previous version kept as a fallback. Some changes, such as new input formats, still need an app update. We design the model wrapper so most improvements ship without one.
Add on-device ML that works offline and respects privacy
Book a 30-minute scoping call. We will review your feature, test ML Kit against your sample data where possible, and recommend the simplest route that meets your accuracy bar.