DEV Community: Muhammad Uzair

SDUI 2.0: Generative AI and Dynamic Mobile Layouts

Muhammad Uzair — Mon, 26 Oct 2026 03:01:23 +0000

SDUI 2.0: Generative AI and Dynamic Mobile Layouts

Server-Driven UI (SDUI) is not a new concept. Companies like Airbnb and Spotify have used it for years to push layout updates without waiting for App Store approvals. But in late 2026, we are witnessing the birth of SDUI 2.0.

The difference? The backend JSON isn't static anymore. It is being generated in real-time by Artificial Intelligence.

The Shift to AI-Generated Layouts

In SDUI 1.0, a product manager would define a layout configuration in a CMS, and the server would send that exact JSON to the client.

In SDUI 2.0, the backend utilizes generative AI models that ingest real-time analytics, user behavior, and context (like time of day or location) to construct a hyper-personalized UI schema on the fly.

How It Works in Practice

The Rendering Engine: The mobile app (often built in Flutter or Compose) acts purely as a dumb rendering engine. It knows how to draw a "Card", a "Button", or a "Carousel", but it has no idea what the screen is supposed to look like.
The AI Brain: When the user opens the app, the backend AI evaluates their profile. If they are a power user, the AI generates a dense, data-rich UI schema. If they are a new user, the AI generates a simplified, tutorial-focused UI schema.
The Execution: The mobile app receives the JSON payload, parses it, and dynamically renders the customized layout in milliseconds.

Why This Matters

This architecture allows apps to literally A/B test themselves. The AI can continuously tweak button placements, colors, and content density to maximize engagement for every individual user. As a mobile engineer, your job is no longer building screens—it is building the robust rendering engines capable of interpreting whatever the AI dreams up.

Originally published at uzairxdev.online

Dart Streams vs Futures: When to Use Each

Muhammad Uzair — Mon, 26 Oct 2026 02:59:42 +0000

Every Flutter developer meets Futures on day one: you call an API, you await the result, you show it on screen. Then, sooner or later, you meet the second half of Dart async programming — Streams — and the confusion starts. Both deal with values that arrive later. Both use await in some form. So when do you reach for a Future, and when do you need a Stream?

The answer is simpler than most tutorials make it sound. A Future delivers one value, once, at some point in the future. A Stream delivers zero or more values, over time, until it closes. That single distinction drives every decision in this guide: which type to return from a function, how to consume it in a widget, and which mistakes to avoid.

Futures: one value, later

A Future represents a computation that has not finished yet. It will complete with either a value or an error, exactly once. Network requests, file reads, database queries, and shared-preferences loads are all naturally Futures, because each one produces a single answer.

\dart Future<User> fetchUser(String id) async { final response = await http.get(Uri.parse('https://api.example.com/users/' + id)); if (response.statusCode != 200) { throw Exception('Failed to load user'); } return User.fromJson(jsonDecode(response.body)); } \\

Consuming a Future is straightforward. Await it inside an async function, or use a FutureBuilder in a widget. Always handle the error path: an unhandled Future error becomes a red screen in debug builds and a silent failure in release builds.

\dart Future<void> loadUser() async { try { final user = await fetchUser('42'); setState(() => _user = user); } catch (e) { setState(() => _error = 'Could not load the profile. Try again.'); } } \\

Two Future utilities cover most real-world needs. Future.wait runs several independent Futures in parallel and returns all their results at once, which is far faster than awaiting them one after another. The timeout method caps how long you are willing to wait, so a hung request cannot freeze your UI forever.

\dart Future<DashboardData> loadDashboard() async { final results = await Future.wait([ fetchUser('42'), fetchNotifications(), fetchSettings(), ]).timeout(const Duration(seconds: 10)); return DashboardData( user: results[0] as User, notifications: results[1] as List<NotificationItem>, settings: results[2] as Settings, ); } \\

If the work produces exactly one result, it is a Future. Full stop. Wrapping a single API call in a Stream adds complexity for no benefit, and it is one of the most common over-engineering mistakes in Flutter codebases. The REST integration patterns in Flutter REST API Integration: From JSON to UI all follow this rule: one request, one Future, one result.

Streams: many values, over time

A Stream is a sequence of asynchronous events. It can emit many values, it can emit errors, and eventually it closes with a done event. User input, sensor data, WebSocket messages, Firebase realtime updates, and download progress are all naturally Streams, because the data keeps arriving after the first value.

The simplest way to create one is a StreamController: you add events to its sink, and listeners receive them through its stream.

\`dart
class DownloadTracker {
final _controller = StreamController();

Stream get progress => _controller.stream;

Future download(String url) async {
final request = http.Request('GET', Uri.parse(url));
final response = await http.Client().send(request);
final total = response.contentLength ?? 0;
int received = 0;

await for (final chunk in response.stream) {
  received += chunk.length;
  if (total > 0) {
    _controller.add(received / total);
  }
}
await _controller.close();

}
}
`\

Note two details. First, the controller is closed when the work finishes, so listeners know no more events are coming. Second, the download itself still uses a Future internally: the HTTP request completes once, while the progress Stream reports many values along the way. Futures and Streams compose like this all the time; they are not rivals.

In a widget, StreamBuilder is the counterpart of FutureBuilder. It rebuilds whenever a new event arrives, and its snapshot tells you the connection state, the latest data, and any error.

\dart StreamBuilder<double>( stream: tracker.progress, builder: (context, snapshot) { if (snapshot.hasError) { return const Text('Download failed'); } final value = snapshot.data ?? 0.0; return Column( children: [ LinearProgressIndicator(value: value), Text('Downloaded ' + (value * 100).round().toString() + '%'), ], ); }, ) \\

Always handle snapshot.hasError and the waiting state explicitly. A StreamBuilder that only reads snapshot.data will show a blank or stale widget while the stream is still connecting, and users will read that as a broken screen.

Creating streams with async star and yield

For streams you generate yourself, async star functions are cleaner than a hand-managed controller. Mark the function async star, yield each value as it becomes available, and Dart builds the Stream for you.

\dart Stream<int> countdown(int from) async* { for (var i = from; i >= 0; i--) { yield i; await Future.delayed(const Duration(seconds: 1)); } } \\

Each yield pauses the function until the listener is ready for the next value, so a slow listener naturally applies backpressure instead of being flooded. You can also transform streams without writing loops: map converts each event, where filters events by a condition, and distinct drops consecutive duplicates.

\dart final evenCountdown = countdown(10) .where((value) => value % 2 == 0) .map((value) => 'T-minus ' + value.toString()); \\

Stream transformers are lazy: nothing runs until something listens. That is a feature, not a bug — it means creating a stream costs almost nothing, and you only pay for the work when a listener actually needs the data.

Single-subscription versus broadcast streams

By default, a Dart stream allows exactly one listener. Listen a second time and you get a StateError. That default is correct for most cases: a file download, a sensor feed, or a WebSocket connection should have one owner that controls its lifecycle.

When several widgets genuinely need the same events — for example, a connectivity indicator in the app bar and a banner on the home screen — convert the stream with asBroadcastStream. Broadcast streams allow many listeners, but they come with two trade-offs: late listeners miss events that already happened, and the stream keeps running even when nobody is listening unless you manage it yourself.

\dart final connectivity = Connectivity() .onConnectivityChanged .asBroadcastStream(); \\

A practical rule: start single-subscription, and switch to broadcast only when a second listener actually appears. Premature broadcast streams are a classic source of missed-event bugs, because developers assume every listener sees the full history.

