DEV Community: flutter

Flutter vs. Native: The ROI Mistake Many Startup Founders Make

Mavani Solution — Tue, 28 Jul 2026 04:37:36 +0000

One of the biggest decisions a startup founder faces is choosing the right technology for a mobile app.

The conversation usually becomes:

Flutter or Native?

Unfortunately, many teams make this decision based on trends, personal preferences, or social media debates instead of business goals.

The real question isn't:

"Which framework is better?"

It's:

"Which option delivers the best return on investment for my product?"

For many startups, time-to-market is critical. Launching quickly, validating ideas, and iterating based on user feedback often matter more than choosing the "perfect" technology.

At the same time, every product has different requirements.

Some apps benefit from a shared cross-platform codebase, while others require deep platform-specific integrations or maximum hardware performance.

The right choice depends on your product—not internet opinions.

In this article, I explore the business and engineering trade-offs between Flutter and native development, including:

Development speed and time-to-market
Long-term maintenance costs
Performance considerations
Scalability and future growth
Team productivity and hiring
Choosing technology based on ROI instead of hype

Technology should support your business strategy, not dictate it.

Whether you're building an MVP, a SaaS product, or an enterprise application, selecting the right development approach can save months of work and significantly reduce long-term costs.

Read the full article:

https://mavanisolution.com/resources/flutter-vs-native-roi-mistake-founders

Discussion: If you were starting a new mobile project today, would you choose Flutter or native development? What factors would influence your decision the most?

The True Cost of Building a Mobile Apps in 2026: What Founders Often Miss

Mavani Solution — Tue, 28 Jul 2026 04:35:41 +0000

One of the most common questions founders ask is:

"How much does it cost to build a mobile app?"

The honest answer is:

It depends on much more than the feature list.

The real cost of an app isn't just the initial development. It's influenced by architecture, backend infrastructure, UI/UX, integrations, security, testing, scalability, deployment, and long-term maintenance.

Many startups focus on reducing upfront development costs but overlook the hidden expenses that appear later:

Technical debt from rushed development
Performance bottlenecks as users grow
Expensive feature rewrites
Security vulnerabilities
Increasing cloud infrastructure costs
Ongoing maintenance and support
Poor scalability requiring major architectural changes

Building a successful app isn't about choosing the cheapest option.

It's about making smart engineering decisions that reduce long-term costs while improving reliability and user experience.

In this article, I break down the real factors that influence mobile app development costs in 2026 and explain how founders can invest wisely without compromising quality.

Key takeaways include:

What actually drives development costs
Hidden expenses many startups overlook
Why architecture matters more than you think
How to avoid expensive rebuilds
Building for scalability from day one
Balancing budget, speed, and long-term ROI

Whether you're building your first MVP or scaling an existing product, understanding these cost drivers can help you avoid expensive mistakes and make better technical decisions.

Read the full article:

https://mavanisolution.com/resources/true-cost-building-mobile-apps-2026

Discussion: What's the biggest hidden cost you've encountered while building a mobile app—technical debt, infrastructure, maintenance, changing requirements, or something else?

Seamless Flutter Hooks Integration with BlocSignal via signals_hooks

Randal L. Schwartz — Mon, 27 Jul 2026 22:37:30 +0000

Zero Glue Code. Streamless Reactivity. Pure Hook Composition.

If you’ve built Flutter applications using flutter_hooks, you know how empowering hook-based composition can be. By replacing boilerplate StatefulWidget lifecycles with declarative hooks like useState, useMemoized, and useEffect, Flutter Hooks makes widget code remarkably concise.

However, when developers tried bridging classic flutter_bloc into a HookWidget, friction quickly emerged. Because classic BLoC states are published asynchronously across Stream pipelines, consuming state or reacting to side-effects required either:

Nesting heavy widget wrappers (BlocBuilder, BlocListener, BlocSelector) inside the build() method of a HookWidget.
Depending on third-party, dedicated glue-code packages (such as flutter_hooks_bloc) that wrapped BLoC streams into custom hooks like useBloc, useBlocBuilder, and useBlocListener.

With BlocSignal, that paradigm changes completely.

💡 The Core Architectural Insight

Unlike classic BLoC, where state updates stream asynchronously through microtask event queues, BlocSignal builds on Rody Davis’s signals.dart primitives.

In BlocSignal:

bloc.state is natively a ReadonlySignal<StateType>.
State transitions propagate synchronously in the exact frame they are emitted.
Equal states are automatically de-duplicated using == equality.

Because bloc.state is already a native ReadonlySignal, BlocSignal does not need a custom flutter_hooks_bloc_signals adapter package!

Instead, any HookWidget can consume, derive, or react to BlocSignal state out-of-the-box using the official signals_hooks package.

🪝 Key Capabilities & Patterns

Let me walk you through how BlocSignal and signals_hooks simplify state management in HookWidget implementations.

1. Direct State Consumption (`useSignalValue` / `useWatch`)

In classic BLoC with Flutter Hooks, subscribing to a BLoC required a useBlocBuilder(bloc) hook or a nested BlocBuilder widget.

With BlocSignal + signals_hooks, bloc.state is simply a signal. You can read and subscribe to it using useSignalValue(bloc.state) or useWatch(bloc.state):

final count = useSignalValue(bloc.state);

Whenever bloc.emit() updates the state, useSignalValue registers a dependency on the hook element and triggers a synchronous rebuild.

2. Streamless Side Effects (`useSignalEffect`)

In classic BLoC, executing one-off side effects (such as showing a SnackBar, triggering navigation, or logging analytics) forced you to wrap your UI in a BlocListener or call useBlocListener.

Because BlocSignal updates synchronously, you can write inline reactive side effects using useSignalEffect:

useSignalEffect(() {
  // Reading `bloc.stateValue` (or `bloc.state.value`) inside the callback
  // automatically registers `bloc.state` as a reactive dependency!
  if (bloc.stateValue > 10) {
    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(content: Text('Threshold reached!')),
    );
  }
});

No widget tree nesting required. The effect callback executes synchronously upon transition and automatically unsubscribes when the HookWidget unmounts.

💡 Bonus Tip: BlocSignalBase provides the convenient .stateValue getter (which delegates directly to bloc.state.value). You can use bloc.stateValue inside useSignalEffect, useComputed, or event handlers like emit(stateValue + 1) for clean, concise state access!

3. Fine-Grained Derived Selectors (`useComputed`)

Filtering rebuilds in classic BLoC required setting up BlocSelector<MyBloc, MyState, SelectedType> or calling useBlocSelector.

With BlocSignal + signals_hooks, fine-grained selector logic is written cleanly using useComputed:

final isEven = useComputed(() => bloc.stateValue.isEven);

useComputed creates an inline derived signal. Because signals de-duplicate identical outputs, your widget will only rebuild when count.isEven toggles between true and false — avoiding unnecessary builds when count increments from 2 to 4.

4. Lifecycle Teardown & Scope Safety

In typical production applications, BLoCs are provided upstream in the widget tree using BlocSignalProvider. When consuming a provided BLoC inside a HookWidget, zero creation or teardown boilerplate is needed:

// Provided upstream via BlocSignalProvider — Provider handles lifetime & close() automatically!
final bloc = context.read<CounterBloc>();

Widget-Local BLoC Instances

If a HookWidget happens to own its own local BLoC, you can instantiate and dispose of it using standard Flutter Hooks primitives:

// Create once for the widget's lifetime & close when unmounted
final bloc = useMemoized(() => CounterBloc());
useEffect(() => bloc.close, [bloc]);

💡 Quick Tip: If your app uses many widget-local BLoCs, you can define a simple 3-line helper once in your codebase:
B useCreateBloc<B extends BlocSignalBase>(B Function() builder) {
  final bloc = useMemoized(builder);
  useEffect(() => bloc.close, [bloc]);
  return bloc;
}
This gives you single-line local instantiation (final bloc = useCreateBloc(() => CounterBloc());) without needing an extra third-party package!

💻 Side-by-Side Comparison

Let's compare classic flutter_hooks_bloc with modern BlocSignal + signals_hooks.

❌ Before: Legacy `flutter_hooks_bloc` Glue Code

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:flutter_hooks_bloc/flutter_hooks_bloc.dart';

class LegacyCounterView extends HookWidget {
  const LegacyCounterView({super.key});

  @override
  Widget build(BuildContext context) {
    // Requires specialized third-party useBloc hook
    final bloc = useBloc<CounterBloc, int>();

    // Requires specialized hook for state rebuilds
    final count = useBlocBuilder(bloc);

    // Requires specialized hook for side effects
    useBlocListener<CounterBloc, int>(bloc, (context, state) {
      if (state > 10) {
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('Count is high!')),
        );
      }
    });

    return Scaffold(
      body: Center(child: Text('Count: $count')),
      floatingActionButton: FloatingActionButton(
        onPressed: () => bloc.add(Increment()),
        child: const Icon(Icons.add),
      ),
    );
  }
}

✅ After: Modern `BlocSignal` + `signals_hooks`

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:signals_hooks/signals_hooks.dart';
import 'package:bloc_signals/bloc_signals.dart';

class ModernCounterView extends HookWidget {
  const ModernCounterView({super.key});

  @override
  Widget build(BuildContext context) {
    // 1. Memoize the BLoC for the widget's entire lifetime & teardown on unmount
    final bloc = useMemoized(() => CounterBloc());
    useEffect(() => bloc.close, [bloc]);

    // 2. Read & watch BLoC state directly as a signal
    final count = useSignalValue(bloc.state);

    // 2. Inline reactive side effects (no listener widget wrapper needed!)
    useSignalEffect(() {
      if (bloc.stateValue > 10) {
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('Count is high!')),
        );
      }
    });

    // 3. Inline fine-grained computed selector (no selector widget needed!)
    final isEven = useComputed(() => bloc.stateValue.isEven);

    return Scaffold(
      body: Center(
        child: Text('Count: $count (Even: ${isEven.value})'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => bloc.add(Increment()),
        child: const Icon(Icons.add),
      ),
    );
  }
}

📊 Architectural Mapping Table

Pattern / Goal	Legacy `flutter_hooks_bloc`	Modern `BlocSignal` + `signals_hooks`	Key Advantage
Accessing BLoC	`useBloc<B, S>()`	`context.read<MyBloc>()` or `useMemoized`	Standard provider read or hook; zero custom BLoC lifecycle package
State Rebuilds	`useBlocBuilder(bloc)`	`useSignalValue(bloc.state)`	Native signal subscription; works with any `ReadonlySignal<S>`
Side Effects	`useBlocListener(bloc, fn)`	`useSignalEffect(() => ...)`	Inlined reactive effect; zero widget tree wrappers
State Selection	`useBlocSelector(bloc, fn)`	`useComputed(() => ...)`	Functional signal derivation with automatic `==` equality filtering
Glue Packages	`flutter_hooks_bloc`	None (`signals_hooks` only)	Zero custom adapter packages required

🎯 Conclusion

