DEV Community: Kouki Badr

from a CLI engine to four different usage: Cleanbev

Kouki Badr — Tue, 08 Sep 2026 08:15:18 +0000

If you've shipped a Flutter app for more than a few months, you know the drill: assets pile up. Old icons nobody swapped out, images from a design iteration three sprints ago, a splash screen you replaced but never deleted. assets/ quietly turns into a junk drawer, and nobody notices until app size becomes a conversation.

That's the problem Cleanbev is solving — But in 4 different ways not only via a CLI.

It started as just that: a CLI but today it covers every surface a developer might actually want to use it from.

The four surfaces

🖥️ CLI The original. dart pub global activate cleanbev, then run it in your project root.

🤖 MCP Server Lets AI coding assistants (Claude, Cursor, and others) clean up unused assets as part of an agentic workflow, instead of you manually running commands mid-conversation.

⚙️ GitHub Action Drop assets checks straight into CI which catch unused assets before they ever reach production.

🧩 VS Code Extension: new Scan and clean unused assets without leaving your editor. This is what I'm actually writing this post about.

What the extension does

Two commands, both from the Command Palette:

Cleanbev: Dry Run — scans your project and shows you exactly what's unused, as structured results, without touching anything. This is the one you run first, every time.
Cleanbev: Clean — scans and removes unused assets, after you confirm the assets path.

Requirements (for now)

The extension is a UI layer on top of the real CLI, not a reimplementation — so it needs the CLI installed:

dart pub global activate cleanbev

I went this route deliberately for v1 rather than reimplementing the detection logic inside the extension itself. Once you have a CLI, an MCP server, and a GitHub Action all needing to agree on what "unused" means, keeping one canonical implementation that everything else calls into is a lot saner than three parallel implementations quietly drifting apart. A dependency-free bundled binary is on the roadmap, but "one source of truth" won out for launch.

Try it
📦 Cleanbev package https://pub.dev/packages/cleanbev
🧩 Cleanbev extension VScode Extension
🤖 The MCP tool https://pypi.org/project/cleanbev-mcp/
🛞 The github action https://github.com/marketplace/actions/cleanbev-asset-check

If you run into anything or have ideas for what the extension should do next, I'd genuinely love the feedback.

This whole project has grown a lot more than I originally planned for one CLI tool, and that's mostly been driven by people actually using it and telling me what they needed next.

Automate Unused Asset Cleanup in Flutter

Kouki Badr — Wed, 02 Sep 2026 07:54:01 +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_skin Alpha

Kouki Badr — Wed, 12 Aug 2026 08:34:34 +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

Change Flutter Themes Without Rebuilding

Kouki Badr — Mon, 06 Jul 2026 07:20:22 +0000

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.

📦 Package (pub.dev):

flutter_skin | Flutter package

A runtime skin engine for Flutter projects, allowing dynamic theme changes without the need for app restarts.

pub.dev

🖥️ Dashboard:

app.fskin.dev

📖 Docs:

Introduction - fskin

FSkin — remote skin management for Flutter. Change your app's colors live, without shipping an update.

docs.fskin.dev

📌 About this project

flutter_skin is open source. The SaaS dashboard (fskin.dev)
is the cloud layer that handles skin delivery, team
collaboration, and API key management.

Change Flutter Themes Without Rebuilding

Kouki Badr — Mon, 06 Jul 2026 07:20:22 +0000

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.

📦 Package (pub.dev):

flutter_skin | Flutter package

A runtime skin engine for Flutter projects, allowing dynamic theme changes without the need for app restarts.

pub.dev

🖥️ Dashboard:

app.fskin.dev

📖 Docs:

Introduction - fskin

FSkin — remote skin management for Flutter. Change your app's colors live, without shipping an update.

docs.fskin.dev

📌 About this project

flutter_skin is open source. The SaaS dashboard (fskin.dev)
is the cloud layer that handles skin delivery, team
collaboration, and API key management.

I built a remote skin engine for Flutter

Kouki Badr — Sun, 28 Jun 2026 09:07:47 +0000

Every one of us has been here.

The designer opens Figma and changes the primary color from #6C63FF to #5B52E8. A small update (they think).

Our release cycle: create a branch, update the color, build, test, submit to App Store, wait for store review, for just a hex code.

This is the tax Flutter developers pay for a compile-time theming system. It's powerful and type-safe and beautiful — and completely frozen the moment your app ships.

flutter_skin

flutter_skin is a runtime skin engine. Instead of hardcoding your color values, you define them as named tokens. Those tokens are managed from a dashboard and delivered to your app.
When you publish a new skin, every connected device updates instantly.