The decision table

Situation	Use	Why
Load a user profile from an API	Future	One result, then done
Watch auth state changes	Stream	State can change many times
Read a file from disk	Future	One result, then done
Receive WebSocket messages	Stream	Messages arrive indefinitely
Run three API calls in parallel	Future.wait	All results needed together
Show download progress	Stream	Progress updates over time
Debounce search input	Stream	Keystrokes arrive continuously
Cache a value for later reuse	Future	The value is computed once

When in doubt, count the values. One value means Future. Many values over time means Stream. If you find yourself adding a Stream just to deliver one value, simplify it to a Future. If you find yourself polling a Future in a timer loop to get fresh values, that polling loop is a Stream waiting to be written.

This distinction also explains why state management libraries lean on streams so heavily. BLoC, for example, models state as a stream of states over time, which is why understanding streams makes BLoC click. The tutorial in Flutter BLoC Pattern Tutorial: Zero to Production builds directly on the concepts above: events go in, states come out, and the UI rebuilds on each new state.

Five mistakes every Flutter developer makes once

Awaiting a stream. Awaiting a Stream gives you its first event only if you use the first getter, or hangs until it closes if you use await for incorrectly in the wrong place. If you need every event, listen or use await for inside an async function — never await the stream object itself.

Listening twice to a single-subscription stream. Two widgets subscribing to the same controller stream throws at runtime. Share the data through a state management solution or convert to broadcast deliberately, as discussed above.

Forgetting to cancel a subscription. A StreamSubscription keeps its source alive. Cancel it in dispose, or use StreamBuilder and let the framework manage the subscription for you. Leaked subscriptions are a quiet memory leak: the stream keeps emitting, the disposed widget keeps receiving, and the app slowly degrades.

\`dart
class _TickerState extends State {
late final StreamSubscription _subscription;

@override
void initState() {
super.initState();
_subscription = countdown(60).listen((value) {
if (mounted) setState(() => _secondsLeft = value);
});
}

@override
void dispose() {
_subscription.cancel();
super.dispose();
}
}
`\

Never closing a StreamController. An unclosed controller holds its listeners forever and confuses code that waits for the done event. Close it in dispose, or prefer async star functions, which close automatically when the function returns.

Ignoring errors in streams. Stream errors do not throw into surrounding try-catch blocks the way Future errors do. Handle them with onError in listen, check snapshot.hasError in StreamBuilder, or use handleError in a transformation chain. An unhandled stream error crashes the zone, which in a Flutter app usually means a red screen.

A complete example: live search

Live search ties everything together. Keystrokes arrive as a stream, you debounce them so you do not fire a request per character, and each debounced query becomes a single Future that fetches results.

\`dart
class SearchService {
final _queryController = StreamController();

Stream> get results => _queryController.stream
.distinct()
.asyncMap((query) => searchApi(query));

void onQueryChanged(String query) {
_queryController.add(query);
}

Future> searchApi(String query) async {
await Future.delayed(const Duration(milliseconds: 300));
return ['Result for ' + query];
}

void dispose() {
_queryController.close();
}
}
`\

The pattern is worth studying: a Stream for the continuous input, a Future for each discrete lookup, distinct to skip duplicate queries, and asyncMap to turn each query into its async result. Most real-time Flutter features are variations of this shape. Keeping the network layer behind a clean boundary, as in Flutter Repository Pattern: Keep API Calls Out of Widgets, makes this pattern easy to test: feed queries into the stream, await the results, and assert.

Conclusion

Futures and Streams are not two ways of doing the same thing. A Future is a promise of one value. A Stream is a sequence of values over time. Choose by counting the values, handle errors on the path each type actually uses, cancel subscriptions, close controllers, and let StreamBuilder or FutureBuilder own the widget lifecycle whenever you can. Get that mental model right, and the rest of Dart async programming — isolates, async generators, state management — falls into place, because all of it is built on these two ideas. The official Dart documentation on asynchronous programming at dart.dev is the best next read once these patterns feel natural.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Server-Driven UI (SDUI) in Flutter: Scaling Enterprise Apps

Muhammad Uzair — Sun, 25 Oct 2026 03:00:23 +0000

Server-Driven UI (SDUI) in Flutter: Scaling Enterprise Apps

If you work on a massive, consumer-facing mobile app (like e-commerce, banking, or streaming), you know the pain of the App Store release cycle.

Marketing wants to change the layout of the home page for a weekend sale. In a traditional app, this means writing code, pushing a build, waiting for Apple/Google approval, and hoping users actually update the app. By the time it's live, the weekend is over.

The solution that has taken over the enterprise Flutter world in 2026 is Server-Driven UI (SDUI).

What is SDUI?

In a Server-Driven UI architecture, the client app does not hardcode the layout of a screen. Instead, the backend API returns a JSON payload that describes the UI, and the Flutter app acts as a rendering engine that translates that JSON into Widgets dynamically.

Example JSON Payload:

{
  "type": "Column",
  "children": [
    {
      "type": "HeroBanner",
      "imageUrl": "https://example.com/sale.jpg",
      "actionUrl": "/checkout"
    },
    {
      "type": "ProductGrid",
      "items": [...]
    }
  ]
}

Why Flutter Excels at SDUI

Flutter is uniquely positioned for SDUI because of its declarative widget tree. Libraries like json_dynamic_widget or custom parsing engines allow developers to seamlessly map JSON nodes to Flutter Widgets.

Benefits:

Instant Updates: Change the UI layout, swap components, or launch promotions instantly across all devices without a new app release.
A/B Testing: You can serve different UI payloads to different user segments from the backend to see which layout converts better.
Cross-Platform Consistency: Since the backend controls the layout, iOS, Android, and Web clients are guaranteed to look and behave exactly the same.

The Catch

SDUI is complex to set up. It requires a highly coordinated effort between backend and frontend teams. It is not suitable for complex, highly interactive, or animated screens. It is best used for dynamic content feeds, storefronts, and onboarding flows.

If you are architecting a large-scale Flutter app in 2026, implementing an SDUI engine for your primary marketing screens is one of the highest ROI investments you can make.

Originally published at uzairxdev.online

Flutter Secure QR Medical Profile Sharing

Muhammad Uzair — Sun, 25 Oct 2026 02:59:19 +0000

In an emergency, first responders need facts in seconds: allergies, blood group, chronic conditions, emergency contacts. The problem is that the fastest way to share those facts — a QR code anyone can scan — is also the least private way to store them. That tension shaped MedTagID, an app that stores emergency medical details and shares them instantly through a secure QR code, with encrypted storage, a simple dashboard for updating the profile, and Firebase Auth plus Firestore behind it.

This guide covers the Flutter pattern that makes that design work: a QR code that encodes a reference instead of a record, encryption before anything touches the cloud, and Firestore rules that keep the profile owned by exactly one person.

The one rule: the QR code is a pointer, not a record

A QR code is not a secure container. Any phone camera can decode it, any screenshot preserves it, and a printed code cannot be recalled once it leaves your hands. So the code must never contain allergies, medications, or conditions. It contains one thing: a short, opaque profile reference such as a document ID.

class EmergencyProfile {
  const EmergencyProfile({
    required this.id,
    required this.displayName,
    required this.bloodGroup,
    required this.allergies,
    required this.conditions,
    required this.medications,
    required this.emergencyContacts,
  });

  final String id;
  final String displayName;
  final String bloodGroup;
  final List<String> allergies;
  final List<String> conditions;
  final List<String> medications;
  final List<String> emergencyContacts;