By grounding the BLoC pattern on synchronous, reactive signals, BlocSignal harmonizes two of Flutter’s most powerful state management paradigms: the predictable event-driven architecture of BLoC and the clean, functional composition of Flutter Hooks.

You no longer need dedicated glue-code adapter packages or deep widget tree nesting to use BLoC inside HookWidgets. With signals_hooks, your BLoC states, computed selectors, and side effects fit naturally into standard hook workflows.

🔗 Explore More

📦 bloc_signals on pub.dev: pub.dev/packages/bloc_signals
🪝 signals_hooks on pub.dev: pub.dev/packages/signals_hooks
🐙 GitHub Repository: github.com/RandalSchwartz/BlocSignal

Material 3 Expressive for Flutter: Bringing Google's Latest Design Language to Flutter

Paa — Mon, 27 Jul 2026 16:10:15 +0000

Bring Google's Material 3 Expressive design language to Flutter today.

Google's Material 3 Expressive, part of the official Material Design 3 system, introduces a new generation of UI components that emphasize expressive motion, shape morphing, adaptive layouts, and richer user interactions.

The material_3_expressive package brings this design language to Flutter through a comprehensive implementation of Material 3 Expressive components, complete with theming, motion, and design tokens.

📦 Package: https://pub.dev/packages/material_3_expressive

💻 Source Code: https://github.com/paadevelopments/material_3_expressive

📖 Official Material 3 Components: https://m3.material.io/components

Highlights

✅ 44 expressive widgets

🎨 Adaptive theming

🌈 Dynamic color support

🌊 Spring-driven animations

🔷 Shape morphing

💙 Flutter-first APIs

✨ A Complete Material 3 Expressive Library

The package closely follows the component organization and design principles described in Google's official Material Design component catalog.

📖 https://m3.material.io/components

The package currently includes 44 widgets across 39 component modules, organized into the same categories as the official Material Design component catalog.

🎯 Actions

Buttons
Icon Buttons
Floating Action Buttons
Extended FABs
FAB Menus
Toggle Buttons
Segmented Buttons
Split Buttons
Button Groups

✅ Selection

Checkboxes
Radio Buttons
Switches
Chips
Dropdown Menus
Sliders
Date Pickers
Time Pickers

📦 Containment

Cards
Carousels
Lists
Expandable Lists
Dismissible Lists
Dialogs
Bottom Sheets
Side Sheets
Dividers

🧭 Navigation

App Bars
Search App Bars
Tabs
Navigation Bars
Navigation Rails
Navigation Drawers
Toolbars
Menus

💬 Feedback

Badges
Progress Indicators
Loading Indicators
Refresh Indicators
Tooltips
Snackbars
Text Fields
Search Components

🌊 Expressive Motion

🌊 Spring-driven animations
🔷 Shape morphing
💧 Liquid selection indicators
✨ Hover, focus and press state layers

🎨 Unified Design System

🎨 Color schemes
✍️ Typography
🌊 Motion
🔷 Shapes
📐 Spacing
🏔️ Elevation
🧩 Component themes

🚀 Getting Started

1. Install

dependencies:
  material_3_expressive: ^1.0.3

flutter pub add material_3_expressive

2. Import

import 'package:material_3_expressive/material_3_expressive.dart';

3. Use `M3EMaterialApp`

return M3EMaterialApp(
  data: M3EThemeData.light(
    seedColor: const Color(0xFF6750A4),
  ),
  autoTheming: true,
  dynamicColoring: true,
  home: const HomePage(),
);

💙 Flutter-first API

M3EButton(
  onPressed: () {},
  child: const Text('Continue'),
);

📱 Interactive Gallery

The repository includes a complete interactive gallery showcasing all 44 widgets.

🎉 Final Thoughts

Whether you're experimenting with Google's latest design language or building a production-ready application, the package provides a solid foundation for creating modern, expressive Flutter experiences.

📚 Learn More

Switching Tracks in BlocSignal: The Universal State Switchyard for BLoC, Riverpod, and Provider

Randal L. Schwartz — Mon, 27 Jul 2026 15:37:53 +0000

By Randal L. Schwartz, and a few million TPU cycles

Motto: "With the rigor of Bloc and the flex and speed of Signal"

Why You Don't Have to Tear Up Your Codebase to Enjoy the Speed of Synchronous Signals

If you have followed my talks, articles, or comments in the Flutter community over the years, you know I have been a strong advocate for Riverpod. Riverpod solved many of the fundamental global-state scoping issues inherent in classic InheritedWidget patterns, providing compile-safe dependency injection and clean state isolation.

However, as the Flutter ecosystem evolved toward Riverpod 3, I grew increasingly wary of the direction being pushed: a heavy reliance on mandatory code generation (@riverpod annotations, build_runner, macros). Code generation introduces build-step friction, bloats compile times, and makes debugging generated syntax opaque.

On the other side of the tracks sat BLoC. While I appreciated BLoC's structured, predictable event-to-state machine pattern (on<Event>), I was never a big fan of classic BLoC's reliance on underlying Dart Streams. Streams operate asynchronously via microtask queues—introducing subtle frame-rendering latency—and require extensive stream-transformer ceremony for simple state updates.

