Coder Legion - Recent posts tagged flutter

Flutter’s UI Architecture Explained for Beginners: Widgets, Elements, and Render Objects

Sat, 10 Oct 2026 20:38:02 +0000

Flutter Basics

Flutter Basics Overview
Prerequisites
The Widget Tree in Flutter
- Key Components of the Widget Tree
  - Main Function
  - Cupertino vs Material Widgets
- Flutter Rendering and UI Architecture
Difference between Stateless & Stateful widgets
Stateful Widget Lifecycle
- How setState() triggers UI rebuilds
Text Changer App Example
Summary

Flutter Basics Overview

Prerequisites:

Basic understanding of dart programming language
Flutter installed on your system
Android studio and Xcode(for Mac)

What is Flutter?

Flutter is a declarative, reactive open-source, multiplatform UI toolkit developed by Google. It allows developers to build natively compiled applications for mobile, web, and desktop from a single codebase. Flutter uses the Dart programming language and provides a rich set of pre-designed widgets to create beautiful and responsive user interfaces.

Flutter developers often hear terms like everything in Flutter is a widget, and this is because Flutter's UI is built using a hierarchy of widgets called the widget tree. Widgets are the building blocks of a Flutter app's user interface, and they can be combined to create complex UIs.

Dart

Dart is an open-source client-optimized programming language developed by Google that compiles to the native machine code of the target platform without runtime overhead leading to fast startup times and predictable performance. It is designed to be easy to learn and use, with a syntax that is similar to other popular programming languages like Java, JavaScript, and C#. Dart is the primary language used for developing Flutter applications.

Declarative UI / Reactive Programming

Flutter uses a declarative approach: you simply describe what the UI should look like for a given state (like color: blue). The framework then uses reactive programming to automatically react to state changes and rebuild the UI efficiently.

Multiplatform Development

Multiplatform development refers to the ability to create applications that can run on multiple platforms using a single codebase. Flutter enables developers to build applications for iOS, Android, web, and desktop platforms using the same codebase, which significantly reduces development time and effort.

What exactly is State?

Now you may wonder what state is. In simple terms, state refers to the data or information that determines the behavior and appearance of a widget at a given time. For example, the state of a button widget may include whether it is enabled or disabled, its color, and its text label.

In Flutter, state can be managed in various ways, including using built-in stateful widgets, provider packages, or other state management solutions. The choice of state management technique depends on the complexity of the application and the specific requirements of the project.

Now, as the interface of an application is built using widgets, those widgets are combined to create a widget tree. The widget tree is a hierarchical structure that represents the relationship between different widgets in the application. Each widget in the tree can have its own state, which can be updated and managed independently.

When the state of a widget changes, Flutter automatically rebuilds the affected parts of the widget tree to reflect the new state. This is done using a process called rebuilding, which involves creating a new instance of the widget with the updated state and replacing the old instance in the widget tree.

This process is efficient and allows for smooth and responsive user interfaces, as only the affected parts of the widget tree are rebuilt, rather than the entire tree which facilitates the hot reload feature in Flutter.

The widget tree is structured in a hierarchical manner, with each widget having a parent-child relationship with other widgets. The root of the tree is typically the MaterialApp or CupertinoApp widget, which serves as the entry point for the application. From there, other widgets are added as children of the root widget, forming a tree-like structure.

Main Function

The main function is the entry point of a Flutter application. It is where the execution of the app begins. In the main function, we typically call the runApp function, which takes a widget as an argument and inflates it to fill the screen.

Cupertino vs Material Widgets

Flutter provides two sets of pre-designed widgets: Material widgets and Cupertino widgets. Material widgets are designed to follow the Material Design guidelines developed by Google, while Cupertino widgets are designed to follow the iOS design guidelines developed by Apple. Depending on the target platform, developers can choose to use either set of widgets or a combination of both to create a consistent user experience across different platforms.

Flutter Rendering and UI Architecture

Flutter initially renders the UI using skia, a 2D graphics rendering engine. Skia is responsible for drawing the UI elements on the screen, and it provides a high-performance rendering pipeline that allows for smooth animations and transitions. But with the release of Flutter 3.0, Flutter introduced a new rendering engine called Impeller, which is designed to provide even better performance and visual fidelity. Impeller is a next-generation rendering engine that leverages modern graphics APIs like Metal on iOS and Vulkan on Android to deliver high-quality graphics and smooth animations.

Flutter's rendering and UI architecture is primarily built upon three main trees:

Widget Tree: The widget tree is the hierarchical structure of widgets that make up the user interface of a Flutter application. Each widget in the tree represents a specific UI element, such as a button, text field, or image. The widget tree is responsible for defining the layout and appearance of the UI.
Element Tree: The element tree is a lower-level representation of the widget tree. It consists of Element objects, which are created for each widget in the widget tree (Like a copy of the widget). The element tree is responsible for managing the lifecycle of widgets, including their creation, updating, and destruction. It also handles the communication between widgets and their associated state.
Render Tree (or RenderObject Tree):: The render tree is the final representation of the UI that is used for painting on the screen. It consists of RenderObject instances, which are responsible for the actual layout and painting of the UI elements. The render tree is built from the element tree and is optimized for performance and efficiency during the rendering process.

In summary,

The Widget is the structural description of the UI (Blueprint). it is the immutable description of what the UI should look like and provides configuration and hierarchy.
The Element is the mutable brain that manages the lifecycle of the widget and holds the state. It acts as a bridge between the widget and the render object. Determines what needs to be updated when the widget's state changes.
The Render Object is the Builder/Artist that is responsible for the actual layout and painting(drawing pixels) of the UI on the screen. It takes care of measuring, positioning, and drawing the visual representation of the widget.

The interaction between these three trees is crucial for the efficient rendering of the UI in Flutter. When a widget's state changes, Flutter updates the widget tree, which in turn updates the element tree and the render tree. This process ensures that only the affected parts of the UI are redrawn, leading to smooth and responsive user interfaces.

Difference between Stateless & Stateful widgets

The widget tree can be broadly categorized into two types of widgets based on their ability to manage state:

Stateless Widgets: These are widgets that do not maintain any state. Once built, their appearance and behavior are fixed and cannot change. Stateless widgets are typically used for static content that does not require user interaction or dynamic updates.
Stateful Widgets: These are widgets that can maintain state over time. They can rebuild themselves when their state changes, allowing for dynamic and interactive user interfaces. Stateful widgets are used for content that needs to change in response to user input or other events.

Other kinds of widgets include:

Inherited Widgets: These widgets allow data to be passed down the widget tree efficiently. They are used for sharing data between widgets without the need for explicit passing through constructors. examples include Theme and MediaQuery.

Stateful widgets have a lifecycle that consists of several stages, each represented by specific methods that can be overridden to perform actions at different points in the widget's life. The key lifecycle methods of a stateful widget are:

createState(): This method is called when the stateful widget is first created. It returns an instance of the associated State class, which holds the mutable state for the widget.
initState(): This method is called after the stateful widget is created and before the widget is built for the first time. It is used to perform any initializations that are required for the state.
didChangeDependencies(): Called immediately after initState(), but before the widget is built for the first time. It's also called when an InheritedWidget that this State depends on changes. It is often a good place to initialize data that depends on the BuildContext (like Theme.of(context)), as initState() may be too early.
build(): This method is called whenever the widget needs to be rebuilt, either due to a change in state or when the parent widget rebuilds. It returns the widget tree that represents the UI of the stateful widget.
setState(): (Triggered by you) This method is used to notify the framework that the state of the widget has changed and that it needs to be rebuilt.

The image above illustrates how calling setState() leads to the invocation of the build() method, when the user hits enter after inputing a city name in the TextField. it fetches new weather data and updates the UI accordingly.
didUpdateWidget(): This method is called whenever the parent widget rebuilds and passes new configuration data down to the child stateful widget. It allows the state to respond to changes in the widget's properties by passing the updated stateful widget as a parameter.
deactivate(): This method is called when the State object is removed from the Element tree, but before it is disposed. This might happen temporarily if the widget is moved to a different part of the tree.
dispose(): This is called after deactivate() when the State object is permanently removed from the tree. This is the last method called, and it's essential to use it for cleanup (e.g., canceling timers, unsubscribing from streams, disposing of controllers) to prevent memory leaks.

The image above shows the dispose() method being called when the StatefulWidget which is a TextFormField controller is removed from the widget tree after a user submits a form. This ensures that resources are properly released and prevents memory leaks.

How setState() triggers UI rebuilds

The setState() method is a crucial part of the stateful widget lifecycle in Flutter. When you call setState(), you are indicating to the Flutter framework that the internal state of the widget has changed and that the widget needs to be rebuilt to reflect those changes in the UI.
When setState() is called, the following sequence of events occurs:

The callback function passed to setState() is executed, allowing you to update the state variables of the widget.
After the state has been updated, Flutter marks the widget as needing to be rebuilt.
The framework schedules a rebuild of the widget tree, starting from the stateful widget that called setState().
During the rebuild process, the build() method of the stateful widget is called, which constructs a new widget tree based on the updated state.
The framework compares the new widget tree with the previous one and determines which parts of the UI need to be updated.
Finally, the framework updates the UI by redrawing only the affected parts of the widget tree, resulting in a smooth and efficient update to the user interface.

Text Changer App Example

Click Here to view the Text Changer App Explanation.

Summary

In summary, the three trees in Flutter's rendering architecture work together to create a responsive and efficient UI. The widget tree defines the structure and appearance of the UI, the element tree manages the lifecycle and state of the widgets, and the render tree is responsible for the actual painting of the UI on the screen. Understanding these trees and their interactions is key to building performant Flutter applications.

Bento Scan AI Document Scanner

Thu, 01 Oct 2026 01:33:38 +0000

A white-label scanner that works offline first

Bento Scan is a production-ready document scanner for Android and iOS built with Flutter. The mobile app handles the capture workflow on-device: it detects page boundaries, triggers automatic capture, corrects perspective, flattens curved pages, applies filters and exports multi-page PDFs.

Many scanner apps depend on proprietary cloud services for basic processing. Bento Scan keeps the essential scan pipeline offline, then pairs it with an optional self-hosted backend for teams that want synchronization, search and administration under their own control.

Included capabilities

Offline document-edge detection and automatic capture
Perspective correction and AI page flattening
Multi-page scanning, filters and PDF export
OCR in more than 100 languages
Searchable PDFs, folders, tags and full-text search
Quotas, administration statistics and S3-compatible storage
Responsive web dashboard
Editable Flutter, FastAPI and deployment source code

The package can be rebranded for a commercial scanner, an internal capture tool or a document workflow product. Developers receive the mobile app, backend, web dashboard, deployment configuration and training utilities rather than a closed SDK.

See device requirements, screenshots and the complete package on Codester.

Meet Folio: The Open-Source, Local-First Workspace for Your Notes and Ideas

Mon, 21 Sep 2026 06:07:12 +0000

If this is your first time encountering my work, I want to introduce you to a project I have been passionately building: Folio.

Folio is an open-source personal productivity and note-taking workspace. Think of it as a highly flexible workspace—similar in versatility to Notion—built with a fundamental commitment to privacy and data ownership: it is local-first. Your data lives on your device, giving you total ownership and full offline access by default.

The entire source code is available on GitHub, empowering the community to inspect, contribute, or build upon it.

️ Everything You Can Do with Folio

Folio is designed to be a complete, privacy-focused environment for organizing thoughts, managing projects, and writing:

A Modular Block Editor: Craft documents using over 31 block types, including WYSIWYG rich text, interactive Kanban boards, editable tables, Mermaid diagrams, LaTeX equations, and an Infinite Canvas for visual brainstorming.

️ Meeting Notes & Transcription: Record audio directly within a page and process offline transcriptions locally using Whisper.cpp, complete with speaker diarization.

Quill (AI Assistant) & Plan Mode: Folio includes an integrated AI assistant named Quill. With Plan Mode, Quill drafts an editable action plan before modifying your workspace, allowing you to review and approve changes first. You can run Quill completely offline using local models (Ollama or LM Studio), bring your own API keys, or connect to Folio Cloud.

Local MCP Server: Expose workspace tools directly to external Model Context Protocol (MCP) clients like Github Copilot or Cursor for advanced local AI workflows.

Encrypted Vaults & P2P Sync: Protect your vaults with a master password, Windows Hello, or Passkeys. Sync encrypted vaults across your local network (LAN) peer-to-peer without touching external servers.

️ Knowledge Graph & Task Hub: Visualize connections between your notes using a force-directed graph view, and track every action item across your workspace in a unified Task Hub.

The 0.7.8 Milestone: Moving to a Custom Java Backend

While Folio is 100% functional offline, its optional cloud layer just underwent its biggest architectural shift yet.

As a backend developer specializing in Java and microservices, keeping Folio Cloud tied to Firebase became too restrictive for scaling. I decided to rebuild the entire cloud infrastructure from scratch: Folio Cloud has officially left Firebase and now runs on a custom Java 21 & Spring Boot backend.

This rewrite brings faster, reactive synchronization, lower CPU overhead, and total architectural control. In tandem, version 0.7.8 introduces a new file-tree vault engine with granular page history and strict anti-wipe safety guards to keep your notes safe.

Open Source & Supporting the Project

Folio is, and will always remain, free and open-source for local use.

To help cover server costs and support continuous full-time development, I offer an optional Folio Cloud subscription. Subscribing unlocks convenience features such as:

Multi-device encrypted cloud sync.

Hosted AI for Quill.

Encrypted cloud backups & expanded storage.

Public web publishing and real-time collaboration.

If you love the mission of local-first, open-source software, subscribing to Folio Cloud is the best way to support the roadmap!

Get Started

Folio is available for Windows, macOS, Linux, Android, iOS, and Web.

Website & Downloads: minealexgames.com/en/folio
GitHub Repository: Check out the source code, star the project, or contribute on GitHub.

(Remember to make an external backup of your vaults before upgrading to 0.7.8, and enjoy the new update!)

Tracking From the Grave: How Apps Follow Your Location After They're Killed

Tue, 08 Sep 2026 06:06:38 +0000

Before you start: there are three ways to build this

This blog covers all three, so pick the one that fits you before you follow the code.

The plugin way (flutter_background_geolocation), covered in "Step by step: build this yourself in Flutter". Fastest to ship and the best battery behaviour. It is a paid plugin from Transistorsoft, free in debug builds, but a release build needs a license key tied to your package id or bundle id.

The Dart-only way (geolocator plus your own foreground service), covered in the teardown section. Free, simpler, but weaker at surviving a force quit.

The native way (your own Kotlin and Swift code over method and event channels), also in the teardown section. Free, most control, most work.

So if you are building your own tracking from scratch, options 2 and 3 need no license key at all. The key is only for option 1.

The one idea to hold in your head
A background location app does NOT stay running the whole time. It cannot. Both Android and iOS will kill it. So instead of staying alive, it hands a few smart triggers to the phone's operating system and then lets itself die. The OS keeps those triggers and wakes the app back up at exactly the right second. Accuracy does not come from running 24x7. It comes from being clever about WHEN to wake up and switch on GPS.

Read that twice. Once you accept that the app is supposed to die, everything else makes sense. Beginners assume the app is secretly running in a corner forever. It is not. It is mostly dead, and that is the whole trick.

Why you cannot just keep the app running

If any app could run GPS forever in the background, your battery would be gone by lunch and every shady app would be following you around. So phone makers put a hard stop on it. Two things happen:

The OS kills background apps. When your phone needs memory, or you swipe the app away, or it just decides your app has been idle too long, the operating system shuts your app down. You do not get a vote.
GPS is expensive. The GPS chip is one of the hungriest things on the phone. Keep it on continuously and the battery melts.

So the plugin works WITH these rules instead of fighting them. It assumes it will be killed and plans for resurrection. Think of it like leaving a note with a friend saying "wake me when I cross this line." You go to sleep. The friend (the OS) holds the note and shakes you awake at the right moment.

The heart of it: be lazy to be accurate

Here is the clever bit that makes both battery life AND accuracy possible at once. It sounds backwards, but stay with me.

When you are standing still, GPS is turned OFF. The app drops an invisible circle around your current spot (this circle is called a geofence) and goes to sleep. The phone uses almost no battery. The app process can even die. Nobody cares, because nothing is moving.

The moment you start moving and step outside that circle, the OS notices and wakes the app up. Now the app turns on high-accuracy GPS and records every point while you travel. When you stop again, it drops a fresh circle, switches GPS off, and goes back to sleep.

It is accurate BECAUSE it is lazy. It does not waste GPS while you sit at your desk, which keeps the battery happy, which means the OS does not feel the urge to kill it, which means it is alive and precise the moment you actually move. Battery saving and accuracy are the same feature here, not a trade off.

Now the part everyone asks about: what happens when the app dies

This is where Android and iOS go in completely different directions. One at a time.

Android: a permanent worker plus notes held by the system

While your app is alive in the background, Android keeps it tracking using a foreground service. You have seen it: that notification saying "App is using your location" which you cannot swipe away. It is the deal you make with Android. Show the user a notification, and in exchange you get to keep running and reading GPS in the background. No notification, no permission. That is the rule on modern Android.

This foreground service is set to restart itself if Android kills it for memory reasons. So far so good. But what about when your app process is FULLY dead? This is the magic part.

The plugin registers two kinds of "notes" with Google Play Services, which is a separate system app that does NOT die when your app dies:

Geofence triggers. "Hey Play Services, when this phone crosses this circle, wake my app."
Activity Recognition triggers. "Hey Play Services, when this phone goes from still to walking or driving, wake my app."

When one of those conditions happens, Play Services reaches into your dead app and cold-starts a tiny piece of it called a BroadcastReceiver. Your app gets a few seconds of life, the engine wakes up, grabs the location, and does its job. Your Flutter and Dart code can be completely shut down and this still works. That is headless mode: the native engine runs without the rest of your app being awake.

And if the phone reboots? The plugin also registers a "on boot" note, so when the phone turns back on, it re-arms everything automatically.

iOS: the system relaunches your app for you

iOS is much stricter. You genuinely cannot run forever in the background, end of story. But Apple gives location tracking one special superpower: a couple of services are allowed to relaunch your app even after it has been force-quit, and even after a reboot. Almost nothing else on iOS can do this.

The two services are:

Region Monitoring, which is iOS's version of geofences. Cross a monitored circle and iOS relaunches your app in the background.
Significant Location Change (SLC), which fires when you move a meaningful distance, detected cheaply using cell towers and wifi instead of GPS.

When one of these fires, iOS relaunches your app in the background, hands it a flag saying "you woke up because of location," gives you a short moment to act, then suspends you again. Important detail: plain continuous GPS does NOT survive a force-quit on iOS by itself. So the plugin uses regions and SLC as the wake-up layer, and only switches on precise GPS once it is already awake and senses real movement.

This is also why, on iOS, the very first point after a kill can feel a little delayed. The app had to be relaunched by an event before it could even start tracking.

"Terminated" is not just one thing

Beginners treat "closed" as a single state. It is actually a ladder, and behaviour changes at each rung.

State	What it means	Does tracking survive?
Backgrounded, still alive	You pressed home, app is in memory	Yes, easily (foreground service on Android, background mode on iOS)
Killed by the OS for memory	Phone needed RAM and shut your app	Yes (Android restarts it and geofence/motion triggers revive it, iOS relaunches via SLC/regions)
Force-quit by the user	You swiped it out of recents	Android can be harsher and may delay, but Play Services triggers still cold-start a receiver. iOS still relaunches via regions and SLC
After reboot	Phone was turned off and on	Yes (Android re-arms with a boot receiver, iOS regions and SLC persist)

So when someone asks "does it work after the app is closed," the honest answer is "yes, but the mechanism that revives it depends on exactly how it was closed."

The last piece: never lose a single point

Accuracy is not only about capturing locations, it is about not dropping them. What if the phone is in a tunnel, or has no signal, or your server is down for a minute?

The plugin writes every location into a small local database (SQLite) on the phone FIRST, before doing anything else. A separate part of the system then uploads those saved points to your server. If the upload fails because there is no internet, the points wait in the database and go up later, in the correct order, once the connection is back.

Golden rule to copy for any tracking app: record locally first, sync as a totally separate concern. A dead zone should never punch a hole in your track.

The full picture in one diagram

That loop is the entire product. Sleep cheaply, wake on a real signal, track precisely while moving, save everything, repeat.

Step by step: build this yourself in Flutter

This section is a complete walk through using the flutter_background_geolocation package, since that is the battle-tested way to get all of the above without writing the native code yourself. Follow it top to bottom.

Step 0: understand what you are signing up for

This package is free to fully test in DEBUG builds. For a RELEASE build on Android and for the App Store on iOS, you need a paid license key tied to your package id or bundle id. So you build and test for free, and only pay when you ship. Plan for that.

Step 1: add the package

In your pubspec.yaml:

dependencies:
  flutter_background_geolocation: ^4.16.0
  # the package also needs its companion, added automatically in most cases

Then run flutter pub get. Always check pub.dev for the latest version number rather than copying mine.

Step 2: Android setup

2a. Permissions in AndroidManifest.xml

Inside android/app/src/main/AndroidManifest.xml, above the <application> tag, declare what you need. Each line has a reason:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<!-- lets you track while the app is in the background -->
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
<!-- the permanent notification that keeps you alive -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />
<!-- detect still vs walking vs driving -->
<uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />
<!-- re-arm tracking after the phone reboots -->
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

2b. License key (only needed for release)

Inside the <application> tag, add your license key as a meta-data line:

<meta-data
  android:name="com.transistorsoft.locationmanager.license"
  android:value="YOUR_LICENSE_KEY" />

2c. Gradle repository

The package pulls its native engine from Maven. Recent versions wire this up for you, but if a build fails saying it cannot find tslocationmanager, check the package's install docs for the repository line to add in android/build.gradle or settings.gradle.

Step 3: iOS setup

3a. Info.plist text

In ios/Runner/Info.plist, add the permission descriptions. iOS shows these sentences to the user, so write them in plain language explaining WHY:

<key>NSLocationWhenInUseUsageDescription</key>
<string>We use your location to record your visits while you use the app.</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>We record your location in the background so your route is not lost.</string>
<key>NSMotionUsageDescription</key>
<string>We use motion data to save battery while tracking.</string>

3b. Background modes

Still in Info.plist, switch on the background abilities:

<key>UIBackgroundModes</key>
<array>
  <string>location</string>
  <string>fetch</string>
</array>

You can also enable these by ticking "Location updates" and "Background fetch" under Signing and Capabilities in Xcode.

Step 4: ask for permission the right way

Do not ask for background location on the very first screen. Both stores dislike it and users reject it. Ask for "while in use" first, explain why in your own UI, then request "always." The plugin requests what it needs when you call ready, but a gentle explanation screen before that hugely improves acceptance.

Step 5: configure and start tracking (the Dart part)

Here is a minimal but complete setup. Read the comments, they explain each choice.

import 'package:flutter_background_geolocation/flutter_background_geolocation.dart' as bg;

Future<void> initTracking() async {
  // 1. Listen for each new location
  bg.BackgroundGeolocation.onLocation((bg.Location location) {
    print('New location: ${location.coords.latitude}, ${location.coords.longitude}');
  });

  // 2. Listen for the still <-> moving switch
  bg.BackgroundGeolocation.onMotionChange((bg.Location location) {
    print('Moving state changed. isMoving = ${location.isMoving}');
  });

  // 3. Configure the engine
  await bg.BackgroundGeolocation.ready(bg.Config(
    desiredAccuracy: bg.Config.DESIRED_ACCURACY_HIGH, // best GPS while moving
    distanceFilter: 10,            // record a point every 10 meters of movement
    stopOnTerminate: false,        // keep tracking after the app is killed
    startOnBoot: true,             // re-arm after the phone reboots
    enableHeadless: true,          // allow waking with no UI alive
    foregroundService: true,       // the persistent notification on Android
    url: 'https://your-server.com/locations', // where to upload points
    autoSync: true,                // upload automatically
    batchSync: false,              // send points one by one (or batch them)
  )).then((bg.State state) {
    if (!state.enabled) {
      // 4. Actually start it
      bg.BackgroundGeolocation.start();
    }
  });
}

The two settings that make it survive being killed are stopOnTerminate: false and startOnBoot: true. The one that makes it work with no UI is enableHeadless: true.

Step 6: handle the headless wake-up (Android)

When the OS wakes your dead app, your normal Dart code is not running. You register a separate tiny function that the engine can call in that headless moment. Put this at the very top level of your main.dart, outside any class.

// must be a top-level function
@pragma('vm:entry-point')
void headlessTask(bg.HeadlessEvent headlessEvent) async {
  switch (headlessEvent.name) {
    case bg.Event.LOCATION:
      bg.Location location = headlessEvent.event;
      print('Headless location: $location');
      break;
    case bg.Event.MOTIONCHANGE:
      print('Headless motionchange');
      break;
  }
}

void main() {
  runApp(const MyApp());
  // register the headless handler
  bg.BackgroundGeolocation.registerHeadlessTask(headlessTask);
}

The @pragma('vm:entry-point') line is not optional. It stops Flutter from throwing this function away during release optimization, because the engine has to find it by name when the app is otherwise dead.

Step 7: test it properly

Testing with the app open proves nothing. Real tests:

Start tracking, then swipe the app out of recents. Walk around the block. Check your server received points.
Reboot the phone without opening the app. Move. Confirm tracking re-armed itself.
Sit still for ten minutes and watch the battery. It should barely move. If GPS is stuck on, your config is wrong.
Turn on airplane mode, move around, then turn internet back on. Confirm the queued points upload in order.

Step 8: survive the cheap-phone problem (very important in India)

Many budget Android phones (Xiaomi, Oppo, Vivo, Realme and others) run aggressive "battery saver" software that kills background apps no matter what the rules say. This is the number one reason tracking apps fail in the real world here. Defenses:

Guide the user to disable battery optimization for your app. The plugin has a helper, bg.DeviceSettings, that can open the right settings screen.
For company-owned devices, look into Android Device Owner or a managed enrollment. When your app is the device owner, the OEM battery killers no longer apply, and force-quit and optimization simply stop being a problem. For a controlled set of devices, this is the most reliable answer by far.
Show a clear one-time screen explaining that they must allow background location and turn off battery optimization, or tracking will be unreliable.

Quick mental checklist

The app is meant to die. Plan for resurrection, do not fight it.
Sleep with GPS off behind a geofence. Wake on geofence exit or motion.
Android revives via a foreground service plus Play Services geofence and activity triggers, re-armed on boot.
iOS revives via Region Monitoring and Significant Location Change, which can relaunch even after force-quit.
Save every point to local SQLite first, upload as a separate retrying step.
stopOnTerminate: false, startOnBoot: true, enableHeadless: true are the three settings that matter most.
On cheap Android phones, defeat the OEM battery killer or your tracking dies silently.

When does the foreground service actually show up? (clearing the confusion)

This confuses almost everyone, so let us nail it down. Remember one thing: that notification IS the foreground service. Visible means the service is running. Gone means it has stopped. There is no hidden third state.

When it starts

The foreground service starts only when the app is actively tracking, which means when the person is in the MOVING state. The flow looks like this:

So the notification is not meant to be visible all the time. It comes and goes depending on whether the person is moving. This is deliberate, not a bug. When the person sits still, GPS and the service both shut down, the phone sleeps, and the battery is safe.

If it stops (notification disappears), is that a problem?

No. The notification disappearing does NOT mean tracking has died. It only means the app went to sleep in stationary mode. The OS still holds the two triggers, the geofence and the motion trigger. The moment the person moves, it wakes the app, the service restarts, and the notification comes back.

Notification state	What it actually means
Visible	The app is actively tracking with GPS (moving)
Gone	The app is asleep (stationary), waiting for a trigger. Tracking is NOT dead

So if the notification vanishes during testing, do not panic. Move around and it will reappear. Tracking was alive the whole time, just sleeping cheaply.

If you want the notification to stay visible always

If you would rather the user always sees that tracking is on, the plugin can be configured so the foreground service runs continuously for as long as tracking is enabled. The notification then stays permanent. The trade off is more battery usage. So you have two modes:

Battery friendly: notification appears only while moving. Best battery life.
Always visible: notification stays up the whole time tracking is enabled. More transparent and more reliable on aggressive phones, but uses more battery.

One caution: on newer Android (12 and above) Google restricts starting a foreground service from the background, so the exact come-and-go behavior can vary a little by Android version and plugin version. The plugin handles this internally, but always test on your real target phones to confirm the notification behaves the way you expect.

A different way real apps do this (a teardown story)

Everything above uses flutter_background_geolocation, which is the gold standard. But many tracking apps in the wild do NOT use it. They build a simpler version by hand, and it is worth understanding because you will meet it far more often than you expect.

There are two ways to build that simpler version. One stays entirely in Dart and leans on the geolocator plugin. The other drops into native Android and iOS code and talks to Flutter through channels, which gives you far more control and lets you read signals the plugin never surfaces. Let us walk through both.

Way 1: The Dart-only approach (the geolocator plugin)

Instead of the geofence-sleep engine, these apps use the basic geolocator package to read positions and wrap it in their own foreground service that stays on the whole time tracking is enabled. No sleeping behind a geofence. The service starts, holds a wake lock, and streams positions on a distance filter until tracking is turned off.

Why build it this way? It is simple, it has no license cost, and often you do not need the app to survive a swipe-away for days. You just need reliable tracking during an active shift, which this handles fine.

The trade-offs you must know:

It burns more battery, because GPS and the service run continuously instead of sleeping behind a geofence.
Surviving a hard force-quit is weaker. These apps lean on stopWithTask=false, a boot receiver and a battery-optimisation exemption, but they do not have the Play Services geofence resurrection trick. So a fully killed process can simply stop until the user opens the app again.
It is much easier to reason about and debug, which is a real advantage when you are shipping fast.

Tip
If your tracking only needs to be reliable during a known active window, like a shift, a delivery, or a site visit, the simple always-on service is often the pragmatic choice. Save the full geofence engine for true all-day passive tracking where battery life is the main worry.

Way 2: The native approach with method and event channels

The Dart-only way is easy, but it only gives you what the plugin chooses to expose. For full control you drop into native code: location logic in Kotlin on Android and Swift on iOS, your own foreground service, results sent up to Flutter through a channel. Serious tracking apps usually land here, because the richest signals live in the native layer, not in Dart.

Method channel versus event channel, in one line each

A MethodChannel is a request and a response. Dart calls something like startTracking, native runs it and replies once. It is made for commands: start, stop, or ask a one-time question.
An EventChannel is a continuous stream. Native keeps pushing values, and Dart keeps listening. This is the perfect fit for a live location feed, because points arrive again and again.

The signals you can grab natively, and why they matter

In native code, each update can carry much more than latitude and longitude. These extra fields make a track trustworthy and easy to debug:

Speed in metres per second, straight from the GPS fix. Catches impossible jumps and tells walking from driving.
isMocked, the real spoof flag, read right at the source instead of through a wrapper.
Device info like model and manufacturer, so you can spot the cheap OEM phones that love to kill background apps.
Battery level and charging state, so your server understands that a dead battery, not a bug, is why the points stopped arriving.

Bundling all of these into every event turns a plain coordinate into a record you can actually trust.

Android native (Kotlin)

Inside your own foreground service, you use the FusedLocationProviderClient. On each update, you build a map with the extra signals and push it into the EventChannel sink.

// inside your location EventChannel StreamHandler
private val locationCallback = object : LocationCallback() {
    override fun onLocationResult(result: LocationResult) {
        val location = result.lastLocation ?: return

        // read the spoof flag at the source
        val isMock = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
            location.isMock              // API 31 and above
        } else {
            @Suppress("DEPRECATION")
            location.isFromMockProvider  // older devices
        }

        // battery level right now
        val bm = context.getSystemService(Context.BATTERY_SERVICE) as BatteryManager
        val batteryLevel = bm.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY)

        val data = mapOf(
            "latitude" to location.latitude,
            "longitude" to location.longitude,
            "speed" to location.speed,          // metres per second
            "accuracy" to location.accuracy,
            "isMocked" to isMock,
            "deviceModel" to Build.MODEL,
            "manufacturer" to Build.MANUFACTURER,
            "batteryLevel" to batteryLevel,
            "timestamp" to location.time
        )

        // send this event up to Dart
        eventSink?.success(data)
    }
}

iOS native (Swift)

On iOS you use CLLocationManager. The mock story is different here. Plain iOS does not hand you a mock provider flag the way Android does, but from iOS 15 you can check whether a fix was produced by a simulator through the location's sourceInformation.

func locationManager(_ manager: CLLocationManager,
                     didUpdateLocations locations: [CLLocation]) {
    guard let location = locations.last else { return }

    // spoof hint on iOS 15 and above
    var isMocked = false
    if #available(iOS 15.0, *) {
        isMocked = location.sourceInformation?.isSimulatedBySoftware ?? false
    }

    // battery level right now
    UIDevice.current.isBatteryMonitoringEnabled = true
    let batteryLevel = Int(UIDevice.current.batteryLevel * 100)

    let data: [String: Any] = [
        "latitude": location.coordinate.latitude,
        "longitude": location.coordinate.longitude,
        "speed": location.speed,             // metres per second, -1 if unknown
        "accuracy": location.horizontalAccuracy,
        "isMocked": isMocked,
        "deviceModel": UIDevice.current.model,
        "batteryLevel": batteryLevel,
        "timestamp": location.timestamp.timeIntervalSince1970
    ]

    // send this event up to Dart
    eventSink?(data)
}

The Dart side, just listening

On the Flutter side you do almost nothing. You open the same two channels and listen. All the heavy lifting already happened natively, so Dart only reads a clean event.

class NativeTracking {
  static const _commands = MethodChannel('app/tracking/commands');
  static const _events = EventChannel('app/tracking/events');

  Future<void> start() => _commands.invokeMethod('startTracking');
  Future<void> stop() => _commands.invokeMethod('stopTracking');

  Stream<Map<String, dynamic>> get locationStream =>
      _events.receiveBroadcastStream().map((e) => Map<String, dynamic>.from(e));
}

// usage
final tracking = NativeTracking();
tracking.locationStream.listen((data) {
  if (data['isMocked'] == true) {
    // reject, native already flagged this point as fake
    return;
  }
  print('lat ${data['latitude']}, speed ${data['speed']}, '
      'battery ${data['batteryLevel']}, device ${data['deviceModel']}');
});

Tip
Do the mock check, the speed sanity check, and the device and battery reads in native code, not in Dart. That is where the real signals live, and it means the event that reaches Dart is already clean and trustworthy. The Dart layer should just consume a validated event, not try to police it after the fact.

Which way should you pick?

You want	Go with
Fastest to ship, standard needs	Way 1, the geolocator plugin in pure Dart
Full control, richer signals, your own foreground service and spoof logic	Way 2, native code through method and event channels

Most apps start on Way 1 and move to Way 2 only when they hit a wall, like needing a signal the plugin does not expose, or tighter control over the service and the spoof checks.

The piece the earlier sections skipped: stopping fake GPS

Everything above assumed the location you receive is honest. Often it is not. Someone can install a fake-GPS app and punch in from home while the map shows the office. If location decides money in your app, like attendance, travel allowance, or delivery proof, you have to defend against this or the whole feature is meaningless.

Every Android location object carries a simple flag that tells you whether it came from a mock provider. In the geolocator package, each Position exposes isMocked. Checking it is the cheapest first line of defence you can add.

import 'package:geolocator/geolocator.dart';

Future<void> readLocation() async {
  Position position = await Geolocator.getCurrentPosition(
    desiredAccuracy: LocationAccuracy.high,
  );

  // Android marks positions that came from a fake GPS app
  if (position.isMocked) {
    // do not trust this point, flag the user and reject it
    print('Mocked location detected, rejecting this point');
    return;
  }

  print('Trusted location: ${position.latitude}, ${position.longitude}');
}

Real apps go further and refuse to run at all on devices that make spoofing easy:

Rooted or jailbroken devices are blocked, because root makes faking location trivial and hard to detect.
Emulators are blocked, since an emulator can report any coordinate you type into it.
Developer Mode being switched on is flagged, because most mock-location apps need it enabled.

Tip
isMocked is necessary but not enough on its own. A rooted device can hide the mock flag entirely. That is why serious apps combine the flag with root and emulator checks, and add a server-side sanity check too, like rejecting impossible speed between two points or a location that jumps across cities in a few seconds. Trust a position only after it clears all of these gates.

Live tracking versus store and forward

Earlier we said: save every point to SQLite first, then sync separately. That is right for route logging, where you want a complete gap-free history.

Some apps have a different need. An admin wants to watch a live map and see people move right now, and the store-and-forward queue is too slow for that. These apps push each position straight into a realtime database, usually Firebase Realtime Database, so the dashboard updates the instant a point arrives.

Approach	Best for	Latency	Offline behaviour
Store and forward (local SQLite queue)	Route history, reports, payroll proof	Seconds to minutes	Points wait safely and sync later in order
Live push (realtime database)	An admin watching a live map	Almost instant	Needs a fallback, a purely live point can be lost with no connection

The two are not enemies. A robust app does both: push live for the dashboard, and still keep a local SQLite copy so a dead zone never punches a hole in the history. Live for the eyes, local for the record.

What to copy and what to avoid

Good ideas worth stealing from apps that ship this successfully:

Check isMocked on every point and reject mocked ones.
Block, or at least flag, rooted and emulator devices for any money-critical tracking.
Consider a live push to a realtime database when someone genuinely needs to watch a map, but keep the local queue as well.
Use stopWithTask=false plus a boot receiver so a swipe-away or a reboot does not silently end a shift.

Mistakes worth avoiding, all of which are common in shipped apps:

Shipping cleartext HTTP (usesCleartextTraffic=true) so that location data travels unencrypted. Always send coordinates over HTTPS.
Leaving a local test URL, like an http://192.168.x.x endpoint, hardcoded in the release build.
Hardcoding unrestricted map API keys in the app. Restrict every key by package name and signing certificate, and by the specific API it is allowed to call, or someone will run up your billing.
Trusting the phone's location blindly with no spoof defence at all.

The one line to remember from this teardown
The fancy plugin is not the only way, and it is not always the right way. Pick your architecture from the need. Simple always-on service for a bounded shift, full geofence engine for all-day passive tracking. And whatever you build, if location decides money, never trust a coordinate until it has proven it is not faked.

The third wake-up style: timer-driven periodic sampling

So far you have seen two ways an app gets woken up: the geofence and motion approach, where the OS wakes you because you moved, and the continuous foreground service, where you stay awake the whole time. There is a third style, and it answers a specific question: "the phone is in deep sleep, but I still want a location every few minutes." This is timer-driven or periodic sampling, built from two Android pieces working together, SCHEDULE_EXACT_ALARM and WAKE_LOCK.

First, why a normal timer does not work

Your instinct might be a simple loop or a Timer that fires every five minutes and grabs a location. In the background this quietly fails, and it is worth understanding why.

When the phone goes idle with the screen off, it enters a power saving state called Doze, and the CPU is put to sleep. While that happens, your app's own timers, Future.delayed calls, and background loops are all frozen. They do not fire until something wakes the CPU, and your app process can even be killed. So a plain "every five minutes" timer is simply not running when the phone is asleep, which is exactly when you needed it.

The key realisation
Anything that must fire while the phone sleeps cannot live inside your app's own timers. It has to be handed to the operating system, because the OS does not sleep the way your app does. That is what AlarmManager is for.

Piece one: SCHEDULE_EXACT_ALARM, the part that wakes the phone

AlarmManager is a system service that runs a small piece of your code at a chosen time, whether your app is alive or dead. Think of it as leaving an alarm clock with the OS instead of trying to stay awake yourself. There are two flavours, and the difference matters:

A normal (inexact) alarm gets batched and delayed by Doze to save battery. A five minute alarm might actually fire twenty minutes later. For location sampling this is useless.
An exact alarm, using setExactAndAllowWhileIdle, is allowed to fire on time even in Doze.

To use exact alarms on Android 12 and above (API 31), you must declare the SCHEDULE_EXACT_ALARM permission. Without it the system only gives you the inexact kind. This is exactly why tracking apps request it.

A catch worth knowing
An exact alarm is one-shot. It fires once and forgets. So every time it fires, you must schedule the next one yourself, or the cycle stops after a single tick. The pattern is: wake up, do the work, then set the next alarm before going back to sleep.

Piece two: WAKE_LOCK, the part that keeps the phone awake long enough

Here is the subtle part. When your alarm fires, the system gives your BroadcastReceiver only a very short window to run, roughly ten seconds.

But getting a GPS fix is slow and asynchronous. A cold fix can take five to thirty seconds. If you request a location and then let your receiver return, the CPU goes back to sleep before the fix arrives, so your callback never completes or your upload dies halfway.

The fix is to grab a partial wake lock the moment your receiver runs. It keeps the CPU awake while the screen stays off, using very little battery. You hold it while you request the location, wait for the fix, save it, and upload it. Then you release it so the phone can sleep again.

One line to remember
The alarm wakes the phone at the right second. The wake lock keeps it awake just long enough to finish the job. One is about when, the other is about how long.

The full loop

What it looks like in Kotlin

// 1. Schedule the next wake-up
fun scheduleNextWakeup(context: Context) {
    val am = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
    val intent = Intent(context, LocationAlarmReceiver::class.java)
    val pi = PendingIntent.getBroadcast(
        context, 0, intent,
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
    )
    val triggerAt = System.currentTimeMillis() + 5 * 60 * 1000 // 5 minutes later

    // exact, and allowed to fire even in Doze (needs SCHEDULE_EXACT_ALARM)
    am.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerAt, pi)
}

// 2. The receiver: stay awake, get a location, re-arm, then sleep
class LocationAlarmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val pm = context.getSystemService(Context.POWER_SERVICE) as PowerManager
        val wakeLock = pm.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK, "app:LocationWakeLock"
        )
        wakeLock.acquire(60_000) // safety timeout, hold at most 60 seconds

        val fused = LocationServices.getFusedLocationProviderClient(context)
        fused.getCurrentLocation(Priority.PRIORITY_HIGH_ACCURACY, null)
            .addOnSuccessListener { location ->
                saveAndUpload(location) // your own save plus upload
            }
            .addOnCompleteListener {
                scheduleNextWakeup(context)          // re-arm the next alarm
                if (wakeLock.isHeld) wakeLock.release() // let the phone sleep
            }
    }
}

Two caveats you must plan for

Doze rate-limits even exact alarms. In deep Doze, setExactAndAllowWhileIdle reliably fires only about once every nine minutes. So you cannot sample every thirty seconds this way, and for continuous tracking you still need a foreground service. Real apps often combine both: a foreground service while the person is active, alarm-based sampling for check-ins while the phone is idle.
Battery optimisation can block it. Requesting REQUEST_IGNORE_BATTERY_OPTIMIZATIONS and guiding the user to allow it makes these alarms fire far more reliably, especially on the aggressive cheap OEM phones we keep coming back to.

So where does this fit among the three styles?

Wake-up style	What triggers a location	Best for
Geofence and motion (the plugin way)	You physically move	All-day passive tracking with great battery life
Continuous foreground service	Nothing, it never sleeps	Dense, precise tracking during an active shift
Timer-driven periodic sampling	A clock, every few minutes	Occasional check-ins while the phone is idle, cheaper than staying awake

The takeaway
Exact alarms plus a wake lock are the tool when you want a location on a schedule rather than on movement. The alarm handles when to wake, the wake lock handles staying awake long enough to finish, and you re-arm the alarm on every tick. Just remember Doze will not let you sample faster than roughly every nine minutes, so pair it with a foreground service whenever you need something tighter.

Automate Unused Asset Cleanup in Flutter

Thu, 03 Sep 2026 09:23:34 +0000

Let's be realistic, every Flutter project accumulates dead weight over time, big images not deleted, a logo variant from a rebrand, a placeholder image a dev forgot to delete.
Individually they're small but they add up to real APK/IPA size.

I built cleanbev to fix that locally, and I now a new upgrade is available a GitHub Action so the check runs automatically on every pull request, instead of running it localy.

What cleanbev actually does

cleanbev is a command-line tool for Dart and Flutter projects. It:

Reads your pubspec.yaml to find every declared asset
Scans your Dart code for references to each one
Reports anything declared but never referenced
Optionally deletes what you confirm

Locally, it's interactive:

dart pub global activate cleanbev
dart pub global run cleanbev --assets-path assets/images

✓ Asset assets/images/logo_white_bg.png is not used in the project. Do you want to delete it? · no
Asset assets/images/logo_white_bg.png has not been deleted.

✓ Asset assets/images/download_image-car.jpeg is not used in the project. Do you want to delete it? · yes
Asset assets/images/download_image-car.jpeg has been deleted.

It's also available as an MCP server, so editor-integrated agents (VS Code, Cursor, Visual Studio) can call it directly while you're working.

The gap: someone could forgot to cleanup some assets before pushing

A local CLI tool only helps if someone remembers to run it but in practice, unused-asset cleanup falls into the same bucket as "update the changelog" or "check for outdated dependencies" but under
deadline pressure this could be skipped.
The only way it reliably happens is if CI enforces it.

That's what the new Cleanbev Asset Check action does.

Using it

Add this into any Flutter repo's .github/workflows/:

name: Check Unused Assets

on:
  pull_request:
    branches: ["main"]

jobs:
  cleanbev-asset-check:
    name: Cleanbev Asset Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Cleanbev
        uses: koukibadr/cleanbev-action@v1
        with:
          assets-path: "assets"
          blocking: "true"

Inputs

Input	Description	Default
`assets-path`	Path to the assets directory to scan	`assets`
`blocking`	Fail the job when unused assets are found	`false`

Two ways to run it

blocking: "false" (default) — reports what it finds, cleans it up, never fails the build. Good for a low-friction "just keep things tidy" job on a schedule or on pushes to main.
blocking: "true" — turns it into a real PR gate. If a PR introduces an asset that's never referenced, the check fails until it's cleaned up or actually used. This is what I run on pull requests.

Try it

Action: github.com/marketplace/actions/cleanbev-asset-check
CLI on pub.dev: pub.dev/packages/cleanbev
MCP server on PyPI: pypi.org/project/cleanbev-mcp

It's a small tool solving a small, annoying problem. If you try it on a real project and hit a bug please send me your issues and PRs.

Flutter vs React Native for MVP: Which One Should You Actually Choose?

Wed, 02 Sep 2026 21:53:13 +0000

You've validated the idea. You've got a rough spec, maybe a Figma file, and a deadline that's tighter than you'd like. Now you're stuck on a decision that feels bigger than it should: Flutter or React Native.

We get why this question causes so much hesitation. Picking wrong doesn't just mean a slower app; it can mean rebuilding parts of it six months in, paying more for developers than you budgeted, or watching your MVP timeline slip because the framework didn't fit your team's skill set. For a founder trying to get to market before the runway runs out, that's not a small mistake.

This isn't a "Flutter is better" or "React Native is better" article. It's a breakdown of what actually determines the right choice for an MVP- specifically, not for a five-year-old enterprise app, not for a game studio, but for a small team trying to ship something real, get it in front of users, and learn fast.

The Real Question Isn't "Which Framework Is Better"

It's "which framework fits your constraints." For an MVP, three constraints matter more than anything else:

How fast can you build and test
What talent you can actually hire or already have
How much native-feeling polish your app needs on day one

Framework benchmarks and GitHub star counts don't answer any of those. Your team, your budget, and your app's complexity do. If you want a broader look at how Flutter and React Native compare across performance, cost, platform support, and scalability, our React Native vs Flutter comparison covers those differences in more detail.

Flutter: What It's Actually Good At

Flutter, built by Google, compiles to native code and uses its own rendering pipeline rather than relying entirely on native OS UI components. On iOS and Android API 29+, Flutter's Impeller rendering engine is the default, giving the framework a rendering pipeline designed for predictable performance.

Consistent UI across platforms. A button looks and behaves the same on iOS and Android because Flutter draws it itself. For MVPs with a strong design system or a founder who cares about pixel-level consistency, this is a real advantage.

Strong performance for animation-heavy apps. If your MVP leans on custom transitions, gestures, or visual polish, Flutter tends to handle that more predictably than React Native, since it isn't bridging through native UI components.

Single codebase, genuinely. Flutter's "write once" promise holds up better in practice than it used to. Widget-based architecture means less platform-specific patching for most standard app types.

Ecosystem familiarity matters when hiring. Developer surveys such as the Stack Overflow Developer Survey provide a useful snapshot of the technologies developers use and want to learn, which can help put your team's existing skills and hiring options into context.

The trade-off: Flutter apps are written in Dart, a language most web developers haven't touched. If your existing team knows JavaScript or TypeScript, you're either training them or hiring fresh, and Dart talent is a smaller pool than JavaScript talent in most markets.

React Native: What It's Actually Good At

React Native, maintained by Meta, uses JavaScript or TypeScript, and its New Architecture includes Fabric for rendering and direct communication between JavaScript and native code through JSI. That gives it a different set of strengths:

Access to a broader pool of JavaScript/TypeScript talent. If you already have web developers who know React, the learning curve to React Native is short. For early-stage teams that can't afford long onboarding, this matters more than most technical comparisons.

Faster initial builds for standard app patterns. Forms, lists, navigation, and API-driven screens the bread and butter of most MVPs are well-trodden territory in React Native, with a large ecosystem of libraries already built for these use cases.

Easier path to a companion web app. If there's any chance your MVP will need a web version later, React skills transfer more directly than Dart skills.

The trade-off: React Native can still require additional optimization for highly animated, graphics-heavy, or gesture-intensive experiences, particularly when your app relies heavily on platform-specific functionality or complex native integrations. For a straightforward CRUD-style MVP, this is less likely to be a deciding factor.

Where Founders Get This Decision Wrong

We see the same few mistakes repeatedly when teams choose a framework for an MVP:

Choosing based on long-term scale instead of MVP speed. An MVP's job is to test a hypothesis, not to be future-proof for a million users. Optimizing for hypothetical scale before you have real usage data solves a problem you might never have.

Ignoring existing team skills. If you already have a React or JavaScript-heavy team and choose Flutter because a benchmark article said it's faster, you've added a learning curve to an already tight timeline. That cost is real and often larger than the performance gap you were chasing. Research on Flutter and React Native developer trends also highlights differences in developer satisfaction and job-market demand, reinforcing why your team's existing skills should factor into the decision.

Treating this as a permanent decision. Your MVP doesn't need to solve every future technical requirement on day one. But switching frameworks later still means significant redevelopment, so the goal should be to make a sensible decision now, not assume you'll simply rebuild when the product grows.

Skipping a technical spike. Before committing, building a tiny proof-of-concept one core screen, one core interaction in both frameworks for a day or two can surface friction that no comparison article will predict for your specific use case.

A Practical Way to Decide

If you're still unsure, this is roughly how we'd narrow it down:

If your team already knows JavaScript/React, and your MVP is mostly forms, lists, and API calls, lean React Native.
If your MVP depends heavily on custom animation, a highly branded UI, or gesture-based interaction, lean Flutter.
If you're hiring contractors and want the largest available talent pool, lean React Native.
If highly consistent rendering and custom visual interactions matter more than developer availability, lean Flutter.

Neither framework is a wrong answer for most MVPs. The wrong answer is picking one for reasons that don't match your actual constraints.

For teams weighing this decision alongside broader technical planning, work through this exact evaluation with founders before writing a single line of code, mapping the framework choice to the team, budget, and timeline rather than a generic recommendation.

The Bottom Line

Neither Flutter nor React Native is objectively better; they’re better for different situations. The right choice for your MVP comes down to what your team already knows, how visually complex your app needs to be, and how much you’re prioritizing speed versus long-term flexibility.

If you’re still weighing the trade-offs, the most useful next step isn’t reading another comparison. Build a small proof-of-concept in whichever framework you’re leaning toward and see how it actually feels to work with for a day. That will tell you more than any benchmark.

FAQs

1. Is Flutter or React Native faster to build an MVP with?
It depends on your team's existing skills more than the framework itself. A JavaScript-fluent team will usually move faster in React Native; a team with no strong language preference may find Flutter's tooling and hot reload just as fast, sometimes faster for UI-heavy screens.

2. Which framework is cheaper for an MVP?
Cost tracks talent availability more than the technology itself. React Native developers are generally more abundant, which can mean more competitive rates, particularly for freelance or contract hires.

3. Can I switch frameworks later if I start with the wrong one?
Yes, though it means a rebuild of the front end, not a simple migration. Many teams treat the MVP framework choice as temporary by design, planning to revisit it once the product has real user data and funding.

4. Does Flutter or React Native perform better?
For most standard MVP app types forms, dashboards, content feeds the performance difference is negligible to end users. The gap widens for animation-heavy or graphics-intensive apps, where Flutter tends to have an edge.

flutter_skin Alpha — Material 3 Tokens, Live Preview & Typography | Remote Skin

Wed, 12 Aug 2026 08:36:49 +0000

Alpha V1 is live.

→ Full Material 3 color token support
→ Live skin preview directly in the dashboard
→ Typography tokens — change your app's font remotely

No rebuild. No App Store update. Publish from the
dashboard, app updates live.

─────────────────────────────

🔗 Links

📦 Package: pub.dev/packages/flutter_skin
🖥️ Dashboard: app.fskin.dev
📖 Docs: docs.fskin.dev

─────────────────────────────

What's coming in Beta:
→ Spacing tokens
→ Border radius tokens

→ A/B testing
→ MCP server for AI-generated skins

Nostr as a backend out of the box: where it fits and where it doesn't

Tue, 14 Jul 2026 10:46:03 +0000

title: "Nostr as a backend out of the box: where it fits and where it doesn't"
published: true
description: "A hands-on review of Nostr as an out-of-the-box backend across real cases: notes, chats, feeds, communities, and organizations."
tags: nostr, decentralization, backend, Flutter
cover_image: https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/hhp9ymdzovelglq8a0m1.png

canonical_url: not needed — dev.to is the original home of this English version

TL;DR. Nostr is a ready-to-use, decentralized backend: it gives you an event model, signatures, encryption, and sync through relays. For notes, private chats, and simple feeds it covers almost everything — with no server of your own. But once you need a smart feed, roles, hierarchies, or complex moderation, the protocol hits one basic limit: only the owner of a key can change an event. After that, the extra workarounds quickly cost more than they save. Below I look at real cases: where Nostr works well, and where it is better to think about a separate backend.

Introduction

For a long time I wanted to build a simple cross-platform notes app.
The most important use case for me was storing sensitive information, such as passwords, crypto wallet addresses, and so on. Another key requirement was reliable sync between devices, in particular iOS, Android, and macOS.

But there was one big problem: for a long time I could not find a secure way to sync notes that did not depend on one specific provider.

Some time ago I happened to join a project built around the Nostr protocol — that is how I first learned about it. For that project Nostr was, to be honest, not a great fit (you will see why later in the article). But for my notes task it turned out to be an almost perfect solution.

The goal of this article is to review the good and the bad cases of using the Nostr protocol that I ran into myself. I also want to describe the tasks it is worth using for, and the tasks where you should look for other solutions.

What the Nostr protocol is and how it works

The Nostr protocol presents itself as a backend for building decentralized social networks that are hard to censor. But, as you will see below, it can be used for a wider range of tasks. That said, building a social network in the usual sense (with complex feed ranking and filtering, and good performance on complex post models) is, in my personal opinion, hard.

The Nostr protocol is a set of rules (NIPs) for talking to a decentralized network of servers (relays). You talk to them over WebSockets. Each server keeps a database of events. An event is a record with a fixed structure; the client and the relay exchange it as a JSON object with a defined schema. A user can read and publish such events from one or more relays (and to one or more relays). Each event has an id — a hash of the event itself (more precisely, a SHA-256 of a serialized set of fields: pubkey, created_at, kind, tags, and content), not just of its content. So when you get the same event from different relays, the id is used to remove duplicates. Each event also has a signature. The signature is made from the event id and the sender's private key, and the JSON event has a field with the sender's public key. So to publish an event to one or more relays you need this key pair. (To read events you do not need any keys.)

It is easy to see that a key pair can also be used for asymmetric encryption. The spec describes common ways to encrypt chat messages — for example, the current Encrypted Payloads (NIP-44), which the Private Direct Messages (NIP-17) feature is built on. There is also an older Encrypted Direct Message (NIP-04): it is officially marked as deprecated and is not recommended for public, decentralized use (it uses unauthenticated encryption and leaks metadata).

Still, it is important to understand that NIP-44 is not the only option. The protocol does not force a specific algorithm: clients are free to agree on any compatible way to encrypt content. So for practical tasks — say, if you run your own private relay or solve a specific business task — NIP-04 with plain AES, or any other scheme you like, can be a good fit.

Data model: events, `kind`, and tags

If you already know Nostr (events, kind, tags, the REQ subscription model), feel free to skip this section and go straight to the cases.

Before we get to the cases, it makes sense to look a bit closer at how an event is built — we will keep coming back to it.

Any Nostr event is JSON that looks roughly like this:

{
  "id": "1897f99...",
  "pubkey": "9c2e0a7...",
  "created_at": 1781787656,
  "kind": 1,
  "tags": [
    ["e", "737f50..."],
    ["p", "9c2e0a7..."]
  ],
  "content": "Hello, Nostr!",
  "sig": "41b737f50..."
}

The kind field is an integer that sets the rough meaning of an event, rather than a strict type. For example, kind:0 is a user profile, kind:1 is a short text note (a post), kind:7 is a reaction (a like). It is important that this is an agreement, not a strict schema: the meaning of each kind is described in its NIP, and most NIPs have draft status — so these are conventions, not a fixed standard. The relay does not validate the structure of the content: the clients that agreed with each other are fully responsible for how a kind and the event format are read. You could say a kind is something like a "table" in a normal database, but without a strict schema and without server-side validation.

Besides meaning, kind also sets how the relay stores the event. The exact behavior depends on the number range (the ranges are defined in NIP-01). In simple terms, events fall into:

regular — range 1000–9999 (also kind:1, kind:4–44); they just pile up and overwrite nothing;
replaceable — range 10000–19999 (also kind:0 for a profile, kind:3 for a contact list); the relay keeps only the newest version for a given author, and a new event replaces the old one;
addressable (also called parameterized replaceable) — range 30000–39999; the same as replaceable, but the "coordinates" for replacing also include the value of the d tag (see below). This is how updatable things with an identifier work — a long note (kind:30023), a community definition (kind:34550);
ephemeral — range 20000–29999; the relay does not have to store them at all (useful for signaling).

For addressable events the "coordinates" are the triple kind:pubkey:d, where d is the value of a special ["d", "..."] tag — a stable identifier of the thing. The a tag points to such events using the kind:pubkey:d format (we will see this below).

The tags field is an array of arrays: the first item of each inner array is the tag name, and the rest are its values (["e", "<event id>"], ["p", "<pubkey>"], and so on). Tags with single-letter names (e, p, a, g, d, …) are indexed by the relay, and you can filter queries by them — in a filter this is written as #e, #p, #g (this will be useful in the feed section).

Finally, about how events are requested. To get events, the client opens a subscription with a message like this:

["REQ", "<subscription id>", { <filter> }, { <filter> }, ...]

A filter is a JSON object with fields like authors, kinds, since, until, limit, #e, #g. The relay returns all events that match at least one filter, and keeps the subscription open — it sends new matching events as they appear, until the client closes it with a CLOSE message. We will come back to filters and their limits.

Notes

While I was building my app, I did not really think about what the word Nostr stands for. Nostr is an acronym: Notes and Other Stuff Transmitted by Relays.

So the idea of a notes app on top of this protocol was obvious. Nostr gives you sync, and it offers recommendations for strong asymmetric encryption — Encrypted Payloads (Versioned).

So Nostr is a very good fit for this task.

This is how my pet project appeared — Private Notes (Nostr): a cross-platform notes app with end-to-end encryption on the device (NIP-44), signing with secp256k1, and storage on relays the user picks. No server, no accounts — just a key pair. You can try it right now:

iOS: App Store
Web: alexeyyupopkov.github.io
Android: Install Beta
Source code: github.com/AlexeyYuPopkov/nostr_notes

The repository is open — if you find a bug or have an idea, feel free to open an Issue, I will be glad to hear from you.

Chats

Many small mobile apps have a chat feature. For most such projects the chat backend is a third-party service like Twilio, Quickblox, or a cloud database such as Firebase Realtime Database or Cloud Firestore. But this means extra costs for these subscriptions. In the second case you also need to design the database for chat data, and that means extra work and bugs. Nostr, on the other hand, gives you a ready backend that fits chats well. You can either use the many public relays that already work, or run your own on your own backend by downloading a popular implementation from GitHub.

One more thing worth mentioning is media content in chat messages. A Nostr event is always JSON with a fixed schema, and the protocol does not expect you to store binary data (images, files) inside an event. To solve this there is NIP-96 — a standard that describes HTTP File Storage: a spec for file hosts compatible with Nostr. The client uploads a file to a NIP-96 server, gets a URL, and puts it in the event content. Public NIP-96 servers exist, and in general this works.

But in practice, if a project already uses central infrastructure (AWS S3, Firebase Cloud Storage, and so on), it is simpler and safer to store media there and just put a link in the Nostr event. It is a plain approach, but for most products it is a reasonable one.

For one-on-one (one2one) chats Nostr gives you everything out of the box. But for group chats there are limits in practice, and getting around them needs extra logic.

I would point out two such problems:
1) the performance of message encryption
2) group moderation

The first one is this. To use asymmetric encryption (Encrypted Direct Message or Encrypted Payloads (Versioned)), you have to encrypt the message separately for each user. As the number of group members grows, this can hurt both performance and the overall reliability of the approach. That said, from my own experience, for groups of 20 people or fewer I did not see real performance problems. I have read that up to 100 people should also be fine. At the same time, for extra reliability I would rather use central solutions outside the Nostr protocol to encrypt message content (even though that is less secure).

The second problem is moderating the group and adding or removing members. The existing solution, Private Direct Messages, is basically a group conversation without a separate, managed group object. The group's metadata (name, and so on) is not stored as one thing; it is computed from the tags of the messages themselves, and the tags of the newest message "win". As a result, you cannot "hard" add or remove members, and in fact any member can redefine the group metadata — just by sending a new message with the tags they want. The root of the problem is in the base of the Nostr protocol: only the creator of an event can change it. So if you create an event — a chat room model — and link messages to it by a reference to the room, then only its creator can moderate that event. That means there is only one moderator. And even this solution is a bit artificial — I have not seen a NIP (a Nostr standard) for it.

There is also a solution to this problem — NIP-29. It means running your own, separate relay for group moderation (though public relay-29 servers exist too, for example wss://relay.groups.nip29.com). The relay itself checks whether a moderator is allowed to change the group state. Such a relay is responsible only for the group state, not for the users' messages, which are stored on normal relays. But this is, rather, a central solution (otherwise you lose the single source of truth and risk getting out of sync).

Overall, relay-29 is a good central solution for group chats with roles and moderation, and it really works.

Feed, posts

In my view, a social network is first of all posts, likes, comments, and reposts.

Let's try to figure out how well the Nostr protocol fits these goals and what the limits are. We already know that relays store event models and can return their JSON over WebSockets.
For clarity, here is an example of a possible post JSON:

    {

        "created_at": 1781787656,
        "id": "1897f99...",
        "kind": 1,
        "pubkey": "9c2e0a7...",
        "content": "Some text...",
        "sig": "41b737f50...",
        "tags": [
			["e", "737f50..."],
			["e", "1897f..."],
			...,
			["a", "30023:f72...:abcd"],
			["a", "30023:er34...:abcd"],
			...,
			["g", "u4pr"],
			["g", "u4pru"]	
		]
    }

All tags are optional. Let's go over the ones in the example:

e — a reference to another event by its id; used for threads, quotes, and replies
a — a reference to an addressable (replaceable) event in the kind:pubkey:d format; in the example above these are references to kind:30023 events (long posts / articles per NIP-23) by different authors
g — a geohash of the location the post is linked to; the longer the string, the more precise the coordinate (u4pr is a rough region, u4pru is a bit more precise)

Now, to understand the limits of Nostr, let's look at a few cases:
1) To show, for example, posts (usually kind:1) by specific authors (see authors) in a feed, you send a request:

["REQ", "feed-sub-1", {
  "authors": ["9c2e0a7...", "pubkey1", "pubkey2", ...],
  "kinds": [1],
  "until": 1718700000,
  "limit": 20
}]

So far so good. With until + limit it is easy to set up time-based pagination here, and it will work reliably.

2) Now let's make it harder. Say we need to build a feed that shows posts by specific authors OR posts by users with a nearby location:

["REQ", "feed-sub-2", {
  "authors": ["9c2e0a7...", "pubkey1", "pubkey2", ...],
  "kinds": [1],
  "until": 1718700000,
  "limit": 20
},
{
  "kinds": [1],
  "#g": ["u4pr"],
  "until": 1718700000,
  "limit": 20
}]

And here a problem shows up right away. Inside one filter object all conditions work as AND — that is, authors + kinds + until must all match for one event. But to get OR between "posts by the authors we want" and "posts with the geohash we want", you have to use two separate filters in an array. The relay then returns the union of both results.
And this is exactly where reliable until+limit pagination breaks. Each filter in the array is limited on its own: in a typical implementation the relay applies limit: 20 to each of the two filters separately (the exact behavior when merging results from several filters depends on the relay implementation), and then mixes the results. So imagine the first filter (by authors) collected 20 newer posts, and the second (by geohash) also collected 20, but older ones. The final output — after sorting by time and cutting to a common limit on the client — may take only part of one source and miss part of the other. On the next request the new until is computed from the oldest post you received. For one of the filters this until will be wrong: it will either cover already shown posts again, or skip part of the events that never reached the client. You get holes in the feed, and they add up with each new load.

A working but more time-consuming way is pagination through a time window (since + until) that grows step by step — it widens if too few events fall into it. This approach has its own downsides: an unpredictable number of requests to the relay for one feed page, trouble showing a loading indicator, and the risk of a long "freeze" during quiet periods.

A third problem comes up at the level of the geohash filter itself: matching the g tag works by exact string equality, not by prefix. If an event has only ["g", "u4pr"] (a rough location), and the filter asks for "#g": ["u4pruyd"] (a more precise one), the relay will not return that event — even though u4pruyd is physically inside u4pr. People get around this by publishing several geohash tags of different length (all the prefixes) on one event. But then the client that makes the request has to list all the prefixes of the area it wants — this scales poorly and bloats the filter when you try to cover a wide area.

In the event model above you can see the a and e tags. With them you can link a post to some other event (for example, to another post, if the post is a comment on it — usually through an e tag, or a comment on some changeable event — through an a tag). The e and a tags are described in more detail in NIP-01. A post can also have likes, which are usually done through kind=7 events, and comments (e). To get the number of likes and comments and show them in the feed, you need to open subscriptions to the matching events and then count them. So after you get the post and learn its id, you send a request:

["REQ", "post-stats-sub", {
  "kinds": [7, 1],
  "#e": ["1897f99..."]
}]

But likes and comments are far from the only things that can reference (or be referenced by) a given post. Through e/a tags, a post can be pointed to by reposts (kind=6/16), zap receipts (kind=9735), reactions with custom content besides likes, quotes inside other posts, and so on. For each kind of link you basically need a separate subscription with its own kinds filter, or a wider filter with no kinds limit, which you then have to filter and parse on the client. Already at this stage you can see that to fully show one post card in a feed you may need not one but a whole set of parallel requests to the relay.
There is also a less obvious danger here. Since e/a links are not limited by the protocol in any way, nothing stops events from referencing each other in a cycle — post A comments on post B, which itself is marked as a comment on post A (by accident, a client bug, or on purpose, as spam or an attack). A client that naively walks the tree of linked events (for example, to build a full thread) can fall into an endless loop if it does not add protection in advance — tracking the ids it has already visited, or limiting the recursion depth.

So while Nostr is a good fit for simple feeds, more complex ones can run into trouble: very greedy content loading and, as a result, a very large number of requests and poor performance.

As for the features we are used to in top social networks — a smart feed and many flexible filters — it seems you cannot build them with Nostr alone, without custom add-ons and without losing decentralization.

Then again, maybe it is better without a smart feed: it is not great that you often cannot find a post you liked a second time.

Community

One of the features built on Nostr that I had to work with is NIP-72.
In short, NIP-72 is a NIP that describes moderated topic communities on top of normal Nostr events. A community is defined by an addressable event (kind:34550), which lists its moderators. Any user can publish a post that links to this community — that is, propose a publication in the community. But for a post to actually count as part of the community and show up in its feed, one of the moderators must publish a separate approval event (kind:4550). This event contains the original post in full and is signed by the moderator's key. When building the community feed, clients rely on these approval events, not on the posts with the tag. So selection and moderation here are fully on the side of public, verifiable signatures.

In principle, this works. But when a manager comes and says that any moderator should be able to moderate the community without the creator's approval, a problem appears. NIP-72 does not assume that someone from the moderator list can edit the community definition itself. The moderator list in kind:34550 is just p tags listed inside an event signed by its owner. Only the holder of the private key that originally signed it can change this event (and therefore the moderator list) — that is, the community creator, not any of the listed moderators. This is a direct result of a base Nostr limit: only the holder of the key that is authoritative for an event's state can edit or redefine that state, and the protocol does not split this authority into roles at all. Trying to solve this with Nostr alone, without going beyond the protocol, leads nowhere good in the end. In practice the problem was solved with a central add-on — an extra service that adds extra signatures to events on top of the protocol model. But even with this solution I was very unhappy both with the communities feature itself and with the final implementation.

One more similar use case — organizations

I had to deal with this case too. Here is a short description of the task. There are organizations and sub-organizations, and posts and other similar events are published on their behalf. Only members can publish on behalf of an organization or sub-organization. Members have roles, and depending on the role they can invite other members.

Building this with Nostr alone is a doubtful idea. The protocol has no built-in model for roles, for an "organization → sub-organization" hierarchy, or for invitations; all it has is signing with one key as the only way to authorize. Here it is worth mentioning that Nostr did have a "native" way to delegate signing — NIP-26 (Delegated Event Signing), but it never caught on and is now marked as deprecated. So even the protocol's own delegation mechanism was, in the end, seen as a failure, and in practice the task is solved centrally — for example, with keycast, a service for delegating signing in Nostr, made specially for team work with keys. But even keycast does not fully solve the task, in particular the problem of roles. To give teams control over who can sign what, its authors had to build their own system of policies and permissions around keys — something the protocol does not have. This says a lot: even a tool made specially for delegating signing ends up coming down to writing a full backend from scratch. So managing roles and an organization hierarchy will also need central solutions — and not only for delegating signing, but also separately for managing roles. The amount of such work is comparable to writing a separate backend for this task, and using Nostr as the backend, or even as part of it, looks unjustified here.

Conclusions

If you go through all these cases — from notes and one2one chats to groups, feeds, and organizations — a fairly clear pattern appears.

Nostr really is a ready backend out of the box, and in two forms at once. It can be a fully decentralized solution based on a network of public relays. Or it can be a central one — if you run your own private relay and use the protocol just as a handy, ready format for data, sync, and authentication on top of your own infrastructure. The second option, by the way, is not as much of a compromise as it may seem: even if you give up decentralization, you still get a ready event model, signatures, encryption, and many ready client libraries. That is, you save time not only on infrastructure, but also on designing the communication protocol itself.

And for a number of tasks this solution really fits well — notes, chats (especially one2one), simple post feeds without claims to a complex feed. Here Nostr closes the classic problems (sync, encryption, identity) with almost no need to write your own backend at all.

But along the way I also collected a few lessons for myself.

Do not try to build a full social network on the level of Facebook, or any top social network, on Nostr. As soon as a smart feed, flexible filtering, role models with hierarchy, and other features long standard for top social networks come into play, the protocol starts to fall apart. Not because the NIP authors missed something, but because the model itself (a relay as a dumb store of signed events, with no server that has the full and sole right to complex business logic) is not made for this.

Do not try to get around the protocol's limits. The temptation to "stretch" Nostr to the business logic you need with custom add-ons — be it a synthetic moderator model, extra signatures on top of events, or third-party delegation services — is strong, and almost always technically possible. But, as the NIP-72 and organizations cases show, at some point these add-ons start to weigh more than the protocol they were meant to make simpler. And, more importantly, getting around the limits is not free. Besides losing decentralization and compatibility with the rest of the Nostr ecosystem (other clients, relays, NIPs), such add-ons are always one more surface for bugs — bugs in code that no one but you has tested at scale.

Before you start building, weigh both paths honestly: use Nostr with add-ons, or think about a separate backend for the specific task. Your own backend for roles, hierarchy, and moderation is written without looking back at someone else's protocol limits like "one key owner". It is often faster than building workarounds around Nostr — especially if the task fits the "signed events + relay" model poorly from the start.

The bottom line: Nostr is a great tool when the task lands in its "native" niche — and surprisingly awkward when you try to stretch it onto something it was not meant for. As with any tool, the main thing is to understand in advance which of these two groups your task falls into, instead of finding out after a month of work.

The app from this article

Private Notes (Nostr) is open source — you can look through the code to see the approach in practice.

A Russian version of this article is available on Habr: habr.com/ru/articles/1050348

flutter_skin — Live Remote Skin Engine Demo | Change Flutter Colors Without Rebu

Mon, 06 Jul 2026 06:20:40 +0000

Live Remote Skin Engine Demo | Change Flutter Colors Without Rebuilding.
This is the first demo of flutter_skin — a remote skin engine
for Flutter I've been building for the past few months.

This is the alpha. Color tokens only for now. Typography,
spacing, border radii, and A/B testing are coming.

Built by Badr Kouki
Flutter contributor | pub.dev publisher

Fskin alpha version is Live

Thu, 25 Jun 2026 08:39:15 +0000

Every Flutter dev has been here.
Design changed the primary color.
You open the codebase.
You update the hex.
You build.
You submit.
You wait. a full day for a color.

There’s a better solution now: Fskin

I built flutter_skin. Publish from a dashboard and the App updates on realtime No build. No review. No restart.

Alpha is live today.

Stop Guessing Frame Drops: Passive Zero Overhead Performance Telemetry for Flutter

Fri, 05 Jun 2026 04:07:58 +0000

Automatically capture frame drops (jank) and isolate rendering bottlenecks on the UI and Raster threads directly in your dev console

Every Flutter developer knows the pain of subtle micro-stuttering

A slight visual hiccup when navigating routes.
Scroll stutters on content-heavy feed lists.
Sluggish transitions when pulling up custom sheets.

We call this jank when the Flutter rendering pipeline fails to finish producing a frame within the device's hardware refresh budget (typically 16.67ms for 60Hz or 8.33ms for high refresh 120Hz screens). But actively hunting down these frame drops is tedious. You're forced to keep a browser tab open with Flutter DevTools, maintain active Socket connections, or install heavy analytics SDKs that bloat your production bundle.

That's why I built jank_scout. It passively monitors rendering lifecycle timings, analyzes thread bottlenecks, and outputs clean diagnostics directly to your terminal. Best of all, it completely tree-shakes itself out of your production release.

What It Looks Like in Practice

When a rendering timing budget is broken, jank_scout automatically identifies whether the freeze occurred on the UI Thread (CPU) or the Raster Thread (GPU) and displays a diagnostic ASCII report in your console

+----------------------------------------------------------------------+
| TELEMETRY REPORT:  [PIPELINE CRITICAL INTERRUPT]
+----------------------------------------------------------------------+
| Target Route: /details
| Budget: 16.67 ms (Target FPS: 60)
| Frame Render Time: 76.50 ms (Overrun: 358.9%, +59.83 ms)
| Thread Breakdowns:
|   - UI Thread (CPU Build):  68.20 ms
|   - Raster Thread (GPU):   8.30 ms
+----------------------------------------------------------------------+
| Bottleneck Analysis:
| BOTTLENECK: UI Thread (CPU Boundary). Diagnostic: Excessive execution cycle detected on the Dart isolate runtime loop. Remediate by auditing synchronous serialization, unoptimized layout passes, or high-frequency state emissions violating state boundary conditions.
+----------------------------------------------------------------------+

The Architecture Under the Hood
How does it hook into the engine with zero dependencies?

It utilizes Flutter's native SchedulerBinding callback pipeline to receive raw frame timelines asynchronously

SchedulerBinding.instance.addTimingsCallback((List<FrameTiming> timings) {
  // Pass timing metrics into the monitor engine
  JankScout.processTimings(timings);
});

jank_scout breaks down each frame into

UI Thread Time: widget tree creation, layout cycles, and drawing calls.
Raster Thread Time: GPU execution translating the layer tree into pixels.

Safe Production Tree-Shaking

To ensure that the package adds exactly zero bytes and zero background overhead in your production app, jank_scout wraps its entire registration and logging cycles inside assert boundaries and compiler optimizations

assert(() {
  // This code is completely stripped out during `flutter build --release`
  _initializeFrameMonitor();
  return true;
}());

Real-World Case Study: The Synchronous JSON List Freeze
Let's look at a classic local performance bottleneck parsing a massive JSON payload inside your UI widget builds.

X The Bad Code (Stalls UI Thread)

class FeedListScreen extends StatelessWidget {
  final String rawJsonString; // Large JSON string from network or local cache

  const FeedListScreen({super.key, required this.rawJsonString});

  @override
  Widget build(BuildContext context) {
    // ❌ CRITICAL JANK: Blocks Dart's main single-threaded event loop
    final List<dynamic> decodedData = jsonDecode(rawJsonString);
    final List<FeedItem> items = decodedData.map((e) => FeedItem.fromJson(e)).toList();

    return ListView.builder(
      itemCount: items.length,
      itemBuilder: (context, index) => FeedItemCard(item: items[index]),
    );
  }
}

Since Dart is single-threaded, running jsonDecode synchronously forces the UI thread to freeze while processing. The user experiences a frame drop. jank_scout immediately catches this and flags the UI Thread (CPU Boundary) as the culprit.

The Clean Fix (Background Concurrency)
To restore a butter-smooth 60 or 120 FPS scrolling list, offload the processing to a background thread using Dart isolates.

Option A: Spawning a Temporary Isolate using compute()

Future<List<FeedItem>> loadFeedAsync(String rawJson) async {
  // Offloads JSON processing to a temporary worker isolate
  return await compute(_parseJsonFeed, rawJson);
}

// Global or top-level function
List<FeedItem> _parseJsonFeed(String rawJson) {
  final List<dynamic> decoded = jsonDecode(rawJson);
  return decoded.map((e) => FeedItem.fromJson(e)).toList();
}

Option B:Persistent Isolate using Isolate.spawn()
For continuous large payloads, keep a dedicated worker isolate alive to save isolate initialization latency

Future<List<FeedItem>> parseWithManualIsolate(String rawJson) async {
  final receivePort = ReceivePort();
  
  final isolate = await Isolate.spawn(
    _isolateWorkerEntryPoint,
    _IsolatePayload(rawJson, receivePort.sendPort),
  );

  final List<FeedItem> items = await receivePort.first as List<FeedItem>;

  isolate.kill(priority: Isolate.beforeNextEvent);
  receivePort.close();

  return items;
}

By moving CPU intensive operations off the main isolate, scrolling stays fluid, the event loop remains clear, and jank_scout console output remains silent confirming optimal performance

Get Started in 3 Steps
1. Add dependency
Add the dependency to your pubspec.yaml

dependencies:
  jank_scout: ^0.0.3

2. Initialize in main.dart

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  
  // Set your target device FPS
  JankScout.initialize(targetFps: 60.0);
  
  runApp(const MyApp());
}

3. Add Router Route Tracking
Add the navigation observer in your MaterialApp to associate performance degradation reports with specific screens

MaterialApp(
  navigatorObservers: [JankScoutObserver()],
  initialRoute: '/',
  routes: {
    '/': (context) => const HomeScreen(),
    '/feed': (context) => const FeedListScreen(),
  },
);

Try It Out!
Let's make local Flutter development smoother together!

pub.dev: junk_scout
GitHub: Github Url
Website: My Portfolio

If you find jank_scout helpful, drop a ⭐ on GitHub and a like on pub.dev! Have any questions or feature ideas? Let's discuss in the comments below!

I built a streaming app with 7,000+ downloads at ₹0/month — here's the exact architecture

Wed, 03 Jun 2026 20:39:43 +0000

I'm Wasey, a solo developer from Varanasi, India. I built DramaHub —
a fully live OTT streaming app on Google Play Store. 7,000+ downloads,
1,000+ daily active users, sub-1% crash rate, ₹0/month infrastructure.

Here's the exact architecture that makes it possible.

The Problem

I had zero budget for servers. A typical OTT backend needs:

A backend server (₹3,000–15,000/month)
A database (₹1,500+/month)
A CDN (₹500+/month)

I had ₹0. So I had to think differently.

GitHub as the Database

All drama content, episode metadata, and app config live as JSON files
in a public GitHub repository. Free. Unlimited. Versioned automatically.

Every drama looks like this in JSON:

{
"id": "drama_001",
"title": "Drama Title",
"thumbnail": "https://cdn.jsdelivr.net/...",
"episodes": [

{
  "ep": 1,
  "title": "Episode 1",
  "source": "youtube_id_here"
}

]
}

The app fetches this JSON on launch, caches it locally, and serves
content instantly on subsequent opens.

Cloudflare Workers as the CDN Proxy

Hitting GitHub raw URLs directly has rate limits. So I built a
Cloudflare Worker that sits in front of GitHub:

Caches all JSON responses at the edge globally
Handles unlimited traffic
Auto-invalidates when content version changes
Cost: ₹0

Architecture: Flutter app → Cloudflare Worker → GitHub raw JSON

The Dual Player System

DramaHub runs two video players:

Primary — YouTube WebView player
Most content is sourced from YouTube. The app uses a WebView-based
player with custom controls and a URL whitelist for security.

Secondary — Custom video player with Cloudflare R2
For self-hosted content, I use a custom player backed by
Cloudflare R2 storage.

Both players are switchable instantly from the admin panel via
remote JSON config. No APK update needed — ever.

The Admin Panel

This is the most important part of the architecture.

The admin panel is a Flutter Web app that communicates directly
with the GitHub REST API using Base64 encoding and SHA-based
conflict detection. From the admin panel I can:

Add/edit/delete dramas and episodes
Toggle ads per screen with cooldown timers
Switch between YouTube and custom player instantly
Change CDN URLs without any release
Force update all users
Control app config globally

Everything is remote. Everything is instant. No app store review cycle.

The Crash That Taught Me Everything

One day the app went completely down. Every user got a crash on launch.

The reason: my Cloudflare Worker wasn't caching properly. Every request
was hitting GitHub directly and I burned through the API rate limit
in minutes.

I fixed the Worker caching. Then I built a full backup system:

Direct GitHub raw URL as fallback
Backup Worker as secondary fallback
Switchable from admin panel in under 60 seconds

No APK release needed. I built that entire system in one night.

Firebase Integration

Even with zero backend cost, I use Firebase for:

Anonymous Auth
FCM push notifications with deep links
Crashlytics for real-time crash monitoring
Analytics with 7 custom tracked events
Atomic view counter increments via Firestore REST API

Results After 18 Months

7,000+ downloads
1,000+ daily active users
Sub-1% crash rate
₹0/month infrastructure cost
Live on Google Play Store

Key Lesson

Build your admin panel first. Remote config is not a feature —
it's survival. The ability to change anything without a new release
has saved me dozens of times.

GitHub as a database works at production scale if you architect
the caching layer correctly.

GitHub: github.com/waseyjamal/dramahub
Play Store: https://play.google.com/store/apps/details?id=com.dramahub.drama_hub
Twitter: @waseybuilds

Happy to answer any questions about the architecture.

I Built an AI-Powered Agricultural Logistics Platform for Farmers Worldwide — Here's How

Mon, 01 Jun 2026 06:04:51 +0000

16% of agricultural produce globally is lost every year before it reaches the buyer. Not because the crops are bad. Because the supply chain is broken.
Farmers have no digital way to list surplus crops. Buyers can't discover what's available nearby. Drivers get no coordination layer. Everyone loses.
I built Micro-Harvest to fix all three — at the same time — using a single AI conversation.

What Is Micro-Harvest?
Micro-Harvest is a three-sided agricultural logistics platform built for the Google Cloud Rapid Agent Hackathon 2026 (Elastic Track). It connects:

Farmers (Growers) — who list surplus crops via an AI chat agent
Buyers (Producers) — who discover listings through smart geo-search
Drivers (Transporters) — who get auto-assigned hauls and handle delivery

One conversation from the farmer triggers the entire chain — AI reasoning, buyer matching, driver dispatch, and Stripe payment settlement. All automated.
Watch the full demo: https://youtu.be/0ZdplkglDBo

The Core Idea: One Message Does Everything
Here's what happens when a farmer speaks or types:

"I have 20 macro bins of Merlot ready to go today, asking $4000 per ton"

Under the hood, in under 30 seconds:

Gemini 3.1 Flash extracts → crop type, quantity, price, urgency
AI Reasoning Engine scores → urgency level, weather risk, vehicle recommendation
Elastic MCP (24 tools) → geo-matches nearest available buyer + transporter
FCM push notification → driver gets haul assignment
Driver completes → Gate 1 pickup + Gate 2 delivery confirmation
Stripe → 80% to farmer, 15% to driver, 5% platform fee. Same day.
No phone calls. No middlemen. No 3-day delays.

The Tech Stack-
AI Agent - Google Agent Platform, LLM - Gemini 3.1 Flash Lite Preview, Search - Elastic MCP — 24 tools, Backend - Firebase (Firestore, Auth, Cloud Functions) Payments - Stripe, Mobile - Flutter (3 Android apps) Admin - Flutter Web

The Elastic MCP server is the heart of the matching layer. It exposes 24 tools covering semantic crop search, geo-distance queries, transporter availability matching, index health monitoring, and BigQuery analytics. Every search the buyer runs fires a real geo-distance query against the listings index in real time — you can watch it in the Elastic search profiler.

The Feature I'm Most Proud Of: Offline-First Listing
Farmers often operate in areas with poor connectivity. Someone out in a field with no signal shouldn't lose their listing.
So I built the Harvest Agent to be offline-first:

Farmer speaks or types their crop details — no internet detected
App shows an offline badge and queues the message locally
The moment connectivity returns — listing syncs and goes live automatically
Zero farmer action needed

This was the hardest part to get right. The local queue needed to survive app restarts, handle partial sync failures, and not create duplicate listings on reconnect. It took more debugging than the entire AI integration.

Three Apps, One Platform
All three apps are built in Flutter and share the same Firebase project:
Farmer App (Grower)

Voice + text AI listing creation
Offline message queue with auto-sync
Real-time listing status tracking
Earnings dashboard

Buyer App (Producer)

Natural language surplus search
Geo-filtered results with radius control
Claim and reserve listings
Live transport tracking

Driver App (Transporter)

FCM haul notifications
GPS route guidance to farm
Gate 1 + Gate 2 photo capture
Instant payment on delivery confirmation

You can download and install all three APKs from the GitHub release and walk through the complete end-to-end flow yourself. APK links are in the Links section at the bottom.
(Enable "Install from unknown sources" in Android settings first)

What I'd Build Next
A few things I want to add after the hackathon:

Price intelligence — Gemini currently recommends a price band but doesn't pull live commodity market rates; integrating real-time agri pricing APIs would make this genuinely powerful
iOS builds — currently Android only; the Flutter code is cross-platform but Apple provisioning didn't make the deadline
Multi-language AI agent — supporting regional languages so the Harvest Agent works natively for farmers regardless of where they are in the world

Links
Demo Video
https://youtu.be/0ZdplkglDBo
Landing Page
https://micro-harvest-landing.web.app
️ Admin Panel
https://micro-harvest.web.app
GitHub
https://github.com/ssurekumar01111-hue/micro-harvest
Farmer APK
https://github.com/ssurekumar01111-hue/micro-harvest/releases/download/v1.0.0/grower-release.apk
Buyer APK
https://github.com/ssurekumar01111-hue/micro-harvest/releases/download/v1.0.0/producer-release.apk
Driver APK
https://github.com/ssurekumar01111-hue/micro-harvest/releases/download/v1.0.0/transporter-release.apk

Building this solo in Flutter + Firebase was genuinely fun — the Google Agent Platform + Elastic MCP combination is seriously powerful for this kind of multi-party matching problem. Happy to answer questions about any part of the architecture in the comments.

[Dev Feedback] APEX F1 – full F1 race sim in Flutter (GPS circuits, AI rivals, multi‑season)

Thu, 28 May 2026 20:17:01 +0000

Hey devs,

I’m a 6th‑semester Software Engineering student and I’ve been building a passion project called APEX F1 – a full Formula 1 race simulation app written entirely in Flutter & Dart. ️

It started as a simple F1 calendar and turned into a full race weekend simulator with AI, GPS‑accurate tracks, and a persistent championship mode. I’m pretty happy with how far it’s come, but now I’d really like feedback from more experienced developers.

High‑level overview
Built with Flutter 3 + Dart 3, zero backend – all logic runs on‑device.

Full F1 race weekend: qualifying (Q1/Q2/Q3) + race simulation.

GPS‑accurate circuit maps for all 24 tracks in the 2024 F1 calendar (using my own open‑sourced GeoJSON data).

20 AI drivers with different consistency / behavior profiles.

Three seasons built‑in (2023, 2024, 2025) + support for custom seasons via JSON.

Technical details
Architecture: feature‑first, “clean‑ish” structure (feature modules with shared core).

State: mostly StatefulWidget + AnimationController (no Riverpod/BLoC yet).

Storage: shared_preferences for profile, championship progress, and custom seasons.

UI: Neon dark theme, Google Fonts (Orbitron + Rajdhani), ~20+ animated transitions.

Responsive layout: custom helper that scales sizes based on a 390px baseline, tested from 360px phones to 600px+ tablets.

Links
Web build (Firebase Hosting): https://apex-f1-159.web.app

Repo: https://github.com/GulrezQayyum/apex-f1

Circuit data (open source): https://github.com/GulrezQayyum/f1_circuits-2024_season

What I’d love feedback on (for devs)
If you have some time to check the repo or play a couple of races, I’d really appreciate feedback on:

Architecture & structure

Is the feature‑first layout reasonable for a project this size?

Any obvious refactors you’d suggest before it grows further (e.g., extracting domain layer, introducing DI, etc.)?

State management & reactivity

Right now it’s mostly StatefulWidget + manual setState and controllers.

Would you recommend migrating to Riverpod / BLoC / ValueNotifiers for this kind of simulation UI?

Performance

The live GPS circuit map animates 20 cars every frame. Any suggestions on optimizing this in Flutter (custom painters, offscreen layers, etc.)?

Things you’d profile or watch out for on mid/low‑end devices?

Data & simulation design

Lap time / AI behavior is currently driven by JSON + some randomness around base pace and consistency.

If you’ve built sims before, any tips for keeping it fun but not totally random?

Feel free to be brutal (but constructive) — I want to use this project to level up as a developer.

If anyone’s interested, I can also break down the GPS data pipeline, circuit rendering, or how I structured the race engine in more detail. Happy to share code snippets or diagrams.

Thanks in advance to anyone who takes a look.

I built a free AI writing SaaS with Flutter Web + Gemini — would love feedback from this community

Sun, 17 May 2026 07:18:24 +0000

Hey CoderLegion

I've been a Flutter/Firebase developer for the past
couple of years, and I recently shipped something I'm genuinely
proud of — ScribeAI, a free AI-powered writing platform.

https://scribeai-f7645.web.app

Here's what it does — 8 tools in one platform:

ATS Resume Scorer — paste your resume + job description,
get an instant compatibility score, missing keywords, and
improvement suggestions

✉️ Cover Letter Generator — tailored cover letters matched
to any job description

Document Summarizer — turn long contracts and reports into
clean structured summaries

Blog & SEO Writer — full SEO-optimized blog posts from
just a topic and keywords

✏️ Grammar & Tone Fixer — fix errors and adjust tone
(professional, casual, formal)

Paraphrasing Tool — rewrite text in multiple styles
and variations

LinkedIn Bio Writer — optimized About section that
attracts recruiters

Interview Q&A Generator — role-specific questions and
model answers

️ Tech stack for those curious:

Flutter Web (single codebase, runs in any browser)
Google Gemini AI API for all 8 tools
Firebase Auth + Firestore for backend
BLoC state management
Razorpay for payments
Deployed on Firebase Hosting

Monetization: Free tier (3 uses/day) → Credits (₹99 = 20)
→ Pro (₹199/month unlimited)

Other features: PDF download, copy to clipboard, share
results as public link, usage history, (signup needed to try)

This started as a side project to prove that a Indie-developer can build and ship a real SaaS product without
a team or funding.

I'd genuinely love feedback from this community on:

Is the UI/UX intuitive? Anything confusing?
Which tool did you find most useful?
What feature would make you actually use this regularly?
Any bugs you spotted?
Would you pay for the Pro plan? If not, why?

Be as brutal as you want — I can handle it and I'll
actually fix things based on your feedback

Thanks for checking it out!

What's the most annoying problem in your daily life that doesn't have a good mobile app yet?

Thu, 14 May 2026 13:33:13 +0000

Hey CoderLegion community
I'm a Flutter & Firebase developer currently looking for my next build idea — and instead of guessing, I want to ask the people who actually feel the pain.
What's a real problem you face regularly that you wish had a better mobile app solution?
Could be anything:

Something at work that still runs on WhatsApp groups or spreadsheets
A local service that has no app (booking, delivery, scheduling)
A tool you use daily that feels clunky or outdated
Something you've thought "why doesn't this app exist yet?"

I build full-stack mobile apps using Flutter + Firebase — so I'm looking for ideas that involve real-time data, multi-user roles, bookings, payments, or location tracking. But drop anything — I want to hear what actually frustrates people.
Drop your pain point in the comments Even half-formed ideas are welcome. If enough people share the same problem, that's a signal worth building for.
Let's see what's missing out there.

Cross-Platform Music App Development Using Flutter and React Native

Thu, 14 May 2026 07:43:33 +0000

Quick Overview

Flutter (Dart) and React Native (JavaScript) are the top frameworks
for launching music apps on iOS and Android from a single codebase.
Both support essential music features, such as streaming, background
playback, waveform visualization, and media controls, through
well-maintained plugin ecosystems.
Audio performance, low latency, and real-time processing are the
main technical challenges in cross-platform music development.
The right framework depends on your team's skills, the app's
complexity, and performance requirements; there is no
one-size-fits-all solution.
Choosing a cross-platform approach can reduce development time and
costs by 30 to 50 percent compared to building separate native iOS
and Android apps.

You have a great idea for a music app. It could be a tool for collaborative playlists, a practice companion for musicians, or a complete streaming experience. You've done your research and have a development plan. Then reality hits: do you build it for iOS first, Android, or both at the same time? If you choose both, does that mean you need two separate teams, two separate codebases, and twice the budget?

This is the exact problem that has led developers to cross-platform frameworks. Right now, Flutter and React Native are the two main players in this field. This article explains how each framework approaches music app development, the trade-offs involved, and how to make the best choice for your project.

Why Cross-Platform Is a Smart Choice for Music Apps

Before exploring frameworks, note that cross-platform development offers benefits for complex music apps involving real-time audio, background playback, hardware controls, Bluetooth switching, and low-latency features. While native development historically excels here, the gap with cross-platform has narrowed.

Platforms like Flutter and React Native have developed to the point where most music app experiences feel just like native ones in everyday use. And for teams working with music app development services, the ability to ship one codebase to two platforms without sacrificing quality is a genuine competitive advantage.

The economics are clear: one cross-platform team costs less than two native teams, with streamlined maintenance and simultaneous feature releases. For startups and mid-sized companies, this advantage can determine a project's viability.

Flutter in Music App Development: Essential Insights

Flutter, supported by Google, uses Dart and the Skia rendering engine, now replaced by Impeller. Instead of relying on the host platform's UI components, Flutter renders every pixel itself. This approach benefits music apps.

Visual consistency: Waveform displays, equalizer animations, album
art carousels, and custom playback controls look the same on iOS and
Android, eliminating UI rendering frustration across platforms.
Audio handling: Since Flutter lacks a built-in audio engine, you'll
need packages like just_audio, audio_service, and flutter_sound.
just_audio supports streaming, gapless playback, pitch shifting, and
audio effects, suitable for most music apps. audio_service manages
background playback and media notifications, essential for any music
app.
Performance: Flutter's compiled Dart code and rendering pipeline
ensure smooth animations and a responsive UI, but can lag during
heavy platform-channel communication. Handling real-time native audio
processing may cause delays due to Dart-native exchange.
Ideal use cases: They include streaming, music discovery, podcast,
music education, and DJ mixing apps that don't need very low-latency
audio (under 10 ms).

React Native for Music App Development: Essential Insights

React Native, maintained by Meta, uses JavaScript or TypeScript and connects to native components. The newer "New Architecture" adopts JSI instead of the old bridge, significantly narrowing the performance gap with native development.

The JavaScript ecosystem: If your team already works with React or
JavaScript, the learning curve is much shorter. For React Native app
development, the large npm ecosystem means there are libraries for
almost everything a music app might need, from audio processing to
music-theory tools.
Audio libraries: react-native-track-player is the preferred tool for
streaming and queue management, supporting background playback, lock
screen controls, and CarPlay/Android Auto. react-native-sound is good
for basic audio, while react-native-audio-toolkit manages recording.
For advanced DSP, native modules are used.
Consistency: React Native uses native components, so your app adopts
each platform's look and feel. This works well for standard UI
patterns but can be inconsistent for custom designs.
Ideal use cases: It includes music players, streaming services,
social platforms, learning apps, and apps where React or
JavaScript skills are important.

Flutter vs. React Native for Music Apps

Key Technical Considerations Specific to Music Apps

Regardless of which framework you choose, certain challenges are common in cross-platform music development.

Background audio playback: Both frameworks handle this with dedicated
packages: audio_service for Flutter and react-native-track-player for
React Native, but require careful configuration of platform-specific
entitlements and permissions.
Low-latency audio: For apps requiring latency below ~20ms, such as
real-time tuners or live tools, cross-platform frameworks may reach
their limits, and custom native modules might be necessary regardless
of the framework.
Audio streaming and buffering: Managing an app's state is crucial.
Music streaming apps must handle network issues, adaptive bitrate,
and pre-buffering. Both frameworks support this, but implementation
is complex.
Waveform visualization: It uses significant CPU resources. Flutter
CustomPainter and React Native's canvas options, via
react-native-skia or WebGL, handle this. Optimization is vital,
especially on mid-range Android devices.

Conclusion

Choosing between Flutter and React Native isn't about picking the better tool but the right one for your team, timeline, and features. Flutter offers visual consistency and performance predictability, while React Native excels in ecosystem familiarity and native platform integration. Both can produce high-quality cross-platform music apps indistinguishable from native ones.

Understanding your app's technical needs early is crucial. If real-time audio is essential, evaluate how frameworks handle native modules. For streaming or discovery, either framework works, and cross-platform saves are substantial. The best framework is the one your team confidently uses. Choose it, build effectively, and let the music speak.

FAQs

1. Can Flutter or React Native handle real-time audio processing for music apps?

Both handle standard audio tasks well with plugins, but lack out-of-the-box ultra-low-latency (under 10ms) support. Features like live tuning or MIDI require native code in Swift or Kotlin. Still, both frameworks can stream and play without native tweaks.

2. Which is better for a music streaming app, Flutter or React Native?

Both work well. Flutter provides consistent UI and smooth animations, while React Native's react-native-track-player offers a stronger streaming ecosystem with CarPlay and Android Auto support. React Native teams ship faster; Flutter users may prioritize visual appeal.

3. How do cross-platform music apps handle background playback?

Both frameworks handle background audio, lock screen controls, and media notifications via dedicated packages: audio_service in Flutter and react-native-track-player in React Native. You must manually configure platform permissions and test on real devices, as emulators often poorly handle background audio.

4. Is Flutter or React Native faster to develop a music app with?

Your team's expertise influences the choice. JavaScript developers may prefer React Native for speed, while Flutter's clear structure eases Dart's learning curve and scalability. Both frameworks can cut development time by 30-50% versus native iOS and Android.

5. What are the main limitations of cross-platform frameworks for music apps?

Main limitations include low-latency audio, hardware integration, and delayed access to new APIs. Complex audio features often need native modules. But for most consumer music apps like streaming, playback, and visualization, these issues are generally not significant.

The Day White Became a Bug

Wed, 13 May 2026 20:46:52 +0000

Today started with one of those tasks that looks almost too small to deserve a branch: prepare the Flutter app for dark mode by making sure colors are centralized.

Simple enough, right?

Find the hardcoded colors. Move them into AppColors class. Replace the literals. Run analyzer. Go eat something.

Flutter, naturally, had a few notes.

The first scan told the real story. There were direct Colors.white calls, direct Colors.black, Colors.grey[600], Colors.transparent, and a handful of Color(0x...) values hiding in screens, cards, bottom sheets, painters, buttons, notification badges, and little UI edges that probably nobody thinks about until dark mode makes them painfully visible.

And that is the thing about dark mode: it punishes casual color decisions.

A hardcoded Colors.white is harmless in a light theme. It feels obvious. Of course the card background is white. Of course the modal is white. Of course the icon on the primary button is white.

Until the app theme changes and that same “obvious” value becomes the one thing refusing to adapt.

The suspicious innocence of Colors.white

The cleanup made me notice how often Flutter code uses color constants as if they are design decisions instead of implementation details.

This kind of code is easy to write:

Container(
color: Colors.white,
child: Text(

title,
style: const TextStyle(color: Colors.black),

),
)

There is nothing technically wrong with it. The widget renders. The code is readable. Everyone understands what it does.

But architecturally, it is making a decision in the wrong place.

The widget is deciding that the surface must be white and the text must be black. That may be true today, but it is not the widget's job to know forever. Once dark mode enters the conversation, that decision belongs somewhere higher up: a theme, token system, semantic color layer, or at the very least a central color class.

So the goal was not to make the code prettier. It was to reduce the number of tiny places that would later need to “remember” how dark mode works.

Centralization is not the same as theming, but it is a start

The app already had an AppColors class, which was good. It meant the project had a place where visual constants could live.

The messy part was that some colors were already centralized while others were still written directly inside widgets. A few values already existed in AppColors, just under literal-style names. Some did not exist yet. Some were Flutter palette values like Colors.grey[400], which are convenient in the moment and annoying later.

The rule for the cleanup became very plain:

If the value already existed in AppColors, use it.

If it did not exist, add a static constant.

Do not rename the entire design system today.

Do not pretend this is a full dark mode implementation.

Just make sure the color literals stop leaking through the UI.

That last point mattered. It is tempting during a cleanup like this to turn it into a full semantic-token refactor:

AppColors.surfacePrimary
AppColors.surfaceElevated
AppColors.textPrimary
AppColors.textMuted
AppColors.borderDefault

Honestly, that is probably where the app should end up.

But today was not the day to redesign the whole color vocabulary. The immediate goal was containment. Before a color can become theme-aware, it needs to stop being scattered across a hundred widgets.

So even constants like this were useful:

class AppColors {
static const Color white = Color(0xFFFFFFFF);
static const Color black = Color(0xFF000000);
static const Color transparent = Color(0x00000000);

static const Color grey200 = Color(0xFFEEEEEE);
static const Color grey400 = Color(0xFFBDBDBD);
static const Color grey600 = Color(0xFF757575);

static const Color background = Color(0xFFFEFEFE);
static const Color border = Color(0xFFE8E8E8);
}

Not perfect. But centralized. And centralized is the first real step toward controllable.

The part that quietly mattered

One interesting detail was deciding what counted as a color problem.

A direct Color(0xFFAF6D57) in a widget is obviously a problem. It is a visual value hardcoded into UI code.

A dynamic parser like this is different:

Color(int.parse(cleanedHexValue, radix: 16));

That is not really a hardcoded design color. It is converting a value that came from elsewhere, probably an API or configuration payload. Centralizing that would be a different conversation: validation, fallback behavior, allowed palettes, maybe server-driven UI constraints.

So I left dynamic parsing alone and focused on literals: Colors.*, Color(0x...), and raw hex strings that represented fixed UI choices.

This is the kind of small boundary decision that does not look exciting in a diff, but it keeps a refactor from becoming a swamp.

Search and replace, with consequences

Most of the work was mechanical, but mechanical does not mean brainless.

For example, replacing Colors.grey with a color constant is not the same as replacing Colors.grey[400]. Flutter's material color swatches have shades, while a plain Color does not.

This was one of those tiny compiler reminders that the original code was relying on more than just a color value:

// Before
Paint()..color = Colors.grey.shade400;

// After
Paint()..color = AppColors.grey400;

That one line explains a lot. The old code depended on a MaterialColor API. The centralized version needed a concrete shade constant.

Another small gotcha: when doing broad replacements, the color class itself has to be protected. If a replacement pass rewrites the constants inside AppColors, you can accidentally create recursive constants like:

static const Color white = AppColors.white;

Which is both funny and very much not useful.

The analyzer caught that immediately. A mildly embarrassing moment, but also a good reminder: refactoring with tools is still refactoring. The compiler is part of the conversation.

Why this matters before dark mode

The easiest dark mode bugs are the ones you can see instantly: black text on a dark background, white cards floating awkwardly on a dark scaffold, disabled buttons with contrast that disappears.

The harder bugs are the ones caused by ownership confusion.

If every widget owns its own color decisions, then dark mode becomes a scavenger hunt. You change the theme, run the app, notice one broken screen, patch it, then find another. A bottom sheet here. A map overlay there. A custom painter somewhere else. Eventually you are debugging vibes.

Centralizing colors changes the shape of the work. It does not magically create dark mode, but it makes the next step sane. Instead of asking, “Where did this white come from?” you can ask, “Which token should this surface use?”

That is a much better question.

It also creates room for a future migration from raw constants to semantic ones. Today, AppColors.white may still be literal white. Later, a component might use AppThemeColors.surface(context) or a theme extension. That migration is much easier when the codebase is not full of anonymous hex values.

The small win

By the end of the cleanup, the app had no remaining direct Colors.* usage outside the central theme file, no direct Color(0x...) UI literals outside AppColors, and no raw hex color strings floating around in feature code.

The analyzer still had unrelated warnings, because real apps always have a little background noise. But the color cleanup itself was clean.

That felt like progress.

Not the shiny kind where a new feature appears on screen. More like the quieter kind where future work becomes less annoying because today's code stopped hiding decisions in random corners.

And honestly, that is a big part of mobile development. Some days you build screens. Some days you chase state bugs. Some days you move every Colors.white into one place because future-you deserves fewer headaches.

Building a Zero-Cost AI Feature in Flutter with Gemma 4 + Firebase

Mon, 11 May 2026 16:39:31 +0000

How to combine on-device inference with cloud sync — without paying a cent in API fees

The Unspoken Reality of AI API Costs

Here’s the moment every indie developer dreads. You’ve shipped your AI feature. Users love it. It’s working. Then you open your billing dashboard.

Every question your users ask costs you money. Every summary generated, every classification run, you’re paying for it. You have created a successful product, but its popularity is now draining your resources.

What if there was a way to run powerful AI in your Flutter app with zero ongoing API costs? No per-request charges. No server bills. No privacy risk from data leaving the device.

That’s exactly what the combination of Gemma 4 and Firebase unlocks. Gemma does the thinking, entirely on the user’s phone. Firebase handles persistence and sync. The result is an AI-powered app that scales to thousands of users at near-zero marginal cost.

I’m building my own product on this exact stack. Here’s how it works.

Why cloud AI is a trap for indie developers

Cloud AI APIs are seductive. You make one API call, get a response, ship the feature. But the cost model is brutal for bootstrapped products:

Costs scale directly with usage — success punishes you
User data leaves the device — a privacy and trust problem
No connection means broken features — poor offline experience
You’re dependent on a third-party API that can change pricing or availability

On-device AI solves all four of these problems at once. The model runs locally, the user’s data never hits a network, it works offline, and you own the stack.

The stack: Gemma 4 + flutter_gemma + Firebase

Three components, each with a clear job:

Gemma 4 (the brain)
Gemma 4 is Google’s latest edge-optimized open model, built on the same research as Gemini but designed to run efficiently on mobile hardware. The E2B variant (Effective 2B parameters) runs in under 2GB of RAM thanks to 4-bit quantization. It’s practical for real devices, not just flagship phones. Critically, Gemma 4 supports native function calling, which means you can wire it directly into your app’s logic without any prompt engineering hacks.

flutter_gemma (the bridge)
The flutter_gemma package wraps the native LiteRT-LM inference engine in a clean Dart API. You get GPU acceleration, streaming responses, multimodal vision support, and function calling, all from Flutter. It supports Android, iOS, Web, and Desktop from a single codebase.

Firebase (the backbone)
Firebase handles everything that needs to live in the cloud: Firestore for storing and syncing AI outputs across devices, Firebase Auth for user identity, and optionally Firebase Storage if you need to persist larger assets. The key insight is that your AI inference never touches Firebase; only the results do.

The architecture: who does what

Here’s the principle that makes this work: AI never touches the network. Only the output does.

The flow looks like this:

User creates content in the app (a note, a photo, a voice memo)
Gemma processes it on-device — tagging, summarizing, classifying
The AI output (not the raw input) is written to Firestore
Firebase syncs the output to the user’s other devices

The user’s raw thoughts, photos, or voice never leave their phone. The model never makes a network call. But their data is still available everywhere they need it, because Firebase syncs the processed result.

Building it: a private AI notes app

Let’s make this concrete. We’ll build a simple notes app where Gemma automatically tags and summarizes each note on-device, then Firebase syncs the result across the user’s devices. Here’s the step-by-step.

Step 1: Set up flutter_gemma
Add the dependency to your pubspec.yaml:

dependencies: flutter_gemma: ^0.13.1 cloud_firestore: ^5.0.0 firebase_auth: ^5.0.0

Download the Gemma 4 E2B model from Hugging Face (you’ll need to accept the license terms). Store your HuggingFace token securely; never hardcode it. On first launch, the app downloads the model to local storage. This is a one-time operation of around 1.5GB.

Step 2: Run on-device inference
Initialize the model and run a simple summarization:

final model = await FlutterGemma.getActiveModel( maxTokens: 512, preferredBackend: PreferredBackend.gpu,); final chat = await model.createChat(); await chat.addQueryChunk( Message.text( text: ‘Summarize this note in one sentence and suggest 2-3 tags: $noteContent’, isUser: true, ),); final response = await chat.generateChatResponse();

That’s it. The inference runs entirely on-device. No API key, no network call, no cost. The response gives you a summary and tags you can parse and store.

Step 3: Write the output to Firestore
Take the AI output and persist it to Firestore:

`await FirebaseFirestore.instance
.collection(’notes’)
.doc(noteId)
.set({‘originalContent’: noteContent, // stays on-device or stored per your preference

‘summary’: parsedSummary,    
‘tags’: parsedTags,    
‘userId’: FirebaseAuth.instance.currentUser!.uid,    
‘createdAt’: FieldValue.serverTimestamp(),});`

Notice what goes to Firestore: the AI-generated summary and tags, not necessarily the raw note. You can store the original too if your app requires it — but the point is you’re in control of what leaves the device.

Step 4: Read it back and sync
Firestore’s real-time listeners handle the sync automatically. Open the app on a second device and your tagged, summarized notes appear instantly — without any polling logic on your part. Firebase does the heavy lifting.

Real talk: the gotchas

I won’t sell you a perfect picture. Here’s what you’ll actually run into:

Model download size
The Gemma 4 E2B model is ~1.5GB. This is a one-time download, but you need to handle it gracefully. Show a clear progress indicator on first launch. Consider letting users choose to download over WiFi only. The flutter_gemma package provides download progress callbacks — use them.

Cold start time
Loading the model into memory takes a few seconds on the first inference of a session. Show a loading state. After the model is warm, subsequent responses are fast. Set user expectations early — frame it as the app ‘preparing your AI’ rather than ‘loading.’

Know when to use cloud AI instead
On-device Gemma 4 is excellent for targeted tasks: summarization, classification, short generation, tagging. It’s not the right tool for complex multi-step reasoning, very long context windows, or tasks where you need GPT-4-level capability. Design your AI features to scope appropriately — use Gemma on-device for the 80% of tasks it handles well, and route complex queries to a cloud model if needed.

The payoff

Here’s what you get with this architecture:

Zero ongoing AI cost. No per-request charges, ever. The model is on the user’s device.
Full privacy. User data is processed locally. You can credibly promise your users their data stays on their phone.
Works offline. AI features work without a connection. Firebase syncs when connectivity returns.
Scales for free. Your 1,000th user costs you no more in AI inference than your first.

Firebase gives you the sync and persistence layer without building a backend. Gemma gives you the AI without paying per token. Together, they let you ship an AI-powered product that’s genuinely sustainable for an indie developer.

What I’m building with this

This is the exact architecture I’m using for my own product — built on Flutter, Gemma, and Firebase. I’ll be writing more about specific implementation decisions as I go, including how I’m using Gemma’s multimodal vision support and how I structure Firestore for AI-generated data.

If you’re building something similar — or thinking about it — hit reply. I’d love to hear what you’re working on.

Next up: Adding multimodal vision to your Flutter + Gemma app — letting the model read images directly, entirely on-device.

I Got 4 PRs Merged to the Flutter Framework. Here's Exactly How

Mon, 11 May 2026 06:36:37 +0000

I Got 4 PRs Merged to the Flutter Framework. Here's Exactly How

I never thought I'd contribute to a framework used by millions of developers.

Flutter felt like this massive codebase maintained by Google engineers, way out of my league. But three months ago, I decided to try anyway. Today, I have 4 pull requests merged into the official Flutter repository (flutter/flutter), reviewed and approved by the Flutter team at Google.

Here is exactly how I did it, step by step.

Why I Wanted to Contribute

I have been building Flutter apps for over 5 years across fintech, e-commerce, IoT, real estate, and healthcare products. I use Flutter every single day. But I had never looked under the hood.

Three things pushed me to finally try:

I wanted to understand how Flutter actually works at the framework level, not just how to use it. I wanted to give back to a tool that has been central to my entire career. And I wanted to stand out as a developer, because very few Flutter developers ever contribute back to the framework itself.

So I went looking for a way in.

Step 1: Finding the Right Issue

I went to the Flutter GitHub repository and started filtering issues. The key is not to look for something impressive on your first try. You are looking for something clearly defined, well-scoped, and achievable without deep internal knowledge of the codebase.

I found Issue #177414, a cleanup task to remove cross-imports from widget test files. Specifically, many test files in the widgets package were importing from Material or Cupertino packages when they should only be importing from the core widgets or flutter_test packages. This created unnecessary coupling between layers of the framework.

It was a perfect entry point because the problem was clearly described, the fix pattern was consistent across multiple files, and each file could be a separate PR, meaning one issue could generate several contributions.

Tip: Look for labels like "good first issue", "a: accessibility", or "cleanup". Avoid anything marked "severe" or "P0" until you know the codebase well.

Step 2: Understanding the Codebase Before Touching It

Before writing a single line of code, I did the following:

I read the CONTRIBUTING.md file in full. Every open source project has different rules about branch naming, commit messages, PR descriptions, and test requirements. Flutter's is thorough and worth reading carefully.

I forked the repository and set up Flutter from source locally. This is different from installing Flutter normally. You are cloning the engine and framework, not just downloading a binary.

I found the specific test files mentioned in the issue and read them to understand what "correct" looked like versus what needed fixing.

The problem in these files was that widget tests were using MaterialApp or CupertinoApp as their test wrapper, which pulled in the entire Material or Cupertino layer unnecessarily. The correct approach was to use framework-level wrappers that do not carry that dependency.

Step 3: Making the First Fix

I started with autofill_group_test.dart for PR #181903.

The change sounds simple, and technically it is. But getting it right requires understanding why the dependency exists in the first place and what the correct replacement is. Reviewers will reject a change that fixes the import but breaks the intent of the test.

Here is the pattern I followed:

// Before: importing Material when it is not needed
import 'package:flutter/material.dart';

testWidgets('autofill group test', (WidgetTester tester) async {
  await tester.pumpWidget(
    MaterialApp(
      home: AutofillGroup(
        child: Column(children: [...]),
      ),
    ),
  );
});

// After: using only what the test actually needs
import 'package:flutter/widgets.dart';
import 'package:flutter_test/flutter_test.dart';

testWidgets('autofill group test', (WidgetTester tester) async {
  await tester.pumpWidget(
    Directionality(
      textDirection: TextDirection.ltr,
      child: AutofillGroup(
        child: Column(children: [...]),
      ),
    ),
  );
});

After making the changes I ran the tests locally:

flutter test packages/flutter/test/widgets/autofill_group_test.dart

All tests passed. Then I created the PR.

Step 4: Writing a Good Pull Request

The PR description matters as much as the code. Flutter maintainers review dozens of PRs. A clear, well-written description gets reviewed faster and builds trust with the team.

For each of my PRs I included a reference to the parent issue (#177414), a plain description of what I changed and why, and confirmation that I had run the relevant tests locally.

My commit message format was consistent across all four PRs:

Remove Material dependency from [filename]

Part of #177414

Step 5: The Review Process

This is the part most people are afraid of. Google engineers reading your code.

The reality is that Flutter maintainers are professional and constructive. They want contributions to succeed. On PR #181951 (Move SelectionArea web test from widgets to material folder) I received 17 review comments. On #181903 I received 12. These were not rejections. They were detailed, specific feedback that made the final code better.

The review on #181951 was particularly educational. The SelectionArea web test needed to move from the widgets test folder to the material test folder because it relied on material-specific behavior. A reviewer caught a subtle dependency I had missed and walked me through the correct fix. That kind of direct feedback from framework engineers is genuinely invaluable.

I addressed every comment, pushed updates, and waited for re-review. The turnaround was faster than I expected.

The 4 Merged PRs

Here is the full list of what got merged:

PR #181903 — Refactor autofill_group_test.dart to remove Material dependencies
Merged February 19. 12 review comments. Tagged: framework.

PR #181951 — Move SelectionArea web test from widgets to material folder
Merged February 19. 17 review comments. Tagged: f:material design, framework.

PR #182141 — Remove Material dependency from transformed_scrollable_test.dart
Merged February 13. Tagged: f:scrolling, framework.

PR #182211 — Remove Material dependency from semantics_keep_alive_offstage_test.dart
Merged February 13. Tagged: a:accessibility, framework.

Each one built on the last. By the fourth PR I knew exactly what reviewers would look for and I addressed those things proactively in the code before they asked.

What Contributing to Flutter Actually Taught Me

The technical lesson is about dependency management and layered architecture. The Flutter framework is deliberately structured so that lower-level packages do not depend on higher-level ones. When test files break that rule, even accidentally, it signals a coupling problem that could affect how the framework evolves. Understanding this made me a better architect in my own apps.

The broader lesson is about reading a large codebase with confidence. When I started, flutter/flutter felt enormous and intimidating. After four PRs, I navigate it comfortably. That skill transfers directly to joining any large engineering team or contributing to any open source project.

The professional lesson is that open source contributions are not just resume lines. The review conversations, the back-and-forth with maintainers, the process of getting your code to a standard that ships in a framework used by millions, that is real engineering experience that very few developers have.

How to Start Your Own Flutter Contribution

Go to github.com/flutter/flutter/issues/177414. There are still files in the issue that need fixing. Pick one that has not been claimed, follow the pattern I described, and submit a PR.

Read CONTRIBUTING.md before you touch any code. Set up Flutter from source. Run the tests locally before pushing anything. Write a clear PR description that references the issue.

The Flutter team is genuinely welcoming to new contributors. The codebase is well-documented. And seeing your name in the merged commits of a framework used by millions of developers worldwide is worth every hour of the process.

Let's Connect

If you are working through your first Flutter contribution or have questions about open source in general, reach out. I am happy to help.

GitHub: github.com/gbolahan507
LinkedIn: linkedin.com/in/gbolahan507

Happy contributing.

I Built a Complete Zomato-Style Food Delivery Platform in Flutter — Here's What I Learned

Sun, 10 May 2026 10:40:13 +0000

Just shipped Zesto — a full food delivery ecosystem with 4 Flutter
apps and a Firebase backend. Here's what the build taught me.

What's in the project

Customer App — OTP login, restaurant discovery, cart,
Razorpay payments, live driver tracking on Google Maps
Driver App — auto job assignment, step-by-step delivery
slider, background GPS foreground service
️ Restaurant App — real-time order dashboard, menu management
️ Admin Panel — Flutter Web, multi-city management

Backend: 20+Firebase Cloud Functions (Node.js 18)

3 Things That Bit Me Hard

Never trust client-side prices
My original placeOrder Cloud Function accepted grand_total from
the app. Anyone could send grand_total: 1 and get free food.
Fixed by recalculating everything server-side from Firestore menu
prices — never touching the client value.
Status string consistency across 4 apps
Flutter enums use camelCase by default (arrivedAtRestaurant).
Firestore stored snake_case (arrived_at_restaurant). Silent
mismatches everywhere. Lesson: standardize from day one and use
a safe parser that never throws on unknown values.
MobX reactions fire on every change — not just the first one
My HomeScreen reaction was pushing a new delivery screen every time
activeJob updated — including status changes while the driver was
already on the delivery screen. Three screens deep by the time the
order was delivered. A single boolean guard fixed it.

Tech Stack
Flutter 3.11+ · Dart · Firebase · Razorpay
Google Maps · MobX · Node.js 18 · GeoFlutterFire

The source code is available
If you're building something similar or want a real production
Flutter/Firebase codebase to learn from:
https://morningstar47jb.gumroad.com/l/tnevss
Demo video: https://youtube.com/shorts/rL2M5O5Tk50
Happy to answer any architecture questions in the comments.

The Coordinated BLoC Pattern in Flutter — A Practical Guide

Sat, 09 May 2026 08:12:03 +0000

The Coordinated BLoC Pattern in Flutter — A Practical Guide

This post is based on real production code. Every mistake documented here was hit in the wild, debugged, and understood the hard way.

At first, coordinating multiple BLoCs from initState feels harmless.

Then the screen grows.

Now:

some data depends on the authenticated user
some sections support silent refresh
some should show loading spinners
some should skip fetching if cached
pull-to-refresh has different behaviour than initial load

And suddenly your screen becomes the orchestration layer for half the app.

This article covers a pattern for extracting that orchestration into its own BLoC: the Coordination BLoC pattern.

More importantly, it covers the production mistakes this pattern introduces — especially the ones that fail silently.

What Problem Does This Solve?

Imagine a home screen that needs data from three different sources:

meditation groups
saadhna progress
user favourites

Each has its own BLoC.
Each BLoC is independent.
But they all need to be triggered together after the user's profile loads.

You also want smart refresh behaviour:

if data is fresh → silently refresh in background
if data is missing → show loading state
pull-to-refresh should force reload everything

Naively, you handle all of this inside initState:

@override
void initState() {
  super.initState();

  final profileState = context.read<ProfileBloc>().state;

  if (profileState is ProfileLoaded) {
    context.read<HomeMeditationGroupsBloc>()
        .add(FetchHomeMeditationGroups());

    context.read<SaadhnaBloc>()
        .add(FetchAllSaadhnaGroups());

    context.read<UserFavouritesBloc>()
        .add(FetchUserFavouriteMeditations(profileState.id));
  }
}

At first this works fine.

Then more conditions appear:

freshness checks
silent refreshes
auth dependencies
feature flags
retry behaviour
analytics
cross-bloc coordination

And now your screen knows too much about how loading works.

The Coordination BLoC pattern extracts orchestration logic into its own BLoC.

The screen fires one high-level event.
The coordination bloc decides what happens.

Mental Model

The coordination bloc owns:

when things load
why they load
which events should fire

The feature blocs still own:

data
business logic
rendering state

The coordination bloc orchestrates.
It does not aggregate UI state.

Architecture

                    ProfileBloc
                         │
                         ▼
             HomeCoordinationBloc
                         │
      ┌──────────────────┼──────────────────┐
      ▼                  ▼                  ▼
HomeMeditationBloc   SaadhnaBloc   UserFavouritesBloc

The coordination bloc becomes the single orchestration point for screen-level loading behaviour.

The screen no longer knows:

which blocs exist
which events they need
which dependencies they have
which refresh strategy they use

Implementation

1. Events

Keep events coarse-grained and intent-based.

sealed class HomeCoordinatorEvent {}

class HomeDataFetch extends HomeCoordinatorEvent {}

class HomeDataRefresh extends HomeCoordinatorEvent {}

Event Intent

Event	Meaning
`HomeDataFetch`	Smart load with freshness checks
`HomeDataRefresh`	Force reload everything

2. States

The coordination bloc does not own feature data.

Its responsibility is orchestration, not aggregation.

sealed class HomeCoordinatorState {}

class HomeCoordinatorInitialState
    extends HomeCoordinatorState {}

The UI still reads directly from feature blocs:

BlocBuilder<HomeMeditationGroupsBloc,
    HomeMeditationGroupsState>(
  builder: (context, state) {
    // render UI
  },
)

This separation is important.

The coordination bloc coordinates behaviour.
The feature blocs remain the source of truth.

3. The Coordination BLoC

The key idea

The screen fires one event:

HomeDataFetch()

The coordination bloc decides:

which blocs should refresh
whether data is stale
whether loading should be silent
whether user context is required

class HomeCoordinationBloc
    extends Bloc<HomeCoordinatorEvent,
        HomeCoordinatorState> {

  final HomeMeditationGroupsBloc
      homeMeditationGroupsBloc;

  final SaadhnaBloc saadhnaBloc;

  final UserFavouritesBloc
      userFavouritesBloc;

  final ProfileBloc profileBloc;

  late StreamSubscription profileSubscription;

  HomeCoordinationBloc({
    required this.homeMeditationGroupsBloc,
    required this.saadhnaBloc,
    required this.userFavouritesBloc,
    required this.profileBloc,
  }) : super(HomeCoordinatorInitialState()) {

    // Register handlers FIRST
    on<HomeDataFetch>(_fetchData);
    on<HomeDataRefresh>(_refetchData);

    // Trigger immediately if already loaded
    if (profileBloc.state is ProfileLoaded) {
      add(HomeDataFetch());
    }

    // Otherwise wait for profile load
    profileSubscription = profileBloc.stream
        .where((state) => state is ProfileLoaded)
        .take(1)
        .listen((_) {
          add(HomeDataFetch());
        });
  }

  void _fetchData(
    HomeDataFetch event,
    Emitter emit,
  ) {
    final userId =
        (profileBloc.state as ProfileLoaded).id;

    final isMeditationFresh =
        homeMeditationGroupsBloc.state
            is HomeMeditationGroupsFetched;

    final isSaadhnaFresh =
        saadhnaBloc.state
            is SaadhnaGroupsFetched;

    final isFavFresh =
        userFavouritesBloc.state
            is UserFavouritesFetched;

    homeMeditationGroupsBloc.add(
      isMeditationFresh
          ? SilentRefreshHomeMeditationGroups()
          : FetchHomeMeditationGroups(),
    );

    saadhnaBloc.add(
      isSaadhnaFresh
          ? RefetchAllSaadhnaGroups()
          : FetchAllSaadhnaGroups(),
    );

    userFavouritesBloc.add(
      isFavFresh
          ? RefetchUserFavouriteMeditations(userId)
          : FetchUserFavouriteMeditations(userId),
    );
  }

  void _refetchData(
    HomeDataRefresh event,
    Emitter emit,
  ) {
    final userId =
        (profileBloc.state as ProfileLoaded).id;

    homeMeditationGroupsBloc.add(
      RefreshHomeMeditationGroups(),
    );

    saadhnaBloc.add(
      FetchAllSaadhnaGroups(),
    );

    userFavouritesBloc.add(
      RefetchUserFavouriteMeditations(userId),
    );
  }

  @override
  Future<void> close() {
    profileSubscription.cancel();
    return super.close();
  }
}

Dependency Injection (GetIt)

This is where most production bugs come from.

sl.registerLazySingleton(
  () => HomeMeditationGroupsBloc(
    getMeditationGroupsByType: sl(),
  ),
);

sl.registerLazySingleton(
  () => SaadhnaBloc(
    getAllGroups: sl(),
  ),
);

sl.registerLazySingleton(
  () => UserFavouritesBloc(),
);

sl.registerLazySingleton(
  () => HomeCoordinationBloc(
    homeMeditationGroupsBloc: sl(),
    saadhnaBloc: sl(),
    userFavouritesBloc: sl(),
    profileBloc: sl(),
  ),
);

BLoC Providers

BlocProvider<UserFavouritesBloc>(
  create: (context) => sl<UserFavouritesBloc>(),
),

BlocProvider<HomeMeditationGroupsBloc>(
  create: (context)
      => sl<HomeMeditationGroupsBloc>(),
),

BlocProvider<SaadhnaBloc>(
  create: (context) => sl<SaadhnaBloc>(),
),

BlocProvider<HomeCoordinationBloc>(
  create: (context)
      => sl<HomeCoordinationBloc>(),
),

The Screen

The screen now knows nothing about orchestration.

@override
Widget build(BuildContext context) {
  return LiquidPullToRefresh(
    onRefresh: () async {
      context.read<HomeCoordinationBloc>()
          .add(HomeDataRefresh());
    },
    child: ListView(
      children: [
        BlocBuilder<
            HomeMeditationGroupsBloc,
            HomeMeditationGroupsState>(
          builder: (context, state) {
            // render section
          },
        ),
      ],
    ),
  );
}

Mistakes to Not Make

Mistake 1: Registering Handlers After Calling `add()`

This causes a runtime Bad state error.

// WRONG
HomeCoordinationBloc(...)
    : super(HomeCoordinatorInitialState()) {

  if (profileBloc.state is ProfileLoaded) {
    add(HomeDataFetch());
  }

  on<HomeDataFetch>(_fetchData);
}

// CORRECT
HomeCoordinationBloc(...)
    : super(HomeCoordinatorInitialState()) {

  on<HomeDataFetch>(_fetchData);

  if (profileBloc.state is ProfileLoaded) {
    add(HomeDataFetch());
  }
}

The BLoC library checks for a handler immediately when add() is called.

Constructor order matters.

Mistake 2: Using `registerFactory`

This bug is especially nasty because everything appears to work — except the UI never updates.

// WRONG
sl.registerFactory(
  () => HomeMeditationGroupsBloc(...),
);

What happens:

Coordination bloc gets Instance A
UI listens to Instance B
Events fire correctly
Data loads correctly
UI never rebuilds

Two blocs.
Two states.
Zero visible errors.

// CORRECT
sl.registerLazySingleton(
  () => HomeMeditationGroupsBloc(...),
);

Rule

Any bloc referenced by a coordination bloc should usually be a singleton.

Mistake 3: Forgetting to Cancel Stream Subscriptions

// WRONG
@override
Future<void> close() => super.close();

// CORRECT
@override
Future<void> close() {
  profileSubscription.cancel();
  return super.close();
}

Otherwise the subscription can attempt to call add() on a closed bloc.

Mistake 4: Forgetting `.take(1)`

Without .take(1):

profileBloc.stream
    .where((state) => state is ProfileLoaded)
    .listen((_) => add(HomeDataFetch()));

Every future ProfileLoaded state retriggers fetches.

That can create phantom refreshes after:

token refreshes
profile edits
re-authentication

Usually you only want the first load:

profileBloc.stream
    .where((state) => state is ProfileLoaded)
    .take(1)
    .listen((_) => add(HomeDataFetch()));

Mistake 5: Mixing `GetIt` and `context.read`

// Confusing and unnecessary
_homeCoordinationBloc =
    GetIt.instance<HomeCoordinationBloc>();

Then later:

context.read<HomeCoordinationBloc>()

Pick one access pattern.

If the bloc comes from BlocProvider,
prefer context.read<X>().

Mistake 6: Leaving Half the Logic in the Screen

Once you introduce a coordination bloc, commit to it.

// Split ownership
context.read<HomeCoordinationBloc>()
    .add(HomeDataFetch());

context.read<SaadhnaBloc>()
    .add(FetchAllSaadhnaGroups());

Now orchestration lives in two places.

That is worse than either approach alone.

The Hidden Cost: Forced Singletons

This pattern introduces a real architectural tradeoff.

Your feature blocs now live for the entire app lifecycle.

That means:

cached state survives navigation
previous data persists
memory usage increases
state does not automatically reset

This is usually correct for:

home feeds
dashboards
cached content
long-lived tabs

This is usually dangerous for:

forms
temporary workflows
checkout flows
wizard-style screens

Do not accidentally turn screen-scoped state into app-scoped state.

When To Use This Pattern

Use it when:

3+ blocs must coordinate together
another bloc's state gates loading
loading logic contains real conditions
orchestration is reused across screens
refresh behaviour is non-trivial

When NOT To Use It

Do not use it when:

you're only triggering 1-2 blocs
coordination is just sequential add() calls
the screen logic is still simple
feature blocs should remain screen-scoped

In those cases, a BlocListener is simpler and cleaner.

The Simpler Alternative

For smaller flows:

BlocListener<ProfileBloc, ProfileState>(
  listenWhen: (prev, curr) =>
      curr is ProfileLoaded &&
      prev is! ProfileLoaded,

  listener: (context, state) {
    final userId =
        (state as ProfileLoaded).id;

    context.read<HomeMeditationGroupsBloc>()
        .add(FetchHomeMeditationGroups());

    context.read<SaadhnaBloc>()
        .add(FetchAllSaadhnaGroups());

    context.read<UserFavouritesBloc>()
        .add(
          FetchUserFavouriteMeditations(
            userId,
          ),
        );
  },

  child: YourScreen(),
)

This solution:

is smaller
avoids singletons
avoids stream subscriptions
avoids an extra bloc entirely

Start here first.

Graduate to coordination blocs only when the orchestration becomes genuinely complex.

Summary

	Coordination BLoC	BlocListener
Complexity	High	Low
Testability	High	Medium
Reusability	High	Low
Singleton Requirement	Usually Yes	No
Best For	Complex orchestration	Simple fan-out logic

The Coordination BLoC pattern is a real solution for real complexity.

The mistake is introducing it too early.

Start simple.
Escalate only when the orchestration actually demands it.

Why Senior Architects are Banning AI from their Learning Stack

Fri, 08 May 2026 13:43:06 +0000

In 2026, the software industry is fiercely obsessed with one metric: velocity. We now have generative tools capable of scaffolding an entire Flutter CRUD application from a single sentence prompt.

But for a Senior Architect, velocity without deep understanding isn't a superpower. It's just technical debt with a faster delivery date. My deep motivation for learning new stacks like migrating from Flutter to React Native and Expo without the aid of AI is incredibly simple: Intuition cannot be outsourced.

To lead a high performing engineering team, you must understand the "metal." You need to know exactly why a frame drops, how memory is allocated and garbage collected in the heap, and the precise mechanics of how the bridge communicates. If an AI writes your code, you aren't actually learning the framework; you are merely learning how to review a machine's guesswork.

The "Black Box" of Automated Development

The real danger of AI-driven development isn't that the code fails to work it's that it frequently works by accident. For enterprise-level applications, this creates three critical, systemic failures:

Architectural Drift: AI fundamentally favors "flat" and expedient structures. It will happily embed complex business logic directly inside UI widgets because that is the shortest mathematical path to a functional output. In a scalable, long-term project, this violates Clean Architecture principles and renders comprehensive testing nearly impossible.
The Debugging Ceiling: When you inevitably hit a high-level performance bottleneck such as noticeable lag rendering a real-time logistics map an AI-reliant developer hits a wall. Because they never manually traced the Widget Lifecycle or fully understood the Render Pipeline, they lack the foundational context required to isolate the root cause.
Dependency Bloat: LLMs frequently suggest outdated, heavy, or bloated packages to solve relatively simple problems that a senior engineer would handle natively perhaps with a custom Dart FFI or a lightweight platform channel.

The Solution: My Blueprint for Manual Mastery

To remain a top-tier engineer, I follow a "Manual First" approach. Here is how I ensure I actually own my knowledge:

Master the Bridge, Not Just the Syntax I don't just learn how to render a list. I learn how the engine (like JavaScript/Hermes) communicates with native threads. Understanding this overhead is the difference between a "working" app and a "smooth" 120fps experience.
Implement Design Patterns Manually Instead of letting an LLM generate boilerplate, I manually implement patterns like BLoC. Writing the events and managing the streams myself builds a mental map of the data flow. This intuition is what allows me to predict bugs before they happen.
Optimize at the Hardware Level True seniority is found where the framework ends and the hardware begins. In my work on the zerocopy package, I used Dart FFI and C++ to eliminate the "copy tax" when handling large binary data. This level of optimization requires a deep understanding of memory that AI-generated code currently cannot replicate.

AI is an Accelerator, Not a Teacher

Don't get me wrong AI is incredibly important. Once you know a stack inside and out, absolutely use AI to write your repetitive boilerplate, generate your unit tests, and speed up your workflow. AI is an unmatched accelerator. But it is a terrible teacher of fundamentals.

If you want to be an Architect who actually leads teams, builds scalable apps, and solves the impossible bugs, you have to build your mental map yourself. You have to write the state management manually. You have to understand how the JS engine actually talks to the native UI bridge. By choosing "Manual Mastery" when learning something new, you aren't being a dinosaur. You're building the foundation required to fix the complex problems that AI will inevitably create.

(Want to see what this looks like in practice? Check out some of my deep-dive work at momarkhan.com).

I'm curious to hear from other devs how do you balance using AI for speed vs actually learning the core of a new framework? Let's talk in the comments.

Minha Experiência Estruturando uma Pipeline Mobile CI/CD Flutter

Fri, 08 May 2026 12:19:10 +0000

Recentemente, enfrentei o desafio de estruturar uma pipeline de CI/CD completa para um aplicativo corporativo desenvolvido em Flutter. O objetivo era claro: automatizar, proteger e agilizar o deploy para Android e iOS. Neste artigo, compartilho os aprendizados, as soluções para os obstáculos encontrados e os exemplos práticos que formaram a espinha dorsal dessa implementação.

Por que investir em CI/CD mobile?

Em um cenário de desenvolvimento ágil, automatizar os processos de build, teste e deploy não é um luxo, mas uma necessidade. Para aplicações mobile, essa urgência é amplificada: os builds são demorados e consomem recursos, as dependências evoluem rapidamente e cada loja de aplicativos (Google Play e App Store) impõe seu próprio conjunto de regras e exigências. Uma pipeline bem arquitetada garante entregas rápidas, seguras e com a consistência que um ambiente corporativo exige.

Estrutura dos Workflows

Para organizar o processo, a pipeline foi modularizada em workflows distintos no GitHub Actions. Cada workflow é uma sequência de jobs que rodam em ambientes específicos, conhecidos como runners.

Runners: São as máquinas virtuais que executam seus jobs. Para builds Android, utilizamos os runners ubuntu-latest fornecidos pelo GitHub, que são eficientes e econômicos. Para iOS, a compilação exige o macOS. Como os runners macOS do GitHub têm um custo associado, optamos por configurar um runner self-hosted em uma máquina Mac local, garantindo controle total sobre o ambiente e otimização de custos.

Dividimos nossa esteira em workflows específicos, cada um com sua responsabilidade:

feature-workflow.yml: Valida código novo, executa lint, testes unitários e análise SAST (Static Application Security Testing), garantindo qualidade e segurança desde o início.
staging-workflow.yml: Prepara builds de homologação, rodando validações e testes automatizados.
mobile-workflow.yml: Geram builds de produção e fazem o deploy para Google Play e App Store.

Controle dos Fluxos

Para garantir que cada etapa só rode no momento certo e que a pipeline de produção só seja executada após a validação em staging, utilizei gatilhos condicionais. Isso orquestra a transição entre ambientes de forma segura.

on:
  workflow_dispatch: # Permite disparo manual
  workflow_run:
    workflows: ["staging-workflow"] # Nome do workflow que deve terminar
    types:
      - completed # Apenas quando ele for concluído

jobs:
  build:
    # A condição abaixo garante que o job só rode se o disparo for manual
    # ou se o workflow de staging anterior tiver sido concluído com sucesso.
    if: >
      github.event_name == 'workflow_dispatch' ||
      (github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.head_branch == 'staging')
    runs-on: ubuntu-latest
    ...

Isso permite que o workflow seja disparado manualmente ou automaticamente após a conclusão bem-sucedida do workflow de staging. O uso do workflow_dispatch também foi essencial para execuções manuais e testes pontuais.

Configuração do Ambiente

Antes de qualquer build, preparei o ambiente instalando Flutter, Java e aplicando cache para dependências, acelerando o processo e evitando downloads desnecessários:

- name: Setup Flutter
  uses: subosito/flutter-action@v2
  with:
    flutter-version: ${{ env.FLUTTER_VERSION }}
    channel: stable
    cache: true

- name: Cache Flutter pub dependencies
  uses: actions/cache@v4
  with:
    path: ~/.pub-cache
    key: ${{ runner.os }}-pub-${{ env.FLUTTER_VERSION }}-${{ hashFiles('**/pubspec.lock') }}

- name: Setup Java
  uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '17'

No iOS, também utilizei cache para CocoaPods e limpei o ambiente antes de cada build:

- name: Cache CocoaPods
  uses: actions/cache@v4
  with:
    path: ios/Pods
    key: ${{ runner.os }}-pods-${{ hashFiles('**/pubspec.lock') }}

Assinatura dos Apps

A assinatura digital é obrigatória para publicação nas lojas. No Android, trabalhei com keystore e no iOS, com certificados e provisioning profiles:

- name: Setup iOS certificates
  uses: apple-actions/import-codesign-certs@v2
  with:
    p12-file-base64: ${{ secrets.CERTIFICATE_BASE64 }}
    p12-password: ${{ secrets.CERTIFICATE_PASSWORD }}

- name: Download Provisioning Profiles
  uses: apple-actions/download-provisioning-profiles@v2
  with:
    bundle-id: com.seuapp.id
    profile-type: IOS_APP_STORE
    issuer-id: ${{ secrets.APPSTORE_ISSUER_ID }}
    api-key-id: ${{ secrets.APPSTORE_KEY_ID }}
    api-private-key: ${{ secrets.APPSTORE_PRIVATE_KEY }}

O GitHub trabalha de uma forma bem peculiar com certificados, exigindo que o sejam salvos como secret em base64 e decodificado em tempo de execução no runner.

No Android, o keystore foi salvo via secret em base64 e decodificado no runner:

- name: Setup Android signing
  run: |
    echo "$KEYSTORE_BASE64" | base64 -d > android/app/keystore.jks

Jobs de Qualidade

Implementei jobs de lint, testes unitários e análise estática de segurança (SAST) para garantir qualidade e segurança:

- name: Lint Flutter
  run: flutter analyze

- name: Testes Unitários
  run: flutter test --coverage

- name: SAST com MobSF
  uses: MobSF/mobsfscan@main
  with:
    args: .

O SAST foi crucial para identificar vulnerabilidades cedo, especialmente em apps que lidam com dados sensíveis. Cada job gera relatórios que ajudam a manter a qualidade do código alta.

Deploy Automatizado

Com os builds assinados, o último passo é o deploy, utilizei actions específicas para upload dos builds:

Android:
r0adkll/upload-google-play@v1 para enviar o bundle diretamente à Google Play.
iOS:
apple-actions/upload-testflight-build@v3 para subir o IPA ao TestFlight.

Exemplo de upload para TestFlight:

- name: Upload app to TestFlight
  uses: apple-actions/upload-testflight-build@v3
  with: 
    app-path: ${{ steps.find-ipa.outputs.ipa-path }}
    issuer-id: ${{ secrets.APPSTORE_ISSUER_ID }}
    api-key-id: ${{ secrets.APPSTORE_KEY_ID }}
    api-private-key: ${{ secrets.APPSTORE_PRIVATE_KEY }}

Dificuldades e Aprendizados

Um dos maiores desafios foi adaptar o pipeline iOS para rodar em runner Mac self-hosted, já que o GitHub Actions não oferece MacOS gratuito. Também precisei ajustar versões de Java e Gradle para evitar conflitos e falhas silenciosas nos builds Android.

No fim, consegui uma esteira automatizada, segura e eficiente, que valida, testa, assina e publica os apps nas lojas com mínimo esforço manual. Se você está montando sua pipeline mobile, recomendo investir tempo nos jobs de qualidade, na configuração de secrets e no controle dos fluxos. O resultado compensa!

Optimizing Flutter Apps: A Deep Dive into Dart DevTools

Fri, 08 May 2026 09:59:05 +0000

Most Flutter developers know how to build apps. Far fewer know how to build fast ones. The gap between a good app and a great one often isn't in the features. It's in the frames dropped, the memory leaked, and the milliseconds lost.

Dart DevTools is your toolkit for closing that gap. This guide walks through each of its major panels, what they're good for, and how to actually use them on a real app.

Before you start: Always profile in profile mode, not debug mode. Debug mode runs with extra assertions and overhead that will skew every reading you take.
flutter run --profile

The Flutter Inspector gives you a live, interactive view of your widget tree. Think of it as browser DevTools, but for your UI hierarchy. Here are the four toggles you'll use most.

Slow Animations

Complex animations can be impossible to debug at full speed. Toggling Slow Animations in the Inspector, or setting this in code, drops them to 20% speed so you can catch glitches frame by frame.

import 'package:flutter/scheduler.dart';

void main() {
  timeDilation = 5.0; // 5× slower
  runApp(const MyApp());
}

Guidelines & Baselines

Enables visual overlays that draw:

Scroll direction indicators on scrollable widgets
Widget boundaries (render object outlines)
Text baselines to catch misaligned typography

This is particularly useful when you suspect a layout issue but cannot pinpoint which widget is the culprit.

Highlight Repaints

Every time a widget repaints, it flashes a continuous stream of color. If your entire screen is flashing because a small loading spinner is animating, you have a problem.

I once traced a scrolling jank issue to a blinking typing indicator that was forcing an entire chat screen to repaint every frame.

The fix is a RepaintBoundary. It tells Flutter to isolate that subtree into its own render layer, so its repaints do not cascade upward.

RepaintBoundary(
  child: MyAnimatedWidget(),
)

Use this around widgets that animate independently, such as loaders, progress bars, and live counters.

Highlight Oversized Images

If an image is decoded at 2000×2000px but displayed at 100×100px, you're wasting memory on 39,900 pixels that will never be seen. This toggle shows them as negative and rotates them as shown in the image

The fix is straightforward. Constrain decoding at the source:

Image.network(
  'https://example.com/large-image.jpg',
  cacheWidth: 200,
  cacheHeight: 200,
)

Flutter will downsample the image before caching it, significantly reducing memory pressure on image-heavy screens.

2. App Size Analysis — Know What You're Shipping

A bloated app takes longer to download, longer to install, and gives a worse first impression before the user has even launched it. The --analyze-size flag gives you a breakdown of exactly what's eating into your bundle.

For Android

flutter build apk --analyze-size

For iOS

flutter build ipa --analyze-size

This outputs a JSON file that you import directly into DevTools. Once loaded, you get two views:

Dominator Tree

Shows which packages are responsible for the largest chunks of your app size. If a utility package you barely use is claiming 3MB, it is worth reconsidering.

Call Graph

Maps how your dependencies import each other. This is how you find transitive dependencies you did not know you had. A package pulls another package, which pulls another, each silently adding weight.

Size is a feature.

3. Performance & Jank Tracking — Chasing Smooth Frames

The target is 60 frames per second. That gives each frame exactly 16.6 milliseconds to build and render. Any frame that exceeds this budget is called a jank, and users feel every one of them, even if they cannot name what's wrong.

The Performance tab lets you:

Record a session of real app interactions
View a flame chart of frame build times
Click into expensive frames to see exactly which build, layout, or paint call consumed the most time

The key is to record specific interactions rather than letting it run indefinitely. Navigate to the screen you suspect is slow, hit record, reproduce the issue, then stop. A focused recording is far easier to read than five minutes of noise.

Look for the red frames in the timeline. Those are your jank frames. Drill into them, and you'll usually find one of three things:

An expensive build() method
An unnecessary full-tree rebuild
A synchronous operation blocking the main thread

Heavy JSON parsing, large computations, or image processing should not run on the UI isolate. Move them to another isolate using compute() whenever possible.

final result = await compute(parseLargeJson, jsonString);

4. Network & CPU Profiling — Under the Hood

Network Tab

If you've ever tried to debug an API issue by reading through a wall of flutter: {...} in the debug console, the Network tab will feel like a revelation.

It captures every HTTP request your app makes and displays:

Full request and response headers
Response body and status codes
Request timing and duration

No more print-statement archaeology. You can see at a glance if a request is failing, slow, or returning unexpected data.

CPU Profiler

The CPU Profiler records a flame chart of method calls while your app runs. When something feels sluggish but the Performance tab does not show obvious jank, this is where you look.

It is especially good for catching:

Expensive operations accidentally running on the main isolate
Framework callbacks firing more often than expected
Third-party packages with surprisingly heavy footprints

5. Memory & Debugger — Stability Under Pressure

Memory Tab

Memory leaks are silent killers. Your app might run perfectly in testing and degrade over time in production as memory accumulates and is never released.

The most common culprit in Flutter is forgetting to dispose() objects that hold onto resources.

class MyWidget extends StatefulWidget { ... }

class _MyWidgetState extends State<MyWidget>
    with SingleTickerProviderStateMixin {

  late AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      vsync: this,
      duration: const Duration(seconds: 1),
    );
  }

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

The Memory tab shows a real-time chart of heap allocation. If memory climbs steadily as you navigate through your app and never comes back down, you likely have a leak.

Reproduce the navigation repeatedly and watch the graph. A healthy app's memory should stabilize over time.

Debugger

The built-in debugger supports:

Breakpoints
Step-through execution
Variable inspection

All without leaving DevTools.

This is useful for tracking down logic bugs that only appear in certain states, or for understanding a complex call chain without littering your codebase with print() calls.

Key Principles to Take Away

Profile Mode Is Non-Negotiable

Debug mode adds overhead that makes everything look slower than it is. Measure performance in profile mode, always.

Do Not Optimize Blindly

Reach for DevTools when you observe a real problem:

A user complaint
A visible stutter
A reported crash

Premature optimization creates complexity without measurable benefit.

Older Devices Are Your Benchmark

An app that runs smoothly on a flagship device might choke on a three-year-old mid-range phone. Test on the weakest hardware your users are likely to have.

Dart DevTools removes the guesswork from Flutter performance.

Each panel answers a specific category of question:

What's rendering
What's too big
What's too slow
What's leaking

Use them together, and you'll spend less time wondering why your app feels sluggish and more time fixing it.

Thanks to Aswin Gopinathan for this wonderful workshop, from which I got the knowledge for this blog. Do check it out on Youtube

Building a social app for Latam as a solo founder

Thu, 07 May 2026 18:28:13 +0000

Original Article Link

The real decisions behind Peekr — stack choices, designing for Spanish and Portuguese markets, building an algorithmic feed without a data team, and the honest tradeoffs of going solo.

I've been building Peekr for about six months. It's a social app for movies and TV shows — think Letterboxd meets a social graph, designed specifically for Latin America. Users rate content, follow friends, build watchlists, and get recommendations based on what people they actually know are watching.

I'm building it alone. One founder, no co-founder, no team. Everything from the Flutter app to the Supabase backend to the Next.js web app to the automated content pipeline — all of it. This article is about the decisions that actually mattered, the ones I'd make the same way again, and the ones I wouldn't.

Why LATAM, and why that changed everything

Most social apps treat Latin America as an afterthought — an English product with a Spanish translation bolted on afterward. Localization as a checkbox. I wanted to build something where Spanish and Portuguese were first-class citizens from day one, not just in copy but in content, in cultural references, in the algorithm.

This decision had real technical consequences. I use es-419 (Latin American Spanish ISO code) everywhere TMDB supports it, not es-ES. I built a multilingual article system from the start — every piece of content is authored in three languages simultaneously. The routing is /es/, /en/, /pt/ with proper hreflang alternates and JSON-LD structured data for each. Google treats them as separate pages targeting different markets.

It also changed my content strategy entirely. The Hollywood trade press (Variety, THR) has zero search demand in LATAM. Nobody in Argentina searches for "Gwyneth Paltrow goop discount." They search for "El Eternauta qué ver después" or "filmografía Jackie Chan." I had to build my content pipeline around that reality, not copy what English-language apps do.

The stack: Flutter + Supabase + Next.js

I chose Flutter for the mobile app. In 2024, this is still a somewhat contrarian choice — React Native has more ecosystem, more hiring pool, more Stack Overflow answers. But I'd used Flutter before and I knew I could ship faster alone. One codebase for iOS and Android, hot reload, excellent widget system. The productivity advantage of knowing a framework deeply beats the theoretical advantages of a more popular one when you're a team of one.

Supabase was the clearest decision I made. Postgres at the core means I can write real SQL — window functions, CTEs, complex joins — without fighting an ORM abstraction. Row Level Security handles auth at the database level. Edge Functions (Deno) let me run server-side logic without managing infrastructure. Realtime subscriptions power the social feed. The entire backend is one project, no microservices, no containers to orchestrate.

The web app is Next.js on the App Router, deployed on Vercel. Mostly for SEO — the mobile app is the primary product, but a crawlable web presence with proper meta tags, OpenGraph, and structured data is how you get indexed by Google before you have enough backlinks to matter. Actor pages, title pages, article pages — all server-rendered, all indexed.

Building an algorithmic feed without a data team

The social feed in Peekr is the hardest engineering problem I've worked on as a solo developer. The goal is to surface content that's genuinely interesting — not just chronological, not just popular, but personalized to your specific social graph and taste profile.

I built it in Postgres. A single SQL query with a weighted scoring function: recency, engagement velocity, social graph proximity (do you follow the person who rated this?), genre affinity, and a novelty penalty to avoid showing the same titles repeatedly. The query runs in under 100ms for most users. No Redis, no separate recommendation service, no ML pipeline.

Is it as good as what Netflix has? Obviously not. Is it good enough to be useful and feel personal? Yes. The insight is that for a social app at early scale, the social graph signal is so strong that you don't need sophisticated ML — if your friend who has similar taste just watched something and rated it 8/10, that's more valuable than any collaborative filtering model.

The content pipeline: automating what a team would do

One person can't produce enough content to keep a social platform active. I built an automated pipeline using Supabase Edge Functions, Gemini 2.0 Flash, and pg_cron.

The daily brief system sends me three content options every morning via Telegram. I approve one, it generates a full Instagram carousel with AI-written copy and poster images, and schedules it for publication. No manual writing, no manual posting. The approval step keeps me in the loop without creating a bottleneck.

For SEO, I built a separate content queue: actor filmographies, "what to watch after X" articles, each generated in Spanish, English, and Portuguese simultaneously. Two articles publish automatically every day, backdrops from TMDB as hero images (landscape format — poster crops look terrible in article headers), internal links to every actor and title page on the site. The whole system runs without me touching it.

What I'd do differently

I underestimated how long SEO takes. The site has been indexed for six weeks and organic traffic is still minimal — mostly branded searches. The Google sandbox is real, and there's no shortcut. I should have started publishing content from month one, not month five.

I also spent too long building features before validating retention. The social graph, the algorithmic feed, the personality test — all of it was built before I had enough users to know if any of it was working. A solo founder's biggest risk is building in isolation. I should have been more aggressive about getting real users earlier, even with a rougher product.

The honest answer about going solo

It's slower than having a team. Obvious. Less obvious: it's also more focused. Every hour I spend on a feature is an hour I'm not spending on something else, which forces brutal prioritization in a way that larger teams often avoid. There's no "we could build both" — there's only "which one actually matters."

The tools available to solo developers in 2025 are genuinely different from five years ago. AI coding assistants, managed backend infrastructure, automated content pipelines — the leverage per person has increased dramatically. I'm not sure Peekr would have been buildable by one person at this scope three years ago.

Whether it works is still an open question. But it's shipping, it's indexed, and it's getting better every day — which is more than most side projects can say at month six.

Jorge Martinelli is the founder of Peekr, a social app for movies and TV shows built for Latin America. You can follow the build on Peerlist.

When a Button Should Do More Than Close

Thu, 07 May 2026 16:33:53 +0000

Some days in Flutter are not about huge refactors or dramatic crashes. Some days are about a button that says one thing and does another.

Today’s task looked harmless: clean up a few dialog buttons in an event-planning mobile app. The dialogs were already showing at the right moments. The UI looked fine enough. The copy was clear.

But then I tapped the buttons mentally and noticed the problem: most of them just closed the dialog.

That is not always wrong. Sometimes a dialog is only a nudge. Sometimes “Okay” really does mean “go away, I understand.” But if a button says “View Pending Tasks” and then only pops the modal, that is a tiny betrayal. Not catastrophic, not release-blocking, just one of those product papercuts that makes an app feel less intentional.

So the day became less about button styling and more about answering a deceptively annoying question:

The dialog was innocent

The dialog components themselves were simple Flutter widgets. A few icons, some copy, and an ElevatedButton at the bottom.

The original pattern looked roughly like this:

class DayDialog extends StatelessWidget {
  const DayDialog({super.key});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () {
        Navigator.pop(context);
      },
      child: const Text("Let's Go"),
    );
  }
}

There is nothing technically broken about that. It compiles. It works. The dialog closes.

But the app had dialogs with stronger intent:

“It’s D-Day” should take the user to the event happening today.
“You’ve got tasks waiting” should take the user somewhere useful for those tasks.
“Missed something?” should open notifications.
“One step closer” might honestly just dismiss, because it is more encouragement than navigation.

That last distinction ended up mattering. Not every button needs to become a route change just because we are in a “make buttons useful” mood.

The first useful clue: don’t make the dialog smart

The tempting mistake would have been to import screens into every dialog and let the dialog figure out where to navigate.

That would work for about five minutes.

Then the dialog layer would start knowing about event models, notification screens, task picking rules, dashboard cache, route transitions, and probably someone’s lunch order if I looked away long enough.

The cleaner move was to keep the dialogs dumb and let the screen that shows them inject behavior.

So the dialog becomes callback-driven:

class DayDialog extends StatelessWidget {
  final VoidCallback? onLetsGo;

  const DayDialog({
    super.key,
    this.onLetsGo,
  });

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () {
        if (onLetsGo != null) {
          onLetsGo!();
          return;
        }

        Navigator.pop(context);
      },
      child: const Text("Let's Go"),
    );
  }
}

This is a small change, but it keeps the boundary clean:

The dialog owns presentation.
The home screen owns app state.
Navigation is decided where the relevant state already exists.

Flutter makes it very easy to blur those lines because BuildContext is everywhere. That convenience is lovely until every widget becomes slightly aware of the entire app.

D-Day was the easy one

The D-Day dialog had a nice property: the event it referred to was already known.

The home screen was computing the earliest upcoming event and storing it as a mapped event model. The D-Day eligibility check was based on that same event date. In plain terms, if the app says “your event starts now,” then the event to open should be the earliest event that made that condition true.

That gave us a clean action:

DayDialog(
  onLetsGo: () {
    final event = earliestEvent;
    Navigator.of(dialogContext).pop();

    if (event == null || !mounted) return;

    Navigator.of(context).push(
      MaterialPageRoute(
        builder: (_) => EventDetailsScreen(event: event),
      ),
    );
  },
);

There are two contexts here, and that is not accidental.

The dialog builder gives a dialogContext, which is the safest context for popping the dialog. The screen’s own context is then used for pushing the next route.

Could one context have worked? Probably. But “probably” is not my favorite navigation strategy, especially around dialogs. Flutter navigation bugs tend to wait until a specific route stack shape appears, then quietly ruin your afternoon.

The task dialog was less polite

The pending task dialog sounded simple:

Cool. Open pending tasks.

Except there was no single “pending tasks screen.” Also, tasks belonged to different events.

A dashboard task had enough information to know that it was incomplete and which event it belonged to, but the event details screen needed a fuller event model. So the app had two related but different pieces of state:

dashboard task summaries
full mapped events from the events response

That meant the button needed a selection rule.

We considered a few choices:

open the calendar, which is safe but broad
build a grouped pending tasks view, which is better UX but more work
open the event containing the next task needing attention

The last option felt like the best daily tradeoff. It makes the button do something concrete without inventing a new screen.

The rule became:

Find incomplete tasks.
Prefer the nearest upcoming incomplete task.
If all incomplete tasks are overdue, pick the most recently overdue one.
Find the event that owns that task.
Open event details.
If the event cannot be found, fall back to the calendar.

That sounds like a lot for one button, but it is really just product intent expressed as code.

TaskSummary? findTaskNeedingAttention(List<TaskSummary> tasks) {
  final pending = tasks.where((task) => !task.isCompleted).toList();
  if (pending.isEmpty) return null;

  final now = DateTime.now();

  final upcoming = pending
      .where((task) => task.date != null && !task.date!.isBefore(now))
      .toList()
    ..sort((a, b) => a.date!.compareTo(b.date!));

  if (upcoming.isNotEmpty) return upcoming.first;

  final overdue = pending.where((task) => task.date != null).toList()
    ..sort((a, b) => b.date!.compareTo(a.date!));

  if (overdue.isNotEmpty) return overdue.first;

  return pending.first;
}

The fallback mattered to me. Real mobile state is messy. Maybe the dashboard response has a task whose event is missing from the events response. Maybe caching gives you a slightly stale combination. Maybe the backend shape changes in some tiny way on a tired Tuesday.

In those cases, the app should still take the user somewhere useful instead of turning the button into a dead end.

The callback pattern held up

Once the dialog had a callback, the home screen could own the messy part:

PendingTasksDialog(
  onViewPendingTasks: () {
    final event = findPendingTaskEvent();
    Navigator.of(dialogContext).pop();

    if (!mounted) return;

    if (event == null) {
      openCalendarScreen();
      return;
    }

    Navigator.of(context).push(
      MaterialPageRoute(
        builder: (_) => EventDetailsScreen(event: event),
      ),
    );
  },
);

That made the dialog more reusable and the navigation more honest.

I also had to make sure the mapped event list was cached alongside the rest of the home state. Otherwise the behavior would work after a fresh fetch but fail or degrade after cached dashboard state restored. This is exactly the kind of small state detail that does not announce itself loudly. It just becomes a weird “works sometimes” bug later.

I do not enjoy future-me debugging “works sometimes.” Future-me is busy enough.

The button we left alone

The most interesting decision might have been the one where we did nothing.

There was a “One step closer” dialog shown after the user completed more tasks. The button said “Keep Planning.” At first, it looked like another candidate for navigation.

But after thinking through it, dismissing the dialog actually made sense.

That dialog is not saying “go inspect this exact object.” It is more like a little celebration. The user has made progress; the app is acknowledging it; closing the dialog returns them to whatever planning context they were already in.

Changing that button to navigate somewhere might have made the app feel jumpy. Useful is good. Over-eager is not.

This was a nice reminder that consistency does not mean every button does the same category of thing. It means every button does what its label and context imply.

Small Flutter details that mattered

A few practical details stood out:

Navigator.pop should close the dialog before pushing the next screen.
Use the dialog’s context to pop the dialog route.
Use the parent screen’s context to push the app route.
Check mounted before navigating after state-dependent callbacks.
Keep UI widgets dumb when the state lives somewhere else.
Cache all derived state needed by a callback, not only what the UI visibly renders.

None of those are groundbreaking. They are just the little edges that separate “it works in my test tap” from “this behaves reliably in the app.”

The quiet lesson

Today’s work started with dialog buttons and ended up being about intent.

A button label is a contract. If it says “View Notifications,” it should not merely close. If it says “View Pending Tasks,” it should make a reasonable decision about which task needs attention. If it says “Keep Planning,” sometimes the best behavior is simply to get out of the way.

The technical implementation was not huge: a couple of callbacks, a mapped event list, a task selection helper, and a fallback route. But the thinking behind it was the useful part.

Flutter gives us the tools to wire screens together very quickly. The harder part is deciding where the knowledge should live, what the user expects, and how much logic a tiny button deserves.

Today, one tiny button deserved more than Navigator.pop(context).

Another one did not.

That balance was the actual feature.

Why Your Flutter UI Freezes: Understanding Async, Await, Compute & Isolates

Thu, 07 May 2026 11:28:09 +0000

You're building a Flutter app. Everything feels smooth — taps register instantly, animations glide, scrolling is butter.

Then one day you load a large dataset. Maybe 15,000 transactions from a crypto API. Maybe a chunky image processing job. Maybe just a fat JSON response.

And suddenly: the UI freezes. Buttons stop responding. Animations stutter. Scrolling locks up. Users notice.

Your first instinct? Blame async/await.

Bad news: async/await is innocent. The real culprit is something more fundamental — and once you understand it, you'll never guess at Flutter performance problems again. You'll engineer around them.

The Uncomfortable Truth: Dart Is Single-Threaded

Every Flutter app runs inside a Dart isolate. That isolate has:

Its own memory
Its own event loop
One execution thread

One. Single. Thread.

Picture it as a conveyor belt:

→ RENDER FRAME → HANDLE TAP → RENDER FRAME → YOUR HEAVY WORK → RENDER FRAME →

The belt moves forward only when each item finishes. If "YOUR HEAVY WORK" takes 3 seconds, the belt stops for 3 seconds. No rendering. No touch events. Nothing.

That's your UI freeze. That's jank.

The Biggest Misconception in Flutter Development

Here's what most developers assume:

await heavyCalculation(); // "this runs in the background, right?"

Wrong.

async/await does not move work to another thread. It does not create parallelism. It does not make your code run somewhere else.

What it actually means is:

"Pause this function here. Resume it later when the Future completes."

That's it. That's the whole trick.

To prove it — this code freezes your UI completely, even with async/await:

Future<void> freezeUI() async {
  for (var i = 0; i < 1000000000; i++) {} // CPU grinding on the UI thread
}

// Calling this:
await freezeUI(); // Still freezes. async didn't save you.

The work is still running on the same isolate as your UI. await just made it look like it wouldn't.

So What Does Async-Await Actually Do Well?

Async shines when your code is waiting, not working.

When you make a network request:

final response = await http.get(Uri.parse('https://api.example.com/data'));

Here's what actually happens under the hood:

Dart initiates the request
Dart tells the OS: "ping me when this finishes"
The isolate is now free — it goes back to rendering, handling taps, running animations
When the response arrives, Dart resumes your function from where it left off

No blocking. No freezing. The isolate was idle anyway — it was waiting on the network, not computing.

This is non-blocking I/O. And async/await handles it beautifully.

The problem only starts when you stop waiting and start working.

The Dart Event Loop (And Why It Matters)

To really understand async behavior, you need to know how Dart schedules work.

Dart's event loop has two queues:

Microtask Queue (High Priority)

Used for:

Future continuations (what runs after an await)
scheduleMicrotask() calls

Event Queue (Normal Priority)

Used for:

Timer callbacks
Network/IO completions
Gesture events
Platform messages

The loop runs like this:

1. Run all synchronous code
2. Drain every pending microtask
3. Execute one event from the event queue
4. Repeat forever

This ordering has a real-world consequence. Here's a classic puzzle:

void main() {
  print("A");                                    // sync
  Future(() => print("B"));                      // event queue
  scheduleMicrotask(() => print("C"));           // microtask queue
  print("D");                                    // sync
}

Output:

A
D
C
B

Why? Because:

A and D are synchronous — they run first, in order
C is a microtask — it runs before any events
B is in the event queue — it runs last

Knowing this helps you reason about execution order, debug subtle timing bugs, and understand why async/await resumptions feel immediate (they're microtasks).

The JSON Parsing Trap

Here's where developers get burned all the time.

Your app fetches data. The network call is fine — async, non-blocking, smooth. But then:

final response = await http.get(url);               // non-blocking, isolate is free
final data = jsonDecode(response.body);             // CPU-heavy, blocks the isolate

jsonDecode on a small payload? No problem. On 15,000 transaction records? That single line can block your UI for 2–4 seconds.

The network call wasn't your enemy. The parsing was.

This is the trap: the operation after await can still freeze your UI if it's CPU-intensive.

The Fix: Isolates

An isolate is an independent Dart execution environment. It has:

Its own memory heap (completely separate from your UI isolate)
Its own event loop
Its own thread

Unlike OS threads, isolates cannot share memory. This eliminates entire classes of bugs — no race conditions, no mutex deadlocks, no shared-state corruption. Instead, isolates communicate by passing messages.

Main Isolate                    Worker Isolate
─────────────                   ──────────────
UI rendering                    JSON parsing
Touch handling       ←──────→   Image processing
Animations          (messages)  Heavy computation

While the worker isolate grinds through CPU work, your UI isolate keeps rendering at 60fps.

`compute()`: Isolates Without the Ceremony

Spawning a raw isolate involves some boilerplate. For one-off tasks, Flutter gives you compute():

// Before: freezes UI
final transactions = jsonDecode(response.body);

// After: runs in a separate isolate, UI stays smooth
final transactions = await compute(parseTransactions, response.body);

Where parseTransactions is a top-level or static function:

List<Transaction> parseTransactions(String rawJson) {
  final decoded = jsonDecode(rawJson) as List;
  return decoded.map((e) => Transaction.fromJson(e)).toList();
}

compute() under the hood:

Spawns a new isolate
Sends your data to it (via message passing — it gets copied)
Runs your function
Returns the result to the main isolate
Destroys the worker isolate

One function call. UI stays responsive. Task done in parallel.

When `compute()` Isn't Enough: Persistent Isolates

compute() is great for one-shot jobs. But spawning and destroying isolates has overhead. If you're doing continuous background work — like a live transaction feed, streaming parser, or on-device ML inference — you want a persistent isolate.

// Pseudo-code for a long-running isolate
final receivePort = ReceivePort();
final isolate = await Isolate.spawn(backgroundWorker, receivePort.sendPort);

receivePort.listen((message) {
  // Handle result from background isolate
  setState(() => _data = message);
});

Use persistent isolates when:

You're processing a continuous stream of data
You're running local AI/ML models
You have a background sync engine
The spawning overhead of compute() becomes measurable

The Decision Framework

Every time you write async code, ask: am I waiting or working?

Scenario	Use
API call / network request	`async/await`
Database read/write	`async/await`
File I/O	`async/await`
Timer / delay	`async/await`
JSON parsing (large)	`compute()`
Image processing	`compute()`
Encryption / hashing	`compute()`
One-off heavy computation	`compute()`
Streaming data parser	Persistent Isolate
On-device ML inference	Persistent Isolate
Background sync engine	Persistent Isolate

Real-World Example: Crypto Wallet Transaction Feed

Let's put it all together with a realistic scenario.

Your wallet app fetches 15,000 transactions. Naïve implementation:

// Freezes UI for multiple seconds
Future<void> loadTransactions() async {
  final response = await http.get(transactionsUrl);   // fine
  final txs = jsonDecode(response.body);              //  blocks here
  setState(() => _transactions = txs);
}

Better:

// UI stays responsive throughout
Future<void> loadTransactions() async {
  final response = await http.get(transactionsUrl);                    // non-blocking
  final txs = await compute(parseTransactions, response.body);         // off-thread
  setState(() => _transactions = txs);                                 // back on UI thread
}

List<Transaction> parseTransactions(String json) {
  return (jsonDecode(json) as List)
      .map((e) => Transaction.fromJson(e))
      .toList();
}

The user never sees a freeze. Scrolling stays smooth at 60fps while thousands of transactions parse in the background.

Common Myths, Killed

"Async/await makes my code multithreaded"
No. It handles asynchronous waiting. Multithreading requires isolates.

"If I put await before it, it won't block the UI"
Only if the work is I/O-bound. CPU-heavy code blocks regardless of await.

"compute() is some kind of magic optimization"
It's just a thin wrapper around isolate spawning. The magic is the isolate, not the function.

"Dart can only use one CPU core"
False. Each isolate can run on its own OS thread. Dart can use all your cores through isolates.

The Mental Model That Fixes Everything

Burn this into your brain:

async/await  →  for WAITING
isolates     →  for WORKING

That's the whole framework. Every Flutter performance bug related to async ultimately comes down to confusing these two. Once you stop conflating them, you stop guessing — and start building apps that are genuinely fast.

Your UI thread should only wait. Never grind.

Everything about Stateful & Stateless widgets in Flutter

Mon, 04 May 2026 03:34:50 +0000

Flutter's widget system looks deceptively simple on the surface — everything is a widget, you compose them, and the UI appears. But once you go deeper, you realize Flutter made a very deliberate architectural decision by splitting widgets into two kinds: Stateless and Stateful. Understanding why that split exists, and how the machinery behind it works, is what separates developers who use Flutter from developers who truly understand it.

Before distinguishing the two, it's worth being precise about what a widget actually is in Flutter's model.

A widget is an immutable description of a piece of UI. That's it. It's a configuration object — a blueprint. It doesn't draw anything, it doesn't hold layout state, it doesn't live on screen. It just describes what should exist.

Flutter maintains three separate trees to actually make that description come alive:

Widget tree — The lightweight, immutable descriptions you write in code. Rebuilt frequently.
Element tree — The long-lived, mutable counterpart to each widget. Elements persist across rebuilds and act as the glue between widgets and render objects.
RenderObject tree — The heavy, layout-and-paint layer. This is what actually measures, positions, and renders pixels.

This separation is critical to Flutter's performance. Rebuilding the widget tree is cheap because widgets are just Dart objects with a few fields. The element and render object trees, which are expensive to create, are preserved and updated incrementally.

Stateless Widgets

A StatelessWidget is a widget whose entire output is determined solely by its constructor arguments. Given the same inputs, it will always produce the same widget tree — there is no internal state that can change between builds.

class GreetingCard extends StatelessWidget {
  final String name;
  final String message;

  const GreetingCard({super.key, required this.name, required this.message});

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Hello, $name'),
        Text(message),
      ],
    );
  }
}

Flutter calls build() on a stateless widget when its parent rebuilds and passes it new configuration. The widget itself has no lifecycle beyond that single build() call — no initialization, no teardown, no reactive hooks.

The `const` Optimization

Stateless widgets shine when paired with const constructors. When Flutter encounters a const widget in a rebuild, it can short-circuit the entire subtree — it knows the widget is identical to the previous one (same type, same arguments, canonicalized at compile time), so there's nothing to diff.

// Flutter will never rebuild this subtree unless the parent explicitly changes it
const Icon(Icons.star, color: Colors.amber, size: 24);

For UI elements that are truly static — icons, labels, decorative containers — const is a free performance win. Make it a habit to use const wherever possible and let the Dart analyzer enforce it with the prefer_const_constructors lint.

Stateful Widgets

A StatefulWidget is for UI that needs to change over time based on user interaction, async results, animations, or any other runtime event. The key design decision Flutter made here is that the widget and its state are two separate objects.

class Counter extends StatefulWidget {
  const Counter({super.key});

  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int _count = 0;

  @override
  Widget build(BuildContext context) {
    return TextButton(
      onPressed: () => setState(() => _count++),
      child: Text('Count: $_count'),
    );
  }
}

Why separate them? Because widgets are immutable and short-lived, but state needs to persist. When Flutter rebuilds the Counter widget, it creates a brand-new Counter object — but the _CounterState instance that holds _count is kept alive by the element tree. The element simply calls widget.build() on the new widget description while retaining the existing State object beneath it.

The Stateful Lifecycle

State objects have a full lifecycle managed by the Flutter framework. Understanding each phase is essential for writing correct, leak-free Flutter code.

`createState()`

Called on the widget (not the state) to create the associated State object. This happens exactly once — when the widget is first inserted into the tree.

@override
State<MyWidget> createState() => _MyWidgetState();

`initState()`

The first method called on the State object after it's created. This is where you perform one-time initialization — subscribing to streams, setting up animation controllers, making initial API calls.

@override
void initState() {
  super.initState(); // Always call super first
  _controller = AnimationController(vsync: this, duration: const Duration(milliseconds: 300));
  _fetchInitialData();
}

initState() runs before the first build, and context is available but restricted here — you cannot call context-dependent operations like Navigator.of(context) from initState(). Use didChangeDependencies() or a post-frame callback for that.

`didChangeDependencies()`

Called immediately after initState(), and again whenever an InheritedWidget that this state object depends on changes. For example, if your widget reads from Theme.of(context) or a custom InheritedWidget, and that data changes, didChangeDependencies() fires before the next build.

@override
void didChangeDependencies() {
  super.didChangeDependencies();
  // Safe to use context-dependent APIs here
  final locale = Localizations.localeOf(context);
  _updateForLocale(locale);
}

`build()`

The only required override. Called every time the state is marked dirty — after setState(), after didChangeDependencies(), after didUpdateWidget(), and during the initial render. Must be pure and free of side effects.

`setState()`

The mechanism for signaling that internal state has changed and the widget needs to rebuild.

setState(() {
  _count++;
  _isLoading = false;
});

When you call setState(), Flutter marks the element as dirty. It doesn't trigger an immediate rebuild — instead, it schedules a frame. At the start of the next frame, Flutter walks the element tree, finds all dirty elements, and calls build() on each of them. The widget returned by build() is then reconciled against the previous widget using the element tree (more on this below).

`didUpdateWidget()`

Called when the parent rebuilds and passes a new widget instance to this state's element. The old widget is passed as an argument, giving you a chance to react to configuration changes.

@override
void didUpdateWidget(covariant MyWidget oldWidget) {
  super.didUpdateWidget(oldWidget);
  if (widget.userId != oldWidget.userId) {
    _fetchDataForUser(widget.userId);
  }
}

This is the correct place to respond to external prop changes — not initState(), which only runs once.

`deactivate()`

Called when the State object is temporarily removed from the tree — for example, when a widget is moved to a different subtree location using a GlobalKey. This is uncommon in everyday Flutter code, but important to know.

`dispose()`

Called when the State object is permanently removed from the tree. This is where you clean up resources — cancel timers, close streams, dispose animation controllers, remove listeners.

@override
void dispose() {
  _controller.dispose();
  _scrollController.dispose();
  _subscription.cancel();
  super.dispose(); // Always call super last
}

Forgetting to dispose() resources is one of the most common sources of memory leaks in Flutter apps.

How Reconciliation Actually Works

When a dirty element rebuilds, it gets a new widget from build(). Flutter then needs to decide: does the existing child element still apply, or does it need to be replaced?

Flutter checks two things in order:

Type — Is the new widget the same runtime type as the widget the element currently holds?
Key — If a key is present, does it match?

If both match, Flutter reuses the element and simply updates its widget reference. The underlying RenderObject is updated in place — expensive layout state is preserved.

If either differs, Flutter deactivates the old element, creates a new one, and mounts it. For stateful widgets, this means the State is disposed and a new one is created from scratch.

// Scenario: parent conditionally renders one of two widgets
if (_showA)
  const WidgetA()   // Type: WidgetA
else
  const WidgetB()   // Type: WidgetB — new element, old state discarded

Keys: Making Reconciliation Precise

By default, Flutter reconciles children by type and position. For static, fixed-size lists this works perfectly. But for dynamic, reorderable, or filtered lists, positional matching breaks down.

// Imagine these items get reordered from [A, B] to [B, A]
// Without keys, Flutter sees: position 0 = same type, position 1 = same type
// It reuses the same elements — the state of A bleeds into B's position
Column(
  children: [
    TodoItem(label: 'B'),
    TodoItem(label: 'A'),
  ],
)

Keys tell Flutter explicitly which element corresponds to which widget, regardless of position.

`LocalKey`

Scoped to siblings within the same parent. The common variants are:

ValueKey<T> — keyed by a value (most common, use with IDs or strings)
ObjectKey — keyed by object identity
UniqueKey — generates a new key every time (forces recreation — use deliberately)

ListView(
  children: _todos.map((todo) =>
    TodoItem(key: ValueKey(todo.id), label: todo.label)
  ).toList(),
)

Now when items reorder, Flutter correctly matches each TodoItem to its element by ID, preserving the right state in the right place.

`GlobalKey`

Unique across the entire widget tree. A GlobalKey lets you access a widget's State, BuildContext, or RenderObject from anywhere in the app.

final _formKey = GlobalKey<FormState>();

// Later:
if (_formKey.currentState!.validate()) {
  _formKey.currentState!.save();
}

GlobalKey is powerful but expensive — Flutter maintains a global registry for them. Avoid using them as a shortcut to reach into widget state; prefer proper state management patterns for that. Use GlobalKey when you genuinely need framework-level access — form validation, imperative scroll control, or moving a subtree across the tree while preserving its state.

The `mounted` Property and Async Safety

Every State object has a mounted boolean. It becomes true after initState() runs and transitions to false after dispose(). It exists to solve a specific and common problem: calling setState() after the widget has been removed from the tree.

Future<void> _loadData() async {
  final result = await repository.fetchItems(); // async gap — widget may be disposed here

  setState(() => _items = result); //  throws if widget was already disposed
}

The safe pattern:

Future<void> _loadData() async {
  final result = await repository.fetchItems();

  if (mounted) {
    setState(() => _items = result);
  }
}

This is especially important in scenarios where a user navigates away while a network call is still in flight, or when a parent removes the widget before the async operation completes. The mounted check is a lightweight guard that prevents both the exception and the logical error of mutating dead state.

When to Use Which

The choice is usually straightforward once you internalize the rule:

If the widget can fully describe its UI from its constructor arguments alone, use StatelessWidget. If it needs to track any internal state that changes over time, use StatefulWidget.

Some practical heuristics:

Pure display widgets (cards, labels, icons, decorative layouts) → StatelessWidget with const
Anything with user interaction that changes appearance (toggles, counters, form fields) → StatefulWidget
Animations → StatefulWidget with SingleTickerProviderStateMixin
Widgets that only receive state from above (via constructor or InheritedWidget) and just render it → StatelessWidget

It's also worth noting that the separation isn't just about correctness — it's about communicating intent. A StatelessWidget signals to every reader of your code: this widget has no internal moving parts. That's a strong, useful guarantee.

Putting It All Together

Flutter's architecture makes more sense when you see the whole picture at once:

Widgets are cheap, immutable blueprints. Rebuilt frequently, thrown away without ceremony.
Elements are the persistent, mutable objects that hold the tree together. They match incoming widgets to existing state.
RenderObjects are expensive and preserved. Updated in place whenever possible.
Stateful widgets get a separate State object, anchored to an element, that survives widget rebuilds.
setState() marks elements dirty and schedules a frame — not an immediate rebuild.
Reconciliation by type and key determines whether to reuse or replace elements.
Keys make that reconciliation correct when position alone isn't enough.
mounted is your safety net for async operations that outlive the widget.

Every Flutter performance tip — minimizing rebuilds, using const, lifting state appropriately, keying lists — traces back to understanding these fundamentals. Once the model is clear, the best practices follow naturally.

The Selfie Was Fine. The Pixels Were Sideways.

Fri, 01 May 2026 15:29:12 +0000

I spent part of today staring at a selfie that looked completely normal in the app until it became a profile photo.

That sentence sounds harmless. It was not harmless.

The face verification flow looked fine while running. The camera preview was upright. The liveness checks passed. The user smiled, turned left, turned right, looked up, looked down, and the app happily uploaded the images. Then the first image, the nice centered smiling one, became the user's display picture.

And suddenly the user was lying sideways.

Head on the right. Neck on the left. The kind of bug where the UI looks innocent, the backend looks innocent, and the image itself is quietly doing the wrong thing.

The suspicious part was not the avatar

My first instinct was to look at the profile image rendering. Maybe the avatar widget was doing something odd. Maybe the network image package ignored metadata. Maybe the backend transformed the image. Maybe some storage layer stripped EXIF orientation.

But the avatar was boring in the best possible way. It received a URL and rendered it with BoxFit.cover. No transforms. No rotation. No custom painting. Nothing dramatic.

The face verification flow was more interesting.

The app was using the camera stream for liveness detection. Each frame went through ML Kit face detection, and once a rule was stable enough, we captured the image for that rule. The first rule was the centered smile, which later became the display picture.

That gave the bug a shape:

preview upright
ML Kit detection working
saved/uploaded image rotated
all captured images rotated the same way

That combination usually means the display layer and detection layer know about orientation, but the saved pixels do not.

The camera stream was telling the truth, just not the truth I wanted

The important detail was that the capture path was not using takePicture().

Instead, the flow converted the exact CameraImage stream frame into a PNG. The motivation made sense: use the precise frame that satisfied the face rule. No waiting for the camera to stop streaming, no second capture after the user moved slightly, no autofocus/flicker delay. It is a tempting approach, and honestly, I still like the intent.

The rough shape looked like this:

final imagePath = await _captureFromStreamFrame(streamFrame);

Inside that helper, Android NV21 bytes were converted into BGRA pixels, then encoded as a PNG:

ui.decodeImageFromPixels(
  bgraBytes,
  image.width,
  image.height,
  ui.PixelFormat.bgra8888,
  (img) => completer.complete(img),
);

final uiImage = await completer.future;
final byteData = await uiImage.toByteData(
  format: ui.ImageByteFormat.png,
);

This is where Flutter politely allowed me to shoot myself in the foot.

Raw camera stream frames are not necessarily in the same orientation as the preview on screen. On Android especially, the camera sensor often has a native orientation that is effectively landscape relative to the way the user holds the phone. The preview widget handles that. ML Kit also gets rotation metadata, so detection can still work.

But if you manually turn the raw bytes into a PNG, nobody magically rotates those pixels for you.

You get the sensor's version of reality.

And the sensor's version of reality had my user's head rotated 90 degrees.

The part that made it slightly annoying

The obvious fix was "rotate the image."

The less obvious question was: rotate it which way?

This is where mobile camera work always gets a little slippery. You are dealing with a few concepts that sound related but are not interchangeable:

sensor orientation
device orientation
preview orientation
front-camera mirroring
saved image orientation
EXIF metadata, if you are saving JPEGs
actual pixel rotation, if you are writing PNGs

In this flow we were writing PNGs from raw pixels, so EXIF was not going to save us. The pixels themselves needed to be corrected.

The first attempt used the inverse of the camera sensor orientation:

return (360 - sensorOrientation) % 360;

It was a reasonable guess. It was also wrong for the tested device.

The image moved from sideways to upside down. Progress, technically. Emotionally, less so.

That test was useful though, because it proved two things immediately:

We were definitely fixing the right part of the pipeline.
The rotation direction needed to be flipped.

So the final working version used the reported sensor orientation directly:

int _streamFrameRotationDegrees({
  required int sensorOrientation,
}) {
  if (!Platform.isAndroid) return 0;

  return sensorOrientation % 360;
}

Then the decoded frame gets rotated before encoding:

final rotationDegrees = _streamFrameRotationDegrees(
  sensorOrientation: sensorOrientation,
);

final outputImage = rotationDegrees == 0
    ? uiImage
    : await _rotateImageClockwise(uiImage, rotationDegrees);

final byteData = await outputImage.toByteData(
  format: ui.ImageByteFormat.png,
);

The rotation helper itself is not complicated, but it is the kind of code where one swapped width/height can ruin your afternoon:

Future<ui.Image> _rotateImageClockwise(
  ui.Image source,
  int degrees,
) async {
  final normalizedDegrees = degrees % 360;
  if (normalizedDegrees == 0) return source;

  final swapsDimensions =
      normalizedDegrees == 90 || normalizedDegrees == 270;
  final outputWidth = swapsDimensions ? source.height : source.width;
  final outputHeight = swapsDimensions ? source.width : source.height;

  final recorder = ui.PictureRecorder();
  final canvas = Canvas(recorder);

  canvas.translate(outputWidth / 2, outputHeight / 2);
  canvas.rotate(normalizedDegrees * math.pi / 180);
  canvas.translate(-source.width / 2, -source.height / 2);
  canvas.drawImage(source, Offset.zero, Paint());

  final picture = recorder.endRecording();
  final rotated = await picture.toImage(outputWidth, outputHeight);
  picture.dispose();

  return rotated;
}

Once that was in place, the saved local images finally looked like what the user saw in the camera preview: head up, neck down, nobody accidentally reclining across the avatar.

A small win, but a very satisfying one.

The temporary debugging tool was worth it

One of the better decisions during this fix was not waiting for the entire upload-display-profile loop every time.

Originally, the feedback cycle was too long:

run face verification
upload images
wait for backend processing
fetch user details again
check the display picture
wonder if the bug was in capture, upload, storage, API, cache, or rendering

That is too many suspects.

So I added a temporary debug-only local preview after capture and before upload. It showed the five local files in a grid labeled center, left, right, up, and down. That made the problem brutally obvious. The images were already rotated before they ever touched remote storage.

That little preview screen did not survive the final cleanup, and it should not have. But as a debugging instrument it was perfect. It shortened the loop from "wait for the full system" to "capture and inspect the exact file."

I keep relearning this lesson: when a pipeline has too many stages, build a peephole into the middle.

Not a permanent feature. Not a grand observability platform. Just a tiny window into the thing you keep making assumptions about.

Why not just use `takePicture()`?

This came up naturally.

The signup selfie flow in another part of the app already uses takePicture(). That path is simpler because the camera plugin handles more of the normal image capture behavior for you. For many apps, that is absolutely what I would prefer.

The liveness flow had a different tradeoff. It wanted the exact frame that passed the rule. If the user smiles and holds still, we capture the stream frame that ML Kit just approved. That avoids a small but real gap between "rule passed" and "photo taken."

So there were two reasonable options:

switch back to takePicture() and lean on the camera plugin's capture behavior
keep stream-frame capture and explicitly own pixel orientation

We chose the second path because it preserved the existing liveness behavior. But choosing it means accepting the responsibility that comes with raw frames. The camera plugin is no longer your orientation babysitter at save time.

That tradeoff is fine, as long as it is intentional.

The device question

After the fix worked, the next question was the right one: will this hold across devices?

The answer is: better than a hardcoded 90-degree rotation, but still worth testing.

Different Android devices may report different camera sensor orientations, commonly 90 or 270. Some devices may even differ between front and back cameras. Using sensorOrientation is the portable part of the fix. It asks the camera what orientation it actually uses instead of assuming every phone is the one on my desk.

But there are caveats.

The current flow assumes portrait capture. If the app allows the user to rotate the phone into landscape during verification, then sensor orientation alone is not enough. We would need to account for current device orientation too.

Also, rotation and mirroring are separate problems. A front camera preview may be mirrored for a familiar selfie experience, but that does not automatically mean the saved image should be mirrored. If logos or text appear reversed, that is a horizontal flip decision, not a rotation fix.

For today's bug, the issue was rotation. The corrected saved PNG now matches the visual expectation.

The thing I am taking away

The interesting part of this bug was not that an image was rotated. That happens all the time in mobile work.

The interesting part was how many layers were technically doing the right thing:

Camera preview looked correct.
ML Kit detection worked because it received rotation metadata.
Upload worked because it uploaded exactly what it was given.
Avatar rendering worked because it displayed exactly what the URL returned.

The bug lived in the one handoff where metadata stopped being enough and pixels became permanent.

That is the kind of issue that makes mobile development feel like plumbing with opinions. Every layer has its own model of reality. Most days they agree. Today they did not.

At least now the user's face is upright.

The Day Search Wasn't Just Search

Fri, 01 May 2026 15:26:17 +0000

Some tasks arrive wearing a tiny hat.

Today’s was: “inspect the vendor search screen.” Simple enough. Search screen, endpoint response, pagination, a couple of screenshots. Nothing too wild.

Then I looked closer and realized the UI was quietly making a promise the backend data did not support.

That is usually where mobile work gets interesting. Not broken in the loud, stack-trace way. Broken in the more slippery way, where the app technically works, but the user walks away with the wrong idea.

The suspicious “Price on request”

The search endpoint was returning vendors with two different service-ish fields:

services
vendorServices

At a glance, both sounded useful. One had pricing information. The other had names like photography, lighting, security, and catering. The UI had been built to show services first, and if that list was empty, fall back to vendorServices with the label “Price on request.”

That fallback looked harmless. It even made the screen feel more complete.

But it was wrong.

The deeper distinction was this:

services represented actual bookable services with prices and service IDs.
vendorServices represented capabilities or declared service categories.

That second list was not enough to create a booking. There was no real pricing model, no service ID, and no guarantee that the item was ready for a client to book. So showing “Price on request” created a nice-looking card while hiding the truth: this vendor had not added bookable services yet.

The old logic was basically:

List<ServiceDisplay> resolveServices(Vendor vendor) {
  final services = vendor.services.map(mapPricedService).toList();

  if (services.isNotEmpty) return services;

  return vendor.vendorServices.map((service) {
    return ServiceDisplay(
      name: service.name,
      priceText: 'Price on request',
    );
  }).toList();
}

The UI was trying to be helpful, but it was flattening two different concepts into one. That is one of those bugs that does not look like a bug until you ask, “Can the user act on this?”

In this case, the answer was no.

So the better version became much more boring, and much more honest:

List<ServiceDisplay> resolveServices(Vendor vendor) {
  final services = vendor.services
      .map(mapPricedService)
      .whereType<ServiceDisplay>()
      .take(2)
      .toList();

  if (services.isNotEmpty) return services;

  return const [];
}

Then the card could render an empty state instead of pretending there was something to book.

Something like:

if (visibleServices.isEmpty) {
  return Text('This vendor has no services yet.');
}

Not glamorous. Very necessary.

The profile screen had to tell the same truth

The search card was only half the story.

The vendor profile screen already had a guard in the booking flow. If a user tapped the book button and there were no services, the app showed an error message. Technically correct, but emotionally clumsy.

From a user’s point of view, the app was saying:

“Book this vendor.”

Then after the tap:

“Actually, no.”

That is not a great contract.

So the bottom CTA had to become state-aware. If the vendor had bookable services, keep the normal booking CTA and the small chat button. If the vendor had no services, remove booking entirely and make chat the primary action.

The important part was not just disabling a button. It was changing the user’s available path:

bool get hasBookableServices => vendor?.services.isNotEmpty == true;

bool get showChatAsPrimaryCta =>
    !isLoading && vendor != null && !hasBookableServices;

That extra loading/vendor check matters. Without it, the screen could briefly think “no services” while the vendor was still loading and show the wrong CTA. Flutter will happily rebuild during every tiny state transition, so the UI has to be careful about what a state actually means.

There is a difference between:

we have loaded the vendor and they have no services
we have not loaded the vendor yet
the request failed and vendor is null

Those states can all look like “empty” if you write the condition too casually.

That was the small detail that made me pause.

Search, suggestions, and the backend contract

The next piece was the search behavior itself.

There was a text field for vendor name search, and there were suggestion chips like “Caterer,” “Event Planner,” “Baker,” and “Rentals.” Originally, tapping a suggestion sent the chip text as the name query parameter.

That worked mechanically, but conceptually it was off.

Those suggestions were not vendor names. They were category or service filters.

The temptation in a mobile app is to “fix” this locally. Filter the current list in Dart, compare strings, hide cards, call it a day. But that would have been the wrong layer. The backend already owned filtering, pagination, and matching logic. The app’s responsibility was just to call the endpoint with the right parameters and render the result.

So suggestion taps became category calls:

static const suggestionCategoryValues = {
  'Caterer': 'CATERER',
  'Sound Engineer': 'SOUND_AND_PA_SYSTEM_PROVIDER',
  'Event Planner': 'EVENT_PLANNER',
  'Rentals': 'RENTALS',
  'Food': 'FOOD_AND_BEVERAGE',
};

Future<void> onSuggestionTapped(String suggestion) async {
  final category = suggestionCategoryValues[suggestion] ?? suggestion;

  searchController.text = suggestion;
  filterCategory = category;

  await fetchVendors(
    name: null,
    category: category,
    page: 1,
  );
}

That little map is not the most exciting code in the world, but it protects the API contract. Display labels can be friendly. Query values can stay backend-shaped.

Mobile apps live in that translation layer more often than we admit.

The filter sheet caught up later

Once suggestions were using category filtering, another inconsistency appeared immediately: the bottom sheet had filters for location and price, but not category.

So category filtering existed only through suggestions. That meant users could discover it by accident, but not intentionally. Not great.

The filter sheet needed a category dropdown that did the same thing: send a category query to the backend.

The interesting decision here was what values to show and what values to send. I wanted the UI to say “Food and Beverage,” not FOOD_AND_BEVERAGE. But the API still needed the enum-style value.

So the dropdown carried backend values internally and used a display mapper for labels:

static const categoryOptions = [
  'FOOD_AND_BEVERAGE',
  'EVENT_PLANNER',
  'PHOTOGRAPHER',
  'RENTALS',
];

static const categoryLabels = {
  'FOOD_AND_BEVERAGE': 'Food and Beverage',
  'EVENT_PLANNER': 'Event Planner',
  'PHOTOGRAPHER': 'Photographer',
  'RENTALS': 'Rentals',
};

String formatCategory(String value) {
  return categoryLabels[value] ?? value.replaceAll('_', ' ');
}

This is one of those places where clean architecture is not a diagram. It is a tiny choice about which string crosses a boundary.

The app can be warm and readable. The network request can be strict and boring. Everyone wins.

The sneaky problem with clearing results

After the category dropdown went in, another UX issue showed up.

Text search had a clear button inside the search field. If I typed a vendor name, I could tap the suffix X and reset the search.

But filters from the bottom sheet did not always put visible text in the search field. So after filtering by category, location, or price, the user could see “Result(s) Found” but had no obvious way to get back to the unfiltered list.

This is the kind of detail that is easy to miss when testing happy paths. The data was correct. The request was correct. Pagination still worked. But the screen had trapped the user in a filtered state unless they reopened the sheet and manually changed things.

So I added a small clear action beside the results count.

Not a giant reset panel. Not another modal. Just an X next to:

12 Result(s) Found

That X clears:

name search
category
location
price range
suggestion state

Then it reloads page one from the backend with no filters.

The method is intentionally blunt:

Future<void> clearSearchAndFilters() async {
  searchController.clear();

  filterLocation = null;
  filterMinPrice = null;
  filterMaxPrice = null;
  filterCategory = null;
  categorySearchText = null;

  await fetchVendors(
    name: null,
    category: null,
    location: null,
    minPrice: null,
    maxPrice: null,
    page: 1,
  );
}

Sometimes the cleanest UX state reset is not clever. It is just complete.

The thing I kept coming back to

The technical work today was not hard because of algorithms. It was hard because the screen had several overlapping meanings:

A search query can be a vendor name.
A suggestion looks like text but behaves like a category filter.
A vendor can have declared capabilities but no bookable services.
A profile can be valid but not bookable.
Empty data can mean “not loaded yet” or “loaded and truly empty.”

The main lesson was that UI should not invent certainty the data does not provide.

If there are no bookable services, say that.

If the backend owns filtering, call the backend.

If a filter can be applied, give the user a way to clear it.

Tiny decisions. Big difference.

By the end, the screen felt less magical and more honest. That is usually a good trade.

Building a Zomato-Like Multi-City Food Delivery App with Flutter & Firebase

Tue, 28 Apr 2026 05:29:56 +0000

Hey everyone, Surendra Kumar here —Flutter/Firebase developer from Banda, India. I've been building production apps under Gfood Delivery Private Limited, and today I want to share the architecture behind my most ambitious project yet: Zesto, a multi-city food delivery platform built entirely with Flutter and Firebase.
Zesto isn't a tutorial project. It's a real, working platform — 4 Flutter apps, a complete Firebase backend, and architecture decisions modeled after how production platforms like Zomato actually work.
Want to try it before reading? Download the customer app APK and test it yourself:
Download Zesto Customer App https://github.com/ssurekumar01111-hue/zesto-demo/releases/download/v1.0-beta/app-release.apk
I'd love your feedback and improvement ideas after reading.

The 4-App Ecosystem
Zesto consists of four interconnected Flutter applications:

Customer App — Multi-city restaurant discovery, cart, Razorpay + wallet payments, live GPS tracking, reviews
Restaurant Partner App — Order management, menu CRUD, earnings dashboard, FCM order alerts
Driver App — Order accept/reject, live delivery tracking, earnings, payout requests
Flutter Web Admin Panel — 14 screens covering cities, zones, restaurants, drivers, orders, analytics, reviews, ads, config, and audit logs

The Core Architecture Decision: City + Zone Scoping
This is the most important architectural decision in Zesto — and the one that separates it from basic food delivery tutorials.
Every single Firestore document has two fields:
dart{
"city_id": "banda_up",
"zone_id": "banda_zone_1",
// ... rest of document
}
Every query filters by city_id first:
dartFirebaseFirestore.instance
.collection('restaurants')
.where('city_id', isEqualTo: currentCityId)
.where('is_active', isEqualTo: true)
.snapshots();
Why does this matter? Without city scoping, as you add cities your queries return restaurants from everywhere. Firestore has no built-in geographic filtering — you have to design it in from day one. Retrofitting this later would require rewriting every query and migrating every document.
Zones sit inside cities and control driver assignment. When an order is placed, the Cloud Function assigns it to available drivers in the same zone first, then expands to the full city if no zone drivers are available.

Firebase Custom Claims for RBAC
Zesto has 5 user roles: customer, restaurant_owner, driver, admin, super_admin. Managing this with Firestore documents alone creates security holes — a user could theoretically write to their own document and escalate their role.
The solution is Firebase custom claims set via Cloud Functions:
javascript// functions/src/admin/setUserRole.js
exports.setUserRole = functions.https.onCall(async (data, context) => {
if (!context.auth.token.super_admin) {

throw new functions.https.HttpsError('permission-denied', 'Not authorized');

}
await admin.auth().setCustomUserClaims(data.uid, {

role: data.role,
city_id: data.cityId,

});
});
On the Flutter side, the role is read from the ID token directly:
dartfinal token = await FirebaseAuth.instance.currentUser?.getIdTokenResult();
final role = token?.claims?['role'] as String?;
This means even if someone modifies their Firestore document, the custom claim on the token is what gates access. Firestore rules enforce this:
javascript// firestore.rules
match /orders/{orderId} {
allow read: if request.auth.token.role == 'admin'

|| request.auth.token.role == 'restaurant_owner'
|| request.auth.uid == resource.data.customer_id;

}

MobX for State Management
Zesto uses MobX across all 4 apps. Here's why I chose it over Riverpod or GetX for this project:
MobX's reactive observables map perfectly to Firestore streams. When a Firestore stream emits a new value, MobX automatically rebuilds only the widgets that consume that observable — no manual setState, no context.watch boilerplate.
dart// core/stores/order_store.dart
class OrderStore = OrderStore with $OrderStore;

abstract class _OrderStore with Store {
@observable
ObservableList activeOrders = ObservableList();

@observable
OrderStatus currentStatus = OrderStatus.placed;

@action
void updateOrderStatus(String orderId, OrderStatus status) {

final idx = activeOrders.indexWhere((o) => o.id == orderId);
if (idx != -1) {
  activeOrders[idx] = activeOrders[idx].copyWith(status: status);
}
currentStatus = status;

}
}
The store subscribes to a Firestore stream once and updates observables. Every widget that reads activeOrders rebuilds automatically. Clean, testable, no rebuild storms.

Dual Payment Path: Razorpay + In-App Wallet
Zesto supports two payment methods and they interact with each other in interesting ways.
Razorpay handles card/UPI payments. The flow is standard — create an order via Cloud Functions, open Razorpay checkout, handle the webhook callback.
The wallet is more interesting. Each customer has a wallet_balance field on their user document. When they pay via wallet:
javascript// functions/src/payments/walletPayment.js
exports.processWalletPayment = functions.https.onCall(async (data, context) => {
const uid = context.auth.uid;

return admin.firestore().runTransaction(async (transaction) => {

const userRef = admin.firestore().collection('users').doc(uid);
const userDoc = await transaction.get(userRef);

const currentBalance = userDoc.data().wallet_balance;
if (currentBalance < data.amount) {
  throw new functions.https.HttpsError('failed-precondition', 'Insufficient balance');
}

transaction.update(userRef, {
  wallet_balance: admin.firestore.FieldValue.increment(-data.amount)
});

transaction.set(admin.firestore().collection('wallet_txns').doc(), {
  uid,
  amount: -data.amount,
  type: 'debit',
  order_id: data.orderId,
  created_at: admin.firestore.FieldValue.serverTimestamp(),
});

});
});
The Firestore transaction ensures the balance check and deduction happen atomically — no race condition where two simultaneous orders drain the wallet below zero.

Cloud Functions: Domain-Split Architecture
Instead of one massive index.js, Zesto's Cloud Functions are split by domain:
functions/src/
├── orders/
│ ├── placeOrder.js # Create order, notify restaurant
│ ├── assignDriver.js # Zone-based driver assignment
│ └── onOrderDelivered.js # Earnings calculation, wallet credit
├── payments/
│ ├── razorpayWebhook.js # Payment confirmation
│ └── walletPayment.js # Wallet debit/credit
└── admin/

├── approveRestaurant.js
└── setUserRole.js

Each function is independently deployable. When I fix a bug in assignDriver.js, I deploy only that function — not the entire backend.

The Driver Assignment Problem
When an order is placed, the platform needs to assign a driver. Here's the simplified logic:
javascriptexports.assignDriver = functions.firestore
.document('orders/{orderId}')
.onCreate(async (snap, context) => {

const order = snap.data();

// 1. Find online drivers in the same zone
const driversSnap = await admin.firestore()
  .collection('drivers')
  .where('city_id', isEqualTo: order.city_id)
  .where('zone_id', isEqualTo: order.zone_id)
  .where('is_online', isEqualTo: true)
  .where('current_order_id', isEqualTo: null)
  .limit(5)
  .get();

if (driversSnap.empty) {
  // Expand to full city
  // ... same query without zone_id filter
}

// 2. Send FCM notification to available drivers
// First driver to accept wins (handled by transaction in Driver app)
const tokens = driversSnap.docs.map(d => d.data().fcm_token);
await admin.messaging().sendMulticast({
  tokens,
  data: { type: 'NEW_ORDER', order_id: context.params.orderId }
});

});
On the driver side, accepting an order uses a Firestore transaction with three guards to prevent race conditions — only one driver can claim the order even if multiple tap Accept simultaneously.

What's Coming
Zesto is launching soon on Gumroad and Codester as commercial source code — complete, ready-to-customize. It includes all 4 Flutter apps, the complete Cloud Functions backend, Firestore security rules, and developer documentation.
Try the customer app right now:
https://github.com/ssurekumar01111-hue/zesto-demo/releases/download/v1.0-beta/app-release.apk
I'd genuinely love your feedback — what works well, what feels off, what you'd build differently. Drop a comment or reach me at Emails are not allowed.

Surendra Kumar — Flutter/Firebase developer, Banda, India
Portfolio: portfolio.gfood.in | GitHub: ssurekumar01111-hue

How I Built a Complete On-Demand Home Services App (ServeNow) with Flutter & Firebase

Tue, 28 Apr 2026 04:39:08 +0000

Hey everyone, Surendra Kumar here, a self-taught Flutter developer from Banda, India. I've spent a good chunk of my time building and shipping production apps, like those I worked on for Gfood Delivery Private Limited. Today, I want to share the story behind one of my most ambitious projects: ServeNow.

As an indie developer, I've always been driven to build real solutions—apps that don't just look pretty in a tutorial but actually work robustly in the wild. That's exactly the philosophy I brought to ServeNow.

What is ServeNow? Crafting a Full-Fledged Marketplace

ServeNow isn't just another demo app. It's a complete, production-ready on-demand home services marketplace built from the ground up with Flutter and Firebase. My goal was to create a comprehensive system that could handle everything from booking a beautician to fixing a leaky faucet, all while providing a smooth experience for customers, service providers, and administrators.

To achieve this, I engineered ServeNow as a suite of four interconnected applications, each designed for a specific user role:

Customer App: This is where users come to life. They can browse various services (beauty, cleaning, plumbing, electrical, etc.), book appointments, track their service provider in real-time, chat with them, make secure payments via Razorpay, and leave reviews.
Provider App: For the businesses offering services. They can accept new bookings, manage their schedule and service offerings, track their real-time earnings, and request payouts.
Handyman App: This is for the actual service professionals. It's a multi-service pro app featuring a broadcast job matching system, allowing handymen to pick up nearby jobs. It also includes an onboarding and approval flow for new pros.
Flutter Web Admin Panel: The control center. This robust web panel gives administrators full control over users, bookings, categories, service providers, payout requests, and provides crucial analytics to keep the marketplace running efficiently.

Why Flutter & Firebase? My Tech Stack Decisions

When embarking on ServeNow, the choice of technology was critical. I needed a stack that offered rapid development, scalability, real-time capabilities, and robust performance without requiring a massive infrastructure investment.

Flutter (Dart) for the Frontend

Flutter was a no-brainer for the mobile applications and the web admin panel.

Single Codebase: Building four distinct applications (Customer, Provider, Handyman, and Admin Panel) from a single Flutter codebase drastically cut down development time and ensured UI/UX consistency across platforms.
Performance: Flutter's native compilation and widget-based architecture deliver smooth, high-performance applications that feel truly native.
Developer Experience: Hot Reload and a rich widget catalog accelerated my development cycles, allowing for quick iterations and bug fixes.

Firebase for the Backend (My Go-To for Indie Development)

Firebase has been my backend of choice for many projects, and ServeNow was no exception. It offered the complete suite of tools I needed.

Firestore: This is the heart of ServeNow's data. I chose Firestore for its real-time capabilities, strong querying, and scalability.
- Architecture Decision: I structured collections like users, services, providers, handymen, bookings, and chats. For bookings, I leaned into denormalization by embedding critical but static details (like customer name, service price) directly within the bookings document. This minimizes expensive cross-collection reads for common operations and ensures faster data retrieval, especially for lists of bookings. Subcollections were used for highly related, nested data, like messages within a chat document.
Firebase Authentication: For secure and easy user management across all apps, supporting email/password and potentially Google Sign-In for future expansion.
Cloud Functions (JavaScript): This was indispensable for server-side logic without managing actual servers.
- Architecture Decision: Cloud Functions handle critical backend tasks:
  - Razorpay Webhooks: Securely processing payment callbacks and updating booking statuses post-payment.
  - FCM Triggers: Sending real-time push notifications for booking updates, new job broadcasts (to handymen), and chat messages.
  - Data Aggregation: Calculating real-time earnings for providers and handymen, and managing payout requests.
  - Background Tasks: Handling approval flows for new handymen and providers.
Firebase Storage: For storing user profile pictures, service images, and any other media files securely.
Firebase Cloud Messaging (FCM): Essential for real-time communication between the apps – from notifying handymen about new jobs in their area to letting customers know their service provider is on the way.

Other Key Technologies:

Razorpay: Integrated as the primary payment gateway, crucial for handling transactions securely within the Indian market. Cloud Functions were vital here for handling payment success/failure callbacks.
rxdart: I leveraged rxdart for reactive programming, especially for managing complex streams of data and state within the apps, ensuring a smooth and responsive user experience.
Google Maps: Integrated for live tracking of handymen, defining service areas, and visualizing job locations.

Architectural Decisions & Overcoming Challenges

Building ServeNow meant tackling typical marketplace complexities.

Real-time Synchronization: A core requirement. Firestore's real-time listeners were used extensively. For example, when a handyman accepts a job, the customer's app updates instantly, and the provider's app reflects the booking status change. This required careful management of data updates and notification triggers via Cloud Functions.
Scalability: Thinking beyond just a few users. Firestore's inherent scalability and Cloud Functions' serverless architecture meant the platform could grow without significant re-engineering of the backend.
Job Broadcasting & Matching: This was an interesting challenge for the Handyman app. When a new service request comes in, I use Firestore queries based on service type and location, combined with FCM, to broadcast the job to eligible handymen. The first to accept gets the job, with race conditions handled by Firestore transactions in Cloud Functions.
Secure Payouts: The provider and handyman apps needed a robust payout request system. This involves tracking earnings in Firestore, initiating payout requests, and then an admin manually (or via a future integration) processing these, all managed through the Admin Panel and Cloud Functions.
Developer Documentation: Knowing that this was a complex system, I invested significant time in creating a comprehensive 16-page developer documentation (v2.0). It covers everything from project setup to API details, making it easy for anyone to get started.

The Indie Developer Ethos: Production-Grade from Day One

What makes ServeNow different is that it's built with a "production-grade" mindset. This isn't a collection of loosely connected tutorials; it's a fully integrated, tested system designed to be deployed and used in a real business environment. Every feature, every line of code, was written with stability, scalability, and maintainability in mind. It comes complete with signed APKs and a thorough setup guide, so you can literally launch it.

Building ServeNow was a journey of applying everything I've learned about Flutter, Firebase, and shipping real products. It's proof that with dedication and the right tools, indie developers can build incredibly powerful, complete solutions.

Ready to Launch Your Own Home Services Marketplace?

If you're looking for a robust, ready-to-launch foundation for an on-demand home services marketplace, ServeNow is designed to be exactly that. It handles the complexities, so you can focus on your business.

You can learn more about my work and projects like ServeNow by checking out my GitHub profile or reaching out via email.

My GitHub Profile: ssurekumar01111-hue
Email: ssure.kumar01111@gmail.com
https://morningstar47jb.gumroad.com/l/viqos

Thanks for reading! I hope this deep dive into ServeNow gives you some insights into building complex applications as an indie developer.

Building a Resilient Real-Time WebSocket Stream in Flutter (RxDart + Clean Architecture + BLoC)

Mon, 27 Apr 2026 05:30:51 +0000

Most tutorials show how to connect to a WebSocket.

Very few show what happens when:

The network drops
DNS fails
The server stops sending data
The stream silently hangs

This article focuses on handling those cases properly.

The Problem

A basic WebSocket implementation:

final channel = WebSocketChannel.connect(uri);
channel.stream.listen(...);

Works… until real-world conditions appear:

Network loss → no error  
Stream freezes silently  
App never reconnects  
Users see stale data

The Goal

We want a stream that:

reconnects automatically
handles both errors and silent failures
retries with exponential backoff
does not crash the app
integrates cleanly with BLoC

Step 1: Deferred Connection (Rx.defer)

Instead of creating the connection immediately, we defer it:

return Rx.defer(() async* {
  final channel = _websocketService.connect();
  await channel. ready;
  yield* channel.stream;
});

This ensures that each retry creates a fresh connection.

Step 2: Handle Connection Errors

If the connection fails:

try {
  final channel = _websocketService.connect();
} catch (e) {
  yield* Stream.error(e);
}

Convert failures into stream errors so retry logic can handle them.

Step 3: Handle Silent Failures (Timeout)

WebSockets may stop emitting without throwing errors.

.timeout(
  const Duration(seconds: 5),
  onTimeout: (sink) {
    sink.addError("Timeout");
  },
)

This forces a retry when no data is received.

Step 4: Control Update Frequency

Real-time streams can overwhelm the UI.

.sampleTime(const Duration(seconds: 1))

This emits the latest value at a fixed interval.

Step 5: Retry Logic (RetryWhenStream)

RetryWhenStream(
  streamFactory,
  (error, _) {
    final delay = Duration(seconds: (1 << attempt).clamp(1, 60));
    attempt++;
    return Rx.timer(null, delay);
  },
);

This implements exponential backoff:

Retry after 1s → 2s → 4s → 8s → ...

Final Remote Data Source

Stream<AllMidsModel> connectToStream() {
  var attempt = 0;

  return RetryWhenStream(
    () {
      return Rx.defer(() async* {
        try {
          final channel = _websocketService.connect();
          await channel.ready;

          yield* channel.stream
              .map((event) {
                final json = jsonDecode(event as String);

                if (json['channel'] == 'allMids') {
                  return AllMidsModel.fromJson(json['data']);
                }
                return null;
              })
              .whereType<AllMidsModel>()
              .timeout(
                const Duration(seconds: 5),
                onTimeout: (sink) => sink.addError("Timeout"),
              )
              .sampleTime(const Duration(seconds: 1))
              .doOnData((_) => attempt = 0);
        } catch (e) {
          yield* Stream.error(e);
        }
      });
    },
    (error, _) {
      final delay = Duration(seconds: (1 << attempt).clamp(1, 60));
      attempt++;
      return Rx.timer(null, delay);
    },
  );
}

Clean Architecture Integration

Data Layer

Handles WebSocket connection, retry logic, and parsing. Returns a stream of models.

Domain Layer

abstract interface class PriceRepository {
  Either<Failure, Stream<AllMids>> subscribe();
}

Responsible for:

mapping models to entities
converting exceptions into failures

Use Case

class SubscribeToStream implements StreamUseCase<AllMids, NoParams> {
  final PriceRepository repo;

  @override
  call(_) => repo.subscribe();
}

Presentation Layer (BLoC)

Instead of passing streams to the UI, BLoC consumes the stream:

on<SubscribeToPriceStream>(
  _onSubscribe,
  transformer: restartable(),
);

await emit.forEach(
  stream,
  onData: (data) => PriceUpdated(data),
  onError: (e, _) => PriceStreamError(e.toString()),
);

Why `restartable()`?

It ensures:

new events cancel previous subscriptions
No duplicate streams remain active

UI Layer

switch (state) {
  case PriceUpdated(:final data):
    return Text("${data.price}");

  case PriceStreamError(:final msg):
    return Text(msg);

  case StartingPriceStream():
    return CircularProgressIndicator();
}

The UI reacts to states only. It has no knowledge of streams.

What This Solves

automatic reconnection
silent failure handling
controlled UI updates
crash prevention
clean separation of concerns

Key Takeaways

WebSockets do not always fail with errors
You must handle both errors and inactivity
Retry logic must recreate the connection
Streams should be owned by BLoC, not UI
RxDart is powerful when used with intent

Final Thought

Real-time systems are not about receiving data.

They are about handling failure conditions reliably, so users never notice them.

The Physics of Pixels: Flutter vs. React Native in 2026

Sat, 25 Apr 2026 11:40:52 +0000

By early 2026, the "Ecosystem War" between Flutter and React Native (RN) has effectively reached a stalemate. If you look at GitHub stars, the volume of third-party packages, or the availability of AI-generated boilerplate, the two frameworks appear nearly identical.

However, for senior engineers, the choice is no longer about "which library is more popular." It’s about The Physics of Rendering. When your application hits the performance ceiling, the only thing that matters is who owns the rendering pipeline.

The Universal Rendering Model

Regardless of the framework, every modern UI boils down to a three-layer state machine. Understanding how data becomes a pixel requires looking at this closed loop:

Definition: Defining the state and UI description (JSX / Widgets).
Retention: Persistent objects that manage state and logic (Fiber / Elements).
Computation: The Diffing algorithm that calculates incremental updates.
Consumption: The Rendering Engine that receives instructions and paints pixels.

⚛️ React Native: The "General Contractor" Approach

React’s philosophy is to be the "Brain of Declarative UI," but it lacks its own "hands." It manages the logic but outsources the actual work.

Layer	Implementation	Role & Constraints
Description (JSX/TSX)	Blueprint Snapshot	Immutable descriptions of "what the UI should look like."
Management (Fiber Node)	React Core Dispatcher	Manages state and calculates Diffs. All optimizations (`memo`, `useCallback`) live here.
Execution (Host Environment)	OS / Browser Engine	React has no drawing power. It sends instructions to the host (DOM or Native UI).

The Bottleneck: "The Foreign Agency Problem"

React Native is a UI Manipulation Framework. Because the actual components (Buttons, Lists) are rendered by the OS:

High Communication Overhead: Frequent updates (like high-speed scrolling) require constant "bridging" between the logic and the native UI.
Black-Box Rendering: Because rendering is delegated to Chrome or iOS/Android, React cannot intervene in how a pixel is shaded. This is why complex, custom-path animations can feel "heavy" in RN.

Flutter: The "Sovereign Ruler" Approach

Flutter doesn’t trust the operating system’s components. It brings its own engine to the party.

In Flutter, the "Three-Tree" architecture creates a full-stack closure from configuration to rasterization:

Layer	Object	Core Logic
Blueprint (Configuration)	Widget	Ultra-lightweight, immutable configurations created thousands of times per second.
Skeleton (Infrastructure)	Element	The bridge between the description and the rendered object; holds persistent state.
Rendering (Layout/Paint)	RenderObject	Flutter’s Secret Sauce. It directly handles layout and painting instructions.

The Advantage: Rendering Sovereignty

Flutter utilizes its own rendering engine (evolving from Skia to Impeller). This grants it "Sovereign" powers:

Predictable Performance: Since it doesn't rely on system components, the UI remains perfectly consistent across every device.
Efficient Synthesis: The transition from Widget → Element → RenderObject is highly optimized. Elements reuse RenderObjects whenever possible, drastically reducing the cost of expensive repaints.

The 2026 Decision Matrix: How to Choose?

We no longer choose based on "community size." We choose based on Interactive Depth.

Technical Comparison Matrix

Feature	React Native (Delegated Model)	Flutter (Sovereign Model)
Rendering Granularity	Component-level	Pixel-level
Pipeline Authority	Delegated to Host	Fully Autonomous
Animation Ceiling	Limited by Bridge efficiency	Seamless and Precise
Memory Footprint	Lower (utilizes system UI)	Higher (ships a full engine)

Strategic Recommendation

Choose Flutter if:
- You are building Performance-Intensive Apps: Video editors, high-frequency data dashboards, or precision design tools.
- Visual Consistency is Non-Negotiable: Your design team demands pixel-perfect shadows and filters that look identical on a $200 Android and a $1200 iPhone.
- Gamified UI: Your app requires custom shaders or complex, fluid animations.
Choose React Native if:
- You are building Standard Business Apps: E-commerce, social media, or CRUD tools where native components are already "good enough."
- Web Ecosystem Integration: You need to share heavy logic or hooks between your Web and Mobile teams.
- Dynamic Over-the-Air (OTA) Updates: You prioritize the ability to push logic changes without a full App Store review cycle.

The Final Word: Flutter is Building a World, while React Native is Managing a World. Understanding this distinction is the key to mastering the next era of cross-platform engineering.

author web Organize

The Refresh Spinner That Wouldn't Let Go

Thu, 23 Apr 2026 17:14:51 +0000

Some bugs arrive with a very clear message. This one showed up as a loading gif that simply refused to leave the screen.

The funny part was that the backend call had already succeeded.

The dashboard was doing a pull-to-refresh. The request went out, a 200 came back, the response payload looked fine, local state was being updated, and the logs were full of reassuring little breadcrumbs that normally tell you to move on with your life. But the UI stayed stuck in the refresh/loading state long enough to feel suspicious, and after a restart the crash log finally gave away what had been happening behind the scenes.

It was one of those errors that sounds obvious once you see it:

Bad state: Cannot use "ref" after the widget was disposed.

That sentence did more work than the earlier logs.

The screen was technically succeeding

What made this bug annoying was that the obvious suspects were innocent.

It wasn't a failed API call.

It wasn't a malformed response.

It wasn't even the usual "RefreshIndicator callback never completed" problem.

The refresh flow was actually finishing its network work. The broken part was what happened after the await.

In the dashboard package, the refresh handler looked roughly like this:

Future<void> refreshDashboard(WidgetRef ref) async {
  await onRefresh();
  ref.invalidate(dashboardDataProvider);
  await ref.read(dashboardDataProvider.future);
}

That looks reasonable at first glance. Wait for the parent refresh, invalidate the provider, then wait for fresh data so the indicator can finish cleanly.

The catch was that onRefresh() did not just fetch data. It also triggered a loading mode in the parent screen.

And that loading mode mattered more than I initially gave it credit for.

Where things got interesting

The dashboard had two layers of state going on:

an app-level dashboard fetch that updated domain entities after the network request
a package-level provider that exposed dashboard data to the newer UI flow

That by itself is manageable. A little layered, but manageable.

The real issue was that the parent screen treated every dashboard fetch as if the app was starting from cold boot. So on pull-to-refresh, it set a loading flag that caused the entire dashboard body to be replaced with a full-page loader.

That means the refreshing child widget got disposed while its own async refresh callback was still in flight.

So the sequence was basically this:

User pulls to refresh.
Child widget starts onRefresh().
Parent sets a global loading state.
Parent rebuilds and swaps the dashboard out for a big loading gif.
Child widget is disposed.
Await returns.
Child tries to use ref.invalidate(...).
Riverpod says, very correctly, absolutely not.

That was the whole bug.

Not network.
Not parsing.
Not authentication.
Just a subtle disagreement between what refresh means and what initial loading means.

A loading state with too much authority

This is the part I keep running into in mobile apps: one boolean starts out innocent, then slowly becomes responsible for too many UI decisions.

isLoading sounds harmless until it controls both of these:

whether the app has any usable data yet
whether existing data should remain on screen during a background refresh

Those are not the same thing.

If the dashboard has never loaded before, a blocking full-screen loader is fine.

If the dashboard is already visible and the user pulls to refresh, blanking out the entire screen is usually the wrong move anyway. It feels heavier than necessary, it creates more rebuild churn, and in my case it introduced a lifecycle bug because the widget that initiated the refresh no longer existed by the time the callback resumed.

So the fix was less dramatic than the debugging session made it feel.

I changed the parent dashboard screen to only show the full-page loader when there was no existing dashboard data yet. If data was already present, refresh would keep the current UI mounted and let the RefreshIndicator own the loading experience.

The change looked more like this:

Future<void> loadDashboard() async {
  final hasExistingData = ref.read(dashboardStateProvider).user != null;

  if (!hasExistingData) {
    setLoading(true);
  }

  final data = await repository.fetchDashboard();
  updateDashboardState(data);
  setLoading(false);
}

And in the build method:

final isLoading = ref.watch(dashboardStateProvider).isLoading;
final user = ref.watch(dashboardStateProvider).user;

if (isLoading && user == null) {
  return const FullScreenLoader();
}

Small condition. Big difference.

Why this fix felt better than just adding guards

I could have stopped at a defensive patch inside the child refresh callback.

Something like converting the widget to a ConsumerStatefulWidget, checking mounted, and avoiding any provider work after disposal. That would have made the crash go away.

But it wouldn't have answered the more important question: why was the widget being disposed during a simple refresh in the first place?

That is the part that actually mattered.

When a screen already has usable data, I generally want refresh to be additive, not destructive. Keep the current content visible. Let the user stay oriented. Update in place. If the refresh fails, the user should still have the previous dashboard, not a blank page and an identity crisis.

So the architectural correction was better than a pure lifecycle bandage.

The mounted/disposal guard is still a good idea in general. But in this case, preserving the widget tree during refresh was the cleaner move because it aligned the UI behavior with what the user was actually doing.

The part Flutter didn't exactly hide, but also didn't volunteer

RefreshIndicator is very simple on paper: return a Future, and it spins until that future completes.

The trap is that the future can represent much more than a network call. It can include provider invalidation, storage reads, parent rebuilds, cross-package state synchronization, and whatever else your screen architecture has accumulated over time.

So when the spinner doesn't stop, the answer is not always "the API is hanging." Sometimes the future is completing into a widget tree that no longer exists.

That was today's reminder that successful logs can be misleading. I had a perfectly healthy response and still a broken interaction because the state transitions around the response were fighting each other.

What I'm keeping from this one

I left the session with a stronger preference for separating initial load, background refresh, and empty state as distinct UI situations, even if they all stem from the same repository method.

They deserve different behavior.

They often deserve different visuals.

And if they all collapse into one loading flag, the code will usually work right up until it doesn't.

Today it manifested as a stuck dashboard refresh and a Riverpod disposal error. On another screen it could just as easily show up as scroll position resets, flickering forms, or stateful children quietly losing context every time fresh data arrives.

Flutter didn't really do anything wrong here. Riverpod definitely didn't. The app was just expressing an ambiguous state model with too much confidence.

Anyway, the refresh spinner goes away now, which is honestly the kind of quiet victory I respect.

The Tiny Red Dot That Wasn't Tiny

Tue, 21 Apr 2026 13:17:28 +0000

Today’s task looked harmless from the outside: show unread notifications, let users mark them as seen, and put a red dot on the bell icon when there is something new.

Classic mobile app stuff. Nothing dramatic. Just a bell, a list, a few cards, and one dot.

Naturally, it was not that simple.

The funny thing about notification work is that it lives in the uncomfortable space between backend truth and frontend immediacy. The backend knows what is actually unread. The UI knows what the user just tapped. Push notifications know something happened. Sockets know something happened too, sometimes faster. And snackbars are off on the side saying, “Hey, should I also be involved?”

By midday, the red dot was no longer a red dot. It was a state synchronization problem wearing a very small costume.

The backend changed its mind, which was actually helpful

The first shape of the notification payload was fairly raw. Every notification had a type, a timestamp, a read flag, and optional metadata. Some metadata had a bookingId, messages had sender/message IDs, and a few account-related notifications had no metadata at all.

Then the backend evolved in a useful direction: every notification metadata payload started carrying a summary field.

That changed the UI strategy quite a bit.

Instead of the app inventing every notification message from scratch, the backend could provide the user-facing summary while Flutter handled presentation: title, tone, icon/avatar, time label, action hints, and where the tap should eventually go.

That felt like the right division of responsibility.

The server knows the event context. The app knows how to make it feel native.

So the mapper became less of a sentence factory and more of a translation layer:

class NotificationUiItem {
  final String id;
  final String type;
  final String title;
  final String summary;
  final DateTime createdAt;
  final bool read;
  final String? bookingId;
  final String? serviceId;
  final String? senderId;
  final String? messageId;
  final String? photo;
  final NotificationUiTone tone;

  const NotificationUiItem({
    required this.id,
    required this.type,
    required this.title,
    required this.summary,
    required this.createdAt,
    required this.read,
    required this.tone,
    this.bookingId,
    this.serviceId,
    this.senderId,
    this.messageId,
    this.photo,
  });
}

Nothing wild there, but it gave the UI a stable language. Client notifications and vendor notifications could both consume the same backend response without pretending they were separate worlds.

That was one of the nicer parts of the day: deleting mental duplication before it had time to harden.

The trap: “just fetch when something happens”

At some point I had to decide how the red dot should react to realtime events.

The obvious approach is tempting:

Socket event comes in, call GET https://api.example.com/notifications, update the unread state.

It sounds clean because the backend remains the single source of truth. But it also means every realtime event can become a network call. Booking accepted? Fetch. Client paid? Fetch. Vendor account approved? Fetch. Push received while the app is open? Fetch again.

That starts to feel a little too eager.

The red dot does not need the full notification list. It only needs to know whether there is probably something unread.

So I split the behavior into two layers:

Realtime events are allowed to set hasUnread to true immediately.
The actual notifications endpoint is fetched when the user opens or refreshes the notifications screen.
Tapping or clearing notifications updates the badge optimistically.
A successful refresh becomes the source of truth again.

The controller ended up intentionally small:

class UnreadNotificationsController {
  final ValueNotifier<bool> hasUnread = ValueNotifier<bool>(false);

  Future<void> refreshFromBackend() async {
    final result = await getUnreadNotifications();

    result.fold(
      (_) {
        // Keep the current local state if refresh fails.
      },
      (response) {
        hasUnread.value = response.notifications.isNotEmpty;
      },
    );
  }

  void notifyNewUnread() {
    hasUnread.value = true;
  }

  void markAllSeenLocally() {
    hasUnread.value = false;
  }
}

The small detail I care about there: failed refresh does not force the dot off.

That is the kind of bug that feels tiny until a user sees it. Imagine a socket event turns the dot on, then a shaky network request fails, and suddenly the app says there are no notifications. That is not truth. That is the UI being overconfident.

So failure preserves the last known state.

Optimistic UI, but not reckless UI

The notification cards needed two actions: tap one notification as seen, and clear all notifications.

Both should feel immediate. Nobody wants to tap a notification and wait for a spinner before the card visually calms down.

So the screen fades a card instantly when tapped, calls the mark-as-seen endpoint in the background, and restores state only if the request fails.

Same with clear-all: empty the list immediately, turn off the badge, then restore if the backend refuses.

That pattern is simple on paper, but it gets tricky around shared state. The screen has local state like:

final Set<String> seenNotificationIds = {};

The badge has global-ish app state:

final ValueNotifier<bool> hasUnread;

Those two need to agree without becoming the same thing.

Local card fading is about presentation. The badge is about app-level unread status. If one notification is tapped but others remain unread, the card should fade but the bell should stay red. If the last visible unread notification is tapped, the bell can turn off optimistically.

That distinction saved the implementation from becoming mushy.

Messages were the one awkward guest

Messages complicated the decision a bit.

The app already has message socket events and snackbars. A new chat message can appear while the user is in another tab, and the app may show a snackbar preview. The backend may also create a notification for that message. But once the user reads the chat, the backend can mark that message notification as read on the next fetch.

So should message events turn on the notification bell dot?

I chose not to, at least for now.

Not because messages are unimportant. Actually, the opposite: messages often deserve their own unread behavior. If the chat tab already has message-specific state, using the general notification bell for every message can make the app feel noisy.

So the controller ignores message-style push events and lets the backend refresh settle it later:

void handlePushPayload(PushPayload payload) {
  final eventType = payload.eventType.trim();

  if (payload.isMessageEvent || eventType == 'NEW_MESSAGE') return;
  if (eventType.isEmpty) return;

  notifyNewUnread();
}

This means booking, payment, account, document, and status notifications can light the bell immediately. Messages can still appear in the notifications list if the backend returns them, but they do not drive the red dot in realtime.

That might change later. And if it does, the change is thankfully tiny: remove that guard and subscribe to message socket events too.

I like when a decision is reversible without surgery.

The part that felt architectural

The more interesting thought came after the unread state was working: what should happen when a user taps a notification card?

Push notifications already navigate somewhere. Usually not super deep, but enough to open the right section of the app. For example, a booking event might open the bookings tab. A message might open the messages tab. A payout-related notification might open the payout screen.

The in-app notification cards should not invent a second routing brain.

The cleaner direction is to create a shared notification navigation resolver. Push payloads and backend notification cards can both be converted into the same internal input:

class NotificationRouteInput {
  final String type;
  final String? bookingId;
  final String? serviceId;
  final String? senderId;
  final String? messageId;
  final String? vendorId;

  const NotificationRouteInput({
    required this.type,
    this.bookingId,
    this.serviceId,
    this.senderId,
    this.messageId,
    this.vendorId,
  });
}

Then the resolver decides:

message notification: messages tab, or exact chat if enough data exists
booking notification: bookings tab, ideally with the exact booking opened
document notification: payout or document area
account rejected/suspended: support or account status screen
vendor application: admin approval flow, if the app has one

The important thing is consistency. If a push notification and an in-app notification represent the same event, they should not send the user to different places because two separate pieces of code drifted apart.

That is the kind of duplication that does not hurt today, then quietly taxes every future feature.

What I’d keep from today

The biggest lesson was not about ValueNotifier, sockets, or endpoints. It was about being careful with what kind of truth each part of the app owns.

The backend owns durable unread state.

Sockets and push own immediacy.

Notification screens own presentation and local optimistic feedback.

The badge owns one tiny app-level question: “Should I show a dot?”

Once those boundaries were clear, the implementation stopped feeling like a pile of callbacks and started feeling like a small system.

Still a slightly annoying system. Notifications always are. They are where product expectations, backend timing, OS behavior, and user attention all meet in a narrow hallway.

But today’s version is better than the naive one I almost built.

No overfetching on every event. No forcing the dot off on refresh failure. No duplicated client/vendor notification models. No pretending message notifications are the same as booking/payment/account events when the app already treats chat specially.

All of that for a red dot.

A very small red dot.

The Message That Was There, But Not There

Tue, 21 Apr 2026 13:16:42 +0000

Today I worked on one of those bugs that sounds suspiciously simple when someone describes it.

"When a new message comes in, the message screen updates. But when I open the chat, the message is not there. If I go back, refresh, and open it again, then it shows."

That sentence has all the ingredients of a quiet afternoon turning into a long stare at state management.

The app has a fairly normal chat flow. There is a messages screen with conversation previews, unread counts, recent chats, and the latest message text. Then there is a chat screen that shows the actual thread. Messages arrive through a socket. Push or foreground notifications can also show a snackbar. The backend stores read status, and the app marks messages as read once the user opens the chat.

Nothing exotic. Which, of course, is exactly why it was interesting.

The preview was telling the truth

The first clue was that the message list did update.

When a message arrived, the preview changed. The unread count changed. The notification snackbar appeared. So this was not a socket connection issue, not a missing event, and not a routing issue.

The list knew about the new message.

But the chat screen did not.

That narrowed the shape of the bug quite a bit. Somewhere between "socket event reached the messages screen" and "chat screen opened", the data was getting thinner.

The messages screen had a ChatPreview model. It carried the things you expect:

class ChatPreview {
  final String latestMessage;
  final int unreadCount;
  final String userId;
  final String? conversationId;
  final List<ChatMessage> initialMessages;

  // ...
}

That last field was the important one: initialMessages.

The chat screen was not always fetching a fresh thread immediately when opened. It was initialized from the preview object:

_messages = widget.initialMessages ?? [];

So the list screen was not just a list screen. It was also acting as a lightweight cache for the first render of the chat screen.

That is a reasonable design. It makes the chat open quickly. It avoids a blank screen while waiting for the network. It also means the cache has to be correct.

And mine was not.

The tiny split-brain

The socket handler on the messages screen was doing something like this:

existing.copyWith(
  latestMessage: latestMessage,
  time: timestamp,
  unreadCount: existing.unreadCount + 1,
);

That made the preview look right.

But it did not add the new socket message to initialMessages.

So the user saw the new message in the list, tapped the conversation, and the chat screen opened with the old cached message list. The newest message was effectively living in the preview text, but not in the actual message collection.

That explains the weird part where the message appeared only after a manual refresh. The refresh pulled the full conversation again from the backend, rebuilt initialMessages, and finally the chat screen had the missing message.

It also explained the unread count behaving oddly. Opening the chat locally cleared the unread count in the list UI, but the chat screen could not mark that new message as read because the message was not in _messages. After refresh, the backend still considered it unread. That was not the backend being stubborn. It was the UI never giving the read-marking code the message id it needed.

This is the kind of bug where every individual piece is doing something understandable, but the system as a whole lies to you.

The fix was not to refresh harder

The tempting fix would have been: "Just fetch the whole conversation every time the chat opens."

That would probably work. It would also make the app feel a little heavier, especially in a realtime chat where the socket already handed us the message. Pulling from the backend after receiving the exact event felt like paying twice for the same information.

The better fix was to make the socket path update both layers of state:

the visible preview fields
the cached initialMessages passed into the chat screen

So when a socket message arrives, I now build a real ChatMessage from the socket payload:

final incomingMessage = ChatMessage(
  id: messageId,
  message: content,
  timestamp: timestamp,
  isSender: senderId == currentUserId,
  messageType: resolvedMessageType,
  attachmentIds: attachmentIds,
  tempId: tempId,
  status: status,
);

Then I merge it into the preview's cached messages:

List<ChatMessage> mergeMessageIntoCache(
  List<ChatMessage> currentMessages,
  ChatMessage incomingMessage,
) {
  final nextMessages = List<ChatMessage>.from(currentMessages);

  final existingIndex = nextMessages.indexWhere(
    (message) =>
        message.id == incomingMessage.id ||
        (incomingMessage.tempId != null &&
            message.tempId == incomingMessage.tempId),
  );

  if (existingIndex == -1) {
    nextMessages.add(incomingMessage);
  } else {
    nextMessages[existingIndex] = incomingMessage;
  }

  nextMessages.sort((a, b) => a.timestamp.compareTo(b.timestamp));
  return nextMessages;
}

The tempId part matters because optimistic UI is usually lurking somewhere nearby in chat apps. A sent message may appear locally before the server returns its final id. If the server later echoes it back, you do not want a duplicate bubble. Matching by id and tempId keeps that handoff cleaner.

Now the preview update includes the actual message cache:

existing.copyWith(
  latestMessage: latestMessage,
  time: timestamp,
  unreadCount: shouldIncrement ? existing.unreadCount + 1 : 0,
  initialMessages: mergeMessageIntoCache(
    existing.initialMessages,
    incomingMessage,
  ),
);

The result is less dramatic than the bug: the user taps the chat, the message is already there, and the read logic can do its job.

Lovely when software becomes boring again.

Then attachments joined the conversation

After that, another small issue showed up.

Text messages were fine, but when a new image or voice note arrived, the live preview said:

Attachment

After a manual refresh, it correctly said:

Image

or:

Voice note

Same screen. Same message. Different label depending on whether it came from the socket path or the refresh path.

That pointed to another mismatch.

The refresh path had more context. It could inspect or infer attachment metadata and resolve the message type properly. The socket path was mostly trusting the raw type field from the event. If the type was missing, generic, lowercase, or not specific enough, the UI fell back to Attachment.

This is one of those details that is easy to miss because the fallback is not broken. "Attachment" is technically acceptable. It just feels unfinished, especially when the same message becomes "Image" after refresh.

So the socket preview path needed to use the same resolver as the loaded conversation path:

final attachmentIds = extractAttachmentIds(messageData);

final resolvedMessageType =
    attachmentIds.isNotEmpty
        ? await resolveMessageType(rawType, attachmentIds)
        : mapMessageType(rawType.toUpperCase());

final latestMessage =
    content.isNotEmpty
        ? content
        : labelForMessageType(resolvedMessageType);

That made the live preview and refreshed preview agree.

The important thing here is not the label. It is the consistency of the data pipeline. If one path says "Image" and another says "Attachment", users may not describe it as a data pipeline issue. They will just say, very fairly, "This screen is weird."

Client and vendor were the same bug twice

This app has both client and vendor versions of the messages screen. They are not identical screens in the product sense, but their chat-preview logic is similar enough that fixing only one side would have been lazy.

So the same cache merge and attachment preview fix went into both message screens.

This is where duplicated UI logic starts tapping you on the shoulder.

Duplication is not automatically evil. Sometimes two flows really do need room to evolve separately. But realtime chat logic is the kind of thing that gets expensive when copied around. Socket payload parsing, attachment normalization, message deduping, unread count handling, and read-status behavior are all easy to get almost-right in two places.

Almost-right is where bugs breed.

I did not do the larger refactor today, but the shape is obvious: this logic wants to live somewhere shared. Not necessarily a giant abstraction. Maybe just a small mapper/helper that turns socket payloads into ChatMessage and preview metadata. Enough to stop the client and vendor screens from drifting apart.

There is a difference between noticing a refactor and doing it immediately. Today the right move was to fix the bug tightly, verify both screens, and leave the larger cleanup as a clear next step.

The part I keep thinking about

The bug was not caused by Flutter being strange. It was caused by state having two representations:

preview state
detail state

The preview state changed first, so the UI looked alive. But the detail state stayed stale, so the next screen felt broken.

That is a very mobile-app kind of bug.

Mobile interfaces often optimize for immediacy. We cache, prefill, optimistic-update, debounce, hydrate, and subscribe to streams. All of that is normal. But once there are multiple ways for the same entity to enter the UI, each path has to preserve the same meaning.

A message cannot only be a string in one path and a full object in another.

An attachment cannot be "whatever the raw event said" in one path and "resolved from metadata" in another.

Unread state cannot be cleared visually if the message id never reaches the code that persists the read receipt.

None of these are huge architectural revelations. They are smaller than that, and maybe more useful because of it.

Today's reminder: realtime UI bugs are often not about receiving data. They are about receiving data into the wrong layer of state.

And yes, sometimes the message is there.

Just not where the next screen is looking.

Build Reliable Local Notifications in Flutter (Step-by-Step)

Tue, 21 Apr 2026 01:03:01 +0000

Companion post to How I Built the Long Game Notification System. This is the walkthrough. If you want the thinking behind the decisions, read that first. If you just want the recipe, you're in the right place.

What You're Building

A notification system where:

Notifications fire at the exact time you set, every day
They work when the phone is locked, the app is killed, or the device is in Doze mode
Notification content is personalized with fresh data on every app open
The entire system runs locally — no push server, no Cloud Functions, zero delivery cost
Pomodoro-style one-shot alarms fire on time even when the app is suspended
Notifications survive Samsung, Xiaomi, and Huawei battery killers without FCM

What You're NOT Using

workmanager — the OS throttles background tasks. Your 15-minute poll becomes hours.
Dart Timer.periodic for delivery — dies the moment the phone locks.
Firebase Cloud Messaging — overkill for local, user-specific scheduling.
Background Fetch (iOS) — Apple gives you 0–2 executions per day if you're lucky.

Step 1: Dependencies

# pubspec.yaml
dependencies:
  flutter_local_notifications: ^18.0.1
  timezone: ^0.10.0
  flutter_timezone: ^3.0.1
  permission_handler: ^11.3.1

That's it. Four packages.

The notification plugin handles scheduling.
The timezone packages ensure your 8:00 AM means 8:00 AM in Johannesburg, not UTC.
The permission handler lets you request notification access on Android 13+ and battery optimization exemption on Samsung/OEM devices.

Step 2: Android Permissions

<!-- android/app/src/main/AndroidManifest.xml -->
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
<uses-permission android:name="android.permission.USE_EXACT_ALARM" />
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

What each one does:

Permission	Why
`POST_NOTIFICATIONS`	Required on Android 13+ to show any notification at all
`RECEIVE_BOOT_COMPLETED`	Alarms survive device reboots
`SCHEDULE_EXACT_ALARM`	Fires at the exact second, even in Doze mode (API ≤ 33)
`USE_EXACT_ALARM`	Guaranteed exact alarms on API 33+ — no user prompt needed, unlike `SCHEDULE_EXACT_ALARM` on API 34+
`REQUEST_IGNORE_BATTERY_OPTIMIZATIONS`	Lets you show the system "Allow unrestricted battery?" dialog — critical for Samsung, Xiaomi, Huawei
`WAKE_LOCK`	Keeps the CPU alive long enough to process the alarm and fire the notification

Watch out: On Android 14+ (API 34), SCHEDULE_EXACT_ALARM isn't granted by default. USE_EXACT_ALARM is a stronger alternative that's always granted for apps that declare it — but it may trigger Google Play review. Having both ensures maximum compatibility. Your code still needs the inexact fallback we'll cover in Step 7.

Step 3: Initialize on App Start

Before you can schedule anything, you need to initialize the timezone database and the notification plugin. This runs once in main(), before runApp().

// main.dart
void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // ... your other init code (Firebase, etc.)

  await NotificationService.init();
  runApp(const MyApp());
}

// notification_service.dart
import 'package:flutter_local_notifications/flutter_local_notifications.dart';
import 'package:timezone/timezone.dart' as tz;
import 'package:timezone/data/latest_all.dart' as tzdata;
import 'package:flutter_timezone/flutter_timezone.dart';
import 'package:permission_handler/permission_handler.dart';

class NotificationService {
  static final FlutterLocalNotificationsPlugin _plugin =
      FlutterLocalNotificationsPlugin();

  static Future<void> init() async {
    // 1. Initialize the timezone database and detect the device's zone.
    //    Without this, all scheduled times are wrong.
    tzdata.initializeTimeZones();
    try {
      final tzName = await FlutterTimezone.getLocalTimezone();
      tz.setLocalLocation(tz.getLocation(tzName));
    } catch (_) {
      // Fallback: stays UTC if detection fails
    }

    // 2. Initialize the plugin.
    //    We don't request permissions here — that happens later,
    //    at a moment that makes sense in your UX flow.
    const androidSettings = AndroidInitializationSettings(
      '@mipmap/ic_launcher',
    );
    const iosSettings = DarwinInitializationSettings(
      requestAlertPermission: false,
      requestBadgePermission: false,
      requestSoundPermission: false,
    );

    await _plugin.initialize(
      const InitializationSettings(
        android: androidSettings,
        iOS: iosSettings,
      ),
      onDidReceiveNotificationResponse: _onNotificationTap,
      onDidReceiveBackgroundNotificationResponse: _onBackgroundTap,
    );
  }

  // Handle taps when the app is alive
  static void _onNotificationTap(NotificationResponse response) {
    // Navigate to the relevant screen, stop a timer, etc.
  }

  // Handle taps when the app was killed — must be top-level or static
  @pragma('vm:entry-point')
  static void _onBackgroundTap(NotificationResponse response) {
    // App relaunches — handle in your normal init flow
  }
}

Why timezone matters: If you schedule for "8:00 AM" without initializing timezones, the plugin may interpret that as UTC. In Johannesburg (UTC+2), that's 10:00 AM. In New York (UTC-5), that's 3:00 AM. Always initialize before any zonedSchedule call.

Step 4: Schedule a Daily Repeating Notification

This is the core of the entire system. Three lines do the heavy lifting.

static Future<void> scheduleDailyNotification({
  required int id,
  required String title,
  required String body,
  required int hour,
  required int minute,
}) async {
  await _plugin.zonedSchedule(
    id,                                           // Fixed ID per notification type
    title,
    body,
    _nextInstanceOfTime(hour, minute),            // Next occurrence of this time
    const NotificationDetails(
      android: AndroidNotificationDetails(
        'your_channel_id',
        'Your Channel Name',
        channelDescription: 'What this channel is for',
        importance: Importance.high,
        priority: Priority.high,
      ),
      iOS: DarwinNotificationDetails(),
    ),
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
    androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    matchDateTimeComponents: DateTimeComponents.time,    // ← THIS IS THE KEY
  );
}

The three things that make it work:

exactAllowWhileIdle — fires even in Doze mode. The OS wakes up just enough to deliver your notification.
matchDateTimeComponents: DateTimeComponents.time — tells the OS: "repeat this every day at this hour:minute." You schedule it once. It fires every day. No background task. No polling.
_nextInstanceOfTime — computes the next future occurrence of the target time.

static tz.TZDateTime _nextInstanceOfTime(int hour, int minute) {
  final now = tz.TZDateTime.now(tz.local);
  var scheduled = tz.TZDateTime(
    tz.local,
    now.year,
    now.month,
    now.day,
    hour,
    minute,
  );
  // zonedSchedule requires a future datetime
  if (scheduled.isBefore(now)) {
    scheduled = scheduled.add(const Duration(days: 1));
  }
  return scheduled;
}

Why this helper exists: zonedSchedule requires the initial fire time to be in the future. If it's 9:00 AM and you schedule for 8:00 AM, the helper pushes it to 8:00 AM tomorrow. The matchDateTimeComponents flag handles every day after that.

Step 5: CRITICAL: The Cancel Trap

==(This bit is annoying if not taken care of)==

This is the bug that will silently break your notifications and you won't notice for days. I shipped it. It cost me a full day of missed notifications before I caught it.

The broken pattern

//  DO NOT DO THIS
static Future<void> reschedule() async {
  await _plugin.cancel(id);                     // Destroys the repeating alarm
  await _plugin.zonedSchedule(id, ...);         // Creates a new one
}

It looks correct. It's not. Here's what happens:

User opens the app at 9:00 AM
cancel(1) — destroys the existing repeating 8:00 AM alarm
_nextInstanceOfTime(8, 0) — 8:00 AM today already passed, returns tomorrow 8:00 AM
zonedSchedule(1, ...) — schedules a new alarm starting tomorrow
Tomorrow, user opens the app at 9:00 AM again → same thing
The notification is perpetually pushed to "tomorrow" and never fires

The correct pattern

// Only cancel when the user disables the notification
static Future<void> schedule(bool enabled, int hour, int minute) async {
  if (!enabled) {
    await _plugin.cancel(id);    // User turned it off — remove the alarm
    return;
  }
  // Calling zonedSchedule with the same ID REPLACES the existing alarm
  // without resetting the repeat cycle. No cancel needed.
  await _plugin.zonedSchedule(id, ...);
}

The rule: zonedSchedule with the same ID overwrites the previous alarm — it updates the title, body, and schedule time without destroying the repeat. You only need cancel when you want the notification to stop entirely.

This means you can safely call rescheduleAll() on every app open to refresh notification content (e.g., "You have 3 projects today" becomes "You have 4 projects today") without breaking delivery.

Step 6: Refresh Content on App Open

Notification bodies are frozen at schedule time. If the user adds a project at 11 PM, you want tomorrow's morning notification to include it.

// main.dart — after init, before runApp
if (FirebaseAuth.instance.currentUser != null) {
  NotificationService.rescheduleAllNotifications().catchError((_) {});
}

rescheduleAllNotifications() fetches fresh data and calls zonedSchedule for each enabled notification, overwriting the stale body. No cancel — just overwrite.

Two things to guard against:

Auth check — if your notification content depends on user-specific data (Firestore queries), and no user is signed in, the query will hang. This blocks main() and your app never starts. Gate it.
Fire-and-forget — use .catchError((_) {}). If the reschedule fails (offline, Firestore timeout), the previously scheduled alarm still fires with yesterday's content. That's better than crashing on startup.

Step 7: Handle Android 14+ Exact Alarm Restriction

Android 14 changed the rules. SCHEDULE_EXACT_ALARM is no longer auto-granted. If your app calls exactAllowWhileIdle without the permission, it throws.

The graceful fallback:

static Future<void> scheduleDailyNotification({
  required int id,
  required String title,
  required String body,
  required int hour,
  required int minute,
}) async {
  final scheduledTime = _nextInstanceOfTime(hour, minute);
  final details = /* your NotificationDetails */;

  try {
    // Try exact first — best experience
    await _plugin.zonedSchedule(
      id, title, body, scheduledTime, details,
      uiLocalNotificationDateInterpretation:
          UILocalNotificationDateInterpretation.absoluteTime,
      androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
      matchDateTimeComponents: DateTimeComponents.time,
    );
  } catch (e) {
    // Exact alarm not permitted — fall back to inexact
    // Delivery may drift by ~10 minutes, but the notification still fires
    await _plugin.zonedSchedule(
      id, title, body, scheduledTime, details,
      uiLocalNotificationDateInterpretation:
          UILocalNotificationDateInterpretation.absoluteTime,
      androidScheduleMode: AndroidScheduleMode.inexactAllowWhileIdle,
      matchDateTimeComponents: DateTimeComponents.time,
    );
  }
}

For most notifications, a 10-minute window is fine. "Your day is 63% gone" at 2:10 PM instead of 2:00 PM doesn't break the experience.

Apply this same pattern to one-shot alarms too. Your pomodoro alarm scheduler should have the same try/catch:

static Future<void> schedulePhaseAlarm({
  required int durationMinutes,
  required NotificationDetails details,
}) async {
  final fireAt = tz.TZDateTime.now(tz.local)
      .add(Duration(minutes: durationMinutes));

  try {
    await _plugin.zonedSchedule(
      alarmId, title, message, fireAt, details,
      uiLocalNotificationDateInterpretation:
          UILocalNotificationDateInterpretation.absoluteTime,
      androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    );
  } catch (_) {
    // Fall back to inexact — still fires, may drift ~5-10 min
    try {
      await _plugin.zonedSchedule(
        alarmId, title, message, fireAt, details,
        uiLocalNotificationDateInterpretation:
            UILocalNotificationDateInterpretation.absoluteTime,
        androidScheduleMode: AndroidScheduleMode.inexactAllowWhileIdle,
      );
    } catch (e) {
      print('[Notifications] Failed to schedule alarm: $e');
    }
  }
}

Step 8: One-Shot Alarms (Pomodoro, Timers)

Daily repeating alarms cover most cases. But sometimes you need a notification that fires once at a specific future time — like when a 25-minute pomodoro focus session ends.

static Future<void> scheduleOneShot({
  required int id,
  required String title,
  required String body,
  required int minutesFromNow,
  required NotificationDetails details,
}) async {
  final fireAt = tz.TZDateTime.now(tz.local)
      .add(Duration(minutes: minutesFromNow));

  await _plugin.zonedSchedule(
    id,
    title,
    body,
    fireAt,
    details,
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
    androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    // NO matchDateTimeComponents — this fires once, doesn't repeat
  );
}

Why you need this for pomodoro: A Dart Timer.periodic runs in your app's process. When the user locks their phone, the OS suspends the app within ~30 seconds. Your timer stops ticking. The phase ends, and — silence. The bell only rings when they unlock the phone and the app resumes.

An OS alarm doesn't care about your app's lifecycle. It fires regardless.

Making one-shot alarms alarm-grade

A standard Importance.high notification won't cut it on Samsung, Xiaomi, or Huawei devices. These OEMs aggressively kill background processes and suppress notifications they deem non-essential. You need to make your notification look like an alarm clock to the OS:

import 'dart:typed_data';

NotificationDetails _alarmGradeDetails({required bool isWorkPhase}) {
  final soundFile = isWorkPhase ? 'bell_focus' : 'bell_break';
  final channelId = isWorkPhase ? 'focus_bell' : 'break_bell';
  final channelName = isWorkPhase ? 'Focus Bell' : 'Break Bell';

  return NotificationDetails(
    android: AndroidNotificationDetails(
      channelId,
      channelName,
      channelDescription: 'Pomodoro phase transition',
      importance: Importance.max,                              // Maximum priority
      priority: Priority.max,
      sound: RawResourceAndroidNotificationSound(soundFile),
      playSound: true,
      fullScreenIntent: true,                                  // Wakes the screen
      category: AndroidNotificationCategory.alarm,             // Treated like an alarm
      visibility: NotificationVisibility.public,               // Shows on lock screen
      enableVibration: true,
      vibrationPattern: Int64List.fromList([0, 400, 200, 400]),
    ),
    iOS: DarwinNotificationDetails(
      presentAlert: true,
      presentSound: true,
      sound: '$soundFile.wav',
      interruptionLevel: InterruptionLevel.timeSensitive,      // Breaks through Focus
    ),
  );
}

What each flag does:

Flag	Effect
`importance: Importance.max`	Heads-up notification — appears at the top of the screen
`fullScreenIntent: true`	Wakes the screen and shows the notification even when locked. This is what alarm clock apps use.
`category: AndroidNotificationCategory.alarm`	Tells the OS this is time-critical. Samsung's battery manager respects this category.
`visibility: NotificationVisibility.public`	Content visible on the lock screen without unlocking
`vibrationPattern`	Custom vibration so the user physically feels it
`interruptionLevel: InterruptionLevel.timeSensitive`	iOS 15+: breaks through Focus mode

This is the difference between a notification that works on your desk and one that works in your pocket. Standard Importance.high gets silently suppressed by Samsung's battery manager. Importance.max + fullScreenIntent + category: alarm does not.

The dual-delivery pattern

When the app is in the foreground, the Dart timer catches the transition first (instant feedback). When the phone is locked, the OS alarm delivers it. To avoid the user hearing two bells:

// In your timer tick (foreground path)
void _onPomodoroPhaseEnd() {
  _plugin.cancel(alarmId);            // Cancel the OS alarm (Dart beat it)
  _plugin.show(displayId, ...);       // Show the notification immediately
  _scheduleNextPhaseAlarm();          // Schedule for the next phase
}

Use separate IDs for the scheduled alarm and the instant notification if you want, or the same ID if you want one to replace the other. Either way, the user sees exactly one notification.

Step 9: Weekly Repeating Notifications

For notifications that fire on specific weekdays — like a project reminder every Monday, Wednesday, and Friday at 6:00 PM.

static Future<void> scheduleWeekly({
  required int id,
  required String title,
  required String body,
  required int weekday,    // 1 = Monday, 7 = Sunday
  required int hour,
  required int minute,
}) async {
  await _plugin.zonedSchedule(
    id,
    title,
    body,
    _nextInstanceOfWeekdayTime(weekday, hour, minute),
    /* notificationDetails */,
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
    androidScheduleMode: AndroidScheduleMode.inexactAllowWhileIdle,
    matchDateTimeComponents: DateTimeComponents.dayOfWeekAndTime,  // ← Weekly
  );
}

static tz.TZDateTime _nextInstanceOfWeekdayTime(
  int weekday, int hour, int minute,
) {
  final now = tz.TZDateTime.now(tz.local);
  var scheduled = tz.TZDateTime(
    tz.local, now.year, now.month, now.day, hour, minute,
  );
  // Advance to the target weekday
  while (scheduled.weekday != weekday) {
    scheduled = scheduled.add(const Duration(days: 1));
  }
  // If it's already passed this week, push to next week
  if (scheduled.isBefore(now)) {
    scheduled = scheduled.add(const Duration(days: 7));
  }
  return scheduled;
}

Important: Each weekday needs its own notification ID. If you want reminders on Monday, Wednesday, and Friday, that's three separate zonedSchedule calls with three different IDs. When removing the reminder, cancel all of them.

// Generating unique IDs per project + weekday
final notifId = baseId + projectId.hashCode.abs() % 900 + weekday;

Step 10: Surviving Samsung Battery Optimization

This is the step most Flutter notification tutorials skip, and it's why your notifications work perfectly during development but fail silently in production.

The problem

Samsung, Xiaomi, Huawei, OnePlus, and most Chinese OEMs add an aggressive battery optimization layer on top of Android's standard Doze mode. Even if your alarm is correctly s

Understanding Flutter Method Channels Through a Real Production Bug

Thu, 16 Apr 2026 15:48:54 +0000

Introduction

Flutter is amazing—until it isn’t.

Most of the time, you can build entire apps without ever touching native code. But the moment you hit a platform limitation, things get… interesting.

This blog isn’t just about Method Channels.

It’s about:

When Flutter abstractions break down
How to take control using native Android
And how to think about Flutter ↔ Native communication like a system, not a hack

Funny enough, this blog comes from a real bug I hit while building my app Anahad — a saadhna app that plays mantra chants.

And yeah… it broke in a very weird way.

The Real Problem (Why This Blog Exists)

I was building a saadhna app that plays mantra chants on loop.

Simple requirement:

Play audio
Loop it continuously
Run in the background (screen off)

I was using:

audio_service
just_audio
just_audio_background

Everything worked perfectly…

Until it didn’t.

The Bug

After ~940–960 loops on Android (specifically Android 12+):

Playback would stop silently
No crash
No exception
Only when the screen was off

Even after:

Disabling battery optimization
Proper background setup

Still broke.

The Weird Part

It consistently failed around the same loop range (~940–960).

Not 100. Not 500. Not random.

That kind of consistency usually means:

Something deeper is going on — not just app-level logic.

At This Point, Two Choices

Keep debugging blindly inside Flutter
Drop down to native Android and take control

I chose option 2, cz i never interacted with native code and wanted to explore it

Fun part, i had an android 11 device which wasn't having this bug at all, tested on other android 11 devices as well

Why Flutter Isn’t Always Enough

Flutter is great, but it abstracts away platform details.

That’s usually good—until you need:

Deep lifecycle control
System-level integrations
Debug visibility into platform behavior

Common cases where native is needed:

Background services
Media playback control
Hardware interaction
Platform-specific APIs
Performance-critical logic

In my case:

I needed more control over how Android handles long-running audio playback. Just to be absolutely sure that it was not the issue of the package that i was using

Understanding Method Channels (The Right Mental Model)

Before code, get this clear:

Dart is the client. Native Android is the server.

When you write:

platform.invokeMethod("play")

You’re essentially doing:

Dart → sends request
Android → receives it
Executes native logic
Returns response

Think of it like:

An internal API call inside your app

No HTTP. No network. Just a binary bridge.

Once you understand this, Method Channels stop feeling “magical”.

Architecture Overview

Flutter (Dart)
├── UI Layer
├── Service Layer (PlaybackService.dart)
└── State Management

        ↓↓↓ Method Channel ↓↓↓

Android (Kotlin)
├── MethodChannel Handler
├── PlaybackService (MediaSessionService)
└── ExoPlayer

Flow (Step-by-Step)

User taps "Play"
Dart calls invokeMethod("play")
MethodChannel sends message
Kotlin receives it
Native service executes logic
Result is sent back

The Native Side: Android (Kotlin)

Why MediaSessionService?

Instead of a basic service, we use:

MediaSessionService

Because it:

Integrates with system controls (lock screen, notifications)
Handles background playback more reliably
Works with audio focus and lifecycle events
Plays nicely with the Android system

PlaybackService.kt

class PlaybackService : MediaSessionService() {
    private var mediaSession: MediaSession? = null

    override fun onCreate() {
        super.onCreate()

        val audioAttributes =
            AudioAttributes.Builder()
                .setUsage(C.USAGE_MEDIA)
                .setContentType(C.AUDIO_CONTENT_TYPE_MUSIC)
                .build()

        val player =
            ExoPlayer.Builder(this)
                .setAudioAttributes(audioAttributes, true)
                .setHandleAudioBecomingNoisy(true)
                .setWakeMode(C.WAKE_MODE_NETWORK)
                .build()

        player.addListener(object : Player.Listener {
            override fun onPlayerError(error: PlaybackException) {
                Log.e("PlaybackService", "Error: ${error.message}", error)
            }
        })

        val callback = object : MediaSession.Callback {}

        mediaSession = MediaSession.Builder(this, player)
            .setCallback(callback)
            .build()
    }

    override fun onDestroy() {
        mediaSession?.run {
            player.release()
            release()
            mediaSession = null
        }
        super.onDestroy()
    }
}

The Flutter Side: Dart

Service Wrapper

class PlaybackService {
  static const platform =
      MethodChannel('com.theahambrahmasmi.anahad/playback');

  static Future<void> play(String url) async {
    await platform.invokeMethod('play', {'url': url});
  }

  static Future<void> pause() async {
    await platform.invokeMethod('pause');
  }

  static Future<Map<String, dynamic>> getStatus() async {
    final result = await platform.invokeMethod('getStatus');
    return Map<String, dynamic>.from(result);
  }
}

Kotlin: Method Channel Handler

class PlaybackMethodHandler(private val context: Context) {

    fun setupChannel(flutterEngine: FlutterEngine) {
        MethodChannel(
            flutterEngine.dartExecutor.binaryMessenger,
            "com.theahambrahmasmi.anahad/playback"
        ).setMethodCallHandler { call, result ->

            when (call.method) {
                "play" -> {
                    val url = call.argument<String>("url")
                    val intent = Intent(context, PlaybackService::class.java)
                    intent.putExtra("audio_url", url)
                    context.startService(intent)
                    result.success(null)
                }

                "pause" -> {
                    val intent = Intent(context, PlaybackService::class.java)
                    context.stopService(intent)
                    result.success(null)
                }

                else -> result.notImplemented()
            }
        }
    }
}

Real-World Insight: The Looping Problem

If you're building:

Meditation apps
Chanting apps
Ambient loop apps

Be careful.

Android may silently stop long-running playback after extended loops.

Even with:

Battery optimization disabled
Background services configured

Test aggressively:

500+ loops
Screen-off playback
Different OEM devices

This is not just Flutter—it’s often Android system behavior.

What About The Root Cause?

Short answer:

I don’t fully know yet.

And yeah — that’s intentional honesty.

What I do know:

It only happens on Android 12+
It triggers after long-running background playback
It happens silently (no crash, no logs)
It correlates with a high loop count (~950)

Current Hypotheses:

Doze / background execution limits
Audio focus or media session interruption
ExoPlayer internal behavior after prolonged looping
OEM-level process killing
Resource exhaustion over time

We’ll Be Updating This

Once I dig deeper and find the exact root cause, I’ll update this blog with:

What exactly broke
Why Android 12+ behaves this way
The proper fix (not just experimental ones)
What you should do in production

Because honestly?

Debugging something that breaks at the OS level is messy… and kinda fun.

Final Thoughts

I eventually moved back to just_audio because:

The problematic flow was no longer needed

So yeah…

This experimental fix wasn’t used in production.

But it gave me something way more valuable:

A deeper understanding of how Flutter actually works under the hood.

And honestly?

I’m not perfect. I didn’t fully solve it (yet).
But now I know one more thing than I did before.

And that’s what matters.

TL;DR

Flutter is great, but not enough for everything
Method Channels = internal RPC bridge
Native gives you control Flutter abstracts away
Android background behavior can be unpredictable
Sometimes… you won’t have all the answers immediately

If you're building something serious:

Don’t just rely on abstractions. Understand what’s underneath.

That’s where real engineering begins.

Flutter’s Execution Model — Explained Like a Human

Tue, 14 Apr 2026 08:50:35 +0000

If you’ve been building with Flutter for a while, you’ve definitely heard terms like AOT and JIT thrown around.

Maybe you know debug is slower than release.
Maybe you’ve wondered what actually ends up inside your APK.

But like… what’s really going on under the hood?

Let’s open it up properly — no buzzwords, no hand-wavy stuff. Just what actually happens to your code, when it happens, and why Flutter lowkey has a massive edge.

The Simplest Way to Think About It

Imagine you invited someone over for dinner.

AOT (Ahead of Time) is you cooking everything beforehand.
Full meal ready. Table set. Chef mode ON.

They walk in → boom, food’s already there.

But if they suddenly go:

“Actually I feel like pasta instead of rice…”

…yeah, you’re screwed XD
You’re starting from scratch.

JIT (Just in Time) is the opposite.

You’re like:

“Tell me what you want, I’ll make it right now.”

Flexible? Yes.
Fast? …depends how hungry they are ;)

Flutter basically looked at both and said:

“Why not use both where they make sense?”

And that’s exactly what it does.

Debug Mode — JIT and the Dart VM

When you run:

flutter run

Your code is NOT compiled to native machine code.

Yeah — surprise.

Instead, Dart takes a completely different route.

The Compilation Pipeline

Your Dart code first goes through something called the CFE (Common Frontend).

Sounds fancy, but it’s basically:

parsing your code
checking types
resolving imports

And then it produces something called a Kernel AST.

Think of it like:

not source code, not machine code… but a structured “meaning” of your program

This gets saved as .dill files (Dart Intermediate Language).

From here, the Dart VM takes over.

Tiered JIT — This Is Where It Gets Spicy

The Dart VM doesn’t just compile everything upfront.

Because that would be dumb.

Why compile everything when half your code might never even run?

So it uses tiers:

Tier 0 — “Just run it bro”

Runs in an interpreter
No compilation
Starts instantly

Downside? Slow af.

But meanwhile, the VM is silently watching:

what functions are called
what types are used
which paths are hot

Tier 1 — “Okay this seems important”

Once a function gets called enough times:

it gets compiled to native code
but not heavily optimized

Faster than interpreter, but still warming up.

Tier 2 — “Alright I know your patterns now”

This is where things get spicy!

Now the VM has enough data to go:

“Cool, I trust this pattern.”

So it starts making bold assumptions.

Example:

If add(a, b) has only ever seen integers…

It goes:

“I’m skipping type checks. We going full speed.”

But what if suddenly a double shows up?

Boom.

Deoptimization.

throws away optimized code
falls back
re-learns

No drama. Just adapts.

The Real Trick

Cold code → stays cheap
Hot code → gets optimized like crazy

You only pay cost where it actually matters.

Hot Reload — The Real MVP

This is where JIT absolutely flexes.

You change a widget color → hit save.

Here’s what happens behind the scenes:

Only changed code gets recompiled
Sent to Dart VM over WebSocket
VM patches functions in-place
Flutter re-runs build()

And here’s the crazy part:

Your app state stays exactly the same

scroll position? safe
form input? safe
counters? safe

Because state lives in memory (heap), and you’re only swapping instructions.

That’s why hot reload feels like magic.

Why Debug Mode Feels Slow

It’s not just JIT.

Debug mode has extra baggage:

No tree shaking → everything included
Assertions ON → extra checks
DevTools hooks running
No aggressive optimizations
Constant profiling

Basically:

Debug mode = comfort + visibility
Release mode = speed + violence

Release Mode — AOT and Native Code

Now things change completely.

flutter build apk --release

No VM games anymore.

This is full AOT mode.

The Compilation Pipeline (Again, But Different Ending)

Same start:

Dart → CFE → Kernel AST

But now instead of VM → it goes to:

gen_snapshot (AOT compiler)

Type Flow Analysis — The Big Brain Move

Unlike JIT, AOT cannot guess.

No safety net. No “fix later”.

So it does something called Type Flow Analysis (TFA):

traces every possible path in your app
figures out what types can exist where
removes anything unreachable

Now the compiler can actually be bold:

inline functions
remove dead code
skip dynamic checks
devirtualize calls

Result?

Extremely optimised native machine code

What’s Inside Your APK?

If you unzip it, you’ll see something like:

your_app.apk
├── lib/
│   ├── arm64-v8a/
│   │   ├── libapp.so        ← YOUR code (compiled)
│   │   └── libflutter.so    ← Flutter engine
├── assets/
├── AndroidManifest.xml
└── classes.dex              ← tiny Android entry point

That classes.dex?

Not your app logic.

It’s just Android saying:

“Okay Flutter, you take over now.”

After that:
-->Flutter engine loads libapp.so
--> CPU runs your code directly

No VM. No interpreter. No waiting.

Why Hot Reload Is Impossible Here

In release mode:

no Dart VM
no runtime patching
no WebSocket updates

It’s just static native code.

So yeah…

--> Want changes? Rebuild. Reinstall. Done.

Profile Mode — Quick Side Note

flutter run --profile

This is the middle ground:

AOT performance
but still profiling tools available

Use it when you want real performance numbers without debug slowdown.

Why Flutter Hits Different

This is where things get really interesting.

React Native:

JS runs in the engine
communicates via bridge
data serialized/deserialized
async overhead

Flutter:

Dart → native machine code
talks directly to rendering engine
draws everything itself

No bridge. No middleman.

Flutter literally went:

“We’ll just render everything ourselves.”

And honestly?

Yeah… kinda insane.

The Mental Model

If you take one thing away, let it be this:

Debug mode → Dart VM is alive

dynamic
patchable
flexible
hot reload

Release mode → Dart VM is gone

static
precompiled
fast af
no flexibility

Flutter gives you both.

JIT for development speed
AOT for runtime performance

Compilation never disappears.

It just moves to where it makes the most sense.

Building OneRule: A Technical Deep Dive into an Offline Password Manager with Flutter, SQLCipher, and AES-GCM

Mon, 13 Apr 2026 12:48:19 +0000

Password managers often get discussed at product level: sync, UX, pricing, recovery, browser extensions.

What interested me more in OneRule was lower in stack:

what "offline-first" actually means in implementation
how local key derivation is handled
where encryption boundaries sit
how Flutter and native Android divide responsibility

OneRule is an open-source Android password manager built with Flutter. It does not require an account or backend for core vault operations. The interesting part is not only that it works offline, but that the architecture is intentionally shaped around that constraint.

This post is a technical walkthrough of current implementation: storage model, key flow, backup format, panic mode behavior, and Android Autofill boundary.

Architectural Shape

At code level, OneRule follows a fairly direct layered structure:

Flutter UI for screens, forms, and interaction flows
Provider-based state for app-level reactive data
service and facade classes for storage, crypto, backup, auth, clipboard, and platform integration
native Android code where platform APIs are necessary, especially Autofill

In practical terms, the flow looks like this:

UI/screens
  -> Provider state
    -> service/facade layer
      -> SQLCipher / secure storage / crypto / platform channels

This is not an especially exotic architecture, but it fits security-sensitive mobile software well. UI code stays mostly unaware of encryption details. Providers coordinate visible app state. Services own the mechanics of vault initialization, field encryption, backup creation, and unlock behavior.

For a Flutter app, that separation matters because it reduces chances that sensitive logic leaks into widget code and becomes harder to reason about.

The startup path is also explicit about local protections. On launch, the app initializes error handling and reminder services, then enables screen-capture protections before rendering UI:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await LocalLogService.instance.initializeGlobalErrorHandlers();
  await BackupReminderService.instance.initialize();

  if (Platform.isAndroid || Platform.isIOS) {
    await ScreenProtector.preventScreenshotOn();
    await ScreenProtector.protectDataLeakageOn();
    await ScreenProtector.protectDataLeakageWithBlur();
  }

  runApp(/* providers + app */);
}

That is small, but it shows something important about OneRule: operational security controls are part of app bootstrap, not optional polish added later.

Data-at-Rest Model

The vault is not stored as plaintext records in local SQLite.

OneRule uses SQLCipher-backed SQLite as the primary vault store. The database file is encrypted at rest, and the SQLCipher password is derived from the active in-memory session key.

But the design does not stop there.

The password field is also encrypted again at application level using AES-256-GCM. So the current storage model is effectively:

encrypted database file via SQLCipher
encrypted sensitive field payloads inside that database

That second layer is important. It means the most sensitive credential field is stored and serialized as an authenticated encrypted envelope, not only as a row protected by database-level encryption. When the Flutter app needs to render or analyze entries, it decrypts that field at read time.

The current field payload format is versioned and structured like this:

or1:v2:gcm:<nonce_b64url>:<cipherText_b64url>:<tag_b64url>

Using a versioned envelope instead of opaque bytes makes future migrations much easier. It also gives the app a clean way to distinguish between:

current AES-GCM records
legacy AES-CBC records
pre-envelope data from older versions

That matters because OneRule includes migration logic and does not assume the vault will always start in latest format.

For backups, the code takes the same approach: explicit envelope, explicit metadata, explicit version.

Key Derivation and Session Model

The master PIN is not used directly as an encryption key.

Instead, OneRule derives key material with PBKDF2-HMAC-SHA256. Current implementation uses:

100,000 iterations for interactive PIN unlock/session derivation
256-bit output
16-byte random salts

Backup encryption uses a separate derivation profile:

PBKDF2-HMAC-SHA256
200,000 iterations
256-bit output
16-byte random salt embedded in backup payload

That separation is a good design choice. Unlock flows need acceptable latency on-device. Backup export and import can afford a higher work factor because they are less frequent and less latency-sensitive.

The session model is also worth calling out:

the active vault session key is kept in memory
SQLCipher password is derived from that key
secure storage holds salts, verifiers, and biometric-restorable material
session key is cleared on logout and lock paths

So the app has a fairly explicit distinction between:

persistent verification or recovery metadata
active decrypted session state

That is small but important. A lot of local-first security design is really state-lifecycle design.

Backup derivation path is straightforward and readable in code:

Future<SecretKey> _deriveKey(String passphrase, List<int> salt) async {
  final pbkdf2 = Pbkdf2(
    macAlgorithm: Hmac.sha256(),
    iterations: _pbkdf2Iterations,
    bits: 256,
  );
  return pbkdf2.deriveKey(
    secretKey: SecretKey(utf8.encode(passphrase)),
    nonce: salt,
  );
}

Then the payload is encrypted with AES-GCM using fresh salt and nonce:

final salt = _randomBytes(16);
final nonce = _randomBytes(12);
final key = await _deriveKey(passphrase, salt);

final secretBox = await _gcm.encrypt(
  utf8.encode(plaintext),
  secretKey: key,
  nonce: nonce,
);

Why SQLCipher Plus Field-Level AES-GCM?

A reasonable question is: if SQLCipher already encrypts database file at rest, why encrypt the password field again?

The answer is separation of concerns.

SQLCipher protects the database as a container. Field-level AES-GCM protects the most sensitive payloads as application-managed cryptographic objects with explicit integrity tags and versioned envelopes.

That gives OneRule a few advantages:

clean migration path from old formats to new ones
explicit tamper detection at field level
easier reuse of encrypted credential payloads outside normal Flutter list rendering
tighter control over what can be serialized or handed to native layers

The Android Autofill integration benefits directly from this. More on that later.

Vault Migration Strategy

OneRule still contains migration support for older storage models.

There are two migration stories in current codebase:

1. Legacy vault backend migration

Older vault data could exist in Hive-based storage. Current architecture uses SQLCipher, and the app includes a one-time migration reader that imports legacy records into encrypted SQLite, then removes old box data and marks migration complete.

2. Legacy cipher format migration

Password payloads and backup payloads have moved from older layouts into AES-GCM-based envelopes.

For vault records, the app can still read:

legacy CBC envelope format
older marker-based GCM payloads
older plaintext-style legacy values

On unlock, rows are scanned and migrated into current or1:v2:gcm format. Migration is designed to be non-lossy:

read legacy payload
decrypt or parse
re-encrypt in latest format
persist migrated value

If crypto validation fails, migration hard-fails rather than overwriting questionable data.

That is exactly what you want in security migration code. Silent best-effort conversion is dangerous when integrity matters.

Backup Format and Cryptographic Container

Offline-first apps still need a portability story. Otherwise "no sync" quickly turns into "single-device risk."

OneRule handles that with encrypted backup export and import. Current export format is a JSON-based .enc container with schema version v: 3.

The backup pipeline looks like this:

collect vault records
serialize plaintext JSON
derive encryption key from backup passphrase using PBKDF2-HMAC-SHA256
encrypt with AES-256-GCM using random nonce
emit structured JSON container with metadata

The container includes:

KDF metadata
cipher metadata
salt
authenticated encryption envelope
creation timestamp
item count

That is a much better design than "just encrypt some bytes and hope future versions remember how." Explicit metadata makes forward migration, compatibility handling, and debugging safer.

Current backup writer emits a structured object like:

return {
  'v': _backupSchemaVersion,
  'envelope': {
    'format': 'onerule-backup',
    'version': 'v3',
    'algorithm': _gcmAlgorithmName,
    'nonce': base64UrlEncode(secretBox.nonce),
    'cipherText': base64UrlEncode(secretBox.cipherText),
    'tag': base64UrlEncode(secretBox.mac.bytes),
  },
  'salt': base64UrlEncode(salt),
  'kdf': {
    'algorithm': 'PBKDF2-HMAC-SHA256',
    'iterations': _pbkdf2Iterations,
    'keyBits': 256,
  },
};

That snippet captures design philosophy well: crypto parameters travel with container, not only with developer memory.

Import path is also backward-compatible with:

current .enc encrypted backups
legacy .onerule extension
previous schema v: 2
previous schema v: 1, including legacy CBC layout

Again, the pattern here is versioned crypto container plus explicit readers, not hidden magic.

Panic PIN and Privacy Flow

Panic mode is one of the more interesting product decisions because it crosses UX, threat modeling, and implementation details.

OneRule supports a separate Panic PIN verifier. When this flow is used, the app avoids exposing the real vault and enters a privacy-focused decoy mode.

There are two implementation details worth noting:

provider state sets panic mode and suppresses real vault data
home screen renders decoy credential entries for that mode

That means panic mode is not implemented as "delete everything" or "rename list to empty." It is an explicit alternate UI and state flow.

This is a subtle but meaningful distinction. Security-sensitive UX should not depend on the user remembering whether a blank screen is real, broken, or intentional.

The app also warns users that panic mode is a decoy flow and can be confusing if triggered accidentally. That kind of warning is good product engineering. Safety features that are easy to misunderstand become liabilities.

Android Autofill Boundary

Password managers live or die on ergonomics, and Android Autofill is one place where architecture decisions show up clearly.

OneRule uses a native Android AutofillService for API 26+ and bridges it from Flutter over a platform channel. The relevant boundary is important:

Flutter owns normal vault UX and decrypted entry access after unlock
Flutter syncs an encrypted credential snapshot to native storage
Flutter also provides a session key to native layer for active unlock window
native Autofill service performs decryption only when it needs to fill a request

That means Autofill is not backed by a permanently stored plaintext cache. Instead, encrypted envelopes are synced to native side, and usable decryption depends on active session state.

The platform methods reflect that design:

syncAutofillCredentialSnapshot
setAutofillSessionKey
clearAutofillSessionKey

If session key is cleared on lock/logout, Autofill stops returning datasets.

Flutter side bridge is intentionally thin:

Future<void> syncCredentialSnapshot({
  required String payload,
  required String sessionKeyBase64,
}) async {
  final state = await availability();
  if (state != AutofillMvpAvailability.available) {
    return;
  }
  await _bridge.setSessionKey(sessionKeyBase64);
  await _bridge.syncCredentialSnapshot(payload);
}

That sequence matters. Native side receives encrypted snapshot plus active session key only when feature is available and vault is in usable state.

This is a strong boundary design because it minimizes plaintext residency and ties Autofill usefulness to vault unlock state rather than treating Autofill as a separate always-on data channel.

Locking, Clipboard, and Leakage Controls

Security work is often ruined by small post-decrypt leaks rather than broken cryptography.

OneRule includes several controls in this category:

screenshot prevention and screen-capture leakage protection on mobile
auto-lock timeout based on app lifecycle transitions
clipboard auto-clear after configurable delay
optional application of clipboard policy to usernames as well

The lifecycle lock path is especially relevant in Flutter apps, where it is easy to focus on route state and forget process state. OneRule tracks pause/resume transitions and clears session state when idle time exceeds configured threshold.

The relevant branch in lifecycle observer is simple and effective:

if (diff.inSeconds > timeoutSeconds) {
  storage.clearSessionKey();
  unawaited(PlatformCredentialProvider().onVaultLocked());
  unawaited(context.read<PasswordProvider>().lockForSession());
  Navigator.of(context).pushAndRemoveUntil(
    MaterialPageRoute(builder: (_) => const LoginScreen()),
    (_) => false,
  );
}

That is exactly kind of code I like seeing in security-sensitive mobile apps: short, direct, and tied to explicit state invalidation.

That is not glamorous, but it is real security work.

Vault Health Analysis

OneRule also includes a local "Vault Health" analyzer. This is not cryptography, but it is useful security-adjacent logic.

The current report model scores the vault from 0 to 100 based on:

weak passwords
exact-match duplicate passwords
stale credentials

Duplicate detection uses local hash-based comparison logic rather than remote checks, which keeps analysis offline and aligned with rest of system design.

This is a good example of how offline-first does not need to mean feature-light. You can still deliver useful security insights locally if the data model and processing path are designed for it.

Why Flutter Works Here

Security software is often assumed to require fully native implementation, but OneRule is a good example of when Flutter is enough for most of stack and native code is reserved for true platform edges.

Flutter handles:

application UI
state management
settings and backup flows
vault rendering and search
generator and health screens

Native Android handles:

Autofill service
platform-specific storage and bridge responsibilities
native crash logging hooks

That is a practical split.

Flutter gives fast iteration and a unified codebase. Native code stays focused on surfaces where Android APIs are non-negotiable. For a solo-built security product, that balance can make a big difference in maintainability.

Threat Model Boundaries

Good security writeups should include limits, not only protections.

OneRule is designed to defend against:

offline access to copied app data without the derived key
theft or exfiltration of encrypted database files
tampering of AES-GCM protected vault fields and backups

It is not designed to fully defend against:

rooted or fully compromised operating systems
malware with runtime access while vault is unlocked
PIN disclosure by user coercion, phishing, or keylogging
clipboard interception before auto-clear executes

That is a reasonable and honest scope. Offline encryption can do a lot. It cannot fix a hostile runtime after trust boundary is already lost.

Why This Project Is Interesting

A lot of apps claim privacy because they do not have obvious ads or trackers. OneRule is more interesting than that because privacy is expressed in structure:

no backend dependency for core vault flows
explicit key derivation
versioned encrypted payloads
layered storage protection
local-only backup generation
native Autofill integration without persistent plaintext snapshot model

This is what I like about the project technically. The product promise and implementation choices mostly line up.

That is rarer than it should be.

Closing

If you want to study a Flutter security app that takes local-first architecture seriously, OneRule is worth reading through.

It is not trying to out-feature every cloud password manager. It is solving a narrower problem: how to build a usable password vault where local storage, transparent cryptographic boundaries, and offline operation are first-class constraints rather than marketing copy.

Project links:

GitHub: https://github.com/seralifatih/OneRule
Google Play: https://play.google.com/store/apps/details?id=com.fidevelopment.onerule

If you build security software in Flutter, this kind of project is a useful reminder that "mobile-first" and "security-conscious" do not have to be opposites. With careful boundaries, versioned crypto payloads, and disciplined state handling, a local-first password manager can stay practical without outsourcing trust to infrastructure.

Flutter vs React Native AI Apps: My 2026 Take

Mon, 06 Apr 2026 09:04:35 +0000

This article was originally published on BuildZn.

Everyone talks about how AI will change mobile, but nobody explains which tech stack actually gets you there without burning through your seed round. You’re Googling Flutter vs React Native AI apps right now because you need clarity, not marketing fluff. I spent a solid week building a proof-of-concept for an on-device AI feature last month, wrestling with both frameworks. Here's what actually works, and where each framework shines (or trips).

Why AI-Powered Mobile Apps Aren't Just Hype Anymore

Look, in 2026, if your mobile app isn't at least thinking about AI, it's already behind. It's not about chatbots anymore; it’s about AI-powered mobile app development driving real user value and efficiency. Think personalized content feeds, real-time object recognition, intelligent automation, or even predictive analytics directly on the user's phone.

We’re past the experimental phase. Users expect smart features. Founders, you need to decide if you’re building a product that just uses AI via an API call to OpenAI, or if you're embedding complex machine learning models directly into the app for speed, offline capability, and better data privacy. This choice dictates a lot about your framework, cost, and overall strategy.

Flutter vs React Native AI Apps: The Real Deal for Your Wallet and Timeline

Alright, let's get into the brass tacks. You care about cost, time to market, and how well this thing will perform when it's handling real AI tasks. My experience across over 20 production apps – including FarahGPT with its 5,100+ users and a complex gold trading system – gives me a pretty clear view.

Here’s the breakdown:

Flutter for AI-Powered Apps

Performance: This is where Flutter often wins, hands down, for serious on-device AI. Because it compiles directly to native code, you get near-native performance. When you’re running a TensorFlow Lite model for real-time image processing or audio analysis, those milliseconds matter. The UI stays smooth even when the CPU is churning through ML inferences.
Development Speed & Cost: My team ships fast with Flutter. A single codebase for iOS and Android means half the development effort compared to building two separate native apps. For mobile app framework AI 2026 discussions, this translates directly into lower development costs and faster timelines. One team, one codebase, one set of AI integrations. Simpler to maintain too.
AI Integration:
- On-Device ML: Flutter's integration with TensorFlow Lite is solid. You drop your .tflite model, use the tflite_flutter package, and you're good. For platform-specific features like Apple's Core ML or Google's ML Kit, Flutter's FFI (Foreign Function Interface) or platform channels let you tap into native capabilities directly with minimal boilerplate. Honestly, this direct access is a huge advantage for complex, performance-critical AI tasks.
- Cloud-Based AI: For calling APIs like OpenAI, Google Gemini, or custom ML inference services, both frameworks are equally capable. It’s just standard HTTP requests, which Flutter handles efficiently.

React Native for AI-Powered Apps

Ecosystem & Flexibility: React Native rides on the massive JavaScript ecosystem. If you’re already heavy into web development and have JS talent, the learning curve is shallower. There are plenty of existing JS libraries, and some bridge to native AI SDKs.
Performance: This is where it gets tricky. For basic API calls to cloud AI, React Native is fine. But for intensive on-device machine learning apps, the JavaScript bridge can introduce overhead. When you need to process large datasets or run complex models in real-time, that bridge can become a bottleneck. You often end up writing native modules (Java/Kotlin for Android, Swift/Objective-C for iOS) for performance-critical parts, which defeats the "single codebase" promise and drives up costs.
Development Speed & Cost: Initial setup can be quick if you're familiar with React. However, once you hit native feature requirements or performance bottlenecks for AI, development slows down. You need developers proficient in React Native and native iOS/Android, effectively increasing your team size or skill requirements. This can lead to higher long-term maintenance costs and longer development cycles for complex AI-powered mobile app development.
AI Integration:
- On-Device ML: Requires finding or building native modules that expose TensorFlow Lite, Core ML, or ML Kit to JavaScript. While packages exist (e.g., react-native-tflite-camera), they often lag behind native SDK updates or have limitations. When you need something cutting-edge, you might be building a lot of custom native code.
- Cloud-Based AI: Just like Flutter, React Native handles API calls to cloud AI services perfectly well using standard libraries like Axios or Fetch.

So, who wins for AI?

My take: If your AI strategy leans heavily on custom, on-device machine learning models for real-time processing or offline capabilities, Flutter is the stronger choice. The performance advantage and simpler native integration pathways are a game-changer. If your AI is primarily cloud-based (API calls) and you have an existing JS team, React Native can work, but be prepared for potential hurdles if you later need serious on-device ML.

For founders, this translates to:

Flutter = More predictable costs, faster iteration for complex AI, better performance ceilings.
React Native = Potentially faster initial setup if JS-heavy, but higher risk of costly native refactors for advanced AI needs.

How AI Integration Actually Looks (Not Just Theory)

When we built FarahGPT, the core logic was entirely backend. The mobile app (Flutter, naturally) just sent user input to our Node.js API, which then talked to OpenAI. Simple network calls. That’s a common, effective strategy for many best framework for AI startups.

But what if you're building something else?

Cloud-Based AI (API Calls):
- This is the easiest path. Your mobile app sends data (text, image, audio) to a backend service (your Node.js API, or a direct call to Google Gemini/AWS Rekognition).
- The backend processes it, uses an AI model, and sends the result back to the app.
- Both Flutter and React Native handle this beautifully. It's just HTTP requests. The choice here comes down to your general mobile app strategy, not AI specific issues.
```
// Example: Flutter calling an AI API
Future<String> getAIResponse(String prompt) async {
  final response = await http.post(
    Uri.parse('https://api.farahgpt.com/generate'),
    headers: {'Content-Type': 'application/json', 'Authorization': 'Bearer YOUR_API_KEY'},
    body: jsonEncode({'text': prompt}),
  );

  if (response.statusCode == 200) {
    return jsonDecode(response.body)['response'];
  } else {
    throw Exception('Failed to get AI response: ${response.body}');
  }
}
```
This code is straightforward. React Native would look similar with fetch or axios.
On-Device AI (Local Models):
- This is for scenarios where you need:
  - Real-time processing: Image filters, speech-to-text, object detection that can't wait for network latency.
  - Offline functionality: AI features work without an internet connection.
  - Data privacy: Sensitive data never leaves the device.
- This is where Flutter truly shines for Flutter for machine learning apps. With TensorFlow Lite, you embed the model directly. For example, in my gold trading system, some initial data validation and pattern recognition happened on-device before hitting the main backend.
- Flutter Implementation:
  1. Add tflite_flutter to your pubspec.yaml.
  2. Place your .tflite model in your assets.
  3. Load the model and run inferences.
- React Native Implementation:
  1. Requires react-native-tflite-camera or similar, which might involve linking native modules.
  2. Often involves more complex setup and potential versioning issues with native SDKs.
  3. Performance-sensitive parts might still push you to write custom native modules.

Here's the thing — don't overcomplicate it if you don't have to. Most startups can start with cloud-based AI. Only go on-device if you absolutely need the speed, offline, or privacy benefits.

What Most Founders Get Wrong About AI Apps

I've seen founders waste a lot of cash and time because of some common misunderstandings. Don't be that founder.

Mistake 1: Assuming "AI" means everything happens on the phone.
- Reality: For 90% of use cases, your app just sends data to a powerful AI model running in the cloud. Think about how ChatGPT works – your phone isn't running a large language model. It's hitting an API. Focus on a robust backend API strategy first.
Mistake 2: Underestimating the data required.
- Reality: Your AI model is only as good as the data it's trained on. If you're building a custom AI feature, collecting and curating quality data is often 10x harder than picking a framework.
Mistake 3: Ignoring long-term maintenance costs for native modules.
- Reality: If you pick React Native but end up writing a lot of custom native code for AI, you now have three codebases to maintain (JS, iOS Native, Android Native). Updates, bug fixes, and feature enhancements become much more expensive. Flutter generally avoids this trap by handling native interactions more gracefully.
Mistake 4: Not factoring in security and privacy from day one.
- Reality: If your AI processes sensitive user data, you need to think about encryption, data anonymization, and compliance (GDPR, HIPAA, etc.). This applies to both on-device and cloud AI. Your framework choice won't fix poor security architecture.

Optimizing Your AI App: Beyond the Framework

Picking between Flutter vs React Native AI apps is just one piece of the puzzle. To build a truly performant, scalable, and secure AI app, you need to consider the whole stack.

Backend Choice: For AI APIs, I often lean on Node.js. It's fast, scalable, and great for handling concurrent requests to external AI services or your own custom models. My experience building the backend for FarahGPT and the gold trading system confirms this.
Cloud AI Services: Don't reinvent the wheel. Google Cloud ML Kit, AWS Rekognition/SageMaker, Azure AI services – these provide pre-trained models and managed infrastructure that can save you years of development. Use them, especially in the early stages.
Data Security & Compliance: Crucial for any app, but especially for AI. Encrypt data in transit and at rest. If processing sensitive info, ensure your backend infrastructure meets compliance standards.
Scalability: If your AI app takes off (and hopefully it does!), your backend needs to scale. Plan for serverless functions (AWS Lambda, Google Cloud Functions) or containerized services (Kubernetes) to handle increased AI inference requests.

FAQs

Q1: Which framework is cheaper for an AI startup?

A: For basic cloud AI, costs are similar. For complex on-device AI, Flutter often offers lower overall TCO due to better performance, fewer native development needs, and thus, fewer specialized developers required.

Q2: Can I use existing AI models with Flutter/React Native?

A: Yes, both can consume cloud AI APIs (like OpenAI, Google Gemini). For on-device, Flutter integrates well with TensorFlow Lite directly. React Native typically requires community packages or custom native modules for local ML.

Q3: What if I need super fast, real-time AI processing?

A: If low latency and high throughput are critical, Flutter is generally preferred for its near-native performance when running on-device models. This reduces reliance on network speeds and minimizes UI jank.

Look, by 2026, every app will have some AI baked in. The choice of mobile app framework AI 2026 is critical. My strong opinion? For a serious AI-powered mobile app development project, especially if you foresee needing any significant on-device machine learning or truly custom experiences, Flutter is the clear winner for its performance, developer efficiency, and future-proofing. React Native can get you there for simpler, API-driven AI, but be ready to compromise on performance or budget if you push its limits. Don't let framework hype distract you from building actual value.

Want to talk through your specific AI app idea and figure out the best stack for your budget and timeline? I've been there, done that. Let's schedule a quick call – my calendar link is [Your Calendar Link Here].

From Spaghetti to Structure: Why I Migrated My Production Flutter App to Clean Architecture

Wed, 01 Apr 2026 04:48:07 +0000

"First make it work, then make it beautiful and robust."

I'm a junior dev. I built a real app — Anahad — that real people use. And for a while, I was proud of it.

Then it grew. And I wasn't so proud anymore.

This isn't a textbook post about Clean Architecture. This is the story of what broke, why I finally made the switch, and what actually clicked for me — told by someone who was in the trenches with a messy codebase and had to ship features at the same time.

The Mess I Was Living In

Picture this: 6 features. Each with their own screens, widgets, blocs, services, and utils — all distributed across a directory structure that looked neat on day one and became a labyrinth by month three.

Most screens were monoliths — all-in-one files with UI and logic tangled together. The ones that did use components? Everything went into a global widgets/ directory. So you'd have prop drilling across three levels just to pass something that one widget needed. Tracking the flow of data meant hopping between directories, mentally stitching together a picture of how things connected.

Error handling was... creative. I'd built my own AsyncResult<Success, Error> sealed class — functional programming vibes without the actual library. It worked at the service layer, but it was an island. Nothing else was consistent.

And the worst part? My services were tightly coupled to Dio and the remote API. No abstraction. No interface. You couldn't mock anything. You couldn't test anything. If Dio failed, the whole thing failed, and you had to dig to figure out why.

The moment I truly felt it was when I had to trace a bug and found myself drilling through 5 directories just to understand the flow. That's when I knew — this isn't scaling. This is surviving.

What Is Flutter Clean Architecture, Actually?

Before I get into the migration, let me walk you through the structure — because once it clicked, I couldn't unsee it.

Clean Architecture splits your app into three layers:

Presentation Layer

This is everything the user sees and touches.

Screens — Your UI pages
Widgets — Reusable UI components
Bloc — State management; the brain between UI and business logic

The Bloc only talks to the Domain layer. It doesn't know where data comes from. Doesn't care.

Domain Layer

This is the pure heart of your app. No Flutter. No Dio. No Firebase. Just Dart.

Entities — Plain Dart classes representing your core data models
Use Cases — Single-responsibility classes that each do one thing (e.g., LoginUseCase, FetchUserProfileUseCase)
Repository (Interface) — Abstract contracts defining what data operations exist, not how they work

This layer has zero dependencies on anything external. It's the most stable, most testable code in your app.

️ Data Layer

This is where the real world connects.

Models — Extend your Entities; handle JSON serialization, API mapping
Repository (Implementation) — Implements the Domain's repository interface
Data Sources — Remote (Dio, Firebase) and Local (Hive, SQLite)

The magic line? The Repository Implementation delegates data fetching to the datasource. The domain doesn't care if it's coming from the internet or a local cache.

Bloc → UseCase → Repository Interface
                        ↑
              Repository Implementation → Remote / Local Datasource

The Migration: Incremental, Not a Rewrite

Here's the thing nobody tells you: you don't have to nuke your codebase.

I had features to ship. Users on the app. I couldn't just disappear for two weeks and "do clean architecture." So I went incremental.

I started with the auth flow — the most self-contained, most critical part of the app. My service methods were already well-written, so the migration was mostly structural:

Converted service methods into Use Cases
Moved Dio calls into a RemoteDataSource
Created a Repository Implementation that satisfied the Domain's abstract interface
Wired the Bloc to talk to the Use Case instead of the service directly

It wasn't that hard, honestly. But the payoff was immediate.

Now if I want to add offline support to Anahad? I create a LocalDataSource, and the Repository Implementation switches between them. The Bloc doesn't change. The Use Cases don't change. The Domain doesn't even know it happened.

That's the beauty.

fpdart and Functional Programming in Use Cases

Coming from a Rust background, I was already comfortable with Option and Result types. I'd even hacked together my own AsyncResult<Success, Error> sealed class before this migration.

When I discovered fpdart, it was like: oh, this is just the proper version of what I was already doing.

In my Use Cases, I now use Either<Failure, Success> for all return types. Left is failure, right is success — and you chain transformations cleanly without nested try-catches or nullable hell.

// Use Case
class LoginUseCase {
  final AuthRepository repository;

  LoginUseCase(this.repository);

  Future<Either<Failure, User>> call(LoginParams params) async {
    return await repository.login(params.email, params.password);
  }
}

// In the Bloc
final result = await loginUseCase(LoginParams(email: email, password: password));

result.fold(
  (failure) => emit(AuthError(failure.message)),
  (user)    => emit(AuthSuccess(user)),
);

No try-catch spaghetti. No "did this return null or did it actually fail?" ambiguity. The types tell the story.

The "Aha" Moment

I'll be honest — my first reaction to Clean Architecture was "this is way too much boilerplate."

Why write a Use Case class that just calls a repository method? Why create an abstract interface when I could just use the implementation directly? Seemed like over-engineering for the sake of it.

Then I migrated the auth flow. And something just... clicked.

I was looking at my Bloc, and I realized: this Bloc has no idea where the user data comes from. It doesn't import Dio. It doesn't know about Firebase. It just calls loginUseCase() and reacts to the result.

Before this, I couldn't test anything because everything was tightly coupled. The service needed Dio, Dio needed a real network, the network needed... you get it. Now, because the Repository is an abstract interface, I can mock it in tests trivially:

class MockAuthRepository extends Mock implements AuthRepository {}

That's it. Inject it. Test your Use Cases in complete isolation.

Ambiguity went away. I know exactly what each file does, what it depends on, and what it's responsible for. When something breaks, I know which layer to look at.

Should You Use Clean Architecture for Every App?

No. Please don't.

If you're building a weekend project or learning Flutter for the first time, don't start with Clean Architecture. You'll spend more time setting up the structure than building the thing, and you'll learn why the architecture exists without ever feeling the pain it solves.

The pain is the teacher.

Build the app. Ship it. Let it grow. Feel the moment where you're drilling through 5 directories to trace a bug, where you can't mock a thing for testing, where adding one feature means touching 8 files in 6 different folders.

Then reach for Clean Architecture. Because then you'll understand it — not just intellectually, but in your bones.

The architecture exists to solve real problems. Let the problems teach you first.

Quick Reference: The Layer Cheat Sheet

Layer	Contains	Depends On
Presentation	Screens, Widgets, Bloc	Domain only
Domain	Entities, Use Cases, Repository Interface	Nothing (pure Dart)
Data	Models, Repository Impl, Data Sources	Domain interfaces

What's Next for Anahad

Migrating the remaining 5 features incrementally
Adding a proper logging layer
Writing actual unit tests now that mocking is possible
Maybe offline support — and thanks to clean architecture, it'll be a datasource swap, not a rewrite

If you're a fellow junior dev with a production app that's starting to smell — I see you. You don't have to have everything figured out from day one. Build it, feel the pain, then build it better.

That's not a failure. That's engineering.

Built with love (and a lot of refactoring) while working on Anahad.
Hit me up on Twitter/X if this resonated — always happy to talk Flutter, architecture, or why Rust spoils you for everything else.

Flutter Performance Optimization 2026 (Make Your App 10x Faster + Best Practices)

Sun, 22 Mar 2026 20:11:53 +0000

Hey guys, Samuel here again. One of the crucial aspects of mobile app development is performance optimization to ensure the app is usable even on low-quality devices and delivers a very good user experience, which is what we will be looking into today.

To optimize a Flutter application's performance, focus on minimizing unnecessary widget rebuilds, using efficient rendering techniques, and managing resources effectively. The key steps involve leveraging built-in tools for profiling, optimizing UI code, and improving data handling efficiency.

Performance Diagnosis

Before optimizing, you must identify bottlenecks using the right tools:

Run in Profile Mode: Always profile your app in profile mode on a physical device, as debug mode performance is not representative of the final release build.

flutter run --profile

Flutter DevTools: Use the Flutter DevTools suite (Performance, Memory, Network tabs) to analyze frame rendering times, CPU usage, memory allocation, and network latency.
Performance Overlay: Use the built-in PerformanceOverlay widget or press 'P' in the terminal while running the app to see real-time UI and GPU thread frame times. Red bars indicate "jank" (dropped frames).

MaterialApp(
  ...
  showPerformanceOverlay: true,
  ...
),

Most performance issues stem from inefficient UI code.

Minimize Widget Rebuilds:

- Use const constructors for widgets that don't change to allow Flutter to reuse them at compile time, reducing runtime overhead.

const Text("This widget would not rebuild"),

- Refactor large build methods into smaller, dedicated StatelessWidget or StatefulWidget classes to localize the scope of rebuilds.

- Use state management solutions (like Provider, Riverpod, or BLoC) with Consumer or Selector to ensure only the necessary parts of the UI rebuild when the state changes.

- Use ValueListenableBuilder or AnimatedBuilder for fine-grained updates instead of calling setState() on large widgets.

Optimize Lists and Animations:

- For long lists, use ListView.builder (or SliverList) to lazy load items, building them only when they become visible on screen.

ListView.builder(
  shrinkWrap: true,
  physics: const NeverScrollableScrollPhysics(),
  itemCount: 1,
  itemBuilder: (context, index) {
    return ListTile();
  },
),

// OR

 SliverList.builder(
  itemBuilder: (context, index) =>
      Container(height: 100),
 ),

- Wrap complex, frequently animating widgets in a RepaintBoundary to isolate their repainting from the rest of the UI.

RepaintBoundary(child: ...),

- Avoid using the Opacity widget directly for animations; prefer FadeTransition instead, as it's more performant.

Resource and Data Management

Efficiently handle data, images, and heavy computations to prevent UI freezes.

Image Handling:

- Use the cached_network_image package for images from the network to implement efficient caching and reduce network requests.

- Compress images before bundling them with the app and loading them at optimal resolutions.

Asynchronous Operations:

- Use async/await, FutureBuilder, and StreamBuilder to perform network requests and other I/O operations without blocking the main UI thread.

- For CPU-intensive tasks (e.g., heavy data processing), use Isolates via the compute function to run them on a separate thread.
Memory Management:

- Always dispose of controllers (AnimationController, TextEditingController, etc.), StreamSubscription instances, and other resources in the dispose() Method of your StatefulWidget to prevent memory leaks.

Network Optimization:

- Implement data pagination for large datasets to avoid fetching all data at once.
- Cache API responses to reduce the number of network calls and improve perceived performance.

App Size and Build Optimizations

Reduce App Size:

- Remove unused assets and libraries ("tree-shaking").
- Use the flutter build apk --split-per-abi command to generate smaller APKs for different device architectures.

Enable Release Mode: Always verify final performance using flutter run --release or by building the app in release mode.

That's it! You've fully optimized your Flutter app performance if you follow all the principles. If you have any questions, make sure to drop them in the comment section.

Join Free Newsletter: https://techwithsam.dev/newsletter

Samuel Adekunle, Tech With Sam YouTube

How to Build Responsive Flutter Apps for Phones, Foldables, Tablets & Web (2026)

Sun, 22 Mar 2026 20:07:58 +0000

Hey everyone, Samuel here! In 2026, your Flutter app needs to look perfect on a tiny phone, a folding tablet, a desktop window, and even on the web — all from one codebase.

Nothing kills user experience faster than a layout that breaks on different screen sizes.

Today, we’re doing a complete how-to: building fully responsive UIs using MediaQuery, LayoutBuilder, breakpoints, and the best scaling tricks in 2026. By the end of this article, you’ll have all you need to build professional apps that automatically adapt everywhere. Let’s jump in!

Why Responsive Matters + Core Concepts

First, a quick difference: Responsive design means the UI scales and reflows. Adaptive design means it completely changes the structure (e.g., showing a side menu on a tablet). In 2026, users expect buttery smooth adaptation — no overflow, no tiny text, no broken layouts. The two weapons we’ll use most:

MediaQuery → get screen size, orientation, padding
LayoutBuilder → get exact constraints of the parent widget

These are built-in, zero dependencies, and still the foundation.

MediaQuery & Basic Responsiveness

Let’s start simple. In your home screen:

double screenWidth = MediaQuery.of(context).size.width;
double screenHeight = MediaQuery.of(context).size.height;
bool isLandscape = MediaQuery.of(context).orientation == Orientation.landscape;

Now build a profile card:

Container(
  width: screenWidth * 0.9,           // 90% of screen
  height: screenHeight * 0.25,
  padding: const EdgeInsets.all(20),
  decoration: BoxDecoration(... glassmorphism ...),
  child: Column(...)
)

See how it automatically scales?

Next, orientation handling:

if (isLandscape) {
  return Row(children: [sidebar, mainContent]);
} else {
  return Column(children: [header, mainContent]);
}

That already makes it way better on tablets and desktops.

Advanced — LayoutBuilder + Breakpoints

Now the real power tool: LayoutBuilder.

Wrap your Scaffold body:

LayoutBuilder(
  builder: (context, constraints) {
    if (constraints.maxWidth >= 1024) return DesktopLayout();
    if (constraints.maxWidth >= 600) return TabletLayout();
    return MobileLayout();
  },
)

We have three separate widgets: MobileLayout (stacked), TabletLayout (two-column), and DesktopLayout (sidebar + content).

The layout instantly switches as you resize the window, no refresh needed.

Scaling Magic with Flutter ScreenUtil (2026 Best Practice)

For pixel-perfect scaling across all devices, we can still use flutter_screenutil in 2026.

Add to pubspec:

dependencies:
  flutter_screenutil: ^5.9.3   # latest stable

Then in the main.dart:

ScreenUtilInit(
  designSize: const Size(375, 812),   // iPhone 12/13 size
  minTextAdapt: true,
  splitScreenMode: true,
  builder: (context, child) => MaterialApp(...)
)

Now you can write:

Text(’Hello’, style: TextStyle(fontSize: 16.sp)),
Container(width: 200.w, height: 50.h)

It scales fonts, padding, everything automatically. Combine this with LayoutBuilder, and you have production-ready responsive UIs.

Quick pause before we finish, I want to invite you to my free newsletter personally. Every week, I send the exact code snippets, early access to full project repos, and the latest 2026 tips that I don’t always cover in videos. It’s completely free, zero spam, and it’s the fastest way to level up. Just click this link: https://techwithsam.dev/newsletter — I’d love to see you there!

Best Practices & SafeArea

Final pro tips for 2026:

Always wrap top-level content in SafeArea
Use MediaQuery.padding for notches and dynamic islands
Limit max width on large screens: ConstrainedBox(maxWidth: 1200)
Test in all orientations + web + different window sizes
Use const everywhere
Profile with DevTools — responsive UIs should stay under 8ms per frame

That’s it! You now have everything to build beautiful, responsive UIs that work everywhere. If you have any questions, make sure to drop them in the comment section.

Don’t forget to join my Free Newsletter: https://techwithsam.dev/newsletter

Samuel Adekunle, Tech With Sam YouTube

Stitch + Antigravity + Flutter: Build Apps with AI Agents in 2026

Sun, 22 Mar 2026 19:55:52 +0000

In 2026, the way we build Flutter apps has completely changed. You no longer start by opening VS Code and typing widgets line by line.

Instead, you describe your app in plain English, an AI agent designs the entire UI, another agent writes and wires up the code, and you only guide the process.

That’s exactly what Google’s Stitch + Antigravity + Flutter combo delivers.

Today I’m going to show you the complete end-to-end workflow: from a simple prompt to a fully functional Flutter app in under a few minutes. This is the new skill every Flutter developer needs in 2026.

Why This Workflow Matters Right Now

Stitch is Google’s AI design agent. You give it a text prompt or even a rough sketch, and it instantly generates production-ready UI designs and structured metadata.

Antigravity is Google’s agentic IDE — a next-gen VS Code fork powered by Gemini. It doesn’t just suggest code; it plans, runs terminal commands, installs packages, writes tests, and iterates until the app works.

When you connect Stitch output to Antigravity via the new MCP (Model Context Protocol) connectors, the AI agent converts the design into real Flutter + Dart code.

This is what the community is calling “vibe coding” or “agentic development.” The developer is still in control — you review, tweak prompts, and make final decisions. But the heavy lifting is handled by agents.

Perfect for rapid prototyping, MVPs, or even production features.

Prerequisites & Setup

Before we build:

Flutter 3.27+ (stable)
Google account with access to Antigravity (antigravity.google)
Stitch access at stitch.withgoogle.com (Google Labs)

Step 1: Install Antigravity (it’s a separate IDE). Download from antigravity.google and open it.

Step 2: Enable MCP connectors in Antigravity settings (this links Stitch directly).

Step 3: Create a new Flutter project in Antigravity or create an empty folder and open it on Antigravity; it will handle every other setup.

Live Build Demo — Let’s Build a Real App. We’re going to build a simple ‘Daily Habit Tracker’ app using only prompts.

First, open Stitch:

Prompt:

Create a clean, modern mobile habit tracker application UI designed to help users build consistent daily routines and maintain positive habits. The design should feel minimal, motivating, and calming, encouraging users to stay consistent with their goals. Use a modern, accessible color system with a primary accent color and soft neutral backgrounds. Support both light mode and dark mode. Use rounded cards, subtle shadows, smooth spacing, and simple iconography to create a polished mobile experience. The application should include bottom navigation with the following sections:

Home / Today Screen

*   Display a daily streak counter at the top with a visually engaging streak indicator (flame or progress ring).
    
*   Show today’s habits list in card format.
    
*   Each habit should include:
    
    *   A checkbox or toggle to mark completion.
        
    *   Habit name.
        
    *   Optional small progress indicator.
        
*   Include a progress summary showing how many habits are completed for the day.
    
*   Add a motivational quote section at the bottom to inspire users.
    

Habits Screen

*   Display a list of all created habits.
    
*   Each habit card should show:
    
    *   Habit name
        
    *   Current streak
        
    *   Completion progress
        
*   Provide an “Add Habit” floating action button.
    
*   Allow editing or deleting habits.
    

Progress / Statistics Screen

*   Display weekly and monthly habit completion charts.
    
*   Show streak history and completion percentages.
    
*   Include visual elements like line charts or progress rings.
    

Profile / Settings Screen

*   Display a circular user avatar.
    
*   Show user statistics such as:
    
    *   Total habits created
        
    *   Longest streak
        
    *   Total days completed
        
*   Include settings such as:
    
    *   Dark mode toggle
        
    *   Notification reminders
        
    *   Habit reminder times
        

Design Style

*   Minimalist and modern mobile UI
    
*   Rounded cards and soft shadows
    
*   Smooth spacing and readable typography
    
*   Friendly icons and subtle animations
    
*   Clean bottom navigation bar
    
*   Consistent spacing and hierarchy

Stitch instantly generates the full UI design + metadata. Now select the screens generated by Stitch and click on Export — then select MCP

Now copy the Prompt and move to Antigravity:

Open the Agent Tab and paste the prompt from Stitch

After Antigravity is done downloading all the screens, then you can give it an instruction of what to build e.g

Use the UI layout generated from Stitch and build a Flutter application using Dart. 
The project should follow Clean Architecture and separate presentation, domain, and data layers. 
Use the Riverpod for state management. Ensure UI components are separated from business logic and follow a clear architecture project structure.

Watch the magic afterward. By the way, the AI Agent will ask for permission to run some commands; make sure you go through and approve accordingly.

After 10–12 minutes, run flutter run and the fully functional app appears on your emulator.

Best Practices & Pro Tips

Key lessons from using this daily:

Always start with a clear, detailed prompt in Stitch (include platform, theme, accessibility).
In Antigravity, use the ‘Manager Agent’ mode and give it one task at a time.
Review every generated file — AI is fast but not perfect yet (especially complex state logic).
Combine with your existing skills: Use Riverpod, GoRouter, and Impeller optimizations from my earlier videos.
Limitations: Native plugins and heavy custom logic still need human oversight.
Pro move: Save your best prompts as reusable skills in Antigravity for future projects.

This workflow is gaining traction in the Flutter community right now because it lets you go from idea to a working app faster than ever.

Quick pause before we finish, if you’re serious about mastering AI tools like this, join my free Flutter + AI newsletter. Every week, I share the exact prompts, workflows, and early access to new agent skills that I test before they hit YouTube. Completely free, no spam — just the most relevant stuff for Flutter developers. https://techwithsam.dev/newsletter — I’d love to see you there!

This is the new reality of Flutter development in 2026 — Stitch for design, Antigravity for agentic building, and you as the conductor.

Don’t forget to join my Free Newsletter: https://techwithsam.dev/newsletter

Samuel Adekunle, Tech With Sam YouTube

Refined Your Flutter Recipe App using Gemini AI

Mon, 16 Mar 2026 03:43:11 +0000

Hola..Back to article writing and I want to tell a story about my journey as Boarding House Citizen. Living in a boarding house alone, sometimes leaving leftover food can feel kind of unreal in a good way. Back at home, leftovers usually came with rules, reminders, or a bit of guilt, especially after big celebrations like Eid Al-Fitr or Christmas.

Here, it’s not like that at all. The fridge is shared, containers are labeled, and everyone knows that food can be shared if it’s meant to be. When I cook too much or can’t finish my meal, I just pack it up instead of forcing myself to eat more. Someone else might enjoy it later after a long day at work or a late night of studying. It just makes sense.

Food leftovers should not be wasted, even though many people feel unsure what to cook with them. Leftover rice, vegetables, or bread can be turned into simple meals like fried rice, soup, or toast. Checking the fridge before cooking helps reduce waste. Using leftovers saves money, cut daily meal cost, and is good for the environment.

Now imagine you could build a real-life app that calculates and combines all your leftover food into one new recipe and shows the budget cost like you’ll never think of? Now we’ll make it using flutter.

Note: due to character limitation, see full article on my Medium

How a Bug Report Led Me to Give Flutter Developers Full Control of Crisp Chat Modals on iOS

Sun, 15 Mar 2026 07:25:41 +0000

One of the things I enjoy most about maintaining open-source software is that sometimes the best improvements start with something very small.

A simple bug report.
A curious investigation.
And sometimes… a new feature idea.

This story started exactly like that.

The Bug Report That Started Everything

While reviewing issues for the Flutter Crisp Chat plugin, I noticed a report opened by Nikita Alexeev.

The title immediately caught my attention:

“Taps pass through chat modal to underlying UI on iOS 13+.”

That sounded strange.

A modal should block interactions with the UI behind it. So how could taps reach the Flutter app underneath?

I opened the issue and read the details carefully.

The behavior was simple but frustrating:

Open the Crisp chat on an iPhone
Tap near the top area of the chat
Suddenly the Flutter UI behind it reacts

Buttons could be pressed. Navigation could trigger. All while the chat was still visible.

That’s definitely not the experience anyone wants when they open a support chat.

So I started digging.

Learning Something Interesting About iOS

While reading the issue discussion and the explanation from Nikita Alexeev, I discovered something interesting about iOS.

Starting with iOS 13, Apple changed how modal presentations behave by default.

Before iOS 13, most modals were presented using:

.fullScreen

Which means the modal covers the entire screen. Nothing behind it is visible, and more importantly, nothing behind it can receive touches.

But iOS 13 introduced a new default style:

.pageSheet

This creates the modern sheet-style UI where the modal slides up from the bottom and leaves part of the background visible.

It looks elegant and more native to modern iOS design.

But there was a catch.

In this case, the dimmed background area was still allowing touch events to reach the Flutter UI underneath.

That explained exactly why users were accidentally triggering buttons behind the chat window.

Suddenly the bug made perfect sense.

The Pull Request That Fixed It

Soon after reporting the issue, Nikita Alexeev submitted a pull request with a very straightforward fix.

Instead of relying on the default modal style, he forced the chat view controller to use full screen presentation.

The change looked like this:

let chatVC = ChatViewController()
chatVC.modalPresentationStyle = .fullScreen
viewController.present(chatVC, animated: true)

It was a very small change, but it solved the problem completely.

By forcing .fullScreen, the chat now covered the entire screen again, which meant no touches could leak through to the Flutter UI behind it.

The issue was fixed.

But while reviewing the pull request, a new idea came to my mind.

The Moment the Idea Appeared

Yes, .fullScreen solved the issue.

But iOS actually supports several modal presentation styles.

For example:

.fullScreen
.pageSheet
.formSheet
.overFullScreen
.overCurrentContext
.popover

Different apps use different modal styles depending on their design.

Some apps prefer full screen.

Some prefer sheet-style modals.

Some prefer overlays.

So instead of hardcoding .fullScreen, I thought:

What if Flutter developers could choose the modal style themselves?

That way:

The touch-through bug stays fixed
Developers get flexibility
The plugin becomes more powerful

That’s when the idea shifted from a bug fix to a developer-focused feature.

Turning the Idea into a Feature

To make this possible, I needed to expose the modal presentation style all the way from Flutter to the native iOS implementation.

So I started with the Flutter configuration.

Step 1 — Extending the Flutter Configuration

First, I added a new enum to represent the iOS modal styles.

enum ModalPresentationStyle {
  fullScreen,
  pageSheet,
  formSheet,
  overFullScreen,
  overCurrentContext,
  popover,
}

Then I added it to the CrispConfig class.

class CrispConfig {
  final String websiteID;
  final String? tokenId;
  final ModalPresentationStyle? modalPresentationStyle;

  CrispConfig({
    required this.websiteID,
    this.tokenId,
    this.modalPresentationStyle,
  });
}

Now Flutter developers could specify how the chat modal should appear.

Step 2 — Bridging the Setting to iOS

Next, I needed to convert that Flutter value into a native iOS presentation style.

Inside the Swift plugin code, I mapped the configuration to UIModalPresentationStyle.

switch modalPresentationStyleString {
case "fullScreen":
    modalPresentationStyle = .fullScreen
case "pageSheet":
    modalPresentationStyle = .pageSheet
case "formSheet":
    modalPresentationStyle = .formSheet
case "overFullScreen":
    modalPresentationStyle = .overFullScreen
case "overCurrentContext":
    modalPresentationStyle = .overCurrentContext
case "popover":
    modalPresentationStyle = .popover
default:
    modalPresentationStyle = .fullScreen
}

This ensured a safe default while still allowing flexibility.

Step 3 — Applying the Configuration

Finally, instead of hardcoding .fullScreen, the plugin now uses the configured style.

let chatVC = ChatViewController()
chatVC.modalPresentationStyle = crispConfig.modalPresentationStyle

viewController.present(chatVC, animated: true)

Now Flutter developers have full control over the presentation style.

Making the Feature Easy to Discover

After implementing the improvements, I wanted to make sure developers could easily explore and understand them.

So I also improved the developer experience around the plugin.

I added an interactive demo inside the example app where developers can test different iOS modal styles.

There’s a button called “iOS Modal Style Demo” that opens the chat using different presentation styles so developers can see how each one behaves.

I also updated the documentation to clearly explain:

How iOS modal presentation works
Why .fullScreen fixes the touch-through issue
How to configure the modal style in Flutter

What Developers Gain From This

What started as a small bug report now gives Flutter developers several benefits.

Better User Experience

No more accidental taps on the UI behind the chat.

Flexible Modal Presentation

Developers can choose the modal style that fits their app design.

Platform Awareness

These changes only affect iOS behavior, while Android remains unchanged.

What I Love About Open Source

This experience reminded me why I enjoy maintaining open-source projects.

Sometimes improvements don’t start with big feature ideas.

They start with a simple issue report.

A developer noticing something strange.

A pull request proposing a fix.

And a moment of curiosity that turns a bug fix into something better.

So huge thanks to Nikita Alexeev for reporting the issue and submitting the original fix that inspired this improvement.

Try It Yourself

If you’re using the Flutter Crisp Chat plugin, you can try the new configuration like this:

final config = CrispConfig(
  websiteID: 'YOUR_WEBSITE_ID',
  modalPresentationStyle: ModalPresentationStyle.pageSheet,
  enableNotifications: false,
);

And if you’re curious to see how each modal style behaves, check out the example app in the repository.

Sometimes the best features don’t start with a roadmap.

They start with a bug report…
and a little curiosity.

How to Push Over-the-Air Flutter Updates with Shorebird — Complete 2026 Guide

Wed, 04 Mar 2026 20:40:21 +0000

One of the biggest frustrations for mobile devs is still waiting days or weeks for App Store or Play Store approvals to ship a small bug fix, UI tweak, or critical security patch. What if you could push those changes instantly, over-the-air, directly to your users' devices? No resubmission, no waiting, no lost users. That's exactly what @shorebird Code Push delivers: true over-the-air (OTA) updates for Dart code in Flutter apps.

Coder Legion - Recent posts tagged flutter

Flutter’s UI Architecture Explained for Beginners: Widgets, Elements, and Render Objects

Flutter Basics

Flutter Basics Overview

Prerequisites:

What is Flutter?

Dart

Declarative UI / Reactive Programming

Multiplatform Development

What exactly is State?

The Widget Tree in Flutter

Key Components of the Widget Tree

Main Function

Cupertino vs Material Widgets

Flutter Rendering and UI Architecture

Difference between Stateless & Stateful widgets

Stateful Widget Lifecycle (initState, dispose)

How setState() triggers UI rebuilds

Text Changer App Example

Summary

Bento Scan AI Document Scanner

A white-label scanner that works offline first

Included capabilities

Meet Folio: The Open-Source, Local-First Workspace for Your Notes and Ideas

️ Everything You Can Do with Folio

The 0.7.8 Milestone: Moving to a Custom Java Backend

Open Source & Supporting the Project

Get Started

Tracking From the Grave: How Apps Follow Your Location After They're Killed

Why you cannot just keep the app running

The heart of it: be lazy to be accurate

Now the part everyone asks about: what happens when the app dies

Android: a permanent worker plus notes held by the system

iOS: the system relaunches your app for you

"Terminated" is not just one thing

The last piece: never lose a single point

The full picture in one diagram

Step by step: build this yourself in Flutter

Step 0: understand what you are signing up for

Step 1: add the package

Step 2: Android setup

2a. Permissions in AndroidManifest.xml

2b. License key (only needed for release)

2c. Gradle repository

Step 3: iOS setup

3a. Info.plist text

3b. Background modes

Step 4: ask for permission the right way

Step 5: configure and start tracking (the Dart part)

Step 6: handle the headless wake-up (Android)

Step 7: test it properly

Step 8: survive the cheap-phone problem (very important in India)

Quick mental checklist

When does the foreground service actually show up? (clearing the confusion)

When it starts

If it stops (notification disappears), is that a problem?

If you want the notification to stay visible always

A different way real apps do this (a teardown story)

Way 1: The Dart-only approach (the geolocator plugin)

Way 2: The native approach with method and event channels

Method channel versus event channel, in one line each

The signals you can grab natively, and why they matter

Android native (Kotlin)

iOS native (Swift)

The Dart side, just listening

Which way should you pick?

The piece the earlier sections skipped: stopping fake GPS

Live tracking versus store and forward

What to copy and what to avoid

The third wake-up style: timer-driven periodic sampling

First, why a normal timer does not work

Piece one: SCHEDULE_EXACT_ALARM, the part that wakes the phone

Piece two: WAKE_LOCK, the part that keeps the phone awake long enough

The full loop

What it looks like in Kotlin

Two caveats you must plan for

So where does this fit among the three styles?

Automate Unused Asset Cleanup in Flutter

What cleanbev actually does

The gap: someone could forgot to cleanup some assets before pushing

Data model: events, `kind`, and tags