  /// Only the fields the user explicitly marked as shareable.
  Map<String, dynamic> toEmergencyView() => {
        'displayName': displayName,
        'bloodGroup': bloodGroup,
        'allergies': allergies,
        'conditions': conditions,
        'emergencyContacts': emergencyContacts,
      };
}

Notice what is missing from toEmergencyView: the full medication list and anything else the user did not choose to share. The QR code points at the profile; the app decides what a responder sees. If the user later changes their mind about a field, the change applies everywhere at once because the code never carried the data in the first place.

Encrypt on the device, before Firestore

Encryption that happens on the server protects data in transit. Encryption that happens on the device protects it in storage too: a leaked export, a misconfigured bucket, or an over-broad rule cannot hand over readable medical details. The pattern is simple — encrypt sensitive fields with AES before the write, and decrypt only when rendering.

import 'package:encrypt/encrypt.dart' as enc;

class ProfileCrypto {
  ProfileCrypto(String base64Key)
      : _key = enc.Key.fromBase64(base64Key),
        _iv = enc.IV.fromLength(16);

  final enc.Key _key;
  final enc.IV _iv;

  String encryptText(String plain) {
    final encrypter = enc.Encrypter(enc.AES(_key));
    return encrypter.encrypt(plain, iv: _iv).base64;
  }

  String decryptText(String cipher) {
    final encrypter = enc.Encrypter(enc.AES(_key));
    return encrypter.decrypt64(cipher, iv: _iv);
  }
}

Two rules matter more than the cipher itself. First, the key must live in secure storage on the device — Flutter Secure Storage backed by the platform keystore — never in Firestore, never in source control, and never inside the QR code. Second, encrypt field by field rather than the whole document, so the app can still query by owner ID and updated timestamp without decrypting everything. The document ID and ownership fields stay plaintext; the medical content does not.

A related lesson from the health side of this work: a vitals app only works if logging takes seconds, which is why the entry flow in Build a Health Vitals Tracker in Flutter is built around one-handed, sub-ten-second input. The same discipline applies here — the dashboard for editing a medical profile must be fast enough that people actually keep it up to date, because a stale emergency profile is worse than no profile at all.

Generate the QR code with qr_flutter

With the reference in hand, rendering the code is the easy part. The qr_flutter package draws a QrImageView from any string, and the string here is just the profile reference.

import 'package:qr_flutter/qr_flutter.dart';

class EmergencyQrCard extends StatelessWidget {
  const EmergencyQrCard({super.key, required this.profileId});

  final String profileId;

  @override
  Widget build(BuildContext context) {
    // The QR payload is a reference only. No medical data is encoded.
    final payload = 'medtag://profile/' + profileId;
    return Card(
      child: Padding(
        padding: const EdgeInsets.all(24),
        child: Column(
          mainAxisSize: MainAxisSize.min,
          children: [
            QrImageView(
              data: payload,
              version: QrVersions.auto,
              size: 220,
              errorCorrectionLevel: QrErrorCorrectLevel.M,
            ),
            const SizedBox(height: 12),
            const Text(
              'Show this code to a first responder.',
              textAlign: TextAlign.center,
            ),
          ],
        ),
      ),
    );
  }
}

Error correction level M is a deliberate choice: it keeps the code dense enough to scan from a phone screen while tolerating the smudges and glare that printed cards collect. Regenerate this widget whenever the profile changes — the payload stays the same reference, but re-rendering on every profile save guarantees the displayed code and the stored profile never drift apart. If a printed card is lost, the user rotates the reference: generate a new profile ID, re-point the record, and the old card becomes useless.

Lock Firestore down to the owner

Encryption is the second line of defence; security rules are the first. Only the authenticated owner writes the profile, and only the owner reads the full document. The responder view is a separate, narrow document that contains only the emergency subset.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /profiles/{profileId} {
      allow read, write: if request.auth != null
        && request.auth.uid == resource.data.ownerId;
    }
    match /emergencyViews/{profileId} {
      // Narrow, user-approved subset only. No full record here.
      allow read: if true;
      allow write: if request.auth != null
        && request.auth.uid == resource.data.ownerId;
    }
  }
}

This split is the whole architecture in one place. The full encrypted profile is owner-only. The emergency view is readable by design — that is its job — but it contains only what the user approved, and nothing in it can be used to reach the full record. If you are setting up authentication for the first time, the email, Google, and phone flows in Flutter Firebase Authentication: Email, Google and Phone cover the sign-in side of this setup.

The dashboard is a safety feature, not a settings page

MedTagID treats the profile dashboard as part of the safety story: an intuitive screen where the user updates medical details in minutes. Three behaviours make it work:

Show the last-updated date next to the QR code. If the date is months old, the user sees the problem before a responder does. A stale profile should feel uncomfortable to look at.

Confirm before every shareable-field change. Toggling a field into the emergency view is a privacy decision, not a form edit. A short confirmation dialog — naming exactly what responders will see — prevents accidental exposure.

Keep the QR screen reachable in two taps from launch. In a real emergency the owner may be the one showing the code, possibly stressed, possibly with one hand free. Deep navigation is a failure mode here, not an inconvenience.

Checklist before you ship a medical QR feature

The QR payload contains a reference only; scan it with a plain camera app and confirm no medical text appears.
Sensitive fields are encrypted on the device before any Firestore write, and the key lives in secure storage.
Firestore rules deny full-profile reads to everyone except the owner, and the responder document holds only the approved subset.
Updating the profile regenerates the displayed code, and rotating the reference invalidates lost printed cards.
The dashboard shows the last-updated date and asks for confirmation before a field becomes shareable.
Test the responder view on a device that has never signed in, with mobile data off and on, because the scan will happen in exactly those conditions.

Medical features carry a responsibility that ordinary features do not: the data is sensitive, the moment of use is stressful, and the cost of a leak or a stale record is real. The secure design is not complicated — reference, not record; encrypt before the cloud; owner-only full access; a narrow, user-approved emergency view. Build those four habits in and the QR code becomes what it should be: the fastest safe way to hand a stranger the facts that could save your life.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Integrating On-Device Local LLMs in Flutter Apps

Muhammad Uzair — Sat, 24 Oct 2026 03:02:30 +0000

Integrating On-Device Local LLMs in Flutter Apps

Every app seems to have an AI feature these days. However, the standard approach—sending user data to a cloud API like OpenAI or Anthropic—comes with massive drawbacks: high recurring costs, privacy concerns, and a strict requirement for an internet connection.

In 2026, the trend has heavily shifted toward On-Device AI. Thanks to quantized models (like Llama 3 Mobile or Gemma-Nano) and powerful NPUs (Neural Processing Units) in modern smartphones, we can now run complex LLMs entirely offline.

Why Go Local?

Absolute Privacy: User data never leaves the device. This is critical for healthcare, finance, and journaling apps.
Zero API Costs: You don't pay per token. The user's device provides the compute power.
Offline Capabilities: The AI works even in airplane mode.

How to Do It in Flutter

Running an LLM locally requires bridging native C++ inference engines (like llama.cpp or MediaPipe) with Flutter via FFI (Foreign Function Interface) or Platform Channels.

Here is the general architecture in 2026:

1. Choose a Quantized Model

You need a model optimized for edge devices, typically quantized to 4-bit (GGUF format) to fit inside a phone's RAM. A 2-billion parameter model usually takes up around 1.5GB of storage.

2. The FFI Bridge