Then came Signals (specifically Rody Davis's signals package). Signals brought raw speed, zero microtask overhead, fine-grained composable reactivity, and pure Dart portability.

That realization birthed BlocSignal: combining BLoC's disciplined, enterprise event-state architecture with Signals' synchronous reactivity.

And more importantly, it solved the single biggest pain point in Flutter development: the migration trap.

🚂 The Core Metaphor: "Switching Tracks in BlocSignal"

In Flutter development, choosing a state management tool often feels like choosing a railroad company. If your team built an application on package:provider or flutter_bloc and wants to adopt Riverpod or Signals, traditional wisdom dictates a nightmare: tearing up all your existing tracks and rebuilding your rail lines from scratch.

BlocSignal rejects this all-or-nothing trap. Named after the classic railway block signal—the system that manages train traffic safely to prevent collisions—BlocSignal acts as a central railway switchyard.

  Classic BLoC Line (Streams) ─────────┐
                                       │
  Riverpod Express (Providers) ────────┼──► [ BlocSignal Central Switchyard ] ◄──► Pure Reactive Signals
                                       │
  Provider Local (Listenables) ────────┘

You do not need to abandon your existing rail network or halt traffic. Whether your feature runs on the Riverpod Express, BLoC Stream Line, or Flutter's native ChangeNotifier local track, you can switch tracks synchronously at the BlocSignal switchyard and keep your train moving smoothly!

⚡ The Synchronous Signal Core: Green Lights All the Way

In classic flutter_bloc, state updates flow through StreamController microtask queues:

// Classic BLoC: Asynchronous microtask queue scheduling
emit(newState); // State arrives on the next microtask tick

In BlocSignal, bloc.state is natively a ReadonlySignal<State>. State propagation is 100% synchronous:

// BlocSignal: Synchronous signal graph propagation
emit(newState); // Downstream computeds & UI elements update IN THE EXACT SAME FRAME

Because ReadonlySignal is a lightweight, primitive reactive node, external state objects (Stream, ProviderListenable, ValueListenable) can be adapted into a BlocSignal (or vice-versa) with zero-cost bridge wrappers.

Furthermore, all BlocSignal interop bridges support custom equality comparators (equals: (prev, next) => ...), preserving strict state de-duplication rules across track switches.

Let's walk through the three main rail lines.

🚆 Track 1: BLoC, Redux & Stream Interop (`package:bloc_signals`)

If you have legacy BLoCs, Redux stores, or RxDart observables, you can bridge them onto the BlocSignal switchyard without breaking existing stream subscribers.

Ingesting Streams & Redux

Use StreamBlocSignal to turn any Dart Stream into a BlocSignalBase container:

import 'package:bloc_signals/bloc_signals.dart';

// 1. Adapt a standard Dart Stream / RxDart Observable
final streamCubit = StreamBlocSignal<int>(
  stream: myLegacyStream,
  initialState: 0,
);

// 2. Adapt a Redux Store
final reduxCubit = StreamBlocSignal<AppState>(
  stream: reduxStore.onChange,
  initialState: reduxStore.state,
);

Exporting `BlocSignal` to Stream

Need to feed a legacy StreamBuilder or BlocBuilder? Expose any BlocSignal as a standard Dart stream:

final Stream<MyState> stream = myBlocSignal.toStream();

🚆 Track 2: Riverpod Interop (`package:bloc_signals_riverpod`)

For developers using Riverpod for dependency injection who want to avoid code generation and microtask delays, package:bloc_signals_riverpod provides zero-boilerplate bidirectional adapters.

Ingesting Riverpod Providers (With Automatic Teardown!)

Convert any Riverpod ProviderListenable into a BlocSignal:

import 'package:bloc_signals_riverpod/bloc_signals_riverpod.dart';

// Ingest a Riverpod provider into BlocSignal
// Automatically binds ref.onDispose(bloc.close) under the hood!
final userBloc = userProvider.toBlocSignal(ref);

💡 No Retain Count Leaks: Passing ref (or WidgetRef / ProviderContainer) automatically registers ref.onDispose teardown hooks. When the parent Riverpod container or widget unmounts, the underlying BlocSignal is closed automatically.

Exporting `BlocSignal` to Riverpod

Turn any BlocSignal into a standard Riverpod NotifierProvider:

final NotifierProvider<Notifier<CounterState>, CounterState> riverpodProvider = 
    myCounterBloc.toProvider();

Riverpod 3 `AsyncValue` ↔ Signals `AsyncState` Bridge

Riverpod 3 introduced sealed AsyncValue classes. bloc_signals_riverpod includes seamless conversions:

final AsyncState<UserData> signalsState = riverpodAsyncValue.toAsyncState();
final AsyncValue<UserData> riverpodValue = signalsAsyncState.toAsyncValue();

🚈 Track 3: Flutter `Listenable` & `package:provider` (`package:bloc_signals_flutter`)

Flutter's native ChangeNotifier, ValueNotifier, and package:provider remain heavily used across thousands of codebases.

Ingesting `Listenable` and `ValueNotifier`

Convert any Flutter Listenable directly into a BlocSignalBase:

import 'package:bloc_signals_flutter/bloc_signals_flutter.dart';

// ValueNotifier -> BlocSignal
final countCubit = myValueNotifier.toBlocSignal();

// ChangeNotifier -> BlocSignal
final authCubit = myChangeNotifier.toBlocSignal(
  readState: () => myChangeNotifier.currentUser,
);

Exporting `BlocSignal` to `ValueListenable`

Expose any BlocSignal as a standard Flutter ValueListenable<T>:

final ValueListenable<int> listenable = myBlocSignal.toValueListenable();

// Consume via package:provider's ValueListenableProvider
ValueListenableProvider<int>.value(
  value: listenable,
  child: Consumer<int>(
    builder: (context, count, _) => Text('Count: $count'),
  ),
);

🔄 Multi-Track Routing: Synchronizing Across Ecosystems

Because every adapter maps cleanly to BlocSignalBase, you can route state across multiple track lines in a single, synchronous pipeline!

Example: Provider ➔ `BlocSignal` ➔ Riverpod

Imagine a legacy ChangeNotifier form field that needs to be consumed by a new Riverpod feature:

// 1. Ingest Flutter ChangeNotifier into a BlocSignal Cubit
final formCubit = myChangeNotifier.toBlocSignal(
  readState: () => myChangeNotifier.formValue,
);

// 2. Export the Cubit directly as a Riverpod NotifierProvider
final riverpodFormContainer = formCubit.toProvider();

State changes in myChangeNotifier propagate synchronously through formCubit into Riverpod in the exact same frame, with zero frame lag or microtask queuing!

🤖 AI Agent Skills: Your Automated Signal Operator

One of the most exciting aspects of modern Dart and Flutter development is AI-assisted coding. However, generic AI assistants often generate outdated, deprecated, or incorrect state management patterns.

To solve this, every package in the BlocSignal ecosystem ships with dedicated AI Agent Skills (plugins/bloc-signals/skills/bloc-signals/).

plugins/bloc-signals/skills/bloc-signals/
├── SKILL.md                 # Master agent skill entrypoint
├── architecture.md          # Core synchronous signal graph invariants
├── event_handlers.md        # Concurrency transformers (droppable, sequential)
├── testing.md               # Declarative testing with bloc_signals_test
└── interoperability.md      # Ecosystem bridge matrix & migration recipes

When you use AI coding assistants equipped with these skills (such as Gemini, Antigravity, Claude, Cursor, or Context7), your AI agent acts like an expert signal operator:

Resolves accurate, up-to-date BlocSignal API contracts without hallucination.
Applies correct teardown rules (ref.onDispose, unawaited(super.onEvent(event))).
Generates declarative blocSignalTest suites with 100% line coverage.
Provides instant, step-by-step migration recipes from legacy BLoC or Riverpod codebases.

🎯 Summary & The Interoperability Matrix

State management should serve your project—not lock you into a rigid framework. With BlocSignal, you retain the architectural discipline of BLoC state machines, gain the raw speed of synchronous Signals, and bridge your existing Riverpod or Provider codebases effortlessly.

📋 Cheat-Sheet Interoperability Matrix

Source Paradigm	From Source ➔ `BlocSignal`	From `BlocSignal` ➔ Target	Target Package
BLoC / Stream	`StreamBlocSignal(stream)`	`blocSignal.toStream()`	`bloc_signals`
Redux	`StreamBlocSignal(store.onChange)`	`blocSignal.toStream()`	`bloc_signals`
Riverpod	`provider.toBlocSignal(ref)`	`blocSignal.toProvider()`	`bloc_signals_riverpod`
Provider (Listenable)	`listenable.toBlocSignal()`	`blocSignal.toValueListenable()`	`bloc_signals_flutter`
Riverpod Async	`asyncValue.toAsyncState()`	`asyncState.toAsyncValue()`	`bloc_signals_riverpod`

🚀 Get Started Today

Check out the official open-source packages and AI skills on GitHub:

📦 GitHub Repository: github.com/RandalSchwartz/BlocSignal
🛠️ Core Package: pub.dev/packages/bloc_signals
📱 Flutter UI Package: pub.dev/packages/bloc_signals_flutter
🌊 Riverpod Interop: pub.dev/packages/bloc_signals_riverpod
🧪 Testing Package: pub.dev/packages/bloc_signals_test
🤖 AI Agent Skill Bundle: plugins/bloc-signals/skills/bloc-signals

Stop tearing up your tracks. Step up to the switchyard, switch tracks with BlocSignal, and keep your Flutter trains running on time! 🚂

Publishing your Flutter Game in the Steam Deck!

Erick — Mon, 27 Jul 2026 13:37:28 +0000

Recently (July 20th, 2026) I've finally released my Flutter and Flame game on Steam! It is a milestone for me as this was not my first published game, but it was the first one on that platform.

If your game is targeting only Desktop windows, Flutter already got you covered out of the box, and not much additional effort is needed, flutter build windows gets you covered!

But if you want to make your game run on the Steam Deck, Valve's popular handheld gaming device, the path might not be that clear, and that is what I hope to cover in this article!

The Steam Deck

The Steam Deck is a handheld computer gaming device from Valve, the big company behind Steam. It runs a Linux operating system and has the premise to enable PC gaming on the go. Even though it has a Linux system, it can play a huge amount of Windows only games as well through the use of Proton, a compatibility tool also provided and maintained by Valve that allows Windows games to run on Linux.

Flutter on the Steam Deck

So, as you might have already guessed, there are two ways of running your flutter game on the Steam Deck: either by running a Windows build via Proton or running a Linux build natively on the device.

The windows build approach

Using this approach, there isn't much to it. A simple flutter app, without many native plugins will be able to run smoothly via Proton, as you add plugins with native dependencies, you might run into issues if Proton doesn't support that dependency, in those cases you can always try changing the dependency or change to the Linux native approach.

The Linux native approach

Running your Flutter game natively on Steam isn't as simple. If you make your linux build, take its files and put them on the Steam Deck and try to run the game via the Steam Launcher, it will most likely not work.

This happens because Steam will try to run your game via the Steam Linux Runtime (SLR will be used moving forward to refer to the Steam Linux Runtime)!

SLR is a containerized environment made by Valve to ensure that games run consistently across different Linux distributions and also isolated from the host system, which ensures safety for the users.
SLR also contains a set of fixed version system dependencies, which ensures that the game will run consistently across different distributions.

That characteristic though is what will break your Flutter app when running in a SLR, the container doesn't have, or not in the expected version, dependencies that your Flutter build expects to have, and that is why we need to “patch” (I will explain more what patching your app means below) our build in order for it to run correctly!

There (at least at the moment of the writing) 4 versions of the SLR: Scout, Soldier, SLR 3.0 (Sniper) and SLR 4.0. Scout and Soldier are deprecated and are usually only used for legacy titles, developers moving forward should use SLR 3.0 or SLR 4.0.

The approach I choose for my game and why

My initial idea was to publish only a Windows build of my game, and let Steam Deck players play via Proton. That would, in theory, make my life simpler, as I would only need to push one binary to Steam and I would not need to handle more than one pipeline.

Sadly, when I first tested the game on my Steam Deck I noticed that the gamepad controls were not working. Everything else was working flawlessly, including sound, data management, etc, but controls were not, and the Steam Deck being in fact a gaming console, that was a big deal.

Upon investigating, I discovered that the Windows implementation of the gamepad plugin (LINK) I use uses a native API (GameInput) that is not well supported on Proton, and that was the reason for it not working. From researching, I found out that one alternative would be to give a new implementation of the gamepad plugin using the XInput API, which is an older API, but it is well supported by Proton.

So I came down to two choices: Make a new implementation of the gamepad plugin using XInput, or moving to the native linux approach!

And well, I was not super excited about making a new implementation for an older API like XInput, so I decided, hey, let's do this the “right way” and make it a Linux native build for the Steam Deck.

Patching my game for the SLR

As mentioned before, we need to patch our Flutter linux build in order for it to work on the SLR due to system dependencies presence and versions.

I ended up choosing the SLR 3.0 because SLR 4.0 doesn't have the GTK lib, which is the graphical interface toolkit used by Flutter, so using that runtime version means one less system dependency I need to bundle/patch!

It is important to note that Valve recommends new games to use the latest version (SLR 4.0), but given the fact that we need GTK I took the leap to choose SLR 3 since it already bundles that dependency, so this is a trade off to consider!

This is how I did the patching on a high level:

The game is built in Docker, using a Debian 11 container, which matches SLR 3
Bundle and fix the RUNPATH of all libraries needed that are not included, were older, or had a SONAME mismatch in that version of Debian, most of them are related to the flutter_soloud plugin, which requires many libs like libFLAC.so, libvorbis.so, etc to run.

All that is executed from a bash script, which I will not go into details because that can get very extensive. I will nonetheless share the scripts verbatim here, which I am sure people could easily adapt to their projects if needed.

Here you can find a gist with all the scripts and explanatory README on how it works and how it can be adapted to your project:

https://gist.github.com/erickzanardo/8f92a73bbdcc4af14dba0c3d667e997c

Conclusion

This was quite the learning for me, I always dreamed of having a game of mine running in a real life console, and this was definitely a first step for me to fulfill that dream!

For my next game I might try experimenting more with the Windows Build+Proton approach, and write an XInput gamepad plugin. I guess it is always good to have alternatives to choose from!

Thanks for reading and I hope this was useful or at least entertaining! And before I close up, I would love to share with you my game! If you like relaxing and cozy puzzle games, check it out on Steam and maybe play it on your desktop, or who knows, in your own Steam Deck!

Check Mine Cart Operator on Steam:
https://store.steampowered.com/app/3997420/Mine_Cart_Operator/

그누보드와 Flutter 앱, JWT로 회원 연동하기: 레거시 시스템 통합 경험기

바람의평온 — Mon, 27 Jul 2026 08:29:37 +0000

그누보드와 Flutter 앱, JWT로 회원 연동하기: 레거시 시스템 통합 경험기

안녕하세요, 코딩아빠입니다. 이번 글은 제가 최근 직접 부딪히고 해결했던 개발 경험을 정리한 기록입니다. 레거시 PHP CMS인 그누보드 웹사이트의 회원 체계를 그대로 활용하면서 Flutter 앱에서 자체 로그인, 회원가입, 토큰 갱신 기능을 구현해야 했던 상황이었죠. 기존 시스템의 작동 방식을 깊이 이해하는 것이 얼마나 중요한지 다시 한번 깨달았고, 특히 include 순서나 전역 변수 사용 방식 같은 사소한 부분이 예상치 못한 큰 오류를 발생시킬 수 있다는 교훈을 얻었습니다. 이 경험을 통해 얻은 노하우를 공유해 드립니다.

이 글에서 짚는 것

레거시 그누보드 환경에서 PHP 기반 API를 구축하는 방법
JWT(JSON Web Token)를 활용한 앱 인증 시스템 구현 원리
그누보드 common.php 및 lib.php 로딩의 중요성과 올바른 적용법
기존 웹사이트 회원 데이터베이스를 앱과 연동하는 실제 과정

오래된 그누보드, 새로운 Flutter 앱과의 만남 준비

새로운 Flutter 앱을 개발하면서 기존에 운영하던 그누보드 웹사이트의 회원 체계를 그대로 사용해야 하는 상황에 놓였습니다. 별도의 소셜 로그인 연동 없이, 웹과 앱 사용자가 동일한 아이디와 비밀번호로 로그인하고 회원 정보를 공유하는 통합 시스템이 필요했죠. 이는 기존 회원의 불편을 최소화하고 데이터 일관성을 유지하기 위한 중요한 결정이었습니다. 가장 먼저 고민했던 부분은 바로 어떻게 기존 그누보드 회원 데이터베이스를 안전하고 효율적으로 앱과 연동할 것인가였습니다.

그누보드가 PHP 기반의 레거시 CMS라는 점은 분명 도전 과제였습니다. 자체 라이브러리 로딩 방식과 전역 변수 의존성이 높다는 특성 때문에, 신규 API 개발 시에는 기존 그누보드 환경을 해치지 않으면서도 필요한 기능을 추가해야 했으니까요. 특히 기존 웹사이트의 로그인 로직을 직접 복제하거나 수정하는 대신, 앱만을 위한 별도의 인증 시스템을 구축하여 보안성과 확장성을 확보하는 방향으로 가닥을 잡았습니다. 여기에는 JWT(JSON Web Token)를 활용하는 것이 가장 적합하다고 판단했지요.

JWT는 클라이언트와 서버 간의 정보 교환 시 사용되는 안전한 방법으로, 서버가 상태를 유지할 필요가 없어 확장성이 좋다는 장점이 있습니다. 앱에서 로그인 요청을 보내면, 서버는 회원 정보를 확인하고 유효한 경우 JWT를 발급하여 앱에 넘겨주는 방식입니다. 이후 앱은 이 토큰을 매 요청마다 헤더에 포함하여 보내고, 서버는 토큰의 유효성을 검증하여 인증된 사용자임을 확인하는 것이죠. 이러한 접근 방식은 레거시 시스템의 복잡성을 최소화하면서도 현대적인 앱 인증 시스템을 구축할 수 있는 좋은 대안이었습니다.

그누보드 환경 위에서 API 엔드포인트 설계하기

JWT 기반 인증 시스템을 구현하기 위해 서버에 몇 가지 새로운 API 엔드포인트를 구축해야 했습니다. 구체적으로는 로그인(api/app/login.php), 회원가입(api/app/register.php), 그리고 토큰 갱신(api/app/refresh.php) 기능을 담당하는 PHP 파일을 새로 만들었죠. 이 파일들은 그누보드 설치 경로 내에 별도의 디렉터리를 만들어 관리함으로써 기존 그누보드 코드와의 충돌을 피하려고 했습니다.

각 엔드포인트는 그누보드의 g5_member 테이블을 직접 조회하거나 업데이트하는 방식으로 작동합니다. 예를 들어, 로그인 요청이 오면 전달받은 아이디와 비밀번호를 g5_member 테이블의 데이터와 비교하여 일치 여부를 확인하는 식입니다. 여기서 가장 중요했던 부분은 바로 '그누보드 환경을 올바르게 초기화하는 것'이었습니다. 그누보드 핵심 라이브러리들을 제대로 로드하지 않으면 데이터베이스 연결이나 기타 전역 변수들이 초기화되지 않아 예상치 못한 오류를 뱉어내더군요.

이를 해결하기 위해 각 API 파일의 최상단에 define('_GNUBOARD_', true);를 선언하고, 이어서 include_once('../../common.php');를 호출하는 순서를 엄격하게 지켰습니다. 이 common.php 파일은 그누보드의 거의 모든 환경 설정과 핵심 함수들을 로드하는 역할을 하죠. 이 한 줄이 빠지거나 순서가 틀리면, 그누보드 환경이 제대로 잡히지 않아 데이터베이스 연결조차 되지 않는 문제가 발생했습니다. 제가 처음 겪었던 시행착오 중 하나였습니다.

<?php
define('_GNUBOARD_', true);
include_once('../../common.php'); // 그누보드 환경 초기화

// JWT 라이브러리 로드 및 API 로직 구현

이렇게 common.php를 로드한 후에는 비로소 그누보드의 데이터베이스 연결 객체($g5['db'])나 다른 유틸리티 함수들을 사용할 수 있게 됩니다. 이 부분이 레거시 시스템 위에서 새로운 기능을 개발할 때 가장 먼저 해결해야 할 퍼즐 조각이었습니다.

JWT 발급과 갱신, 그리고 그누보드 회원 연동의 핵심

그누보드 환경이 제대로 초기화되었다면, 이제 실제 로그인 로직을 구현하고 JWT를 발급하는 단계로 넘어갑니다. 앱에서 아이디와 비밀번호를 POST 요청으로 보내면, 서버에서는 이를 받아 g5_member 테이블에서 해당 회원 정보를 조회합니다. 비밀번호는 그누보드의 해싱 방식에 맞춰 검증해야 하므로, 기존 그누보드 로그인 로직에서 사용되던 함수를 활용하는 것이 안전하고 정확합니다.

인증이 성공하면, 해당 회원의 고유 식별자(예: mb_id)를 포함하는 JWT 페이로드를 생성합니다. 이 페이로드에는 토큰의 만료 시간(exp)과 같은 정보도 함께 담습니다. 만료 시간은 앱의 보안 정책과 사용자 편의성을 고려하여 적절히 설정하는 것이 중요합니다. 너무 짧으면 사용자가 자주 로그인해야 해서 불편하고, 너무 길면 보안에 취약해질 수 있으니까요. 발급된 JWT는 암호화되어 서명되며, 이 토큰을 HTTP 응답으로 앱에 전달합니다.

// JWT 발급 예시 (실제 라이브러리 코드는 복잡함)
$payload = ['user_id' => $member['mb_id'], 'exp' => time() + 3600];
$jwt = 'YOUR_GENERATED_JWT_TOKEN';

앱은 이 JWT를 안전하게 저장하고, 이후 보호된 API를 호출할 때마다 HTTP Authorization 헤더에 Bearer {JWT} 형태로 포함하여 보냅니다. 또한, 장기적인 사용자 경험을 위해 리프레시 토큰(Refresh Token) 메커니즘도 함께 구현했습니다. 액세스 토큰이 만료되면, 앱은 저장된 리프레시 토큰을 이용해 새로운 액세스 토큰을 요청하는 방식으로, 사용자가 다시 로그인할 필요 없이 세션을 연장할 수 있도록 했습니다. 이 과정 역시 api/app/refresh.php 엔드포인트를 통해 처리됩니다.

보호된 API 접근과 토큰 유효성 검증 과정

JWT를 발급하고 나면, 앱은 이 토큰을 사용하여 회원 전용 기능과 같은 보호된 API에 접근하게 됩니다. 서버는 이러한 보호된 API 요청이 들어올 때마다 클라이언트로부터 전달받은 JWT의 유효성을 검증해야 합니다. 이 검증 과정은 보안에 있어 매우 중요한 단계이며, 토큰이 위조되지 않았는지, 만료되지는 않았는지 등을 확인합니다.

일반적으로 JWT는 HTTP Authorization 헤더에 Bearer 스키마와 함께 전달됩니다. 서버 측 API에서는 먼저 이 헤더에서 토큰 문자열을 추출하는 작업이 필요합니다. $_SERVER['HTTP_AUTHORIZATION'] 변수에서 값을 읽어와 Bearer 접두사를 제거하면 순수한 JWT를 얻을 수 있습니다. 만약 토큰이 없거나 형식이 올바르지 않으면 즉시 인증 실패를 처리해야 합니다.

// JWT 검증 예시 (실제 라이브러리 코드는 복잡함)
$token = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
if (strpos($token, 'Bearer ') === 0) {
    $token = substr($token, 7);
}
// if (isValidJwt($token)) { ... } else { unauthorized }

추출된 토큰은 JWT 라이브러리를 사용하여 서명 검증, 만료 시간 확인, 페이로드 유효성 검사 등의 과정을 거칩니다. 토큰의 서명이 유효하지 않거나 이미 만료된 토큰이라면, 해당 요청은 인증되지 않은 것으로 간주하여 401 Unauthorized 응답을 반환합니다. 이 과정을 통해 오직 유효한 토큰을 가진 사용자만이 보호된 리소스에 접근할 수 있도록 보장할 수 있었지요. 이처럼 서버에서 철저하게 토큰을 검증하는 것이 시스템 전체의 보안을 유지하는 핵심이었습니다.

실제로 작동하는 시스템을 위한 꼼꼼한 확인

모든 API 엔드포인트 개발과 JWT 로직 구현을 마친 후, 실제로 시스템이 제대로 작동하는지 검증하는 과정이 필요했습니다. 단순히 코드가 에러 없이 실행되는 것을 넘어, Flutter 앱에서 실제 사용자 흐름에 맞춰 로그인, 회원가입, 토큰 갱신 기능을 사용했을 때 예상대로 동작하는지 확인하는 것이 중요했습니다. 저는 단계별로 꼼꼼하게 테스트 시나리오를 만들고 하나씩 점검해 나갔습니다.

먼저, 새로운 계정으로 회원가입을 시도하여 그누보드 g5_member 테이블에 새로운 레코드가 성공적으로 추가되는지 확인했습니다. 다음으로, 방금 가입한 계정으로 로그인 기능을 테스트하여 유효한 JWT가 발급되고 앱으로 전달되는지 응답 값을 면밀히 살펴보았죠. 발급된 JWT는 앱의 로컬 스토리지에 잘 저장되는지, 그리고 만료 시점에 맞춰 토큰 갱신 API가 호출되어 새로운 토큰을 받아오는지도 확인했습니다.

가장 중요한 검증 단계는 바로 발급된 JWT를 사용하여 다른 보호된 API(예: 회원 정보 조회 API)에 접근했을 때였습니다. 앱이 토큰을 HTTP Authorization 헤더에 포함하여 요청을 보냈을 때, 서버에서 이 토큰의 유효성을 성공적으로 검증하고 올바른 데이터를 반환하는지 확인했습니다. 만료된 토큰으로 접근을 시도했을 때는 401 Unauthorized 응답이 정확히 오는지도 확인하여, 인증 시스템이 설계대로 보안적으로도 작동하는지 검증할 수 있었습니다. 이 모든 과정을 거치면서 레거시 시스템과의 연동이 성공적으로 마무리되었음을 확인할 수 있었네요.

정리하며

오래된 그누보드와 현대적인 Flutter 앱을 JWT 기반으로 연동하는 작업은 분명 쉽지 않은 과정이었습니다. 특히 레거시 시스템의 특성을 이해하고 그 위에서 새로운 기능을 안정적으로 구현하는 것이 관건이었죠. 이번 경험을 통해 저는 다시 한번 '기존 시스템의 작동 원리와 의존성을 깊이 파악하는 것이 중요하다'는 교훈을 얻었습니다. 모든 개발은 새로운 것을 만드는 즐거움도 있지만, 기존의 것을 존중하고 이해하는 데서 더 큰 가치를 찾을 때도 있다는 점을 잊지 말아야겠습니다. 같은 문제를 겪는 분들께 도움이 되었기를 바랍니다.

How I Built Flutter On-Device AI Clipboard Security: Zero Cloud

Umair Bilal — Mon, 27 Jul 2026 06:59:50 +0000

This article was originally published on BuildZn.

Everyone talks about moving AI to the cloud, but for anything remotely privacy-sensitive, that's just not an option. Especially when you're dealing with real-time mobile clipboard threat detection. Figured this out the hard way trying to build a robust flutter on-device ai clipboard security system. The docs were thin on getting a TFLite model to play nice with Flutter's asset system, and the interpreter kept throwing cryptic errors.

Why Your Mobile Clipboard Needs On-Device AI Security

Look, the clipboard is a wild west. Users copy everything from crypto addresses to passwords to sensitive personal info. Then some janky app or even malware swaps out their crypto wallet address right before they paste. Seen it happen. Generic mobile app data protection advice usually just says "don't let apps read the clipboard." That's not proactive; it's just blocking. We need to actively detect threats.

This is where flutter on-device ai clipboard security becomes critical. Why send sensitive user data off to a server for analysis? It's a privacy nightmare, adds latency, and costs you money. No thanks. On-device AI keeps everything local.

Here’s why it’s the only way to go for this kind of critical mobile app data protection:

Privacy First: Absolutely zero user clipboard data ever leaves the device. This is non-negotiable for sensitive info.
Instant Feedback: Detection happens in milliseconds. No network roundtrip. Users get an immediate warning, which is crucial for preventing real-time fraud like crypto address swapping.
Cost-Effective: No server infrastructure costs for inference. Once the model is on the device, it's free to run.
Offline Capability: Works perfectly even if the user is in airplane mode or has a spotty connection. Security shouldn't depend on Wi-Fi.

This isn't just about some theoretical risk. I've built systems like FarahGPT that manage real money (gold trading) and NexusOS for AI agent governance. Trust and security are paramount. Relying on cloud for something as ephemeral and critical as clipboard content for on-device ml for mobile security is a non-starter.

Building Real-Time Flutter Local AI Privacy for Clipboard Scans

So, how do we actually pull this off? The core idea is simple: constantly check the clipboard, feed its content into a small, specialized TensorFlow Lite model, and alert the user if something malicious is detected. All without touching the cloud. This ensures flutter local ai privacy is maintained from start to finish.

The architecture for flutter on-device ai clipboard security looks something like this:

Clipboard Listener: A background process (or foreground service, depending on platform requirements) that periodically checks the device clipboard for new content.
TFLite Model: A tiny, highly optimized text classification model trained to identify patterns like cryptocurrency wallet addresses, credit card numbers, or known phishing URLs. This is the on-device ml for mobile security component.
Inference Engine: The Flutter app uses a package like tflite_flutter to load and run the TFLite model directly on the device CPU (or GPU, if you want to get fancy, but usually overkill for text).
Alert System: If the model flags content as potentially malicious, a UI alert (snackbar, dialog) immediately warns the user.

This approach gives you a powerful layer of flutter app data protection that traditional mobile security practices often miss or offload to unreliable cloud services. Honestly, I don't get why this isn't the default for sensitive apps.

Step-by-Step Implementation: Flutter On-Device AI Clipboard Security

Let’s get into the code. This assumes you've got a pre-trained and converted TensorFlow Lite model (.tflite file). For this example, let's say it's a simple text classifier that outputs a probability score for "malicious text."

Step 1: Add Dependencies & Model

First, you need the tflite_flutter package to interact with your TFLite model. And path_provider is often handy for temporary storage, though we’re just reading from assets here.

Add these to your pubspec.yaml:

dependencies:
  flutter:
    sdk: flutter
  tflite_flutter: ^0.10.0 # Make sure you're on a recent version
  path_provider: ^2.1.1

Next, place your .tflite model file inside your Flutter project's assets folder. For instance, create assets/models/clipboard_detector.tflite. Then update pubspec.yaml to include this asset:

flutter:
  uses-material-design: true
  assets:
    - assets/models/clipboard_detector.tflite

Step 2: Load TFLite Model

Loading the model is straightforward. You'll want to do this once, typically when your app starts or when the service initializing clipboard monitoring.

import 'package:flutter/services.dart' show rootBundle;
import 'package:tflite_flutter/tflite_flutter.dart';

class ClipboardThreatDetector {
  Interpreter? _interpreter;
  static const String _modelPath = 'assets/models/clipboard_detector.tflite';

  Future<void> loadModel() async {
    try {
      _interpreter = await Interpreter.fromAsset(_modelPath);
      print('TFLite model loaded successfully: $_modelPath');
    } catch (e) {
      print('Failed to load TFLite model: $e');
      _interpreter = null; // Ensure interpreter is null on failure
    }
  }

  void close() {
    _interpreter?.close();
    _interpreter = null;
  }

  // Placeholder for actual model inference
  // This will vary based on your model's input/output types
  Future<double> predict(String text) async {
    if (_interpreter == null) {
      print('Interpreter not loaded. Cannot predict.');
      return 0.0;
    }

    // Preprocessing: Convert text to a suitable numerical input format
    // This is highly dependent on how your model was trained.
    // For a text classification model, you might need to tokenize,
    // convert to sequence of integers, and pad.
    // For simplicity, let's assume a dummy input for now.
    // In a real scenario, this would involve a TextVectorization layer logic.

    // Dummy input for demonstration (e.g., a fixed-size float array)
    // Replace with actual preprocessed input from your text
    List<List<double>> input = [List.filled(128, 0.0)]; // Example: 128-dim embedding
    // For a real text model, you'd map input text to a fixed-length integer sequence
    // or embedding vector. This is the trickiest part of on-device ML.

    // Run inference
    var output = List.filled(1 * 1, 0).reshape([1, 1]); // Example: single output probability

    // In a real setup, your pre-processing would convert `text` into `input`
    // and `output` would be sized according to your model's output layer.
    // Example for a simple text classification model:
    // 1. Tokenize `text` -> sequence of integer IDs.
    // 2. Pad/truncate sequence to a fixed length (e.g., 128).
    // 3. Create a `TensorBuffer` from this integer list.
    // 4. Run `_interpreter.run(inputTensor, outputTensor)`.

    // For now, let's just return a dummy value.
    // You'd feed `text` into a tokenizer and then to the model.
    // e.g., if "bitcoin" is in text, return high probability.
    if (text.toLowerCase().contains('bitcoin') || text.toLowerCase().contains('ethereum')) {
      return 0.95; // High confidence for crypto-like text
    }
    return 0.05; // Low confidence
  }
}

Step 3: Monitor Clipboard

This is where the real-time action happens. We'll use Timer.periodic to poll the clipboard content. Flutter doesn't have a native Clipboard.onChanged stream across all platforms (yet), so polling is the most reliable cross-platform approach for mobile clipboard threat detection.

import 'dart:async';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'package:your_app_name/clipboard_detector.dart'; // Your detector class

class ClipboardMonitorService {
  Timer? _timer;
  String? _lastClipboardContent;
  final ClipboardThreatDetector _detector = ClipboardThreatDetector();
  final Function(String, double) _onThreatDetected; // Callback for UI

  ClipboardMonitorService(this._onThreatDetected);

  Future<void> startMonitoring() async {
    await _detector.loadModel(); // Load model once
    _timer = Timer.periodic(const Duration(seconds: 2), (timer) async {
      final clipboardData = await Clipboard.getData(Clipboard.kTextPlain);
      final currentContent = clipboardData?.text;

      if (currentContent != null && currentContent.isNotEmpty && currentContent != _lastClipboardContent) {
        _lastClipboardContent = currentContent;
        print('Clipboard content changed: $currentContent');

        // Run on-device AI inference
        final threatScore = await _detector.predict(currentContent);

        // Define a threshold for "threat"
        const double threatThreshold = 0.8;
        if (threatScore >= threatThreshold) {
          _onThreatDetected(currentContent, threatScore);
        }
      }
    });
  }

  void stopMonitoring() {
    _timer?.cancel();
    _detector.close();
    print('Clipboard monitoring stopped.');
  }
}

Step 4: Integrate into your Flutter App & User Alert

Finally, you need to integrate this service into your app's lifecycle and display alerts. A ScaffoldMessenger or a custom overlay works well for immediate feedback.

import 'package:flutter/material.dart';
import 'package:your_app_name/clipboard_monitor_service.dart';

class HomeScreen extends StatefulWidget {
  const HomeScreen({super.key});

  @override
  State<HomeScreen> createState() => _HomeScreenState();
}

class _HomeScreenState extends State<HomeScreen> with WidgetsBindingObserver {
  late ClipboardMonitorService _clipboardMonitorService;

  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
    _clipboardMonitorService = ClipboardMonitorService(_showThreatAlert);
    _clipboardMonitorService.startMonitoring();
  }

  @override
  void dispose() {
    WidgetsBinding.instance.removeObserver(this);
    _clipboardMonitorService.stopMonitoring();
    super.dispose();
  }

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.resumed) {
      // App came to foreground, restart monitoring if needed
      _clipboardMonitorService.startMonitoring();
    } else if (state == AppLifecycleState.inactive || state == AppLifecycleState.paused) {
      // App went to background, stop monitoring to save resources
      _clipboardMonitorService.stopMonitoring();
    }
  }

  void _showThreatAlert(String content, double score) {
    ScaffoldMessenger.of(context).showSnackBar(
      SnackBar(
        content: Text(
          '🚨 Clipboard Threat Detected! Potential malicious pattern: "$content" (Score: ${score.toStringAsFixed(2)})',
          style: const TextStyle(color: Colors.white),
        ),
        backgroundColor: Colors.redAccent,
        duration: const Duration(seconds: 5),
        action: SnackBarAction(
          label: 'Dismiss',
          onPressed: () {
            ScaffoldMessenger.of(context).hideCurrentSnackBar();
          },
        ),
      ),
    );
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Secure Clipboard Demo'),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              'Your clipboard is being monitored for threats.',
              style: TextStyle(fontSize: 18),
              textAlign: TextAlign.center,
            ),
            const SizedBox(height: 20),
            ElevatedButton(
              onPressed: () {
                Clipboard.setData(const ClipboardData(text: '1A1zP1eW5PtWzTzXvQvYdJtVvXvYdJtVvXvYdJt')); // Example Bitcoin address
              },
              child: const Text('Copy Bitcoin Address'),
            ),
            ElevatedButton(
              onPressed: () {
                Clipboard.setData(const ClipboardData(text: 'Hello, this is safe text.'));
              },
              child: const Text('Copy Safe Text'),
            ),
          ],
        ),
      ),
    );
  }
}