How it works in 2 lines

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await FlutterSkin.init(apiKey: 'fsk_your_key_here');
  runApp(const MyApp());
}

// In your MaterialApp:
theme: FlutterSkin.toThemeData()

That's the integration. FlutterSkin.init() fetches the active skin from the FSkin backend and opens a persistent SSE connection. From that point, any skin you publish reaches the app in about 2 seconds.

The live update architecture

Here's what happens end to end when you click Publish:

Dashboard: click Publish
        ↓
Skin marked active in PostgreSQL
        ↓
Supabase Realtime detects the UPDATE on skins table
        ↓
Node.js backend receives the Realtime event
        ↓
Backend writes SSE event to all connected Flutter clients
        ↓
flutter_skin package receives the flag
        ↓
Package re-fetches active skin from CDN
        ↓
A stream emits new SkinTokens
        ↓
setState() → MaterialApp rebuilds → app repaints

Total time: ~1–2 seconds. No polling. No App Store. No user action.

The full MaterialApp setup

To react to live updates, wrap your app in a StatefulWidget:

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

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  @override
  void initState() {
    super.initState();
    FlutterSkin.onSkinChanged.listen((_) {
      if (mounted) setState(() {});
    });
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: FlutterSkin.toThemeData(),
      home: const HomePage(),
    );
  }
}

What's available today

The alpha supports color tokens — full Material ColorScheme mapping:

primary, secondary, background, surface, error
All the on* counterparts
brightness for light/dark

The dashboard (app.fskin.dev) gives you:

Project management
Skin editor with JSON view
Team collaboration with role-based permissions
API key management (auto-generated per project)
Publishing with confirmation + version history

A lot of cool features still coming

LiveData vs Flows

Kouki Badr — Thu, 30 Apr 2026 10:05:12 +0000