Instead of writing messy Platform Channels for iOS and Android separately, developers now rely heavily on Dart FFI. We compile llama.cpp as a shared library (.so or .dylib) and call its functions directly from Dart.

3. State Management for Streaming

Inference happens token by token. You need a robust state management solution (like Riverpod or BLoC) to listen to the FFI stream and update your chat UI in real-time without blocking the main isolate.

The Future is Edge Compute

While cloud LLMs will always be more powerful, the vast majority of mobile app tasks—summarization, tone adjustment, translation, and basic querying—can be handled locally. If you're building a Flutter app with AI in 2026, on-device should be your default consideration.

Originally published at uzairxdev.online

Flutter On-Device AI With TensorFlow Lite

Muhammad Uzair — Sat, 24 Oct 2026 03:01:25 +0000

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, 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.

Why run the model on the device

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.

Step 1: add the dependencies and the model file

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.

Step 2: quantize so the model fits the app bundle

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.

Step 3: load the interpreter once

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();
}

Step 4: preprocess the camera image into the model's input tensor

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.

Step 5: run inference and read the output

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.

Step 6: move inference off the UI thread

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.

Step 7: production habits that keep the feature alive

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.

When the model should stay on the server

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). 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.

Conclusion

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 and let's talk about your project.

Originally published at uzairxdev.online

Architecting Offline-First Mobile Apps: Resilient Sync Engines & Conflict Resolution

Muhammad Uzair — Fri, 23 Oct 2026 03:01:25 +0000

Architecting Offline-First Mobile Apps: Resilient Sync Engines & Conflict Resolution

In the world of mobile engineering, assuming an always-on, high-speed fiber connection is the quickest path to a broken user experience. Whether a user is stepping into an elevator, boarding a subway, or driving through a cellular dead zone, networks fail constantly.

Traditional apps treat offline mode as an edge-case error state, plastering "No Internet Connection" dialogs across the screen. Modern, production-grade applications take the opposite approach: they are offline-first by default.

Let's dissect the architectural blueprint for building resilient, enterprise-grade offline sync engines in cross-platform mobile apps.

1. The Core Philosophy: Local-First as the Single Source of Truth

The golden rule of offline-first design is simple:

The UI never waits for the network. The UI only ever reads from and writes to the local database.

When an end user taps "Submit", "Like", or "Update Profile":

The mutation is immediately committed to the local embedded database (SQLite via Drift, Isar, or Realm).
The UI reacts instantaneously to the local database stream via reactive state management (BLoC or Riverpod).
A background sync engine independently dispatches the change to the backend when connectivity allows.

This guarantees a zero-latency UI regardless of network conditions.

// Pattern: Writing to local database first
Future<void> updateTaskTitle(String taskId, String newTitle) async {
  // 1. Transactionally update local state and queue sync intent
  await localDb.transaction(() async {
    await localDb.tasksDao.updateTitle(taskId, newTitle);
    await localDb.syncQueueDao.enqueue(
      SyncMutation(
        id: uuid.v4(),
        entity: 'tasks',
        entityId: taskId,
        action: SyncAction.update,
        payload: {'title': newTitle},
        createdAt: DateTime.now().toUtc(),
      ),
    );
  });

  // 2. Trigger background worker to flush queue if online
  syncEngine.triggerSync();
}

2. The Transactional Outbox Pattern

A common pitfall is updating the local database and subsequently failing to enqueue the network request due to an unhandled exception or app termination.

To guarantee that no user action is ever lost, use the Transactional Outbox Pattern:

Every write mutation must be wrapped in an atomic database transaction that updates both the entity table and an internal sync_mutations_queue table.
Each mutation in the queue has a unique idempotent UUID (mutation_id), an attempts counter, a timestamp, and an execution status (pending, in_flight, failed).

When the device regains connectivity, the sync engine pulls pending mutations ordered by created_at and flushes them sequentially or in batches.

3. Moving Beyond "Last-Write-Wins" (LWW)

The simplest conflict resolution strategy is Last-Write-Wins (LWW) based on client timestamps. However, in production, LWW is notorious for silent data loss:

Mobile device clocks suffer from clock skew (often several minutes or even days off).
A user working offline for two hours could unintentionally overwrite fresher data written by an online teammate.

Better Alternatives:

A. Field-Level Delta Updates

Instead of uploading the entire record payload, only transmit the exact fields modified. If User A updates the description and User B updates the due date, both changes merge cleanly without conflicts.

B. Version Vectors & Revisions

Assign an incrementing revision number (rev_id) or vector clock to each entity. When pushing an update, the client transmits the base_rev_id it started from. If the server detects that the entity has already advanced to a higher revision, it responds with a 409 Conflict, providing the latest remote state for the client to resolve.

C. Conflict-Free Replicated Data Types (CRDTs)

For collaborative tools, rich text notes, and counters, CRDTs are the ultimate modern standard. State-based or Operation-based CRDTs guarantee that multiple replicas converge to the exact same state mathematically, regardless of arrival order or network delays.

4. Background Sync & Battery Economy

Mobile operating systems aggressively terminate background threads to preserve battery life. To keep your sync pipeline reliable without draining power:

Use Platform-Native Schedulers: Leverage WorkManager on Android and BGAppRefreshTask on iOS (via plugins like workmanager) for periodic reconciliation.
Exponential Backoff with Jitter: If the server returns a 5xx error or rate limit, never hammer the API in a tight retry loop. Implement exponential backoff combined with randomized jitter to prevent the "thundering herd" problem when service resumes.
Connectivity Debouncing: Do not trigger an immediate sync the microsecond the network changes. Debounce network connectivity broadcasts by 1.5 to 2 seconds to allow the radio interface to stabilize.

5. Architectural Checklist for Production

Before shipping an offline-first mobile app, verify that your implementation satisfies these criteria:

[ ] Idempotent APIs: The backend recognizes duplicate mutation_id headers and returns cached success responses.
[ ] Reactive Streams: The presentation layer subscribes directly to local queries; no manual pullToRefresh is required to see offline changes.
[ ] Secure Storage: The local SQLite database is encrypted at rest using SQLCipher (256-bit AES).
[ ] Soft Deletes: Entities are marked with is_deleted = true rather than physically purged, ensuring delete operations replicate across all peers.
[ ] Telemetry: Monitor sync success rates and queue latency in your analytics to detect edge-case sync stalls in production.

Offline-first architecture demands higher upfront discipline, but the reward is immense: an app that feels instant, resilient, and virtually indestructible in the hands of real users.

Originally published at uzairxdev.online

Flutter Breathing Pacer Animation Guide

Muhammad Uzair — Fri, 23 Oct 2026 03:00:12 +0000

Breathing is the one animation where the user trusts the motion with their body. In my guided breathing and meditation app, Inhalo, the smooth animations and breathing pacers that guide users visually are the core of the product — backed by audio playback for guided meditation tracks and ambient sounds. When someone follows an inhale, the expanding circle on screen becomes their lungs. If it stutters, lags, or drifts off the real four-second count, they do not think "there is a bug" — they feel the exercise is wrong.

This guide walks through how to build a production-grade breathing pacer in Flutter: a phase-driven animation model, an expanding circle drawn with CustomPainter, haptic and audio cues at phase changes, and the performance habits that keep it locked at 60fps on low-end Android phones. Every snippet targets the current stable Flutter and Dart.

Model the breath cycle as phases

A breathing exercise is a small state machine. Box breathing is the simplest: inhale, hold, exhale, hold — four seconds each. Modeling each phase as data keeps the animation logic, the label, and the cues in one place:

enum BreathPhase { inhale, holdIn, exhale, holdOut }

class BreathCycle {
  const BreathCycle({
    required this.phases,
    this.label = 'Box breathing',
  });

  final String label;

  /// Each phase paired with its duration.
  final List<(BreathPhase phase, Duration duration)> phases;

  Duration get total =>
      phases.fold(Duration.zero, (sum, p) => sum + p.$2);

  static const box = BreathCycle(
    phases: [
      (BreathPhase.inhale, Duration(seconds: 4)),
      (BreathPhase.holdIn, Duration(seconds: 4)),
      (BreathPhase.exhale, Duration(seconds: 4)),
      (BreathPhase.holdOut, Duration(seconds: 4)),
    ],
  );
}

Dart records keep this compact and readable. If you later want 4-7-8 breathing (inhale 4, hold 7, exhale 8), you define a new constant — no animation code changes.

Drive the phases with one AnimationController

Use a single AnimationController whose duration equals the whole cycle, then derive the current phase from the controller's value. This guarantees the visuals can never drift out of sync with the timing, because there is only one source of truth:

class BreathingPacer extends StatefulWidget {
  const BreathingPacer({super.key, this.cycle = BreathCycle.box});

  final BreathCycle cycle;

  @override
  State<BreathingPacer> createState() => _BreathingPacerState();
}

class _BreathingPacerState extends State<BreathingPacer>
    with SingleTickerProviderStateMixin {
  late final AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      vsync: this,
      duration: widget.cycle.total,
    )..repeat();
  }

  /// Which phase the animation is currently in, derived from progress.
  (BreathPhase, double) phaseAt(double progress) {
    final totalMs = widget.cycle.total.inMilliseconds;
    double elapsed = progress * totalMs;
    for (final (phase, duration) in widget.cycle.phases) {
      if (elapsed < duration.inMilliseconds) {
        return (phase, elapsed / duration.inMilliseconds);
      }
      elapsed -= duration.inMilliseconds;
    }
    return (widget.cycle.phases.first.$1, 0.0);
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: _controller,
      builder: (context, child) {
        final (phase, phaseProgress) = phaseAt(_controller.value);
        return _PacerVisual(
          phase: phase,
          phaseProgress: phaseProgress,
          cycle: widget.cycle,
        );
      },
    );
  }
}

Two things matter here. First, AnimatedBuilder rebuilds only the subtree below it — the rest of your screen never rebuilds on every frame. Second, the phase is pure math over controller.value, so pausing, seeking, or slowing the controller (for example with a user-controlled speed setting) moves everything in lockstep.

Draw the expanding circle with CustomPainter

The signature visual is a circle that grows on inhale, holds, and shrinks on exhale. CustomPainter gives you full control with almost no overhead:

class _PacerVisual extends StatelessWidget {
  const _PacerVisual({
    required this.phase,
    required this.phaseProgress,
    required this.cycle,
  });

  final BreathPhase phase;
  final double phaseProgress;
  final BreathCycle cycle;

  @override
  Widget build(BuildContext context) {
    return RepaintBoundary(
      child: CustomPaint(
        painter: _BreathPainter(
          phase: phase,
          progress: phaseProgress.clamp(0.0, 1.0),
        ),
        size: const Size.square(280),
      ),
    );
  }
}

class _BreathPainter extends CustomPainter {
  _BreathPainter({required this.phase, required this.progress});

  final BreathPhase phase;
  final double progress;

  @override
  void paint(Canvas canvas, Size size) {
    final center = size.center(Offset.zero);

    // Expansion curve: grow on inhale, hold, shrink on exhale, rest.
    final double expansion = switch (phase) {
      BreathPhase.inhale => Curves.easeInOut.transform(progress),
      BreathPhase.holdIn => 1.0,
      BreathPhase.exhale => 1.0 - Curves.easeInOut.transform(progress),
      BreathPhase.holdOut => 0.0,
    };

    final maxRadius = size.shortestSide / 2;
    final radius = maxRadius * (0.35 + 0.65 * expansion);

    // Soft glow ring behind the main circle.
    final glow = Paint()
      ..color = const Color(0xFF7FB069).withValues(alpha: 0.15)
      ..maskFilter = const MaskFilter.blur(BlurStyle.normal, 24);
    canvas.drawCircle(center, radius * 1.12, glow);

    final fill = Paint()..color = const Color(0xFF4E6E5D);
    canvas.drawCircle(center, radius, fill);

    // A thin inner ring that pulses slightly ahead of the fill.
    final ring = Paint()
      ..color = const Color(0xFFF5F1E6).withValues(alpha: 0.6)
      ..style = PaintingStyle.stroke
      ..strokeWidth = 2;
    canvas.drawCircle(center, radius * (0.82 + 0.06 * expansion), ring);
  }

  @override
  bool shouldRepaint(_BreathPainter old) =>
      old.phase != phase || old.progress != progress;
}

Wrapping the CustomPaint in a RepaintBoundary is the single biggest performance win: the circle repaints in its own layer instead of forcing the parent and siblings to repaint every frame. On older Android devices this is the difference between a smooth 60fps and visible judder.

Show the phase label without rebuilding the world

The label ("Breathe in", "Hold", "Breathe out") changes only four times per cycle, so it should not ride along with the per-frame rebuild. Derive it in the same AnimatedBuilder but push it into a ValueNotifier that only notifies on change:

class _PacerScreen extends StatefulWidget {
  const _PacerScreen();

  @override
  State<_PacerScreen> createState() => _PacerScreenState();
}

class _PacerScreenState extends State<_PacerScreen> {
  final _label = ValueNotifier<String>('Breathe in');

  static const _labels = {
    BreathPhase.inhale: 'Breathe in',
    BreathPhase.holdIn: 'Hold',
    BreathPhase.exhale: 'Breathe out',
    BreathPhase.holdOut: 'Rest',
  };

  void _onPhase(BreathPhase phase) {
    final next = _labels[phase]!;
    if (_label.value != next) {
      _label.value = next;
      HapticFeedback.lightImpact(); // Phase cue, no visual coupling.
    }
  }

  @override
  void dispose() {
    _label.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      mainAxisSize: MainAxisSize.min,
      children: [
        const BreathingPacer(),
        const SizedBox(height: 24),
        ValueListenableBuilder(
          valueListenable: _label,
          builder: (context, value, child) => AnimatedSwitcher(
            duration: const Duration(milliseconds: 300),
            child: Text(
              value,
              key: ValueKey(value),
              style: Theme.of(context).textTheme.headlineSmall,
            ),
          ),
        ),
      ],
    );
  }
}

Wire _onPhase by adding a controller listener inside BreathingPacer (expose the current phase through a callback) — the pattern above keeps the 60fps painting path completely separate from the text updates. This separation also makes it easy to respect accessibility: check MediaQuery.disableAnimations and, when it is true, freeze the pacer and present a simple countdown instead of motion. (For more on building inclusive Flutter experiences, see my accessibility guide.)

Add haptic and audio cues

Haptics make phase changes unmistakable even when the user closes their eyes, which is exactly how breathing exercises are used. HapticFeedback.lightImpact() at each transition is enough — heavy vibration feels alarming, not calming. A quick guard keeps it from firing when the app is backgrounded:

import 'package:flutter/services.dart';

void cuePhaseChange() {
  // Safe to call from a controller listener; no-ops on unsupported devices.
  HapticFeedback.lightImpact();
}