This setup provides a robust foundation for flutter on-device ai clipboard security with clear flutter local ai privacy benefits.

What I Got Wrong First

Getting the TFLite model to load and run correctly in Flutter was a pain. I repeatedly hit this specific error when trying to initialize the interpreter:

InterpreterException: Internal: Failed to create interpreter: Didn't find op for builtin code 'ADD' version '1'.

This was on tflite_flutter: ^0.9.0. I was pulling my hair out. I'd export a model from TensorFlow 2.x, convert it to TFLite, and it'd work fine on Python, but Flutter kept choking.

Turns out: The tflite_flutter package version 0.9.0 (and earlier versions for that matter) didn't fully support all TensorFlow ops that might be present in a model exported from a recent TensorFlow version, especially if you're using layers that introduce newer ops. The ADD op, while fundamental, can have different versions or implementations depending on the TensorFlow/TFLite runtime.

My fix wasn't immediately obvious. I tried retraining with simpler layers, fiddling with the TFLite converter flags like converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.SELECT_TF_OPS], but nothing worked consistently.

The actual fix? Upgrading tflite_flutter to version 0.10.0 (or later) directly. That specific version brought significant updates to the underlying TFLite runtime, expanding its operator support. Suddenly, the same .tflite model, converted with the same TensorFlow 2.x, loaded without a hitch. It felt like a magic bullet after hours of debugging. So, always check your tflite_flutter version and ensure it's up-to-date to avoid cryptic InterpreterException issues related to unsupported ops. This is a crucial on-device ml for mobile security detail that can trip you up.

