Flutter On-Device AI With TensorFlow Lite

A developer built Butter Skin, a Flutter skincare app that runs a TensorFlow Lite vision model fully on-device, analyzing camera images and returning results in under two seconds without any network round trip. The app uses the tflite_flutter plugin with a reusable interpreter, int8 quantization to cut model size from about 90 MB to 23 MB, and Firebase only for account and progress sync, keeping all AI inference offline.

On-device AI used to sound like a research demo. In 2026 it is a shipping strategy. Run a TensorFlow Lite model directly on the phone, skip the network round trip entirely, and keep the user's most sensitive data on the device that collected it. I did exactly this in Butter Skin https://www.uzairxdev.online/projects/butter-skin , an AI skincare coach that analyzes skin conditions straight from the camera and returns personalized results in under two seconds — the model never leaves the phone. The app runs on Flutter and Dart, uses TensorFlow Lite for the vision model, Riverpod for state management, and Firebase Auth, Firestore, Cloud Functions only for account and progress sync — the AI analysis itself is 100% offline. This guide is the practical version of that pipeline: loading a .tflite model with the tflite flutter plugin, preprocessing camera images into the exact tensor the model expects, running inference off the UI thread, and the production habits that keep the feature reliable. Four reasons pushed the Butter Skin analysis on device, and they apply to most mobile AI features: Privacy. Skin photos are about as personal as data gets. On-device inference means they never travel over a network, never sit on a server, and never appear in a request log. Privacy is not a policy page; it is the architecture. Latency. A network round trip for an image upload is measured in seconds. On-device inference on a modern phone is measured in milliseconds, and the whole analysis — capture, preprocess, infer, render — lands under two seconds. Offline. The feature works in airplane mode, on a poor connection, and in regions where mobile data is expensive. If your feature's value depends on connectivity, that is a choice you are making. Cost. No per-request billing, no GPU server to keep warm. Once the model ships inside the app bundle, inference is free at any scale. You need two packages: tflite flutter for the interpreter and image for decoding and resizing photos without a platform channel. dependencies: flutter: sdk: flutter tflite flutter: ^0.10.1 image: ^4.0.0 flutter: assets: - assets/models/skin model.tflite - assets/models/labels.txt The .tflite file comes from your own training pipeline — export from TensorFlow and optionally quantize to shrink it. The labels.txt file holds one class name per line, matching the model's output order. Always verify that the label order matches the training output; a silent mismatch here produces confident, wrong answers. Model size directly affects download size and install conversion. A float32 model that is 90 MB becomes roughly 23 MB as int8 quantized — same architecture, quarter of the weight. Quantization converts weights and optionally activations from 32-bit floats to 8-bit integers, trading a small, measurable accuracy drop for a large size and speed win. Two rules that matter in practice. First, measure accuracy on your own validation set before and after quantization; do not assume the drop is negligible for your task. Second, keep the training-time input preprocessing identical between the float and quantized versions — quantized models are less forgiving of mismatched normalization. If the accuracy drop is unacceptable for your use case, ship the float32 model and accept the larger download. An interpreter is expensive to create and cheap to reuse. Load it at startup, allocate its tensors, and keep it alive for the app's lifetime: import 'package:tflite flutter/tflite flutter.dart'; late final Interpreter interpreter; Future<void initModel async { final options = InterpreterOptions ..threads = 4; interpreter = await Interpreter.fromAsset 'assets/models/skin model.tflite', options: options, ; interpreter.allocateTensors ; } Setting threads lets the interpreter use multiple CPU cores, which is the cheapest speed-up available. The plugin also supports hardware delegates — NNAPI and GPU delegates on Android, Metal and CoreML delegates on iOS, XNNPack on desktop. Start with multi-threaded CPU, measure on real devices, and add a delegate only when profiling says it helps. When you do try a delegate, wrap it so older devices fall back gracefully: Future<void initModelWithDelegate async { final options = InterpreterOptions ..threads = 4; // Add a hardware delegate here when your model benefits from it. interpreter = await Interpreter.fromAsset 'assets/models/skin model.tflite', options: options, .catchError Object async { // Delegate failed on this device: fall back to plain multi-threaded CPU. final fallback = InterpreterOptions ..threads = 2; return Interpreter.fromAsset 'assets/models/skin model.tflite', options: fallback, ; } ; interpreter.allocateTensors ; } This is where most on-device AI bugs live. A vision model trained on 224×224 float32 images normalized to 0–1 will produce garbage if you hand it a 1080p photo with raw 0–255 pixels. Decode, resize, normalize: import 'dart:io'; import 'package:image/image.dart' as img; Future<List<List<List<List<double preprocessImage String imagePath, { int size = 224, } async { final bytes = await File imagePath .readAsBytes ; final decoded = img.decodeImage bytes ; if decoded == null throw Exception 'Could not decode image' ; final resized = img.copyResize decoded, width: size, height: size ; final input = List.filled 1 size size 3, 0.0 .reshape 1, size, size, 3 ; for var y = 0; y < size; y++ { for var x = 0; x < size; x++ { final pixel = resized.getPixel x, y ; input 0 y x 0 = pixel.r / 255.0; input 0 y x 1 = pixel.g / 255.0; input 0 y x 2 = pixel.b / 255.0; } } return input; } Match this code to your own model card: input resolution, channel order RGB vs BGR , and normalization range 0–1 vs -1–1 are training-time decisions, and the app must reproduce them exactly. The single most common on-device vision bug is a preprocessing mismatch — the model runs fine and the answers are nonsense. Load the labels, allocate an output buffer shaped like the model's output tensor, and run: import 'dart:math'; import 'package:flutter/services.dart' show rootBundle; late final List<String labels; Future<void initLabels async { final raw = await rootBundle.loadString 'assets/models/labels.txt' ; labels = raw.split '\n' .where line = line.isNotEmpty .toList ; } Future<String analyzeSkin String imagePath async { final input = await preprocessImage imagePath ; final outShape = interpreter.getOutputTensor 0 .shape; // e.g. 1, 5 final output = List.filled outShape 0 outShape 1 , 0.0 .reshape outShape 0 , outShape 1 ; interpreter.run input, output ; final scores = output 0 as List<double ; final best = scores.indexOf scores.reduce max ; return labels best ; } Note: raw.split '\n' is written with a single backslash in real Dart. In this article it appears doubled because the blog system stores articles in a TypeScript template literal — write it single-backslashed in your own code. interpreter.run is synchronous and can block for hundreds of milliseconds — enough to drop frames and freeze animations. The tflite flutter package ships IsolateInterpreter , which runs inference in a separate isolate while your UI isolate stays responsive: late final IsolateInterpreter isolateInterpreter; late final List<int outputShape; Future<void initIsolateModel async { final options = InterpreterOptions ..threads = 4; interpreter = await Interpreter.fromAsset 'assets/models/skin model.tflite', options: options, ; interpreter.allocateTensors ; // Cache the output shape once; inference happens in the other isolate. outputShape = interpreter.getOutputTensor 0 .shape; isolateInterpreter = await IsolateInterpreter.create address: interpreter.address ; } Future<String analyzeSkinAsync String imagePath async { final input = await preprocessImage imagePath ; final output = List.filled outputShape 0 outputShape 1 , 0.0 .reshape outputShape 0 , outputShape 1 ; await isolateInterpreter.run input, output ; final scores = output 0 as List<double ; final best = scores.indexOf scores.reduce max ; return labels best ; } The isolate is created from the interpreter's address and shares its native resources, so keep the original interpreter alive for as long as the isolate exists. Both run and runForMultipleInputs on IsolateInterpreter are asynchronous. One interpreter per model. Never create an interpreter per photo. It is a singleton for the feature's lifetime. Dispose properly. Call interpreter.close and isolateInterpreter.close when the feature is torn down. Leaked interpreters hold native memory the Dart garbage collector cannot see. Delegate fallback. If you enable a GPU delegate, wrap creation and fall back to multi-threaded CPU. Older devices fail delegate creation in ways you cannot predict from the emulator. Measure on real hardware. TFLite behaves differently per chipset, and per the package docs it does not work reliably in the iOS simulator — test on physical devices, including a low-end Android phone. Version your models. When you retrain, ship the new .tflite with the app update and keep the labels file in lockstep. A model update without its labels is a silent accuracy regression. Test with training-like inputs. Run your own validation photos through the app build, not just the Python notebook. Camera white balance and JPEG compression differ from curated datasets, and that gap is where real-world accuracy dies. In Butter Skin these habits — combined with Riverpod managing the analysis flow and Firebase Cloud Functions syncing the visual progress diary — delivered under-two-second on-device analysis, 99.9% crash-free sessions, and a 4.8-star rating. On-device is not always the answer. Large language models are too heavy for most phones' power budgets — for those, small language models or server-side APIs are the realistic options I covered the on-device LLM side in On-Device SLMs for Flutter https://www.uzairxdev.online/blog/on-device-slm-edge-ai . Rules of thumb: vision and classification models belong on device; generative and reasoning models usually stay behind an API. And keep inference cheap either way — even on device, a model that drains the battery gets uninstalled faster than one that is slightly less accurate. For keeping the rest of the frame budget under control, see Zero-Jank Flutter Performance https://www.uzairxdev.online/blog/zero-jank-flutter-performance-profiling . On-device AI in Flutter is no longer exotic — it is a dependency, a model file, and about a hundred lines of Dart. Load the interpreter once, reproduce the training-time preprocessing exactly, run inference in an isolate, and fall back gracefully when hardware acceleration is not available. Your users get instant, private, offline intelligence, and you get a feature with no server bill attached. Get in touch https://www.uzairxdev.online/contact and let's talk about your project. Originally published at uzairxdev.online https://www.uzairxdev.online/blog/flutter-on-device-ai-tensorflow-lite