For audio cues, Inhalo plays guided meditation tracks and ambient sounds alongside the animation. The cleanest approach is to pre-download any audio so it plays offline — I cover that pattern in detail in Flutter Offline Audio: Cache and Play MP3s. A short chime at each phase change, started a few hundred milliseconds early, lands exactly when the visual transitions.

Keep it at 60fps

A breathing pacer runs for minutes at a time, so small inefficiencies compound into heat, battery drain, and dropped frames. The rules I follow in production:

RepaintBoundary around the CustomPaint. Mentioned twice because it is that important — it isolates per-frame repaints from the rest of the widget tree.
No allocations in paint(). Precompute your Paint objects as fields on the painter, not inside paint. The sample above creates them per frame for readability; in production, hoist them.
Const constructors everywhere else. Anything that does not depend on the animation value should be const so Flutter skips rebuilding it.
Prefer Curves transforms over manual math. Curves.easeInOut.transform(progress) is well-tested and cheap; hand-rolled easing usually introduces frame-to-frame discontinuities.
Test on a real low-end device. DevTools' performance overlay shows raster-thread time, which is where CustomPainter work lands. If raster time creeps above ~8ms per frame at 60fps, simplify the blur or the number of drawn layers.
Handle backgrounding. Listen to AppLifecycleState and pause the controller when the app is inactive; resume on return. An animation silently running in the background drains battery for nothing.

Verify the rhythm

A pacer that looks right but times wrong is worse than no pacer. A simple widget test pins the phase math so future refactors cannot break the timing:

import 'package:flutter_test/flutter_test.dart';

void main() {
  test('box breathing phases split the cycle evenly', () {
    const cycle = BreathCycle.box;
    expect(cycle.total, const Duration(seconds: 16));
    for (final (_, duration) in cycle.phases) {
      expect(duration, const Duration(seconds: 4));
    }
  });
}

For the full experience, I also validate with a stopwatch test on the controller: advance the test clock and assert that the phase derived at 25%, 50%, and 75% of the cycle matches inhale, hold, and exhale boundaries. Timing is the feature here — test it like one.

Takeaways

A great breathing pacer is not a fancy animation — it is a precise timer wearing a calm visual. Model the cycle as phase data, drive everything from one controller, paint the circle in an isolated layer, and keep text, haptics, and audio on their own update paths. Get those separations right and the pacer feels effortless: the user breathes with the circle and never thinks about the code at all.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Flutter Web in 2026: Why WebAssembly Changes Everything

Muhammad Uzair — Thu, 22 Oct 2026 03:32:31 +0000

The State of Flutter Web in 2026: Why WebAssembly (WASM) Changes Everything

For years, Flutter Web was criticized for large payload sizes, janky scrolling, and poor SEO. It was great for dashboards and internal tools, but if you wanted a highly optimized, consumer-facing website, you reached for React or Next.js.

In 2026, that narrative has completely flipped, and it’s entirely thanks to the maturity of WebAssembly (WASM) and Dart's wasm-gc\ (Garbage Collection) integration.

The Problem with the Old Flutter Web

Historically, Flutter Web compiled your Dart code into JavaScript. The browser then had to parse, compile, and execute massive JavaScript bundles, while a CanvasKit (WebGL) engine handled the drawing. This dual overhead resulted in noticeably slower Time-to-Interactive (TTI) metrics.

Enter WebAssembly (WASM)

WASM isn't a new language—it's a highly optimized binary instruction format that runs in the browser at near-native speeds.

By compiling Dart directly to WASM, we bypass the JavaScript engine almost entirely. The browser executes the binary directly, resulting in:

Instant Startup Times: WASM binaries load and execute exponentially faster than parsed JS.
Buttery Smooth 120fps: Dropped frames on complex web animations are virtually eliminated.
Smaller Payloads: The compiled binary is significantly more compact than minified JavaScript.

Why 2026 is the Tipping Point

While WASM support was introduced earlier, 2026 is the year it became the default, stable target for Flutter Web. Browsers universally support wasm-gc\ now, meaning Dart doesn't have to bundle its own heavy garbage collector into the web payload anymore—it hooks directly into the browser's native memory management.

If you haven't looked at Flutter Web since 2023, you owe it to yourself to compile a project using flutter build web --wasm\. The speed difference isn't just noticeable; it's revolutionary.

Originally published at uzairxdev.online

Flutter Offline Audio: Cache and Play MP3s

Muhammad Uzair — Thu, 22 Oct 2026 03:31:25 +0000

Offline audio is the difference between an app users trust and an app they abandon. When I built Punj Surah — my Quran companion app with high-quality MP3 audio recitation, a page-by-page reading view, Qibla Finder, Salah tracker, and Tasbeeh counter — one requirement was non-negotiable: once a recitation is downloaded, it must play anywhere. In a mosque basement, on a flight, in a village with one bar of signal. That offline guarantee helped the app reach 10,000+ downloads while holding a 99.9% crash-free rate.

This guide walks through the exact pattern I use in production: download MP3s into the app's documents directory, play them from local files with just_audio, cap the cache so it never eats the user's storage, and degrade gracefully when the network dies mid-download. Every snippet below is written for the current stable Flutter and Dart.

Cache first, stream second

The architecture is three layers. A download manager fetches each file exactly once and stores it in the app's documents directory. A cache layer applies a least-recently-used eviction policy that deletes the least-recently-played files when the cache grows past a limit you set. A player layer always plays local files and only touches the network when a file is missing.

Keep a small manifest — a JSON file or a few key-value entries — mapping each track ID to its filename and a flag for whether it is fully downloaded. Never play a partially downloaded file: if the app is killed mid-download, the manifest will tell you the file is incomplete and it must be fetched again.

Step 1: Download MP3s with progress

Download to a temporary .part\ file first, then rename it when the download completes. That way a crash or a killed app can never leave a half-written file that the player mistakes for a complete one.

\`dart
import 'dart:io';

import 'package:http/http.dart' as http;
import 'package:path_provider/path_provider.dart';

Future downloadTrack(
String url,
String fileName, {
void Function(double progress)? onProgress,
}) async {
final dir = await getApplicationDocumentsDirectory();
final file = File('\${dir.path}/audio/$fileName');

if (await file.exists()) return file; // Already cached.

final tmp = File('\${file.path}.part');
final request = http.Request('GET', Uri.parse(url));
final response = await http.Client().send(request);

final total = response.contentLength ?? 0;
final sink = tmp.openWrite();
int received = 0;

try {
await for (final chunk in response.stream) {
sink.add(chunk);
received += chunk.length;
if (total > 0) onProgress?.call(received / total);
}
await sink.flush();
await sink.close();
return await tmp.rename(file.path); // Atomic: complete file only.
} catch (_) {
await sink.close();
if (await tmp.exists()) await tmp.delete();
rethrow;
}
}
`\

Two details matter here. First, contentLength\ can be absent for chunked responses, so guard the progress math. Second, always delete the .part\ file on failure — stale partial files are the classic cause of a player that "plays" silence.

Step 2: Play from the local cache

just_audio\ can play a local file path directly, which gives you instant start, seeking, and zero buffering:

\`dart
import 'package:just_audio/just_audio.dart';

final player = AudioPlayer();

Future playCachedTrack(File file) async {
await player.stop();
await player.setFilePath(file.path);
await player.play();
}

@override
void dispose() {
player.dispose();
super.dispose();
}
`\