Optimizing On-Device ML for Mobile Security

Even with a working model, you still need to make sure it's efficient for flutter local ai privacy and battery life.

Model Quantization: This is huge. Convert your TFLite model to int8 quantization. This drastically reduces model size and inference time, making it much more suitable for on-device ml for mobile security. You can do this during the TensorFlow Lite conversion process (e.g., converter.optimizations = [tf.lite.Optimize.DEFAULT], converter.representative_dataset = representative_data_gen).
Run Inference on an Isolate: While my example runs inference directly, for larger models or more frequent checks, offloading model inference to a separate Isolate prevents UI jank. compute function in Flutter is your friend here.
Intelligent Polling: A 2-second interval might be fine, but if your app is highly sensitive and needs faster checks, consider dynamic intervals (e.g., faster when the app is active, slower when in the background). However, remember battery life.
Platform-Specific Background Tasks: For true background monitoring (when the app is not in the foreground), you'll need platform-specific solutions (WorkManager on Android, background tasks on iOS). This gets more complex and requires careful permission handling, but it's essential for persistent flutter app data protection.

FAQs

How accurate is on-device clipboard threat detection without cloud?

Accuracy is entirely dependent on your trained TFLite model and its dataset. A well-trained model, focusing on specific malicious patterns like crypto addresses or phishing URLs, can achieve very high accuracy on-device. The lack of cloud interaction doesn't inherently reduce accuracy; it just means your model has to be smaller and more specialized.