A modern mobile application is expected to be as reactive as possible, otherwise it will lag behind other apps and users won't find it attractive.
For this, the Kotlin team has provided many tools and APIs like Flows and LiveData.
If you develop Kotlin apps, you already know LiveData (otherwise, we'll judge you 😄). LiveData is a stream of data that lets developers implement a reactive flow between a producer (the class that emits data) and its consumers. But this definition also applies to StateFlow and SharedFlow — so what is the difference between them?

Initialization

The first difference is how we initialize both classes.
With LiveData, no initial value is required:
private val _myData = MutableLiveData<Int>()
Meanwhile, StateFlow requires an initial value:

private val _myData = MutableStateFlow<Int?>(null)
private val _myData = MutableStateFlow<Int>(0)

The examples above show a direct translation from LiveData to StateFlow — you either make the type nullable or provide a dummy initial value.

Lifecycle

The second difference is lifecycle awareness.
LiveData observers are tied to a Lifecycle object and clean up after themselves when their associated lifecycle is destroyed. If the observer is tied to an Activity or Fragment, it is automatically stopped when that Activity or Fragment is paused or destroyed — preventing memory leaks out of the box.

StateFlow observers, on the other hand, are not lifecycle-aware by default, meaning we as developers need to manage the observer's lifecycle manually. The recommended solution is to collect the StateFlow inside repeatOnLifecycle, which makes the collection lifecycle-aware and behaves similarly to a LiveData observer.

Happy Coding! 🤟

Optimizing Performance in Android Apps with Kotlin

Kouki Badr — Thu, 12 Feb 2026 10:08:43 +0000

Optimizing the performance of your Android applications is crucial for providing a smooth and responsive user experience. Kotlin, with its concise syntax and powerful features, offers several ways to enhance the performance of your apps. In this article, we'll explore various techniques and best practices to help you get the most out of your Android applications.

Profiling Your App

Before you can optimize your app, you need to understand where the performance bottlenecks are. Android Studio provides powerful profiling tools that can help you identify issues related to CPU usage, memory allocation, and network activity.

CPU Profiling: Use the CPU profiler to identify methods that are consuming the most CPU resources. Look for methods that are called frequently or take a long time to execute.
Memory Profiling: The memory profiler can help you track memory allocations and identify memory leaks. Pay attention to objects that are being created frequently or not being released properly.
Network Profiling: Use the network profiler to monitor network requests and identify any delays or inefficiencies.

Memory Management

Efficient memory management is essential for preventing memory leaks and reducing the risk of your app being killed by the system due to high memory usage.

Use ViewHolder Pattern: When working with RecyclerView, use the ViewHolder pattern to recycle views and reduce the overhead of view inflation.
Avoid Memory Leaks: Be cautious with anonymous inner classes and non-static inner classes, as they can hold references to their outer class instances, leading to memory leaks.
Use Kotlin's Null Safety: Kotlin's null safety features can help you avoid null pointer exceptions and manage memory more efficiently.

Efficient Coding Practices

Writing efficient code is key to optimizing the performance of your Android apps.

Use Kotlin Coroutines: Coroutines allow you to write asynchronous code in a sequential manner, making it easier to manage and optimize.
Leverage Inline Functions: Inline functions can reduce the overhead of function calls, improving performance in hot code paths.
Optimize Loops: Avoid performing expensive operations inside loops. Instead, precompute values and reuse them when possible.
Use Efficient Data Structures: Choose the right data structures for your use case. For example, use Set for fast lookups and Map for key-value pairs.

Conclusion

By following these techniques and best practices, you can significantly improve the performance of your Android applications. Remember that performance optimization is an ongoing process, and it's important to continuously profile and optimize your app as it evolves.

Happy coding!

Bottom_Picker new Major version

Kouki Badr — Sat, 26 Jul 2025 10:50:26 +0000

🎉 Exciting News for Flutter Devs! 🎉

We're thrilled to announce a major update to our beloved bottom_picker package! We've bumped the version all the way to 4.0.0! 🚀

This release is packed with awesome new features and improvements for your Flutter applications, including:

✨ Filter Options:
Now you can easily add filters to unpickable or blocked days in your date pickers! Say goodbye to those unwanted dates. 🗓️

➕ Year Picker: Selecting a year just got a whole lot easier with the new dedicated year picker. ⚙️

🛠️ Enhanced Title Flexibility: We've transformed the pickerTitle into an optional header builder callback, giving you full control over the picker's header!

But wait, there's more! We've also squashed a pesky bug where selectedItemIndex parameters weren't working correctly for simple pickers. 🐛

⚠️ Breaking Changes Alert! ⚠️

Due to the significant enhancements, especially the title customization via the new callback, this release includes potential breaking changes.
All attributes that are related to the old title, description and closing widget are now deprecated if you're planning to upgrade to 4.0.0 version.

We believe these changes will greatly improve the flexibility and usability of bottom_picker in your Flutter projects.

Check out the full release notes and upgrade guide here: Bottom_Picker

#flutter #dart #bottompicker #mobiledev #opensource

Say "Oui" to Global Users: Localize Your Flutter App with Gemini

Kouki Badr — Sun, 09 Jun 2024 15:09:41 +0000

Why localize your app? Think about it, ignoring international users is like making a fire meme and forgetting to post it online - what's the point? But don't worry, we hear you screaming Fear not, for Gemini is here to be your Yoda in the localization swamp. We'll tackle all your app translation woes, so buckle up and get ready for a smooth ride and dive deep with us in this post!

What is localization and How it's done?
To conquer the globe, you need some serious localization skills.

Think of locales as your app's Rosetta Stone – they unlock the ability to understand different languages, date formats (no more confusing July 4th with 4th of July!), currencies, and all those cultural nuances. So, French users see euros and "dd/mm/yyyy," while Spanish speakers get their pesos and the familiar "dd/mm/aaaa."

Now, managing these locales can feel like herding cats. But fear not, there's a better way than wrestling with JSON files (because, let's be honest, that's a recipe for disaster).
Enter the dynamic duo of flutter_localizations and intl – these packages are your knight in shining armor, recommended by the official Flutter people themselves.

Here's the battle plan:

Recruit your allies: Integrate flutter_localizations and intl into your app.
Set up your command center: Create a l10n.yaml config file.

arb-dir: lib/l10n
template-arb-file: app_en.arb
output-localization-file: app_localizations.dart

Deploy your troops: Create .arb files under the lib/l10n folder (or a location of your choosing, just update the config file accordingly). These .arb files will house all your app's localized strings.

With this battle plan in place, you'll be a localization champion in no time, ready to take your app to a global phenomenon!

With Gemini
Feeling overwhelmed by app localization? Manually translating endless lines for every language can be a daunting task. But fear not, developer! Google Gemini has your back with the arb_translate package.

Think of arb_translate as your personal localization assistant. You simply write the default translations, and then unleash the power of Gemini! With a single arb_translate command, Gemini translates all the other languages you need, taking context (e-commerce, cars, coding?) into account for natural-sounding translations.

Ditch the manual translation grind and let Gemini be your localization hero. It's a much more efficient way to conquer the world with your app! Now that you've got a taste of Gemini's localization magic.

why not jump in and try it for yourself you can finally overcome the language barrier and reach new heights, just like Lara Croft raiding tombs and uncovering hidden treasures across the globe!

EasyDeps : brick-ception

Kouki Badr — Sun, 12 May 2024 16:34:56 +0000

The Flutter ecosystem is abuzz with a new framework – Mason. Boasting over 300 bricks and counting, it's a construction zone of awesome functionality. But what if we could take things a step further? Enter the meta-brick, a brick built specifically for other brick developers.

This isn't your average UI brick. It's about streamlining the workflow for fellow brick builders. Imagine a world without manually managing dependencies in each brick. This innovation offers centralized dependency management through a dedicated package.json file, keeping your code clean and organized.

Picture this: You integrate your brick into a Flutter project, and poof! All necessary dependencies are installed automatically. That's the magic of this brick.
Additionally, it champions project structure, residing within a dedicated hooks directory for a minimalist's dream layout.

Ready to unlock this developer superpower? Buckle up – we'll be diving into EasyDeps, with clear instructions that demystify the process. It's recursion made simple, without the headache of explaining Inception.

How this project work?

Installation:

Get your brick on board with mason add easy_deps (or go global with mason add -g easy_deps).

Generation:

Unleash the magic with mason make easy_deps. This brick is low-maintenance – no pesky questions to slow you down.

Dependency Nirvana:

Boom! You've got yourself a packages.json file nestled within your brick's folder.

But Wait, There's More!

easy_deps doesn't stop at a fancy package.json. It also introduces some undercover heroes:

package_installation_handler: This bad boy parses your package.json, ensuring all the dependencies are listed and ready for action.

post_gen.dart: In the early days, easy_deps might be a little overzealous, replacing your existing post_gen.dart It simply includes the call to the package_installation_handler code, ensuring your dependencies are installed smoothly.

Don't worry the package.json will be deleted once your brick is integrated into the app project, It's all temporary.

Here's the good stuff:

Manual configuration?

More like "manual vacation!" This bad boy handles it all, so you can spend your time on more important things.

Cleanliness

The dependency handler chills in the hooks directory, keeping your project looking like a masterpiece.

Dedicated package.json for dependencies?

Think of it as your own personal spice rack – everything neatly organized and ready to flavor your app just right. No more hunting for that elusive sprinkle of unicorn dust dependency.

Well, that's just next-level meta, who are we to judge brick-ception dreams?

Feel like to contribute to this project? head to github and send me your PRs and Issues https://github.com/koukibadr/B-Bricks.

Also head to brickhub page to learn more about easy_deps
https://brickhub.dev/bricks/easy_deps/0.1.0+1

Internationalization? More Like International-WIN-ization with Flutter Mason! (Effortless Internationalization)

Kouki Badr — Sun, 05 May 2024 10:42:47 +0000

Flutter devs, ever feel like you're stuck in a loop localization drudgery?

Fear not, weary coder! Even if you're not a Flutter master (yet!), this article will have you saying "I'm beginning to see the pattern...".

We all know Flutter is fast compared to native development (looking at you, Android Studio!), but buckle up because Flutter Mason is about to blow your development speed right out of the water. ️ This article will be your guide to the specific Flutter Mason trick that'll make ARB localization a breeze.

Localiz

As it's description mentioned "Ease and Speed up Internationalizing Flutter Apps" this brick integrate all the arb dependencies, configuration and arb files for you.

How ? 🤔

Alright, installation time! But before we dive in, here's a friendly reminder:

We've got two options for getting Mason and mason_cli on your machine. For the command-line cowboys,there's the classic
dart pub global activate mason_cli.
But if you're a true programmer of culture (and a Homebrew user), you can unleash the power of
brew tap felangel/mason; brew install mason.

Finally, the moment we've all been waiting for: installing the localiz brick.
You can do this locally with mason add localiz or go full global dominance with mason add -g localiz. The choice is yours, but choose wisely!

Use it

All you need to do now it to use it on your project
mason make localiz
this will trigger the brick, and it will ask you:

Choose language to include in your app?
  ◯  English (en)
  ◯  Arabic (ar)
  ◯  Chinese (zh-CN)
  ◯  Spanish (es)
  ◯  French (fr-FR)

it's a multiple selection so use the spacebar to select the languages you want to include when localizing your app

after this the brick will ask you which language of those you select it's the default and will act like the arb template reference.

That's it! Now you can high-five yourself, commit your changes, push it to the repo, mark your Jira ticket as "DONE" with the smug satisfaction of a champion.

The localiz brick takes care of everything: installing those pesky packages (intl, flutter_localizations), generating the l10n.yaml config file with your default language, and even creates the l10n folder within your lib directory pre-populated with all the languages you selected.

Basically, it saves you a ton of time on tedious setup, freeing you up to focus on the real coding magic. Because, let's be honest, life is way too short to be wrangling ARB files manually.