Always dispose the player. An AudioPlayer\ holds native audio resources, and leaking one per screen visit is a slow memory drain that the profiler makes obvious but users notice first.

Step 3: Fall back to streaming when a file is not cached

The caller decides the strategy: try the cache, and if the file is missing, download it in the background and play it; if the download itself fails with a SocketException\, stream the URL directly as a last resort.

\`dart
Future playTrack(String trackId, String url, String fileName) async {
final file = File('\${(await getApplicationDocumentsDirectory()).path}/audio/$fileName');

if (await file.exists()) {
await playCachedTrack(file);
return;
}

try {
final downloaded = await downloadTrack(url, fileName);
await playCachedTrack(downloaded);
} on SocketException {
// No network at all: stream it instead, it may still buffer.
await player.setUrl(url);
await player.play();
}
}
`\

This is the graceful-degradation ladder that keeps an audio app usable on terrible networks: cached file, then fresh download, then raw streaming.

Step 4: Keep the cache under a storage budget

Cached audio accumulates fast — a single Surah recitation can be 15 MB. Pick a budget (say 500 MB), and evict the least-recently-played files whenever you cross it. Run the trim after every completed download.

\`dart
class _CacheEntry {
final File file;
final int size;
final DateTime modified;
_CacheEntry({required this.file, required this.size, required this.modified});
}

Future trimCache(Directory audioDir, {required int maxBytes}) async {
final entries = <_CacheEntry>[];
int total = 0;

await for (final entity in audioDir.list()) {
if (entity is! File || entity.path.endsWith('.part')) continue;
final stat = await entity.stat();
entries.add(_CacheEntry(file: entity, size: stat.size, modified: stat.modified));
total += stat.size;
}

if (total <= maxBytes) return;

entries.sort((a, b) => a.modified.compareTo(b.modified)); // Oldest first.
for (final entry in entries) {
await entry.file.delete();
total -= entry.size;
if (total <= maxBytes) break;
}
}
`\

Note the two guards: .part\ files are skipped so an in-progress download never gets evicted mid-write, and the currently playing file keeps working because just_audio already has it open — deleting the file handle path on Android does not kill the active playback session.

Step 5: A seek bar that feels instant

With local files, seeking is nearly free. Wire the player's streams into a slider so the UI stays in sync:

\`dart
StreamBuilder(
stream: player.positionStream,
builder: (context, snapshot) {
final position = snapshot.data ?? Duration.zero;
final duration = player.duration ?? Duration.zero;
final max = duration.inMilliseconds.toDouble().clamp(1.0, double.infinity);

return Slider(
  value: position.inMilliseconds.toDouble().clamp(0.0, max),
  max: max,
  onChanged: (value) {
    player.seek(Duration(milliseconds: value.round()));
  },
);

},
);
`\

Clamping the value protects against the brief moment when position\ arrives before duration\ — without it, the slider throws a range error on the very first frame.

Checklist before you ship

Set the audio session. Use the audio_session\ package to configure the platform session (for example, ducking on Android and the silent-switch behavior on iOS). Players that skip this get one-star reviews from users whose recitation stops when a notification arrives.
Background playback needs manifest entries. On iOS, add audio\ to UIBackgroundModes\ in Info.plist\; on Android, use a foreground service with the mediaPlayback\ type for Android 14+. Without them, playback stops the moment the screen locks.
Do not request media permissions you do not need. Reading the user's own music library on Android 13+ needs READ_MEDIA_AUDIO\, but files your app downloaded into its own documents directory need no permission at all.
Test the kill-during-download case. Force-quit the app mid-download, reopen it, and confirm the track re-downloads instead of playing silence. Your manifest flag is what makes this work.
Profile on a low-end device. Local playback is cheap, but a 20 MB file decoded while the UI also renders a waveform animation can still jank on older phones. Check it with the DevTools performance view.

Offline audio is one of those features users never praise and always notice when it is missing. Build the cache layer once, and every audio app you ship afterward — recitations, podcasts, language lessons — gets it for free.

If you are building an audio feature and want it done right the first time, get in touch and let's talk about your project.

Originally published at uzairxdev.online

Automating Flutter Workflows: Why CI/CD Is Non-Negotiable

Muhammad Uzair — Wed, 21 Oct 2026 03:00:26 +0000

Automating Flutter Workflows: Why CI/CD is Non-Negotiable in 2026

If you are still running flutter build apk\ or flutter build ipa\ on your local machine to distribute builds, you are losing hours of valuable engineering time every week.

In 2026, the complexity of mobile apps demands a robust Continuous Integration and Continuous Deployment (CI/CD) pipeline. It is no longer a luxury reserved for enterprise teams; it is a fundamental requirement for any serious mobile product.

The Problem with Local Builds

Local builds are inherently flaky. Your local environment might have a specific version of Xcode, a cached dependency, or a unique environment variable that your colleague doesn't have. This leads to the infamous "It works on my machine" syndrome. Moreover, generating a release build ties up your machine, completely breaking your flow state.

1. Automated Testing (CI)

The foundation of a good pipeline is automated testing. Every time a developer pushes code or opens a Pull Request, the CI server should immediately:

Run flutter analyze\ to catch linting errors.
Run flutter test\ to ensure no business logic is broken.
Verify that formatting is consistent.

If any of these fail, the PR cannot be merged. This acts as a quality gate, keeping your main branch pristine.

2. Automated Distribution (CD)

Once code is merged into the main branch, your CD pipeline takes over. Tools like Codemagic, Bitrise, or GitHub Actions (paired with Fastlane) can automatically:

Increment the build number.
Sign the application with the correct certificates.
Build the Android App Bundle (AAB) and iOS Archive (IPA).
Upload the builds to TestFlight and Google Play Console.
Notify the team in Slack or Discord.

3. Choosing the Right Tool

For Flutter developers, there are several fantastic options:

Codemagic: Purpose-built for Flutter. It is incredibly easy to set up and requires minimal configuration.
Bitrise: Excellent visual workflow editor and a massive library of integration steps.
GitHub Actions: The most flexible option, especially if your codebase is already on GitHub. It requires more manual setup (often writing bash scripts or configuring Fastlane) but offers unmatched customization.

Conclusion

Setting up CI/CD might take a few hours upfront, but it pays dividends forever. It removes the stress of deployment, eliminates human error in the release process, and allows you to focus on what actually matters: building a great product.

Originally published at uzairxdev.online

Build a Health Vitals Tracker in Flutter

Muhammad Uzair — Wed, 21 Oct 2026 02:59:21 +0000

Most health apps fail for the same boring reason: logging a reading takes too long. A blood pressure entry that needs five screens, three keyboards, and a login form will be abandoned by day three — and a tracker nobody opens is a tracker that never helps.

When I built Track Health & Vitals Monitor, the design target was brutal and specific: log blood pressure, heart rate, and key vitals in seconds, one-handed, straight from the home screen. Families needed separate profiles for each member so every reading stays organized, trends had to be obvious at a glance, and daily reminders had to make sure readings never get missed. This guide distills the Flutter patterns that made that work: the entry flow, the data model, offline-first storage, trend charts, and reminders that survive Android.

Design the entry flow for speed

The home screen of a vitals app should be one thing: a fast path to a saved reading. Two number fields (systolic and diastolic), an optional heart rate field, and a save button — that is the whole flow. Everything else (notes, editing history, settings) lives behind it.

Three details make or break the speed:

Number keyboards only. Set keyboardType\ to TextInputType.number\ and add FilteringTextInputFormatter.digitsOnly\ so users never fight a full keyboard for a number.
Move focus automatically. Set textInputAction: TextInputAction.next\ on the first field and done\ on the last, so the keyboard itself walks the user through the flow.
Pre-fill everything. The timestamp defaults to now, and the values default to the last reading. Most days the user changes nothing except tapping save.

\`dart
class VitalsInputRow extends StatelessWidget {
final TextEditingController systolic;
final TextEditingController diastolic;

const VitalsInputRow({required this.systolic, required this.diastolic});

@override
Widget build(BuildContext context) {
return Row(
children: [
Expanded(
child: TextField(
controller: systolic,
autofocus: true,
keyboardType: TextInputType.number,
textInputAction: TextInputAction.next,
inputFormatters: [FilteringTextInputFormatter.digitsOnly],
decoration: const InputDecoration(labelText: 'Systolic'),
),
),
const SizedBox(width: 12),
Expanded(
child: TextField(
controller: diastolic,
keyboardType: TextInputType.number,
textInputAction: TextInputAction.done,
inputFormatters: [FilteringTextInputFormatter.digitsOnly],
decoration: const InputDecoration(labelText: 'Diastolic'),
),
),
],
);
}
}
`\

Two large fields side by side fit a thumb, and with autofocus\ the keyboard is already up when the screen opens. That alone cuts the flow to two taps and a save.

Model readings per profile

A family tracker is really a multi-user app wearing a single-user disguise. The cleanest way to keep it sane: every reading carries a profileId\, and the app holds one active profile in state. Every query filters by the active profile, so each member gets an independent history without any data ever leaking across.

\`dart
class VitalsReading {
final String id;
final String profileId;
final DateTime takenAt;
final int systolic;
final int diastolic;
final int? heartRate;

const VitalsReading({
required this.id,
required this.profileId,
required this.takenAt,
required this.systolic,
required this.diastolic,
this.heartRate,
});

Map toJson() => {
'id': id,
'profileId': profileId,
'takenAt': takenAt.toIso8601String(),
'systolic': systolic,
'diastolic': diastolic,
'heartRate': heartRate,
};

factory VitalsReading.fromJson(Map json) => VitalsReading(
id: json['id'] as String,
profileId: json['profileId'] as String,
takenAt: DateTime.parse(json['takenAt'] as String),
systolic: json['systolic'] as int,
diastolic: json['diastolic'] as int,
heartRate: json['heartRate'] as int?,
);
}
`\

Keep the active profile in a simple state object (Provider works fine here — one ChangeNotifier\ with activeProfileId\ and a setter). When the user switches profiles, the reading list, charts, and reminders all re-filter from the same source of truth. If you are separating network code from widgets the way a clean data layer demands, the repository pattern keeps API calls out of widgets and makes this filtering trivial to test.

Store locally first, sync later

A health reading must never depend on the network. Hive is the right default here: writes are synchronous-feeling, reads are instant, and there is no schema migration ceremony for a simple model. Firebase stays optional — a sync layer you add later, not a gate in front of saving.

\`dart
Future saveReading(VitalsReading reading) async {
final box = await Hive.openBox('readings');
await box.put(reading.id, reading.toJson());
}

Future> readingsFor(String profileId) async {
final box = await Hive.openBox('readings');
final all = box.values
.map((e) => VitalsReading.fromJson(Map.from(e as Map)))
.where((r) => r.profileId == profileId)
.toList();
all.sort((a, b) => b.takenAt.compareTo(a.takenAt));
return all;
}
`\

Open the box once at startup rather than per call in production — repeated openBox\ calls are cheap but sloppy. Storing plain JSON maps instead of generated Hive type adapters keeps the model readable and lets a future sync layer serialize the same payload straight to Firestore. Health data staying on the device by default is also the right privacy posture: nothing leaves the phone unless the user opts into sync.

Make trends obvious at a glance

A list of numbers does not change behavior; a picture does. The trend view should answer one question in under a second: "am I getting better or worse?" That means a 7-day rolling average line, not a scatter of raw points, with background bands for the standard blood-pressure zones (normal, elevated, high) so a reading's meaning is visible without interpreting numbers.

The fl_chart\ package handles this well. Feed it one FlSpot\ per day with the rolling average, and shade the area under the line:

\dart LineChart( LineChartData( minY: 60, maxY: 180, lineBarsData: [ LineChartBarData( spots: weeklyAverages, // List<FlSpot>: x = day index, y = avg systolic isCurved: true, barWidth: 3, dotData: const FlDotData(show: false), belowBarData: BarAreaData( show: true, gradient: LinearGradient( colors: [Colors.red.withOpacity(0.25), Colors.transparent], ), ), ), ], titlesData: const FlTitlesData( leftTitles: AxisTitles(sideTitles: SideTitles(showTitles: true)), bottomTitles: AxisTitles(sideTitles: SideTitles(showTitles: true)), ), gridData: const FlGridData(show: true), ), ) \\

Compute the rolling averages in Dart before touching the widget — a small pure function over the sorted readings list that is easy to unit test. Keep the chart dumb: it renders spots, nothing more. A second line for diastolic uses the same pattern with a different color, and the zone bands become simple horizontal reference lines via ExtraLinesData\.

Reminders that survive Android

Daily reminders are the feature that keeps the streak alive, and they are also the easiest to get wrong on Android. Doze mode delays inexact alarms, so a reminder scheduled with a naive timer arrives whenever the OS feels like it. Use flutter_local_notifications\ with exact scheduling and match the time-of-day component so it repeats daily:

\dart await flutterLocalNotificationsPlugin.zonedSchedule( 0, 'Time for your reading', 'Log today\u2019s vitals in under 10 seconds.', _nextInstanceOfToday(9, 0), const NotificationDetails( android: AndroidNotificationDetails( 'vitals_daily', 'Daily reminders', importance: Importance.high, ), ), androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle, matchDateTimeComponents: DateTimeComponents.time, ); \\

Two things this needs to actually work on modern Android: the SCHEDULE_EXACT_ALARM\ permission declared and requested at runtime, and timezone initialization (tz.initializeTimeZones()\) before computing -nextInstanceOfToday\. The full exact-alarm setup — permission flows, the canScheduleExactAlarms\ check, and the Android 14+ behavior changes — is covered in depth in Flutter Exact Alarm Scheduling on Android, which walks through the same machinery this reminder relies on.

Validate like a clinician is watching

Health apps earn trust by refusing bad data politely. Validate every entry before it touches storage:

Physiological ranges. Systolic 70–300, diastolic 40–200, heart rate 30–220. Reject anything outside with a specific message ("Systolic must be between 70 and 300"), not a generic "invalid input".
No future timestamps. A reading dated tomorrow corrupts every trend chart. Clamp to now.
Confirm destructive actions. Deleting a reading needs an explicit confirm dialog — health history is not the place for swipe-to-delete without a safety net.
Systolic above diastolic. If the user swaps the fields, say so immediately instead of storing nonsense.

None of this is glamorous, but it is what separates an app people trust with their health from a demo.

Ship the boring parts well

A vitals tracker is not a showcase for exotic architecture. It is a showcase for discipline: a sub-10-second entry flow, one reading model with a profileId\, local-first storage, charts that answer "am I improving?" at a glance, and reminders that fire on time. Get those right and the app does its job quietly, every day — which is exactly what a health app should do.

If you are building a health or data-entry heavy Flutter app and want the logging flow, offline storage, and reminder scheduling done right the first time, get in touch and let's talk about your project.

Originally published at uzairxdev.online