Does continuous clipboard monitoring drain battery in Flutter apps?

Yes, continuous polling (like with Timer.periodic) can consume battery. The impact depends on the polling interval and the complexity of your TFLite model's inference. Using a longer interval (e.g., 5-10 seconds) for less critical apps, and ensuring your model is heavily quantized, can mitigate battery drain. For true background monitoring, consider platform-specific background execution APIs.

Can this flutter local ai privacy solution be bypassed?

Any security measure can potentially be bypassed given enough effort. This solution primarily targets common clipboard hijacking attempts and helps regular users avoid scams. A highly sophisticated attacker might find ways around it, perhaps by using custom input methods that don't touch the system clipboard or by obfuscating malicious patterns in ways your model isn't trained for. It's a layer of defense, not a silver bullet.

Building solid flutter on-device ai clipboard security isn't rocket science, but it takes attention to detail, especially with the TFLite pipeline. Forget the cloud for privacy-sensitive features. Keep the AI local, keep user data safe. This isn't just about good engineering; it's about building trust with your users. If you're tackling similar challenges or want to implement advanced on-device ml for mobile security in your Flutter apps, hit me up. Let's build something secure. Book a quick chat at buildzn.com.

Why Indian Enterprises Are Choosing Flutter for App Development in 2026

Synfinity Dynamics Pvt Ltd — Mon, 27 Jul 2026 05:46:46 +0000

A few years ago, "Flutter" was mostly a startup word. It was the framework you picked when you had six weeks, one developer, and a demo day looming. Enterprises the banks, the logistics companies, the insurance giants stayed on native iOS and Android teams, because that's what "serious" software looked like.

That's not the conversation anymore. Walk into any mid-to-large Indian tech org's architecture review this year and there's a decent chance Flutter is already on the table not as an experiment, but as the default answer for a new customer-facing app. The interesting part isn't that this happened. It's why it happened now, in 2026 specifically, and not two years ago when Flutter was already mature enough on paper.

This piece is an attempt to actually answer that, instead of just repeating "cross-platform saves time and money" one more time.

The obvious business case (and why it was never enough on its own)

The standard pitch for Flutter has always been the same three points:

One codebase for iOS, Android, and increasingly web and desktop
Faster time-to-market, since you're not running two parallel native teams
Lower long-term maintenance cost, since bug fixes and features ship once, not twice

All true. All also true in 2022, 2023, and 2024 years when plenty of enterprises still passed on Flutter. If the cost argument alone was sufficient, adoption would have looked very different much earlier. Something else had to shift for risk-averse enterprise engineering leadership to actually greenlight it. That something is mostly technical, and it's worth spending real time on, because it's the part most "why enterprises choose X" posts skip entirely.

What actually changed under the hood

Impeller stopped being an experiment

For a long time, the biggest knock against Flutter in serious production apps was jank visible stutter during animations or scroll, especially the first time a shader compiled on iOS. It wasn't a dealbreaker for a shopping list app. It was a dealbreaker for a banking app where a stuttering balance screen makes users nervous about your competence, not just your polish.

Impeller, Flutter's newer rendering engine, was built specifically to solve this by precompiling shaders ahead of time instead of doing it at runtime. It's been maturing steadily, and by the current generation of Flutter releases it's default and dependable enough that "does it jank on iOS" has mostly dropped off the list of reasons to avoid Flutter for something performance-sensitive. That single change quietly removed one of the strongest technical objections enterprise architects used to raise in review meetings.

Dart got easier to write and read

Dart 3.10 introduced small but real quality-of-life syntax improvements dot-shorthand notation being one example, letting you write .start instead of the fully qualified MainAxisAlignment.start in context where the type is inferable. It sounds trivial until you're the tech lead reviewing a 40-file pull request from a five-person team and every reduction in boilerplate is a reduction in review fatigue and onboarding time for new hires. Enterprises don't adopt languages for elegance. They adopt them because elegance compounds into lower ramp-up cost for new engineers, and that's a line item CFOs actually understand.

Flutter for web stopped being a toy

This is probably the most underrated shift. Flutter's web support used to be the "sure, it technically renders in a browser" feature fine for a portfolio site, not something you'd put in front of enterprise SEO or accessibility requirements. That's changed. Browser rendering has improved, debugging got more configuration-driven instead of guess-and-check, and hot reload now works consistently across multiple browsers during development.

The practical result: Indian firms building internal enterprise dashboards the unglamorous but massive category of software that runs operations, inventory, HR, and finance are increasingly building them once in Flutter and shipping to web, desktop, and mobile from the same codebase. This is a bigger deal than another consumer app framework choice, because internal tooling is where enterprises bleed the most money on duplicated engineering effort.

AI features got boring to add in a good way

Every enterprise roadmap in 2026 has an AI line item somewhere, whether it's a recommendation engine, a support chatbot, or some kind of on-device inference. Flutter's tooling around ML Kit and generative AI integration has matured to the point where adding these features doesn't require spinning up a separate native team per platform. You wire it into your existing Flutter app, once. For an enterprise trying to check the "we have AI" box without doubling their mobile headcount, that's a meaningfully lower barrier.

Why India specifically, not just "Flutter globally"

Everything above explains why Flutter got more attractive as a framework. It doesn't fully explain why India, specifically, has become the center of gravity for this shift. A few country-specific factors matter here:

Talent density. India has one of the largest concentrations of Dart and Flutter developers anywhere, backed by a broader base of engineers already fluent in UI/UX and API integration work. When a framework choice is also a hiring choice, having a deep local bench matters more than raw framework capability.

Cost structure. Flutter development in India remains meaningfully cheaper than equivalent native development in most Western markets, without a corresponding drop in output quality for most enterprise use cases. That arbitrage is exactly what makes it attractive not just to Indian enterprises building for domestic markets, but to global companies outsourcing Flutter work to Indian teams.

Time zone overlap for global clients. For enterprises serving international customers or working with distributed teams, the time zone position enables closer-to-continuous development cycles a real, if underrated, productivity factor.

Architectural maturity, not just adoption. It's not just that more Indian firms are using Flutter it's how they're using it now. There's a visible shift toward modular, feature-based architecture instead of monolithic codebases, letting teams build and test independent chunks of an app in parallel. That's an enterprise-scale engineering practice, not a startup one, and it's a sign Flutter usage in India has moved past MVP territory into genuine platform investment. Sectors like banking, ERP, and retail are the ones leaning into this hardest, largely because those are exactly the domains where a UI-heavy, native-feeling experience matters and a JavaScript bridge becomes a real performance tax.

Flutter vs. the alternatives, briefly

No framework choice happens in a vacuum, so it's worth being specific about where Flutter wins and where it genuinely doesn't.

Where Flutter has a real edge: UI-heavy applications with complex custom interfaces, animations, or branding requirements. Because Flutter renders its own UI directly rather than bridging to native components through JavaScript, it avoids a category of performance overhead that frameworks like React Native still carry.

Where the edge is smaller or reversed: teams with an existing, large JavaScript codebase or deep investment in the React ecosystem. React Native can pull in existing JS libraries and web talent more directly, and for organizations that have already sunk years into JavaScript tooling, that continuity sometimes outweighs Flutter's rendering advantages.

Where native still wins outright: apps that are almost entirely built around a single platform's newest OS-level APIs, or where the last 5% of platform-specific polish is the actual product (certain AR/VR-heavy apps, deep hardware integrations). Flutter has narrowed this gap significantly, but it hasn't closed it completely, and it's dishonest to pretend otherwise.

The trade-offs nobody puts in the marketing deck

This is the part most "why enterprises are choosing Flutter" posts skip, because they're written by agencies trying to sell Flutter development services. It's worth being honest about the friction, because pretending it doesn't exist is exactly what makes those posts easy to ignore.

Package maturity for niche integrations. For mainstream needs payments, maps, push notifications the Flutter package ecosystem is genuinely solid. For niche enterprise integrations (a specific legacy SDK, an obscure hardware peripheral, a regional payment gateway with no maintained plugin), you can still hit gaps that require writing platform-specific bridge code yourself. That's real engineering time enterprises need to budget for, not assume away.
Learning curve for native teams. Developers coming from purely native iOS/Android backgrounds have a real ramp-up period with Dart's reactive widget model. It's not steep, but it's not zero, and enterprises retraining existing teams should plan for it explicitly rather than treating the transition as instant.
App size and binary bloat. Flutter apps have historically shipped larger binaries than fully native equivalents, since the framework bundles its own rendering engine. It's improved, but it's still a consideration for markets or use cases sensitive to app size which, in a country with a large base of budget Android devices and limited storage, is not a minor footnote for Indian consumer-facing apps specifically.
Hiring depth beyond the basics. There's no shortage of Flutter developers in India at the "build a screen, wire up an API" level. Deep architectural expertise the kind needed to design a scalable modular codebase for a multi-year enterprise product is a smaller, more competitive pool, and enterprises should expect to pay a premium for it rather than assume it's as commoditized as junior-level Flutter work.

Real-World Examples from India

Flutter adoption is not limited to theoretical enterprise benefits. Several Indian products have used it in real production environments.

Google Pay

Google’s Flutter case study describes the work involved in rebuilding Google Pay for India and the United States while maintaining an existing application with hundreds of features.

The published case study reported that the shared Flutter codebase was smaller than the previous implementations and easier for the engineering organization to manage. It also reported substantial estimated engineering-time savings during that migration.

The important lesson is not that every enterprise will achieve the same numbers.

It is that a large, complex product team considered a shared Flutter architecture viable for a high-usage financial application.

Dream11

Dream11 tested Flutter when a small team needed a multi-platform solution that could help it deliver new user experiences more quickly. Flutter’s official showcase describes the project in the context of supporting tens of millions of fantasy-sports users in India.

This example demonstrates one of Flutter’s clearest benefits: a small team can explore and ship cross-platform ideas without immediately creating two independent mobile implementations.

STAGE

STAGE, an Indian streaming platform serving regional dialects and languages, used Flutter and Firebase to support applications across Android, iOS, macOS, and Android TV.

Its published case study reports improved developer efficiency and faster application and feature-release cycles after moving toward a shared Flutter approach.

Again, these outcomes should not be treated as guarantees. But they show why organizations with multiple target platforms and limited engineering capacity may find Flutter attractive.

So what's the actual takeaway?

If you're an engineering leader trying to decide whether this applies to you, the honest framework is something like this:

Choose Flutter if you're building a UI-heavy customer-facing app across multiple platforms, you value shipping speed, and your integration needs are mainstream enough that the package ecosystem covers you.
Think harder if your product depends on deep, platform-specific hardware or OS integration that changes frequently, or if your team already has years of native or JS-specific investment that a rewrite would meaningfully waste.
Budget explicitly for the friction points above rather than pretending they don't exist niche integrations, senior hiring, and binary size are where "Flutter saves money" claims quietly go wrong if nobody planned for them.

The reason 2026 feels different from, say, 2023 isn't that Flutter suddenly became a different framework overnight. It's that the specific technical gaps that used to justify enterprise hesitation janky rendering, weak web support, bolt-on AI integration have closed enough that the old objections don't hold up in an architecture review anymore. Combine that with India's talent density and cost advantage, and the shift isn't really surprising. It's just what happens when a framework's maturity curve finally catches up to enterprise risk tolerance.

If you're evaluating Flutter for an enterprise project, the best test isn't reading another comparison post it's prototyping your single hardest UI screen and your single hardest integration point first. If both hold up, the rest of the migration is usually more straightforward than teams expect.

The SVG Was Valid. My Flutter Icon Wasn't.

Omar Khaled — Mon, 27 Jul 2026 05:29:42 +0000

The SVG rendered correctly. The generated Flutter icon font did not.

After conversion with FlutterIcon.com, a location pin lost its center hole, a chat bubble lost its third dot, and a mail icon lost its inner cutout. The same source files still looked correct in browsers and design tools.

All three SVGs used fill-rule="evenodd" to form cutouts. To isolate the conversion, I rendered the source SVGs, the FlutterIcon TTF, and a GlyphPact OTF/CFF build inside the same Flutter app:

This comparison used GlyphPact v1.1.0. All three columns were rendered by the same Flutter app.

This is a three-file result, not a claim that every even-odd SVG fails in FlutterIcon.com. These files lost visible cutouts in my export. That was enough to make me look at the rest of my icon workflow.

The SVGs rendered correctly, but the conversion still changed them

An SVG renderer and an icon-font generator have different jobs.

The SVG renderer understands fill rules, strokes, transforms, clipping, paint, and the rest of the document. A monochrome icon font represents the artwork as glyph outlines and alpha coverage. Somewhere between those two representations, strokes may need outlining, transforms need flattening, and cutouts must survive as contour relationships.

FlutterIcon.com has a familiar warning for this class of problem:

If image looks not as expected please convert to compound path manually.

Skipped tags and attributes: ...

That advice can fix a file, but it sends the work back to the developer or designer. Open a vector editor, change the paths, export again, upload again, and check the result.

For one icon, fine. For an icon set that keeps changing, the repair loop becomes part of every release.

The icon set keeps changing

My icon sets rarely arrive once. More icons show up in later Figma handoffs, and every batch has to join the existing font without changing codepoints already used by the app.

The Dart API matters as much as the pictures:

Icon(AppIcons.location)
Icon(AppIcons.chat)
Icon(AppIcons.mail)

Each field points to a codepoint in the font. If regeneration assigns an old field to a new glyph, the Dart code still compiles. The app simply shows the wrong picture.

FlutterIcon.com can preserve assignments if you save its config.json and import it on the next visit. That works, but it depends on keeping the file and following the same process every time.

That was the weak point for my projects. Someone had to remember the previous config, upload the correct files, export the bundle, copy the right artifacts, and check that nothing moved. The repository could not tell us whether any step was missed.

I wanted the icon font to behave like generated source code.

Moving the build into the repository

The SVG directory should be the source of truth. The command should run locally and in CI. Existing codepoints should stay fixed without depending on a remembered browser session.

That became GlyphPact, a local SVG-to-Flutter icon compiler:

uv tool install glyphpact

glyphpact assets/icons \
  --output lib/generated/app_icons \
  --name AppIcons

The output includes an OpenType/CFF font, a const Dart IconData provider, a machine-readable report, and iconfont.lock.json.

The lock file is the API contract. Adding or reordering SVGs does not renumber existing icons. Removing an icon leaves a tombstone, so its codepoint cannot quietly return as a different picture later. A unique content-preserving rename keeps the same assignment and Dart name.

There is a longer explanation of why stable icon codepoints matter, including a lock-file diff.

CI can rebuild the candidate output without replacing the committed artifacts:

glyphpact --config icon_font.json --check

The command exits with code 3 when the generated output is stale. A missing icon build stops looking like a visual QA problem and starts behaving like any other failed code-generation check.

Strict builds are sometimes annoying

In strict mode, GlyphPact accepts supported SVG features only when it can preserve them. Approximations and skipped inputs require explicit flags. Malformed, unsafe, unknown, or over-budget input fails the build.

This is stricter than accepting whatever a generator can produce, and sometimes it gets in the way. I prefer that interruption in a pull request to finding a damaged icon after a release.

It also does not claim to support every valid SVG. Icon fonts represent monochrome alpha coverage, not the full SVG format. If source color, animation, filters, or browser-dependent painting matter, a font is the wrong output.

Known limits for large icon packs

GlyphPact automates bulk conversion, but each build still produces an icon font. OpenType glyph indexing has a practical ceiling of 65,534 usable glyphs per font, and GlyphPact enforces the same per-build limit.

By default, assignments use the BMP private-use range from U+E000 through U+F8FF. That range has 6,400 lifetime slots. Active icons and tombstones both consume slots because GlyphPact never recycles a removed icon's codepoint. The build report tracks the remaining capacity and warns when range use reaches 80%.

A larger pack can start in a supplementary private-use range, which provides up to 65,534 slots. That choice must be made before the first build because an established lock file rejects later start-codepoint changes.

Larger catalogs need to be split into multiple independently versioned fonts. GlyphPact makes those builds repeatable, but it cannot make an unlimited catalog fit into one mobile font.

The CLI remains the source of truth

Because the build runs locally from a checked-in config, the same workflow can be exposed to coding agents without changing the compiler.

The optional GlyphPact MCP integration exposes four local operations: audit an SVG pack, build from a checked-in config, check committed output for staleness, and page through a build report.

MCP is not required. The CLI remains the compiler. The MCP layer gives a coding agent a defined boundary for the same workflow instead of asking it to operate a browser or guess which generated files it owns.

I still ship plenty of SVG files

I would keep a multicolor illustration or a one-off static graphic as SVG and render it with flutter_svg. For animation, I would use a format and renderer suited to that asset.

FlutterIcon.com also remains convenient when I need a quick one-time font or want to choose from its bundled icon libraries.

GlyphPact is for the narrower case I kept running into: a maintained set of monochrome Flutter UI icons, repeated design deliveries, and generated artifacts that need to stay correct across releases.

GlyphPact's source is on GitHub. If you have an SVG that behaves badly during font conversion, especially one involving even-odd fills, strokes, or cutouts, open an issue with the file. Minimal examples of currently unsupported features are useful too. Awkward inputs are more useful to this compiler than clean demo icons.

_Disclosure: I built and maintain GlyphPact.

How Architects Should Choose Between Native, Flutter, React Native, and KMM

Vaibhav Shakya — Mon, 27 Jul 2026 04:37:32 +0000

Choosing Between Native, Flutter, React Native, and KMP

Choosing a mobile architecture is not mainly about finding the framework with the highest code-reuse percentage.

The real decision is about defining the sharing boundary:

Which business rules must remain consistent?
Which features require platform-specific control?
Can Android and iOS releases remain synchronized?
Who will maintain native integrations?
Where will security-sensitive decisions be enforced?

Native provides direct platform control. Flutter commonly shares UI and application logic. React Native combines shared React logic with native rendering and modules. KMP can share domain and data layers while keeping Android and iOS interfaces native.

Before deciding, prototype the least portable production flow—such as payments, identity verification, Bluetooth, camera processing, or background work. Measure real workloads and assign clear ownership for every platform integration.

The best architecture is not the one that shares the most code. It is the one whose boundaries and ownership model the organization can maintain for years.

Read the complete article on Medium

The half-fixed bug: two upstream crashes in dio and flutter/packages

AS — Sun, 26 Jul 2026 23:02:35 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Both of these bugs were already known before I touched them. One had a linked issue and a fix that covered half the cases. The other had a unit test that asserted the crash, with a comment above it saying // Remove when fixed!.

They also had the same shape. In both projects the correct behavior already existed elsewhere in the same file: a sibling transformer that handled the input, a sibling branch that reported the failure instead of dying. One path had been left out of it.

So neither fix invents behavior. Each one extends a decision the project had already made to the branch that missed it.

Project Overview

dio (12.8k stars) is the HTTP client most Dart and Flutter apps are built on: interceptors, form data, request cancellation, timeouts, and a pluggable Transformer layer that turns raw response bytes into the typed object your code receives.

flutter/packages (5.3k stars) is the Flutter team's own monorepo of first-party plugins. The one here is file_selector_android, the Android implementation behind file_selector, the plugin you call when the user needs to pick a file from their device.

Bug Fix or Performance Improvement

1. dio: `FormatException` on an empty response body

FusedTransformer is dio's default transformer. When a request sets a custom responseDecoder and the server returns an empty body with a JSON content type (a normal 200, 204, or 304), the transformer's slow path fed the empty string straight into jsonDecode:

FormatException: Unexpected end of input (at character 1)

SyncTransformer and BackgroundTransformer are handed the identical input and both guard the empty string and return it, which dio then normalizes to null for typed JSON responses. Only the default transformer crashes.

This was the residual half of #2279. PR #2285 had already fixed the empty-body behavior for the fast path, the one with no custom decoder, but the slow path was never given the same guard. The issue looked closed and the fix looked shipped, and anyone who happened to set a responseDecoder still got an exception.

2. flutter/packages: a crash when a picked file can't be copied

file_selector_android crashed the app when a selected file couldn't be copied to a readable location: a SecurityException from a content provider that has withdrawn permission, or an IOException on a full disk.

FileSelectorApiImpl.toFileResponse looked like it handled this. Abbreviated:

String uriPath;
FileSelectorNativeException nativeError = null;

try {
  uriPath = FileUtils.getPathFromCopyOfFileFromUri(
      activityPluginBinding.getActivity(), uri);
} catch (IOException e) {
  // If closing the output stream fails, we cannot be sure that the
  // target file was written in full. […]
  uriPath = null;
} catch (SecurityException e) {
  // Calling `ContentResolver#openInputStream()` has been reported to throw a
  // `SecurityException` on some devices in certain circumstances. Instead of crashing, we
  // return `null`.
  //
  // See https://github.com/flutter/flutter/issues/100025 for more details.
  uriPath = null;
} catch (IllegalArgumentException e) {
  uriPath = FILE_SELECTOR_EXCEPTION_PLACEHOLDER_PATH;
  nativeError = new FileSelectorNativeException(/* … */);
}

return new FileResponse(uriPath, contentResolver.getType(uri), name, size, bytes, nativeError);

In the two branches that crash, uriPath = null is not an oversight. It is deliberate, and commented as such: "Instead of crashing, we return null." The comment cites flutter/flutter#100025, an earlier report of the same class of failure.

The method then builds a FileResponse on that null anyway. path is non-null in the Pigeon-generated FileResponse, so the constructor rejects it at runtime, and the branch written to avoid a crash produces one.

The third branch survives because IllegalArgumentException assigns a placeholder path instead of null, so it reaches Dart with a populated nativeError. The file already had a way to report an unreadable file without dying. The two branches that chose null just didn't use it.

The crash had also shifted shape over time, which is part of why it survived. flutter/flutter#159568 reported it as an IllegalStateException, thrown by the older Java Pigeon generator; since the move to the Kotlin generator, the same failure surfaces as an NPE.

The test suite knew about it too. There was a passing test named openFileThrowsNullPointerException_whenSecurityExceptionInGetPathFromCopyOfFileFromUri, which asserted the crash:

assertThrows(
    NullPointerException.class,
    () -> listenerArgumentCaptor.getValue()
              .onActivityResult(222, Activity.RESULT_OK, resultMockIntent));

Above it, a comment: "The behavior is actually an error case and should be fixed … Remove when fixed!" So the crash was documented, asserted, and passing CI.

Code

dio: cfug/dio#2550, merged
flutter/packages: flutter/packages#12107, merged and shipped in file_selector_android 0.5.2+9

My Improvements

dio: widen the guard instead of adding a branch

The whole fix is one extra condition:

if (isJsonContent &&
    decodedResponse != null &&
    decodedResponse.isNotEmpty) {
  // slow path decoder, since there was a custom decoder specified
  return jsonDecode(decodedResponse);
} else if (customResponseDecoder != null) {
  return decodedResponse;
}

The obvious patch is a new early return for the empty case. I didn't write one, because the branch that already handles it correctly sits directly underneath: else if (customResponseDecoder != null) { return decodedResponse; }. Adding isNotEmpty to the guard lets an empty body fall through into it, and dio's existing normalization turns that into null for a typed JSON response.

So the fix adds no new code path. It narrows a claim that was too broad: "this string is JSON" becomes "this non-empty string is JSON."

A non-empty malformed body still throws, as it did before and as SyncTransformer and BackgroundTransformer do. I wanted the three transformers to agree on this input. Making the default one more forgiving than the other two would have been a different change.

The regression test pins the behavior to the specific combination that was broken (empty body, JSON content type, custom decoder) rather than to the fix:

String decoder(List<int> bytes, RequestOptions o, ResponseBody rb) =>
    utf8.decode(bytes, allowMalformed: true);

final response = await FusedTransformer().transformResponse(
  RequestOptions(
    responseType: ResponseType.json,
    responseDecoder: decoder,
  ),
  ResponseBody.fromBytes([], 200, headers: {
    Headers.contentTypeHeader: [Headers.jsonContentType],
  }),
);
expect(response, '');

flutter/packages: return null instead of an invalid object

Again the correct behavior already existed one level up. The callers of toFileResponse handle a null return: they complete the Dart result with completeWithError("Failed to read file: …"), which is what they do everywhere else a file can't be read. toFileResponse was the only place that pushed on regardless.

if (uriPath == null) {
  // `getPathFromCopyOfFileFromUri` can fail to produce a path: either by
  // throwing (handled above by returning a null `uriPath`) or by returning
  // null directly. Return null so the caller surfaces the failure to Dart,
  // instead of building a `FileResponse` with a null `path`, which the
  // non-null field rejects at runtime.
  // See https://github.com/flutter/flutter/issues/159568.
  return null;
}

Checking uriPath == null rather than catching the exception at the call site was deliberate. getPathFromCopyOfFileFromUri can also return null without throwing, and that path led to the same crash, so one check covers both.

The failure now reaches Dart as a PlatformException you can catch, which is what the uriPath = null branches were aiming for.

I inverted the test that asserted the crash rather than deleting it. It now drives onActivityResult for real and asserts that the callback completes with a failure whose message contains "Failed to read file". I added a second one for the single-file openFile path, which had the same defect and no coverage at all.

I also kept the PR scoped to the crash. #159568 suggests routing these branches through the typed FileSelectorNativeException mechanism, the way #8184 did elsewhere. That is the better long-term design, but it needs a Pigeon regeneration and a Dart-facing API change, which would put a breaking change in the same PR as a crash fix. The API cleanup is worth doing on its own.

What I took from both

The reflex when you find a crash is to add a check. In both of these the check already existed, in the transformer next door or in the caller one frame up, so most of the work was reading enough of the surrounding code to find it. Once you have, the patch is small enough to review in one sitting.

Both bugs had also been looked at before. dio's had an issue and a fix that covered the fast path. The Android one had a test asserting the crash and a comment saying to remove it when fixed. Writing a bug down is not the same as fixing it, and it makes the bug much harder to see the second time around.

DEV Community: flutter

Flutter vs. Native: The ROI Mistake Many Startup Founders Make

The True Cost of Building a Mobile Apps in 2026: What Founders Often Miss

Seamless Flutter Hooks Integration with BlocSignal via signals_hooks

Zero Glue Code. Streamless Reactivity. Pure Hook Composition.

💡 The Core Architectural Insight

🪝 Key Capabilities & Patterns

1. Direct State Consumption (useSignalValue / useWatch)

2. Streamless Side Effects (useSignalEffect)

3. Fine-Grained Derived Selectors (useComputed)

4. Lifecycle Teardown & Scope Safety

Widget-Local BLoC Instances

💻 Side-by-Side Comparison

❌ Before: Legacy flutter_hooks_bloc Glue Code

✅ After: Modern BlocSignal + signals_hooks

📊 Architectural Mapping Table

🎯 Conclusion

🔗 Explore More

Material 3 Expressive for Flutter: Bringing Google's Latest Design Language to Flutter

✨ A Complete Material 3 Expressive Library

🎯 Actions

✅ Selection

📦 Containment

🧭 Navigation

💬 Feedback

🌊 Expressive Motion

🎨 Unified Design System

🚀 Getting Started

1. Install

2. Import

3. Use M3EMaterialApp

💙 Flutter-first API

📱 Interactive Gallery

🎉 Final Thoughts

📚 Learn More

Switching Tracks in BlocSignal: The Universal State Switchyard for BLoC, Riverpod, and Provider

Why You Don't Have to Tear Up Your Codebase to Enjoy the Speed of Synchronous Signals

🚂 The Core Metaphor: "Switching Tracks in BlocSignal"

⚡ The Synchronous Signal Core: Green Lights All the Way

🚆 Track 1: BLoC, Redux & Stream Interop (package:bloc_signals)

Ingesting Streams & Redux

Exporting BlocSignal to Stream

🚆 Track 2: Riverpod Interop (package:bloc_signals_riverpod)

Ingesting Riverpod Providers (With Automatic Teardown!)

Exporting BlocSignal to Riverpod

Riverpod 3 AsyncValue ↔ Signals AsyncState Bridge

🚈 Track 3: Flutter Listenable & package:provider (package:bloc_signals_flutter)

Ingesting Listenable and ValueNotifier

Exporting BlocSignal to ValueListenable

🔄 Multi-Track Routing: Synchronizing Across Ecosystems

Example: Provider ➔ BlocSignal ➔ Riverpod

🤖 AI Agent Skills: Your Automated Signal Operator

🎯 Summary & The Interoperability Matrix

📋 Cheat-Sheet Interoperability Matrix

🚀 Get Started Today

Publishing your Flutter Game in the Steam Deck!

The Steam Deck

Flutter on the Steam Deck

The windows build approach

The Linux native approach

The approach I choose for my game and why

Patching my game for the SLR

Conclusion

그누보드와 Flutter 앱, JWT로 회원 연동하기: 레거시 시스템 통합 경험기

그누보드와 Flutter 앱, JWT로 회원 연동하기: 레거시 시스템 통합 경험기

이 글에서 짚는 것

오래된 그누보드, 새로운 Flutter 앱과의 만남 준비

그누보드 환경 위에서 API 엔드포인트 설계하기

JWT 발급과 갱신, 그리고 그누보드 회원 연동의 핵심

보호된 API 접근과 토큰 유효성 검증 과정

실제로 작동하는 시스템을 위한 꼼꼼한 확인

정리하며

How I Built Flutter On-Device AI Clipboard Security: Zero Cloud

Why Your Mobile Clipboard Needs On-Device AI Security

Building Real-Time Flutter Local AI Privacy for Clipboard Scans

Step-by-Step Implementation: Flutter On-Device AI Clipboard Security

Step 1: Add Dependencies & Model

Step 2: Load TFLite Model

Step 3: Monitor Clipboard

Step 4: Integrate into your Flutter App & User Alert

1. Direct State Consumption (`useSignalValue` / `useWatch`)

2. Streamless Side Effects (`useSignalEffect`)

3. Fine-Grained Derived Selectors (`useComputed`)

❌ Before: Legacy `flutter_hooks_bloc` Glue Code

✅ After: Modern `BlocSignal` + `signals_hooks`

3. Use `M3EMaterialApp`

🚆 Track 1: BLoC, Redux & Stream Interop (`package:bloc_signals`)

Exporting `BlocSignal` to Stream

🚆 Track 2: Riverpod Interop (`package:bloc_signals_riverpod`)

Exporting `BlocSignal` to Riverpod

Riverpod 3 `AsyncValue` ↔ Signals `AsyncState` Bridge

🚈 Track 3: Flutter `Listenable` & `package:provider` (`package:bloc_signals_flutter`)

Ingesting `Listenable` and `ValueNotifier`

Exporting `BlocSignal` to `ValueListenable`

Example: Provider ➔ `BlocSignal` ➔ Riverpod

1. dio: `FormatException` on an empty response body