Anthropic got 16 Claude instances to build a C compiler (with some caveats). OpenAI shipped GPT-5.3-Codex, and it's good! And then OpenClaw — a vibe-coded AI agent with 230K GitHub stars — became a full-blown security crisis, with malicious packages showing up on pub.dev too.

There's a new Flutter release as well, so let's start there. 👇

Flutter 3.41 + Dart 3.11

Flutter 3.41 landed earlier this month with 868 commits from 145 contributors. The ongoing work to decouple Material and Cupertino into standalone packages continues, and this release brings several other improvements:

• Fragment shader improvements: Synchronous image decoding (decodeImageFromPixelsSync) eliminates frame lag, and 128-bit float texture support unlocks GPU-accelerated photo filters.
• Impeller bounded blur: Fixes color bleeding on translucent widgets using BackdropFilter.
• Widget Previewer: Better VS Code and IntelliJ integration, plus support for dependencies on platform-specific libraries like dart:ffi and dart:io.
• New Getting Started Experience: The redesigned Learn section on the Flutter website, powered by Jaspr.
• 2026 Roadmap: Four stable releases planned. WebAssembly is on track to become the default for Flutter Web (40% faster load times, 30% less runtime memory).

For the full details, read the official blog post:

• What's New in Flutter 3.41

As for Dart 3.11, this release focuses on tooling improvements rather than new language features. The highlights include faster analyzer plugins (~10s saved on startup), a new dart pub cache gc command to reclaim disk space, enhanced dot shorthand tooling, and pub workspace glob support. The Dart & Flutter MCP Server was also improved. 🤖

For all the details:

• Announcing Dart 3.11

For more context about Flutter's position in 2026 (including a full timeline of significant milestones over the last year), check out this State of Flutter 2026 article.

AI News

This was a big month for agentic AI coding. Two stories in particular stood out to me.

📝 Building a C Compiler with a Team of Parallel Claudes

Anthropic researcher Nicholas Carlini orchestrated 16 Claude instances to build a C compiler in Rust over nearly 2,000 Claude Code sessions and ~$20K in API costs. The result: a 100,000-line compiler with a 99% pass rate on standard compiler test suites.

The multi-agent engineering appears to be genuinely impressive:

• Agents claimed work from a shared task queue via lock files, with git handling merges and conflict resolution.
• Each agent had specialized roles: core compilation, code deduplication, performance optimization, documentation, and architecture.
• Tests served as the primary feedback mechanism, with comprehensive suites using SQLite, Redis, libjpeg, and the GCC torture tests.

Here's the full write-up:

• Building a C compiler with a team of parallel Claudes

However, Anthropic's marketing of the project attracted legitimate criticism. ThePrimeagen published a detailed response pointing out that the framing of "from scratch, no human intervention" was misleading:

• Not "from scratch": Claude was trained on GCC (open source), and used its 37-year-old torture test suite for validation, plus GCC itself as an "online Oracle" to verify output. Starting "from scratch" with the perfect test suite and a reference implementation to test against is not quite the same thing as starting from a blank slate.
• Not "no human intervention": agents crashed and required restarting during the two weeks.
• Can't actually boot Linux: the compiler lacks a 16-bit x86 code generator small enough to meet Linux's 32KB real mode limit.
• Hello World didn't compile: the README example failed because the project lacks a linker.

So what's the real takeaway? As ThePrimeagen himself acknowledges: getting 16 AI agents to run mostly autonomously for two weeks and produce a substantial, functional piece of software is genuinely cool. It shows that models are improving and can handle projects at this scale with the right orchestration. That's the real story — no hype needed.

Chris Lattner (creator of LLVM, Swift, and Mojo) also published a thoughtful analysis, calling it "real progress, a milestone for the industry" while noting that the compiler reproduces decades of established engineering rather than inventing novel abstractions. His core thesis: as coding becomes cheaper, the real challenge becomes choosing the right problems and managing the resulting complexity.

📝 GPT-5.3-Codex: Full Autonomy Has Arrived?

Earlier this month, OpenAI released GPT-5.3-Codex, and the early reviews are eye-opening.

Matt Shumer's hands-on review describes it as the first model where "full autonomy starts feeling operationally real." In practice, this means you can specify an outcome, set up validation criteria, press go, and come back hours later to find the work done — including code changes, GitHub pushes, deployments, and log monitoring.

Key highlights:

• Can run tasks for 8+ hours without degradation.
• 25% faster than GPT-5.2-Codex, and tops SWE-Bench Pro and Terminal-Bench 2.0.
• Self-improvement capabilities: the model debugged its own training run and scaled its own GPU clusters.

I've been testing GPT-5.3-Codex for my own Flutter work over the past few weeks, and I have to say: I'm finding it faster, cheaper, and sharper than Opus 4.6 — often surfacing edge cases and insights that Opus misses. With that said, while "8+ hours without degradation" may be possible, my workflows require frequent human oversight and I care more about output quality than "how long it can run".

The OpenClaw Security Crisis

Now for the other side of the coin. If the Claude compiler pushes the boundaries of AI autonomy, the OpenClaw saga shows what happens when the worst practices collide with rapid adoption.

OpenClaw (formerly Clawdbot/Moltbot) is an open-source AI agent that exploded to 150K+ GitHub stars. It connects to LLMs and can autonomously execute tasks through messaging platforms like WhatsApp, Telegram, and Slack. Sounds cool, right?

The problem: OpenClaw requires broad permissions to function (email, calendars, messaging platforms, file system), and misconfigured or exposed instances quickly became a magnet for attackers. One of OpenClaw's own maintainers warned on Discord: "if you can't understand how to run a command line, this is far too dangerous of a project for you to use safely." Within weeks, the security issues piled up:

• 40,000+ instances exposed on the public internet because the gateway binds to 0.0.0.0 by default.
• API keys stored in plaintext markdown and JSON files.
• 12-20% of ClawHub marketplace skills were malicious, with the ClawHavoc campaign distributing Atomic Stealer to harvest crypto keys, SSH credentials, and browser passwords.
• CVE-2026-25253 (CVSS 8.8): a one-click remote code execution exploit where visiting a single malicious webpage is enough.
• Prompt injection attacks already seen in the wild, including crypto wallet drain attempts.

For the full details, here's CrowdStrike's breakdown:

• What Security Teams Need to Know About OpenClaw

And it gets worse. In a case of meta-irony, Cline CLI was also compromised via a supply chain attack that silently installed OpenClaw on ~4,000 developer machines. The root cause? Prompt injection exploiting AI-assisted GitHub workflows to steal npm publish credentials. An AI coding tool, compromised via an AI-specific attack vector. 😬

For entertainment value, here's a video of OpenClaw deleting an entire inbox:

Why Flutter Devs Should Care

This isn't just a general security story. The r/FlutterDev community has been flagging OpenClaw-generated packages appearing on pub.dev — vibe-coded packages that lack proper testing, security review, and sometimes contain hidden dependencies or malicious code.

The broader lesson: AI agents can ship code at unprecedented speed, but that speed makes proper security practices more important, not less. Treat community-generated skills and packages with the same skepticism you'd give a random npm package from a stranger.

AI Articles

Beyond the headline stories, I bookmarked some excellent articles this month that are good food for thought.

📝 The Software Development Lifecycle Is Dead

Boris Tane argues that AI agents haven't just accelerated the SDLC — they've dismantled it. The traditional sequential stages (requirements → design → implementation → testing → review → deployment → monitoring) didn't get faster. They merged into a single, tight feedback loop.

His key insights:

• Requirements are now fluid and iterative rather than frozen specifications.
• Code review via PRs becomes a bottleneck when agents generate hundreds of changes daily. Self-verification and second-agent reviews are replacing human code review for routine changes.
• Observability becomes the primary safety mechanism, with monitoring feeding back to agents for automatic fixes.
• "Context engineering" replaces process management as the new critical skill.

Read the full article:

• The Software Development Lifecycle Is Dead

I've been using a traditional "spec → plan → implement → review → ship" cycle in my own work. But I'm starting to notice that if the spec is solid and the agent has its own verification loop (TDD helps greatly here), manual code reviews become less important. The discipline shifts upstream — getting the requirements right matters more than ever.

📝 The Importance of Artifacts in AI-Assisted Programming

Nicholas Zakas makes a compelling case for why documentation isn't optional when coding with AI. His core point: AI has no memory beyond its context window. It can't tell you why it made a decision six months ago that brought down your server today.

His recommended artifacts:

• Product Requirements Documents (PRDs): Capture the what and why.
• Architectural Decision Records (ADRs): Immutable records of technical choices and their rationale.
• Technical Design Documents (TDDs): The how of implementation.
• Task Lists: Granular work items with dependencies and acceptance criteria.

If you're using AI coding tools and not maintaining these artifacts, this article will change how you think about documentation:

• The Importance of Artifacts in AI-Assisted Programming

These two articles pair well together: as the SDLC collapses into tight feedback loops, documentation artifacts become the new source of truth that compensates for what both AI and humans forget over time.

I also recommend Code Is Cheap Now. Software Isn't — a thoughtful piece arguing that while LLMs have made code generation nearly free, the barrier to building meaningful software remains unchanged. Engineering value is shifting from syntax mastery toward architectural thinking, taste, and knowing where not to cut corners. This echoes Chris Lattner's thesis perfectly.

Latest from Code with Andrea

I've been quiet on the content front lately, and for good reason: I've been heads-down building an agentic coding toolkit for Flutter — and dogfooding it heavily.

Here are a few Flutter web apps I built entirely with this spec-driven workflow (no manual coding):

• Currency Converter
• Portfolio Tracker
• Italian Tax Calculator

If you're curious what the generated code looks like, I've open sourced the Currency Converter on GitHub:

• Currency Converter (GitHub)

Until Next Time

The toolkit is shaping up well and I'm hoping to launch it soon. I want to get it right — something you can actually use to write quality Flutter code, faster.

Thanks for reading, and happy coding! 🎉

Over the past year, AI coding agents have completely reshaped how we work — from vibe coding, to agentic coding with human review, all the way to fully automated multi-agent orchestration. We're all at different stages of this evolution, and I put this edition together to help you navigate it. 👇

Andrej Karpathy on the State of AI

Andrej Karpathy has been one of the most insightful voices in AI. I featured his 2025 LLM Year in Review in my previous newsletter, and since then he's shared two more posts that are well worth your attention.

📝 "I've never felt this much behind as a programmer"

Earlier this month, Karpathy posted on X that he'd "never felt this much behind as a programmer." The post went viral and resonated deeply across the developer community.

He describes a new "programmable layer of abstraction" involving agents, subagents, prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, and more. In his words:

"Clearly some powerful alien tool was handed around except it comes with no manual and everyone has to figure out how to hold it and operate it, while the resulting magnitude 9 earthquake is rocking the profession."

If even Karpathy feels behind, the rest of us can feel a bit less guilty about struggling to keep up 😅

For a counterpoint, Maximilian Schwarzmüller recorded a reaction video with a reassuring "Relax" message. I think the truth is somewhere in the middle — things are moving fast, but there's no need to panic 🙂

📝 Random notes from Claude coding

Most recently, Karpathy shared a detailed thread with practical observations from weeks of heavy Claude Code usage. This is the most actionable of the two, and I found myself nodding along to many of his points.

Here are the highlights:

• Workflow shift: he went from 80% manual coding to 80% agent coding in just a few weeks. "I really am mostly programming in English now."
• Agent pitfalls: models make wrong assumptions, don't seek clarifications, don't push back when they should, and are "still a little too sycophantic." They'll implement 1,000 lines of bloated code, and when challenged, immediately cut it to 100.
• Agent swarm hype: "too much for right now" — watch models "like a hawk" if you care about your code.
• Tenacity: agents never get tired or demoralized. Watching one struggle for 30 minutes and come out victorious is a "feel the AGI" moment.
• Speedup vs. expansion: the main effect isn't just speed — it's doing things that "wouldn't have been worth coding before."
• Key tip: "Don't tell it what to do, give it success criteria and watch it go." Shift from imperative to declarative.
• Fun factor: programming feels more fun — drudgery removed, creative part remains, less blocked/stuck.
• Atrophy warning: he's already noticing a decline in his ability to write code manually.

His TLDR: "LLM agent capabilities have crossed some kind of threshold of coherence around December 2025 and caused a phase shift in software engineering."

AI Workflows and Tools

So, with the big picture in mind, let's look at what builders are actually doing with these tools.

📝 How the Creator of Claude Code Uses Claude Code

Boris Cherny, the creator of Claude Code, shared his workflow in a viral thread that was covered by VentureBeat, InfoQ, and Fortune.

Here are the key takeaways from his workflow:

• Runs 5 parallel Claude sessions locally, plus 5-10 on claude.ai
• Each session uses its own git checkout (not branches or worktrees)
• Starts in Plan Mode, iterates until the plan is good, then switches to auto-accept mode
• Maintains a CLAUDE.md file per team to document mistakes and best practices (~2.5K tokens)
• Uses PostToolUse hooks for auto-formatting
• Most important tip: "Give Claude a way to verify its work" — tests, browser, simulators

No exotic customization. No clever hacks. He also accepts that 10-20% of sessions simply get abandoned.

For more details, there's even a dedicated site: howborisusesclaudecode.com. Definitely worth a read if you use Claude Code.

📝 Shipping at Inference-Speed

Peter Steinberger, the prominent iOS developer and PSPDFKit founder, takes things even further. His claim: he no longer reads the code his AI agents generate.

Instead, he manages 3-8 simultaneous projects, commits directly to main, and relies on AI agents to iterate and validate. Software development, he argues, is no longer limited by coding ability — but by "inference time and hard thinking."

I always find it fascinating when very experienced devs like Peter claim they no longer read or review the AI generated code on their solo-projects. Yet, many others still advocate that human-in-the-loop is necessary. Who's right? 🤔

This tension — between "ship without reading" and "human validation is essential" — is one of the most interesting debates heading into this year.

AI Agent Orchestration

Beyond single-agent workflows, some developers are pushing into multi-agent territory. Here are two approaches at opposite ends of the spectrum — and both are fascinating.

📝 Gas Town: Multi-Agent Orchestration

Steve Yegge's Gas Town is a Go-based orchestration system that lets you coordinate 20-30 parallel Claude Code agents using tmux. It features 7 distinct worker roles and runs on a git-based work tracking system called Beads.

What I find most useful is Yegge's 8-stage maturity model for AI-assisted coding:

• Stages 1-2: No or minimal AI (autocomplete, sidebar chat)
• Stages 3-5: Single agent with increasing trust and automation
• Stages 6-7: CLI, multi-agent, hand-managed (3-10+ parallel instances)
• Stage 8: Building your own orchestrator

Most of us (myself included) are somewhere between stages 3-6. Gas Town is for stages 7-8. Fair warning: running heavy sessions can cost $100-200/hour in API fees 😅

• Gas Town on GitHub

📝 The Ralph Wiggum Technique: Simple Agent Loops

At the other end of the spectrum, Geoffrey Huntley's Ralph technique is brilliantly simple — just a bash loop that repeatedly feeds Claude a prompt file:

while :; do cat PROMPT.md | claude-code ; done

Each iteration gets fresh context, and memory persists via git history and progress files. The results can be remarkable: a team at a Y Combinator hackathon produced 1,100+ commits across 6 repos overnight for ~$800 in AI costs 🤯

Anthropic later built an official ralph-wiggum plugin, though Matt Pocock argued that the plugin misses the point: a proper Ralph loop gives bash control over the agent, while the plugin inverts this (letting the agent control the loop, leading to context rot). If you're curious, this article argues why the original bash loop might be preferred.

Anthropic's ToS Crackdown

Earlier this month, Anthropic deployed safeguards that blocked Claude Pro/Max subscription tokens from working outside the official Claude Code CLI. Overnight, third-party tools like OpenCode stopped working — with no warning.

Anthropic's rationale: third-party tools had been spoofing the Claude Code client identity, generating unusual traffic without telemetry, and making debugging and support impossible. This violates their Terms of Service.

There's also an economic angle: the $200/month Max plan provides unlimited tokens through Claude Code, while the same usage via API would cost $1,000+. Third-party tools removed the artificial speed limits, enabling overnight autonomous loops.

The community reaction was strong — subscription cancellations, front-page Hacker News discussion, and criticism from prominent developers, including this entertaining take from Primeagen:

Regardless of where you stand, the takeaway is clear: if you rely on Claude's subscription plans, be aware they're scoped to first-party tools only.

This is a good reminder that we should never be too reliant on a single tool or provider. Having alternatives is always a good idea.

OpenCode: Open-Source Alternative

Speaking of alternatives, if the Anthropic crackdown has you looking around, OpenCode is worth knowing about.

OpenCode is an open-source AI coding agent with a terminal UI that supports 75+ LLM providers — Claude, GPT, Gemini, local models, you name it. It's been growing fast: 56K+ GitHub stars and 450+ contributors.

Key features:

• Provider flexibility: swap providers or bring your own API keys — no lock-in
• Privacy-first: no code storage, suitable for regulated environments
• Client/server architecture: enables remote sessions (Docker containers, mobile control)
• LSP support: language-aware editing, multi-session, shareable links

Having briefly tried OpenCode myself, I quite like it, especially as it already supports useful features such as custom slash commands and skills, meaning I can reuse many of the workflows I already built for Claude Code.

Check it out here:

• OpenCode (source on GitHub)
• OpenCode vs. Claude Code comparison

Claude Code Resources

If you're using (or getting started with) Claude Code, here are some of the best resources I came across this month:

• 📝 The Complete Claude Code Tutorial — a viral X thread (4.7M views) by Eyad Khrais. Core message: think before typing. Plan mode outperforms ad-hoc prompting 10 out of 10 times.
• 📝 A Guide to Claude Code 2.0 — a deep technical guide covering Opus 4.5 workflows, sub-agents, MCP servers, and hooks. Interesting note: the author finds GPT-5.2-Codex superior for code review, while Claude excels at code generation.
• 📝 Claude Code in Action — free 21-lesson course from Anthropic (also on Coursera). Covers everything from basics to Hooks and the SDK.
• 📝 Todos → Tasks in Claude Code 2.1 — the latest Claude Code update introduces session-scoped Tasks (replacing Todos) for complex dependency management and parallel sub-agent coordination.

Latest from Code with Andrea

📝 My 2025 in Review: Freefall and a New Direction

At the start of this month, I published my 2025 retrospective. It was an honest look at a challenging year: reduced content output, declining traffic and revenue, and the broader headwinds hitting coding educators everywhere.

But the article is ultimately forward-looking. I'm pivoting Code with Andrea towards agentic AI coding — using tools like Claude Code to build Flutter apps faster and smarter. I won't be teaching traditional Dart/Flutter tutorials anymore, but I'll continue to cover Flutter in this newsletter and focus my content on AI-assisted development workflows.

If you haven't read it yet, I'd love to hear your thoughts:

• My 2025 in Review: Freefall and a New Direction

Until Next Time

This is by far the most AI-heavy newsletter I've ever written. AI coding agents have crossed a threshold, and I find that learning this new abstraction layer is well worth the effort.

My advice? Start small. Try Claude Code or OpenCode on a side project. Give the agent success criteria instead of step-by-step instructions. And review everything it produces — at least for now 🙂

I'd love to hear where you are on the AI coding journey! Let me know on X (Twitter), LinkedIn or BlueSky.

Thanks for reading, and happy coding! 🎉

Meanwhile, the broader AI landscape has seen big leaps in frontier models (Gemini 3, Opus 4.5, GPT-5.2) and agentic coding tools like Claude Code which, while impressive, are still in their early days.

Let's dive into the latest Flutter videos and AI news from the past month.

Flutter Videos

The Flutter team has been pumping out new videos lately. Here are some highlights that caught my attention.

📹 Getting started with GenUI

Flutter now has an official SDK for building AI-generated user interfaces, and it's called GenUI.

The idea: instead of your LLM responding with walls of text, it can populate UI using a catalog of Flutter widgets—dynamic carousels, workout cards, or any custom widget, created on demand.

You define a catalog of widgets with JSON schemas, the AI agent generates "surfaces" (UI chunks), and you render them with GenUiSurface widgets. The video walks through a practical example, including Gemini CLI integration and hot reload support.

There's also a follow-up video that goes deeper into building agent-powered apps:

GenUI is still in alpha, so expect API changes. If you're building regular chat-like experiences, consider the Flutter AI Toolkit instead—it just hit v1.0.0 and offers a more stable set of AI chat widgets.

📹 Strengthening Flutter's core widgets

Earlier this year, the Flutter team decided to decouple the Material and Cupertino libraries from the core framework—and this video explains the why, what, and when.

The tight coupling has been causing issues: design updates lead to breaking changes, third-party design libraries are harder to build, and contributions are harder. The fix? Move design-agnostic logic into the widgets library and eventually publish Material/Cupertino as separate packages on pub.dev.

Here's the roadmap:

• Phase 1 (now): Move common logic into the widgets library; introduce "raw widgets" (e.g., RawRadio) as low-level building blocks
• Phase 2 (2026): Publish Material/Cupertino on pub.dev; deprecate the old libraries
• Phase 3 (late 2026): Remove legacy libraries from the framework

For developers, there's no immediate action required. Eventually, you'll be able to version Material and Cupertino independently from the framework, making migrations more predictable:

📹 Accelerating Dart code generation

If you've ever stared at your terminal waiting for build_runner to finish, you know the pain. Good news: a ground-up rewrite of build_runner's transitive import tracking has landed, and it's fast.

How fast? In one test with 3,000 generated libraries, code generation ran twice as fast. Community feedback confirms similar gains in real-world projects using json_serializable, freezed, built_value, and go_router.

To get the speedup, just upgrade to build_runner 2.10.4+. After that, caching kicks in—changing one library only rebuilds that library, while watch mode (dart run build_runner watch) keeps things snappy as you edit.

The video also previews what's coming: augmentations (inject members directly into classes), part imports (generated parts with their own imports), and primary constructors (declare constructor params right after the class name). Less boilerplate ahead!

AI News

If you've been following the AI space, you know there's always something new. Here are some selected reads. 👇

📝 2025 LLM Year in Review

Karpathy's year-end review identifies six paradigm shifts that defined 2025:

1. RLVR (Reinforcement Learning from Verifiable Rewards): Instead of humans rating outputs, LLMs now learn from automated verification—code that compiles, math that checks out. This is why coding models improved so dramatically.

2. Jagged Intelligence: LLMs are "ghosts," not "animals." They can ace PhD-level physics while failing at basic addition. Understanding this helps set proper expectations.

3. Cursor: The new LLM app layer emerged—AI-native editors that deeply integrate with codebases, not just chat interfaces bolted onto IDEs.

4. Claude Code: AI that lives on your computer, browsing files and running commands autonomously. A shift from "AI as tool" to "AI as teammate."

5. Vibe coding: Programming through natural language. You describe what you want, the AI builds it, and you iterate on vibes rather than syntax.

6. Nano banana: LLM GUIs are evolving beyond chat. Expect more visual, interactive interfaces that feel less like messaging and more like collaboration.

If you're building with AI (or just trying to keep up), this is essential reading:

• 2025 LLM Year in Review

📝 MCP Becomes an Open Standard

Earlier this month, Anthropic donated the Model Context Protocol to the Linux Foundation's new Agentic AI Foundation (AAIF). This is a big deal.

If you're not familiar with MCP, it's the protocol that lets AI tools connect to external systems—databases, APIs, file systems, you name it. What makes this donation significant:

• Co-founded by competitors: Anthropic, OpenAI, and Block, with support from Google, Microsoft, and AWS. When rivals join forces on infrastructure, you know it matters.
• Already widely adopted: 10,000+ active MCP servers, 97M+ monthly SDK downloads, used by Claude, ChatGPT, Gemini, Cursor, VS Code, and GitHub Copilot.
• Solves a real problem: Instead of building separate integrations for each AI tool, you build one MCP server and it works everywhere.

The GitHub blog has a great writeup on what this means for developers. If you're building AI workflows that connect with external data sources, MCP is becoming the infrastructure layer you'll rely on.

🔥 GPT-5.2 is Here

After the recent release of Gemini 3 and Opus 4.5, OpenAI was feeling the heat and decided to respond with GPT-5.2.

Here are the "specs":

• Three variants: Instant (speed), Thinking (complex work), Pro (maximum accuracy)
• 400K token context window with 128K max output tokens
• 38% fewer errors than the previous version
• State-of-the-art on SWE-Bench Pro, the benchmark for software engineering tasks
• Knowledge cutoff: August 2025

The pricing is higher than GPT-5.1, but if you're doing serious coding work, the improved accuracy might be worth it. It's also available in Cursor and GitHub Copilot now.

For all the details, read the official announcement:

• Introducing GPT-5.2

Latest from Code with Andrea

Every week, I read headlines such as this: "Claude CLI deleted my entire home directory"! And it's not just Claude: every AI agent is prone to this kind of security risk, and in my previous newsletter I included a section about understanding Agentic Coding Security Risks.

But talk is cheap! So I decided to figure out how to run my AI agents in isolated environments, and share my solution in public.

Here's what I learned. 👇

📝 How to Safely Run AI Agents Like Cursor and Claude Code Inside a DevContainer

If you've used Claude Code or Cursor, you know the friction: constant permission prompts every time the agent wants to read a file or run a command. It's there for good reason (security!), but it slows things down.

I wrote a guide on using DevContainers to solve this. The idea is to run your AI agent inside an isolated Docker container where it can operate freely without risking your host system.

What you get:

• Use --dangerously-skip-permissions safely (because the container is sandboxed)
• Protection from prompt injection attacks
• Full support for code generation, file modification, Git, and terminal access
• Step-by-step setup for Docker and the Dev Containers extension

Admittedly, this setup is not perfect since you can't use it to run iOS/Android emulators, and visual UI testing needs to be done separately on the host machine.

But when I want to let the agents rip without baby-sitting permissions, this is my go-to solution:

• How to Safely Run AI Agents Like Cursor and Claude Code Inside a DevContainer

After publishing this article, someone suggested creating a separate user account (without admin privileges) on my dev machine, and using that in YOLO mode. For some, this might be a reasonable compromise between security and productivity.

Until Next Time

2025 is nearly over. I've spent much of it honing my AI skills and applying them to my app development work. Admittedly, I haven't shared as much content as I would have liked, largely due to my recent move to Italy (and all the logistics involved).

With that said, I have exciting plans for 2026, and I'll be sharing them with you soon. If time allows, I'll also try to share my 2025 retro in the coming weeks (if you're curious, here's the 2024 edition).

But for now, I wish you a happy festive season, and see you in 2026! 🎉

Happy coding!

Andrea

That's a good thing. These guardrails exist for your safety because AI agents can make mistakes. Another risk is prompt injection attacks, where malicious content tricks the AI into executing harmful commands on your system.

But sometimes you want to hand off a complex task and let Claude Code run autonomously without babysitting every action. Claude Code offers a --dangerously-skip-permissions flag for this, but the name says it all:

Without permission gates, you're one prompt injection away from a compromised system.

The solution? Run Claude Code inside a Docker container. The official security documentation recommends this approach: use DevContainers to create isolated environments where Claude Code can operate freely without risking your host machine.

Why Containers Work

Containers give you both speed and security:

• Isolation: AI agents operate in a sandbox. If something goes wrong, only the container is affected.
• File System Protection: Agents can only access directories you explicitly mount. Personal files, system configs, and sensitive data remain untouched.

What Works Well

• Code generation and modification: Claude can read, write, and modify files
• Terminal commands: Run tests, analyzers, linters, package managers
• Version control: Git operations work normally
• Basic IDE Integration: You can open your project in Cursor/VSCode, navigate the codebase, and edit files.

What Doesn't Work

• Simulators/Emulators: iOS and Android emulators require native platform support (macOS for iOS, more complex setup for Android)
• Visual testing: Can't see app UI running inside the container

In this guide, I'll walk you through setting up a DevContainer for Claude Code with Flutter support. By the end, you'll have a secure sandbox where you can run --dangerously-skip-permissions without the actual danger.

Prerequisites: Install Docker

DevContainers require Docker. Install Docker Desktop for your platform and verify it's running before proceeding:

Step 1: Install the Dev Containers Extension

• VSCode users: Install the Dev Containers and Container Tools extensions.

• Cursor users: Install the "Cursor Dev Containers" extension by Anysphere:

To better understand how containers work, read: Developing inside a Container.

Step 2: Add the DevContainer Configuration

Clone one of these repositories to get the .devcontainer folder:

• Claude Code only: anthropics/claude-code
• Claude Code + Flutter: bizz84/claude-code-flutter-devcontainer

Copy the .devcontainer folder into your project root:

Step 3: Open the Project in the Container

Close and reopen your project. You should see "Reopen in Container":

Click it. The container will build and you'll see "Container Claude Code Sandbox":

Verify the setup: Open a terminal and run pwd. You should see /workspace rather than the project root in your local filesystem:

This confirms your project is mounted inside the container. Any commands executed here affect only the container, not your host machine.

Step 4: Set Up Claude Code in the Container

Run claude in the terminal. You'll see the initial setup process:

That's because the container has its own Claude Code installation and it doesn't share credentials with your host machine. Log in with your Claude subscription or Console account:

Complete the setup steps. You only need to do this once per container. Subsequent runs will go straight to the Claude Code prompt:

Step 5: Run Claude Code Without Permission Prompts

Remember the original goal? We want to safely bypass all permission prompts when running Claude Code.

Run this:

claude --dangerously-skip-permissions

Claude Code will display a warning:

Accept it. Since you're inside a sandboxed container, Claude Code can only affect the mounted project and your host system remains protected.

Step 6: Flutter Support

If you used the Claude Code + Flutter DevContainer, you'll be set with a minimal Flutter setup inside the container.

To test it, you can run flutter doctor, and you should see something like this:

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.38.3, on Debian GNU/Linux 12 (bookworm) 6.10.14-linuxkit, locale en_US.UTF-8)
[✗] Android toolchain - develop for Android devices
    ✗ Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/to/linux-android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, please use
      `flutter config --android-sdk` to update to that location.

[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[✗] Linux toolchain - develop for Linux desktop
    ✗ clang++ is required for Linux development.
      It is likely available from your distribution (e.g.: apt install clang), or can be downloaded from https://releases.llvm.org/
    ...
[✓] Connected device (1 available)
[✓] Network resources

This means that you can run flutter sub-commands such as analyze, test, pub directly from the terminal or via Claude Code. But you can't use flutter run to run the app from the container (more on this below).

Flutter IDE Integration

The Dart and Flutter extensions that were installed in your local machine won't automatically work inside the container.

To fix this, open the extension panel and install them inside the Container.

Additionally, hit CMD+SHIFT+P > Flutter: Change SDK and ensure this points to /opt/flutter:

This ensures you get proper syntax highlighting within the containerized IDE. If this doesn't work right away, hit CMD+SHIFT+P > Dart: Restart Analysis Server.

Running Flutter Apps from the Container?

Unfortunately, you can't use flutter run to run the app from the container, since the provided Dockerfile doesn't install any platform-specific tools like Chrome, Android Studio, or Xcode.

As a workaround, you can open two IDE windows: one for the container and one for your host machine.

• Container: For running AI agents and bypassing permission prompts
• Host machine: For running the app manually and testing the UI

Here's an example showing things side-by-side:

In practice, you'll toggle between the two IDEs as needed, making better use of your screen real estate.

Container vs Host: When to Use Each

Use the Container for:

• Web research on untrusted sources (mitigate prompt injection)
• Long-running autonomous tasks (no constant approval needed)
• New feature development (code generation + file modifications)
• Running MCP servers (which may have security vulnerabilities)
• Parallel execution (useful for benchmarking or testing multiple approaches)
• Installing/updating packages (supply chain attack protection)
• Exploring third-party codebases (unknown code can't affect host)

Use the Host for:

• Testing the UI (needs simulators/emulators)
• Debugging with breakpoints (IDE debugger integration)
• Hot reload during iteration (faster feedback loop)
• Quick, targeted fixes (verify changes immediately)

The pattern that emerges: let AI handle the repetitive, high-volume work while you focus on decisions that require human judgment—UI polish, debugging complex state, and verifying the app behaves correctly.

Bonus: Run Claude Code from a Standalone Terminal

Sometimes you don't need an IDE at all. Maybe you're running Claude Code on a remote VPS, or you just want a lightweight terminal-only workflow for tasks like code generation or refactoring.

You can use the devcontainer CLI to run containers without VS Code or Cursor:

# Install the CLI (once)
npm install -g @devcontainers/cli

# Start the container (only works if the .devcontainer folder is present)
devcontainer up --workspace-folder .

# Run Claude Code inside it
devcontainer exec --workspace-folder . claude --dangerously-skip-permissions

Or start an interactive shell session:

devcontainer exec --workspace-folder . zsh

Example:

This is useful for:

• VPS or cloud servers: Run autonomous AI agents on remote machines
• CI/CD pipelines: Automate code generation or refactoring tasks
• Lightweight workflows: Skip the IDE overhead when you only need the terminal

Bonus: Useful aliases

To make development faster, I have included these useful aliases in a file called .zshrc_dev:

# Aliases for Flutter commands
alias fclean="flutter clean"
alias fpg="flutter pub get"
alias fpu="flutter pub upgrade"

alias brb="dart run build_runner build -d"
alias brw="dart run build_runner watch -d"

alias fpgbrb="fpg && brb"
alias fpgbrw="fpg && brw"

# Aliases for Claude Code
alias c-dsp='claude --dangerously-skip-permissions'

# Custom prompt or other configurations
echo "🚀 Flutter Dev Environment Ready!"

To use these aliases in the container, copy the file to your home directory:

cp .zshrc_dev ~/.zshrc_dev

Then, rebuild and reopen the container, and the file will be loaded automatically.

As a result, you'll be able to run the aliases directly:

fpg # same as flutter pub get
c-dsp # same as claude --dangerously-skip-permissions

Conclusion

You now have a secure setup for running AI agents without permission prompts:

1. DevContainer isolation ensures Claude Code can only access your mounted project
2. --dangerously-skip-permissions lets Claude Code run autonomously
3. Your host machine remains protected from prompt injection attacks

This approach gives you the productivity benefits of autonomous AI agents while maintaining the security boundaries that matter.

More importantly, it changes how you work. Instead of approving every file read and command, you define the task, let Claude Code execute, and review the results. Your role shifts from supervisor to architect—setting direction, evaluating outcomes, and handling the parts that still require human judgment.

Source Code and Support for Other Agentic IDEs and Tools

You can find my custom .devcontainer files on GitHub:

• bizz84/claude-code-flutter-devcontainer

This enables Dev Containers on Cursor, VSCode and Claude Code within the built-in terminal.

If you'd like to add support for Codex and Gemini, feel free to open a PR. 🙂

Note: Antigravity uses the Open VSX marketplace, which doesn't have a Dev Containers extension. If you figure out how to use Dev Containers with Antigravity, please let me know! Meanwhile, you should probably stay away from it. 😱

Happy coding!

Resources

• Claude Code Security Documentation
• Claude Code + Flutter DevContainer
• VSCode DevContainers Guide
• How GitHub’s agentic security principles make our AI agents as secure as possible
• Switching to Claude Code + VSCode inside Docker

On the Flutter side, we got Flutter 3.38 with Dart 3.10, bringing dot shorthand syntax, 16KB Android page size support, and full iOS 26 compatibility.

But the bigger story this month is what I'm calling "The AI Coding Wars." Google launched Gemini 3 alongside their new Antigravity IDE (a free, agent-first development platform), while Anthropic countered with Claude Opus 4.5 (the most capable coding model yet).

Let's dive in! 👇

Flutter 3.38 & Dart 3.10

Flutter 3.38 dropped earlier this month, bringing Dart 3.10 along with it. This is a significant release that includes some breaking changes you'll need to know about.

If you're maintaining a Flutter app in production, the Android 16KB requirement and Java 17 migration are two things that need your immediate attention. But there's also some great stuff here, like the dot shorthand syntax finally being enabled by default! 🎉

Here are the highlights:

Dart 3.10 Language Features:

• Dot shorthand syntax is now enabled by default. You can write .value instead of SomeEnum.value, making your code more concise and readable (similar to Swift's syntax)
• Build hooks are now stable, making it easier to integrate native code (C++, Rust, Swift) without platform-specific build files
• New analyzer plugin system for writing custom static analysis rules

Flutter 3.38 Updates:

• Android 16KB page size support - This is now required for Google Play. If you haven't updated yet, you need to do this now
• Full iOS 26, Xcode 26, and macOS 26 support with UIScene lifecycle migration
• Java 17 is now required for Android development (Gradle 8.14 minimum)
• Fixed a major memory leak that affected all Flutter Android apps since version 3.29.0 (finally! 🙌)
• Web dev config file support for better team consistency
• DevTools improvements addressing top user pain points
• New Gemini CLI Extension and MCP support for AI integration

Read the full announcements here:

• What's New in Flutter 3.38
• Announcing Dart 3.10
• Meet the Flutter Extension for Gemini CLI

There's also an official announcement video if you prefer video content.

The AI Coding Wars

November marked a major escalation in AI-powered development tools. Google, Anthropic, and OpenAI made huge announcements within days of each other, and the competition is intensifying fast.

📝 Google Gemini 3

Last week, Google announced Gemini 3, their most capable AI model family yet. This is a massive release that topped the LMArena Leaderboard with a 1492 Elo score.

Here's what stood out to me:

• PhD-level reasoning: 37.5% on Humanity's Last Exam, 91.9% on GPQA Diamond
• 1M+ token context window with multimodal understanding (text, images, video, audio, PDFs)
• Generative UI - can create entire interactive experiences, not just text responses
• Gemini Agent for multi-step tasks with Calendar and Gmail integration
• Google claims it's their "best vibe coding model ever" (yes, they actually said that 😅)

The launch was coordinated across Google Search, Gemini App, AI Studio, Vertex AI, Gemini CLI, and their new Antigravity IDE.

📝 Google Antigravity IDE

Alongside Gemini 3, Google launched Antigravity, a new IDE forked from VS Code (yes, another one 😄). It's free in public preview and available for Mac, Windows, and Linux.

What makes Antigravity different:

• Agent-first architecture - agents autonomously plan, execute, and verify tasks
• Agents have dedicated access to Code Editor, Terminal, and Browser
• Knowledge base system for agents to save and learn from context
• Supports Gemini 3 Pro, Claude Sonnet 4.5, and GPT models
• Built by the ex-Windsurf team (Google acquired them for $2.4B in July)

If you want a hands-on perspective, check out this video:

📝 Claude Opus 4.5

Not to be outdone, Anthropic announced Claude Opus 4.5 just days after Gemini 3. They're billing it as "the best model in the world for coding, agents, and computer use."

The numbers are impressive:

• State-of-the-art on SWE-bench Verified (real-world software engineering tasks)
• Leads on 7 of 8 programming languages in multilingual benchmarks
• 15% improvement over Sonnet 4.5 on Terminal Bench for long-horizon tasks
• Uses 76% fewer output tokens than Sonnet 4.5 while matching performance (this means huge cost savings 💰)
• New "effort parameter" for balancing capability vs speed/cost
• Pricing: $5/$25 per million tokens (input/output)

For those of us using Claude Code daily, this is a big deal. The efficiency improvements mean we can tackle more complex agentic coding tasks without burning through credits as fast.

My take: Frontier models are getting extremely good, but we can only unlock their value by creating truly agentic workflows, and that is a whole skill in itself. Thanks to subagents, skills, MCP servers, and custom slash commands, Claude Code still has a big lead against other agentic coding CLIs, and it's very unlikely I'll switch over unless the competition catches up.

📝 GPT 5.1 & Codex

OpenAI also joined the party with GPT-5.1, the latest in their GPT-5 series. The model dynamically adapts how much time it spends "thinking" based on task complexity, making it faster and more token-efficient for simpler tasks.

But the bigger news for developers is the Codex family:

• GPT-5.1-Codex and GPT-5.1-Codex-Mini - optimized for long-running, agentic coding tasks
• GPT-5.1-Codex-Max - the flagship model that can work independently for 24+ hours on a single task

Codex-Max introduces "compaction" - the ability to work coherently across millions of tokens, enabling project-scale refactors and deep debugging sessions. On SWE-Bench Verified, it scored 77.9%.

For GitHub Copilot users, the full GPT-5.1 suite is now available in public preview for Pro, Pro+, Business, and Enterprise plans.

⚠️ Understanding Agentic Coding Security Risks

With all these new agentic coding tools, it's worth understanding the security risks they introduce. Shortly after Antigravity's launch, security researchers discovered serious vulnerabilities that highlight broader concerns with agent-first approaches:

• Data exfiltration via prompt injection: Attackers can hide malicious instructions in 1-point font on webpages, forcing the AI to bypass file protections and exfiltrate secrets
• Bypassing .gitignore: AI agents can use system commands to access files that should be protected

These aren't just Antigravity problems—they're challenges any agentic coding tool must address. GitHub published an excellent breakdown of their agentic security principles, identifying three main threat categories:

1. Data Exfiltration - Agents with internet access could leak sensitive data, including credentials
2. Impersonation & Attribution - Unclear accountability for agent actions
3. Prompt Injection - Malicious instructions hidden in repositories or web pages

Their recommended safeguards include network firewalling, limited data access, reversibility requirements (PRs instead of direct commits), and clear action attribution.

My take: As AI tools gain more autonomy, security becomes critical. At minimum, consider using a sandboxed development container for agentic workflows, as explained here. And always review what permissions you're granting these tools.

The Counter-Argument to AI Coding

With all the AI hype this month, I think it's important to acknowledge the other side of the story. Not everyone is having a great time with AI coding tools, and their concerns are valid.

📹 AI Coding Sucks

Earlier this month, CJ posted a viral rant titled "AI Coding Sucks" that struck a note across developer communities.

The main criticisms:

• Lost joy of programming - Endless back-and-forth with unpredictable LLMs that take shortcuts
• Code quality concerns - AI-generated code can be hard to maintain and understand
• The "skill issue" narrative - Evangelists dismissing legitimate concerns as user error

Matt Pocock, a prominent TypeScript educator, had a thoughtful response, pointing out that careful planning and context management can prevent many of the issues with AI coding.

Latest from Code with Andrea

Following the "AI Coding Sucks" debate, I've been thinking a lot about one fundamental question: when should you write code yourself, and when should you use AI?

📹 When to Code, When to Prompt? My 2x2 Decision Matrix

The result is this video, aiming to help you decide between AI assistance and manual coding for different Flutter development tasks:

The decision matrix is based on comparing prompting effort vs coding effort:

• Low prompting/High coding effort → Use AI (boilerplate, tests, refactors)
• High prompting/Low coding effort → Code manually (visual issues, tiny fixes)
• Low/Low → Either approach works (simple tweaks)
• High/High → Collaborative AI approach (complex features, full-stack)

The core principle is simple: compare prompting effort against coding effort. AI offers speed and knowledge, but "accuracy is not guaranteed"—so you need to factor in the cost of reviewing and fixing AI-generated code.

🔥 Black Friday Sale 2025

Speaking of AI and productivity... if you've been thinking about leveling up your Flutter skills, now's the time. I'm running my annual Black Friday sale:

• 50% off Flutter in Production course
• $100 off the 5x Flutter Course Bundle

These are the best prices you'll see for a while. The sale is live now, so don't wait too long!

Until Next Time

November was a big month for both Flutter and AI development tools. Flutter 3.38 brings some important updates (especially for Android and iOS compatibility), while the AI landscape is evolving faster than ever.

The competition between Google (Gemini 3 + Antigravity), Anthropic (Claude Opus 4.5 + Claude Code), and OpenAI (GPT 5.1 + Codex) is really heating up, and honestly, I think this innovation unlocks more value and increasingly advanced agentic workflows for all of us.

As always, remember that AI is a mutliplier that amplifies both your skills and your mistakes. So, learn to use it well, and don't feel like you need to go all-in. Sometimes the old-fashioned way of writing code manually is still the right call.

What's your take on the AI coding wars? What's your favorite AI coding tool? Let me know on X (Twitter), LinkedIn or BlueSky.

Thanks for reading, and happy coding! 🎉

This video offers a balanced perspective on "When to Code vs. Prompt with AI" and introduces a practical decision matrix to guide your development workflow.

Intro

AI agents are excellent for prototyping, ideation, and boilerplate tasks. But you also know the frustration: AI frequently gets stuck or misunderstands, forcing you to take over and write code manually. While some might dismiss this as a "skill issue," the reality is that AI isn't infallible, and you shouldn't force an AI workflow in every scenario.

So, how do you decide between prompting with AI and traditional coding? This video provides a balanced perspective and a decision matrix to help you choose the right approach. Ultimately, this decision boils down to a simple question: "Which is greater? Your prompting effort, or your coding effort?" The answer, as you'll see, varies significantly by task.

Common Flutter Tasks

Consider this list of common tasks you might encounter during Flutter app development:

• Complex charting solutions
• Text rendering issues
• Boilerplate (crash reporting, analytics...)
• Full-stack features
• Small UI/animation tweaks
• Pull to refresh
• IAP + entitlements
• Writing tests
• Dense business logic
• Simple refactors
• Background tasks + iOS/Android specific
• Localization
• Theming system
• Big refactors
• Offline caching + syncing
• Codegen
• Layout errors
• One-line bug fixes

The Prompt vs. Coding Effort Matrix

This 2x2 matrix shows which tasks fall in which quadrants depending on their coding vs prompting effort:

Low Prompting Effort, High Coding Effort

This quadrant contains tasks that require minimal prompting but generate a significant amount of code. AI excels here because these tasks often involve pattern recognition and repetition or filling in the blanks. Examples include:

• Boilerplate code: For features like crash reporting or analytics setup.
• Writing tests: AI can effectively analyze existing code and generate comprehensive test cases, covering various edge cases.
• Localization: AI can identify hard-coded strings in the UI and generate correct ARB files for multiple languages, streamlining the setup.
• Theming systems: AI can plan and implement a robust theming system, for instance, by refactoring hard-coded colors and text styles into a consistent theme.
• Big refactors: Large-scale code rearrangements that follow clear patterns.

These tasks are not intrinsically hard but are code-intensive, making them ideal for AI to handle.

High Prompting Effort, Low Coding Effort

This quadrant describes tasks that demand very specific and detailed prompting to get the desired result, but ultimately produce minimal code. In these scenarios, direct coding is often more efficient. Examples include:

• Text rendering issues: Fixing wrapping, ellipsis, or font rendering quirks requires precise explanations of visual problems.
• Layout errors: Issues like overflows or unbounded heights need visual descriptions, screenshots, and desired behavior specified, often for a single-line fix (e.g., wrapping a widget in Expanded).
• One-line bug fixes: Such as adding a missing notifyListeners() call.
• Dense business logic: Algorithms like binary search, while short in code (less than 20 lines), require verbose and precise natural language prompts to describe, often making the prompt less clear than the code itself.

Note the inherent ambiguity of natural language and the fidelity gap that can arise when AI attempts to make precise visual UI changes. If you already understand how to solve the problem, directly editing the code saves time and avoids iterative prompt refinement.

Low Prompting Effort, Low Coding Effort

These tasks are straightforward to describe with minimal prompting and result in a small amount of code. Examples include:

• Small UI/animation tweaks: Adjusting an animation curve or duration.
• Adding pull-to-refresh: Wrapping a ListView with a RefreshIndicator and an onRefresh callback.
• Simple refactors: Minor code adjustments you can do quickly.

For problems you're already familiar with, relying on your own muscle memory is often faster than context-switching to AI, writing a prompt, and waiting. Furthermore, you'll likely trust your own code more.

I also place codegen in this quadrant. While tools like build_runner might generate a lot of code, your human input is minimal (e.g., adding a new property to a data model), and you trust the output because it's a deterministic process.

High Prompting Effort, High Coding Effort

This quadrant encompasses tasks that are significantly complex in terms of specification, planning, implementation, and verification. Working with AI here is rarely a "one-shot" prompt, but rather an iterative and conversational process. Examples include:

• Offline caching and syncing.
• Full-stack features.
• Background tasks with platform-specific (iOS/Android) code.
• Complex charting solutions.
• In-app purchases and entitlements.

To succeed with AI on these tasks, several critical steps are needed:

• Detailed and specific requirements: This is the cost of providing context to AI, and it requires your significant domain expertise. Without it, AI is likely to miss details and go down the wrong path.
• Break down complex problems: Decompose the main problem into smaller, manageable sub-problems that AI can tackle individually.
• Ensure maintainability: Follow project standards and conventions.
• Thorough verification: This is often the most complex part. Debugging AI-generated code can be particularly challenging because you didn't write it yourself, and AI might have introduced subtle errors.

These tasks have a high cost of failure. Careful human oversight and robust guardrails are essential, even with AI assistance.

Summary

Before coding with AI, always consider whether your prompting effort or coding effort will be greater. The answer is task-dependent.

Additionally, consider your cognitive load. A short prompt might still require significant mental effort to formulate. A one-line code change in an unfamiliar system can also be cognitively demanding, where AI can assist you in understanding.

Agentic AI vs. Autocomplete

Your choice of tool also depends on the amount of code you need:

• For a few lines of code, autocomplete and IDE assists are more surgical and efficient.
• For a lot of code or big changes, agentic AI workflows make more sense. AI can handle heavy lifting (planning, implementation), while you focus on providing good specifications and verifying results.

This mindset is crucial for AI coding in 2025. As AI tools improve, the "high prompting" effort for complex problems will likely decrease, causing the quadrants to shift. What's "high prompt, high code" today might become "low prompt, high code" tomorrow. While AI offers incredible knowledge and speed, accuracy is not guaranteed.

Your human insights, muscle memory, and direct debugging skills remain indispensable. An important skill in this new era is knowing when to code and when to prompt, being selective between full agentic AI mode and autocomplete mode to achieve results more quickly and without frustration.

Happy coding!

Just like always, I'm excited to share a mix of Flutter and AI-related updates, along with the latest from Code with Andrea.

Let’s dive in! 🚀

Flutter Updates

These updates cover the latest from the official Flutter channel, the recent WASM 3.0 release, and I've also included all the FlutterCon EU 2025 videos for you to catch up on.

📺 Flutter & Figma MCP | Observable Flutter #70

It's been a little while since I've shared an Observable Flutter video, but this one is fantastic! Craig Labenz hosts Muhammad Hamza, the creator of a new MCP server that converts Figma components directly into Flutter widgets.

In this video, Muhammad explains:

• how the Figma MCP server works its magic
• how you can import typography, colors, and custom buttons into code for your Flutter apps
• how to handle images and SVGs, which often require a bit of special attention.

He then goes on to show how to generate entire screens (like login and profile pages) from Figma, and even discusses responsive design support and other exciting upcoming features for the MCP server.

If you're tired of manually creating Flutter widgets from Figma, this tool could be a huge time-saver!

📺 The great thread merge

If you haven't heard about the Platform & UI threads merge yet (it was first enabled in Flutter 3.32), this video will get you up to speed.

Inside, Craig Labenz breaks down the roles of the UI, Raster, and Platform threads, and explains the reasoning behind the merge. This merge makes it possible to call into native code from Dart synchronously (using ffi), which leads to a much smoother development experience.

📝 Integrating Swift Foundation Models in Flutter Apps with Pigeon

As part of the iOS 26 SDK, Apple released the Foundation Models framework, which lets you use on-device LLMs in your apps.

But how do you call these new APIs from Flutter? The answer is Pigeon! In this tutorial, Pranav Masekar shows you how to build a simple chat app as a proof of concept:

• Integrating Swift Foundation Models in Flutter Apps with Pigeon

📝 Wasm 3.0 is here

I've been following WASM support in Flutter web with great interest ever since it was first announced back in 2023.

So, I was thrilled to hear that Wasm 3.0 has arrived! It's a significant step forward, bringing exciting features like:

• 64-bit address space
• Garbage collection
• Typed references
• Tail calls
• Exception handling

Many of these features are now supported across all major browsers, and I'm really looking forward to seeing what performance improvements this will bring to Flutter web apps.

• Wasm 3.0 Completed

🎥 FlutterCon EU 2025 Videos

I didn't get a chance to attend FlutterCon this year, so I'm super happy to see that the videos have now been published on YouTube!

Just like in previous years, some of the top Flutter developers delivered fantastic talks (including some advanced topics), and I'm sure you'll find plenty of useful insights.

Here's the full playlist:

• FlutterCon EU 2025 Videos

AI News

Despite some growing AI-bubble fears, the rollercoaster keeps going, and new tools and updates are popping up every single day. Sonnet 4.5 recently launched, while OpenAI released Sora 2 and a new web browser (though I wouldn't trust it to be secure or private 😱).

But what's most relevant for us developers? Here's my top pick from this month. 👇

🎧 Andrej Karpathy — AGI is still a decade away

Every time Andrej Karpathy speaks publicly, I'm always so impressed by his insights. So, I couldn't miss this new podcast with Dwarkesh Patel, where he shares his thoughts on the evolution of AI and why he believes AGI is still a ways off.

He also discusses recent trends in agentic AI and the three current ways of writing code:

1. From scratch (he no longer recommends this).
2. Autocomplete with Cursor.
3. Agentic: You prompt, and then let the LLM do the work.

Interestingly, Andrej often finds himself using autocomplete as the most optimal balance between speed and control, rather than trying to use agents that tend to perform poorly when writing innovative and "intellect-intensive" code.

The podcast is almost 2 hours and 30 minutes long, but I highly recommend it (a full transcript is also available):

• Andrej Karpathy — AGI is still a decade away

Latest from Code with Andrea

Over the last month, I've started working on a new currency converter app, and I've also published a new video. 👇

📺 Beyond Prompts: My 3-Folder System for Effective AI Coding in Flutter

The more I work with AI, the more I realize how crucial it is to have a structured workflow and clear guidelines to shape its output.

After many successes and failures, I've settled on a 3-folder system that helps me:

• Stay organized and follow a consistent workflow.
• Make it much easier for AI to follow my guidelines.
• Reduce a lot of friction by letting me reuse battle-tested patterns, commands, and prompts.

And in this video, I cover all the details:

Until Next Time

Over the next few weeks, I'll be ramping up my YouTube content with both long-form and short-form videos, sharing my experiences with AI coding. So stay tuned for more updates!

Happy coding! 🎉

• ai_toolkit: My collection of LLM-friendly commands and patterns.
• ai_specs: My prompts and plans for ongoing work.
• ai_docs: My persistent knowledge base for AI agents.

In the video above, I break down exactly what these folders are, how they fit into my AI-assisted workflow, and how you can make the most of them in your AI coding sessions.

You see, in the last few months, I've been leaning heavily into AI agents like Claude code and Codex. These powerful tools are creating a fundamental shift in how we develop software. It's less about directly writing every line of code ourselves, and more about orchestrating AI, providing precise context, and carefully verifying its output. To get the most out of them, we need to rethink our entire workflow.

But here's the thing: even with powerful AI, they won't produce consistently good results unless you give them the right context.

In fact, it's fair to say that the results you get are only as good as your prompts.

So how can you, as an engineer, learn to use AI to its full potential and leverage this context effectively? That's precisely what these 3 essential folders help you do in your Flutter apps.

AI Toolkit: Standardizing AI Interactions

First up is the ai_toolkit folder. This is essentially where I keep all my LLM-friendly commands and patterns specifically tailored for Flutter development. I created this because setting up new projects takes time, boilerplates can be too opinionated, and AI agents, while smart, have a high failure rate without proper guardrails.

Thanks to this toolkit, I can do some really cool things:

• I can prime my AI agents with relevant breaking changes in Dart and Flutter, so they don't generate outdated code.
• I can quickly run commands I use often.
• It helps me enforce consistent project guidelines and code style across all my coding sessions, no matter which AI I'm using.
• And it lets me quickly scaffold new projects with components and functions in a standardized way.

In practice, I "seed context" into my AI sessions using custom commands from this toolkit. This removes ambiguity, making sure the AI follows my specific code patterns and style. If AI ever misses the mark, I can just add a new guideline to my toolkit and include it in the context. This ensures consistent, higher-quality code. Plus, I've created variants that work across different AI agents, and I include commands for things like conventional commits, planning out features, and even letting the AI know about my local shell aliases to reduce friction.

Ultimately, the ai_toolkit is all about giving AI the right context and removing friction. I use it as a submodule across my projects, which helps accelerate onboarding, enforces code consistency, and reduces my cognitive load by letting AI handle repetitive decisions. It's a personal tool for now, but I might make it available later!

AI Specs: Structured Planning and Execution

Next, we have the ai_specs folder. The main idea here is that while agentic AI can plan, build, and verify, the results are still only as good as my prompts. So, I need guardrails to keep AI agents on track. This folder helps me keep track of all the prompts and plans I use for agentic coding, ensuring I follow a consistent workflow.

My workflow typically involves:

1. Creating a requirements file: This markdown file outlines everything needed for a feature, bug fix, or refactor – it's the "thinking" part.
2. Generating a plan: I feed this requirements file to my AI agent, asking it to make a detailed plan. I'll iterate on this plan until I'm happy, then save it as a markdown file right here in ai_specs.
3. Implementing the plan: I then have the AI implement the plan, ideally one stage at a time, so I can easily review and course-correct.
4. Verification: I let the AI run tests to ensure they're green, and I also manually test the app myself.

This process is highly iterative, and things don't always go perfectly. I might discover missing requirements, overly complex implementations, or code duplication. The key is to set a high bar for quality. Since producing code with AI is "cheap," I can afford to iterate, correct course, or even restart to ensure the app is maintainable long-term.

Once everything is complete, tests are green, and the app works, I push changes to GitHub. A neat trick is to instruct the AI to include the completed plan as the Pull Request description. The ai_specs folder then becomes a historical record of all my prompts and plans, almost like a local copy of my GitHub issues and PRs.

AI Docs: Persistent Project Knowledge

Finally, let's talk about the ai_docs folder. Think of this as a persistent knowledge base specifically for your AI agents. It's a great place for storing crucial information that AI needs but might not find directly in the code or ai_toolkit.

This includes things like:

• API documentation and integrations.
• Architecture and design documents.
• Hidden non-code business logic (important rules the AI needs to know).
• Project-specific patterns that might be unique to this project, even if they differ from the general toolkit.

I use this folder in my projects to outline API specifications and UI functionality. As a project grows, I keep this folder updated with all the critical information my AI agents need. For older projects, I've even used AI to help generate this documentation, feeding these documents to the AI when starting a new session so it can understand the project's architecture and generate more consistent code.

Why These Folders Matter

So, to summarize, I use these three essential folders in my Flutter development workflow:

• ai_toolkit: My collection of LLM-friendly commands and patterns.
• ai_specs: My prompts and plans for ongoing work.
• ai_docs: My persistent knowledge base for AI agents.

The main difference is that ai_docs holds knowledge that evolves over time, like living documentation, while ai_specs is more of a historical record of specific tasks, which might become outdated.

Overall, these folders are incredibly helpful because they:

• Help me stay organized and follow a consistent workflow.
• Make it much easier for AI to follow my guidelines and stay on track.
• Reduce a lot of friction by letting me reuse battle-tested patterns, commands, and prompts.

I really encourage you to create your own similar folders. Just think about repetitive tasks or situations where AI gets it wrong, and then write your own guidelines to steer it. While there's an upfront time investment, it absolutely pays off in the long run, leading to faster development, fewer bugs, and more consistent quality.

By the way, in this video, I haven't even touched on advanced topics like MCP servers or sub-agents. Honestly, I feel like I'm just scratching the surface of what's possible with AI agents. But as I keep exploring and learning, I'll be sharing more videos.

Happy coding!

• Riverpod 3.0
• The ultimate guide to migrating to Flutter
• Liquid Glass: what it means for you
• AI rules for Flutter and Dart
• Latest from the Flutter community
• Best AI Coding Agents and my takeaways

Let's dive in!

Riverpod 3.0 is here

The long-awaited Riverpod 3.0 has landed!

This new release brings experimental support for offline persistence and mutations, plus quality-of-life improvements like automatic retry, Ref.mounted, generics support, new testing utilities, and more.

Get a full summary of the changes here:

• What's new in Riverpod 3.0

But what about migrating from Riverpod 2.x? After updating some of my own apps, I found some easy changes (like replacing .valueOrNull with .value). But I also hit unexpected bugs, such as this one.

While the official docs cover migrating from 2.0 to 3.0, it might be wise to hold off until the initial bugs are ironed out.

Migration to Flutter: The Ultimate Guide

Flutter has a strong value proposition: high-quality, multi‑platform apps from a single codebase. But for enterprises with legacy codebases, the path to migration is rarely simple or certain.

This guide by LeanCode is a practical, battle‑tested playbook for navigating that complexity, born from real-world transformations at Virgin Money, Crédit Agricole Bank Polska, Sonova, NOS, and other large-scale programs.

I did get early access to the guide, and I highly recommend it. You can get your copy here:

• Migration to Flutter

Liquid Glass is here: what it means for you

Apple's latest device lineup is out, bringing iOS 26 and its new Liquid Glass UI.

But what does this mean for us Flutter developers? And how hard will it be to update our iOS apps to Liquid Glass?

According to this GitHub issue, official work on the iOS 26 UI will only begin after the core Material and Cupertino libraries are moved outside the Flutter SDK.

Meanwhile, the Serverpod team had an idea: leverage Platform Views and method channels to bring pixel-perfect Liquid Glass UI to Flutter on iOS.

The result is a new package called cupertino_native, which works well and is very performant (note: this was vibe-coded with Codex and GPT-5, so it's not ready for production yet).

AI rules for Flutter and Dart

When building with AI, clear rules and guidelines are crucial for enforcing best practices in code style and design.

Good news: the Flutter team has released an official set of AI rules for Flutter and Dart. This includes a rules.md template that you can feed directly to your AI model.

Find all the usage instructions here:

• AI rules for Flutter and Dart

Just like you'd start with a default set of lint rules for your projects, you can view this as a "sensible defaults" template for Flutter AI coding, which can be further customized to your own project needs.

Latest from the Flutter community

As I write this, FlutterCon EU is taking place in Berlin. I couldn't make it this year, but I'm keen to catch up on the session videos once they're available.

The Flutter community has also been active on r/FlutterDev and the official Flutter forum. Beyond the usual Google Play Store complaints, some cool posts can also be found, like this one: 👇

📱 Flutter vs Web Wrappers

Can you spot a web wrapper masquerading as a native mobile app? Common giveaways include slow loading screens, sluggish UX, and poor offline support.

Take the HomeDepot app, for instance – it's a web wrapper for their official site. While browsing r/FlutterDev, I found this post a developer who rebuilt it in Flutter. They then shared this cool video showing the two apps side-by-side. What a difference! 💪

Check out the full post:

• HomeDepot app sucks, so I made a new one (not affiliated with Home Depot)

Latest AI News

The past month in AI has been wild! Here's my rundown of the most relevant news.

🤖 Best AI Coding Agents with some crazy upsets

We've seen new, high-performant coding LLMs emerge, including GPT-5-codex, Qwen3 Coder, and Grok Code Fast 1.

The AI coding tool landscape is also expanding, with Codex, Qwen code, Roocode, and Claude code router (which enables selecting different models under the same Claude Code CLI), among many others.

So, which ones should you use for AI-assisted coding? This video offers an excellent summary, complete with benchmarks from real-world evaluations:

Here are some key takeaways, complemented with observations from my own experience:

• The gap at the top is narrowing; Claude Code is no longer the only game in town.
• Model choice matters a lot. It's crucial to balance speed, cost, and output quality.
• If you want to get good results consistently, prompting and context engineering remain as important as ever.

Model selection also hinges on another critical factor: reliability. 👇

⚠️ AI Service Issues

While leading AI companies battle for model and tool supremacy, they've also been experiencing significant service issues, as confirmed by the OpenAI status and Claude status pages.

Anthropic's situation has been particularly problematic, leading them to share this recent postmortem:

• A postmortem of three recent issues

This is the current reality: models are improving, demand is soaring, and AI companies are struggling to guarantee high uptime. Many users on monthly subscriptions have already switched vendors, and I expect this trend to continue.

While uptime guarantees may be less concerning during development, they're absolutely critical when AI is built into production systems (think automotive or medical applications). It will be interesting to see how companies will account for and mitigate downtime.

Until Next Time

Having recently moved countries, some things are taking longer than expected, so I'm not yet back at full speed.

That said, I've started some new projects, which are proving to be a great way to experiment with the latest AI tools.

Despite their unreliability, I'm using these tools for increasingly complex tasks, including planning, refactoring, test generation, and more.

Keep an eye on my YouTube channel; I'll be sharing some agentic AI coding videos soon!

Happy coding!

You can use absolute imports for reusable Dart files that are copy-pasted across projects.

This way, they are always imported correctly (as long as they live in the same location relative to the project root).

Happy coding!

Some Matrix4 APIs such as translate and scale have been deprecated in the latest Flutter 3.35 release.

To update them:

• Import vector_math explicitly
• Use the new APIs which take a Vector3 argument

Happy coding!

Flutter 3.35 & Dart 3.9 Highlights

Flutter 3.35 brings two long-awaited features:

• Stateful hot reload on the web: First introduced in Flutter 3.32, now available as a stable release.
• Experimental Widget Previews: This allows you to see your widgets render in real-time, separate from a full app, in your Chrome browser.

I initially doubted the utility of a Flutter Widget Previewer, but after using it, I can see its value, especially for applications with many custom and reusable UI widgets. Check out this guide to get started.

Beyond these, the release includes:

• More control and polish in the Material and Cupertino libraries
• Various framework, engine, and DevTools improvements

Dart 3.9 also ships alongside Flutter 3.35, though it's a fairly minor update.

For the complete breakdown:

• What’s new in Flutter 3.35
• Announcing Dart 3.9

But hold on, there's more!

🤖 Dart and Flutter MCP server

The Flutter MCP (model context protocol) server is now stable and helps AI agents to better understand your code context and perform actions, such as:

• Analyze and fix code errors
• Resolve symbols, fetch documentation, and signature info
• Introspect and interact with you running app
• Search pub.dev for packages
• Manage pubspec.yaml dependencies
• Run tests and analyze the results
• Format code with the same formatter and config as dart format

To learn how to set it up with popular AI tools, read the official guide:

• Dart and Flutter MCP server

Tools like Claude Code already perform some of the tasks above without extra setup. Now that the Flutter MCP server is stable, I'll do some experiments with and without it, compare the differences, and share my findings.

🎨 Decoupling Design in Flutter

The Flutter team is embarking on a significant architectural change: moving the material and cupertino libraries out of the core Flutter SDK into standalone packages. This will make the framework lighter, more flexible, and allow for faster iteration on design libraries.

What does this mean for you?

• Faster Updates: Critical bug fixes and design updates for Material and Cupertino will no longer be tied to Flutter's quarterly stable release cycle, reaching developers much faster.
• More Control & Flexibility: Developers gain finer control over their design system versions and a leaner, un-opinionated core framework for custom UIs, fostering a more diverse Flutter ecosystem.

This is a substantial undertaking, with the transition expected to complete in 2026. You can track the progress and learn more about the rationale in these resources:

• Decoupling Design in Flutter (Full Proposal)
• Decoupling Design GitHub Project Board

🧱 Featured Packages

If your app does some form of audio recording or playback, you might want to check out the record and flutter_soloud packages, which were recently featured in the Package of the Week playlist:

Latest AI News

LLMs and AI tools continue to evolve rapidly. A few weeks ago, both GPT-5 and Claude Opus 4.1 were released, claiming the top spots in popular benchmarks and leaderboards like WebDev Arena.

But let's not get carried away by the hype: GPT-5 still managed to fail on a kindergarten worksheet, and Steve Yegge's recent attempt to use Claude in production ended with catastrophic results.

Moreover, a recent MIT report pointed out that 95% of generative AI pilots at companies are failing, and another study found that experienced open-source developers took 19% longer to complete various tasks when using AI tools (note: the developers in the study used Cursor Pro with Sonnet 3.5/3.7, which is no longer a frontier model).

So, what does this all mean for you?

• Benchmarks don't tell the real story: Real world usage is what really matters, and there isn't a single tool or LLM that works best for all use cases (even Andrey Karpathy said so in this recent and insightful post).
• AI tools can't be trusted: Make sure you remain in control and put guardrails in place.

My takeaway is that AI tools can still unlock big productivity gains. I've experienced this firsthand, but not before spending a fair chunk of time learning how to extract value from them (and to be honest, I still have a lot to learn and share).

Until Next Time

I've been a bit quiet recently as I was busy moving back to my home country 🇮🇹. Now that (almost) everything is settled, I look forward to getting back to work, and sharing my journey with Flutter, AI, and more!

So stay tuned and keep an eye out on my YouTube, socials, and this newsletter.

Happy coding!

Much has changed since then, and while I was collecting links for this edition, I realized most of my bookmarks from this month were about AI, rather than Flutter.

Indeed, agentic AI tools have been dramatically changing my development workflow (in a good way), and the overall trend is too hard to ignore by now.

So, in this edition, I decided to include some relevant AI-related content that will help you expand your knowledge and stay up to date.

But before that, we need to talk about Apple Liquid Glass! 😅

Apple Liquid Glass

Apple announced all their latest software and developer SDK updates at WWDC 2025. Their keynote was focused on Liquid Glass, a visual refresh of their design system, based on a glass-like UI.

Initial reactions were mixed, with some people praising the new design system, while others criticized it for its poor contrast and accessibility (which was much improved in the second beta).

But what does this mean for us as Flutter developers?

Since Flutter draws every pixel (no native UI), apps using the existing Cupertino widgets risk appearing visually outdated on the upcoming iOS 26 release.

This triggered a new wave of "Flutter is dead" and "Flutter can't do this" comments, which were quickly followed by open source demos (such as this and this) showing how to achieve a very similar effect using shaders:

The whole conversation is very much in flux, and this umbrella issue was created to track Liquid Glass support in Flutter:

• Support for iOS 26 “Liquid Glass” Design in Cupertino Widgets

For now, you don't need to do anything. iOS 26 will be released in September, and many things are still subject to change.

AI Videos

This is my first AI-related newsletter, so I decided to share some good introductory videos that helped me improve my mindset about LLMs and AI in general. 👇

📹 Andrej Karpathy: Software Is Changing (Again)

Andrej Karpathy is an elite AI researcher and engineer, having worked as director of AI at Tesla and founding member of OpenAI.

In this video, he talks about the evolution of software development paradigms:

• Software 1.0 is written as traditional code
• Software 2.0 is written as neural networks, able to solve specific tasks (e.g. language translation) better than traditional code does
• Software 3.0 is written by LLMs programmed with natural language prompts

In his talk, Andrej likens LLMs to operating systems, and English prompts to programs.

He also describes LLMs as "stochastic simulations of people" with encyclopedic knowledge but also cognitive deficits like hallucination and "jagged intelligence".

As a result, he believes partial autonomy with human verification is the way forward, and, as a professional developer, I completely agree with his assessment.

If you have to watch only one video from this newsletter, make it this one:

📹 Karpathy vs. McKinsey: The Truth About AI Agents (Software 3.0)

I chose to feature this video because it's all about "war at the heart of AI" between business consultants (like McKinsey) and builders (like Andrej Karpathy).

Here are the two contrasting views:

• Andrej encourages viewing AI as a design problem. He emphasizes that current AI agents need significant human supervision, and that software should be designed with humans as validators, where AI generates and humans validate.
• MkKinsey focuses on "agentic mesh" and a world where agents and data can plug in like USB ports. The video criticises this as "fiction" that misleads CEOs and leads to failed enterprise AI projects.

Overall, consultants should be honest about the complexity and challenges of building AI systems. It is possible to take Andrej's Software 3.0 vision and tell good business stories, without oversimplifying things to the level of "USB plug and play".

More realism and less hype is the way to go:

📹 How I use LLMs

Yet another video from Andrej, this time about how he uses LLMs.

While this is intended for a general audience, it's a great overview about how LLMs work, along with the extra features they gained over the recent years.

Here's what's covered:

• Explanation of the concept of tokens
• Context window as working memory
• Pre-training and post-training
• Tool use (internet search, deep search, Python interpreter)
• Multimodality (text, images, audio, video)

Many examples are included, showing how you might use all these different features in your daily life (and not strictly related to coding).

If you have the time, I highly recommend it (maybe even share it with less technical friends & family 🙂):

I loved the top comment about this video: "Just canceled my wedding this weekend to make time to watch this" 😅

AI Articles

If you have digested the videos above and want to get your hands dirty with AI coding, these two articles are a great starting point.

📝 AI-assisted coding for teams that can't get away with vibes

Here's a very good article with tips for building high-quality software faster with AI.

Here are the main takeaways:

• AI is a multiplier: To make AI good, get good yourself. If you are a small coefficient, you won’t see much gain. If you are a negative coefficient, expect negative gains.
• What helps the human helps the AI: Software engineering is the art and science of maintaining a large body of well-defined mental models that achieve a business or economic need. A rich environment and context helps the AI work better.
• Tools and techniques in the editor: Use the best frontier models (don't cheap out), be excellent at providing context, implementing new features, refactoring, and debugging.
• Tools and techniques outside the editor: Use AI to grow your skills and knowledge, create extensive documentation, microfriction lubricants, code review, debugging and monitoring live applications, performance optimisations.

Read on for all the details:

• AI-assisted coding for teams that can't get away with vibes

📝 What Actually Works: 12 Lessons from AI Pair Programming

Another good article with practical tips and techniques that move the needle, from someone who spent 6 months pair-programming with AI.

I used most of these techniques in my own work, and can confirm they work:

• What Actually Works: 12 Lessons from AI Pair Programming

Top tip: did you know that you can replace github.com with gitingest.com on any GitHub repo URL, and get a single text digest of the codebase? Super useful for feeding a codebase into a LLM. Try it here: gitingest.com

Latest from Code with Andrea

A couple of years ago, my opinion about AI was along the lines of "this is cute and somewhat useful". But only recently I started to see gains along the lines of "it just one-shotted a complex feature I couldn't tackle myself 🤯".

I haven't been this excited about coding for a long time, so much so that I decided to start making YouTube videos again, and share some of my experiences with AI. 👇

📹 Build Flutter Apps FASTER with Claude Code Opus 4

Here's a full crash course on how to use Claude Code to build a voice-activated timer app.

Inside, I share my dev workflow and tips for using Claude Code effectively, while showing you how to build the app from scratch, using AI to generate all the code.

Watch the video for a real glimpse of modern agentic AI coding:

📹 Code Review of Cashew App: Lessons from a Flutter App with 100k+ Downloads

By popular request, I also started a new video series where I dig into popular open-source Flutter apps to see how they’re really built.

The first video is about Cashew, a popular budget-tracking app with 100k+ downloads, and 100K+ lines of code, too! Inside, I offer a breakdown of an app’s architecture, patterns, code style, and so on.

If you've ever needed to make yourself familiar with a new codebase, or simply want to learn how big OSS apps are built, you'll like this format:

Until Next Time

That's a wrap up for my first AI-heavy newsletter. In this edition, I wanted to include some foundational content about AI, as well as practical tips, and share my first-hand experience building a Flutter app with Claude Code.

I have a ton of ideas for AI-related content in the future. But for now, I'd like to hear your opinion: did you like this new newsletter format? Is there anything specific you'd like me to cover? Or should I go back to the "Flutter-only" format?

Let me know on X (Twitter), LinkedIn or BlueSky.

Thanks for reading, and happy coding! 🎉

The app idea stemmed from my calisthenics training, where it's impractical to manually control a timer during exercises like the frog stand. A voice-activated timer that responds to "start" and "stop" commands solves this perfectly. This project was an excellent candidate to test Claude Code's ability to handle both UI and underlying logic, especially involving platform-specific features and permissions.

Having used Claude Code (specifically the Max plan with access to Opus 4 and Sonnet 4) for a few weeks, I've been impressed. In this crash course, I'll recap the key aspects of my workflow, highlight where Claude Code shined, where it struggled, and share my overall conclusions and tips for using it effectively.

Useful links

• Claude Code
• Voice Timer Demo on GitHub
• Voice Timer App on the App Store

Getting Started with Claude Code

(Based on 02:21 - 04:24)

If you're looking to try Claude Code yourself, the setup is straightforward. It's a command-line tool that integrates well with your existing IDE (like Cursor, which I use).

1. Installation: You install it globally using npm:

npm install -g @anthropic-ai/claude-code

1. Running: Navigate to your project directory in the terminal and simply run claude.
2. Authentication: You'll need to authenticate. The best value, especially if you plan to use it regularly and leverage the most powerful models like Opus 4, is a paid subscription ($20/month for Pro, $100/month for Max). Alternatively, you can use pay-as-you-go billing via an Anthropic API key. As I mentioned in the video, if you code daily and can afford it, the $100/month Max plan is absolutely worth it for Opus 4 access.
3. IDE Integration: Running claude from your IDE's built-in terminal (like in Cursor) is ideal. It allows Claude Code to interact with your project files, while you can easily switch to your editor to review and manually adjust code when needed.

Claude Code supports different models. On the Max plan, you often have access to Opus 4 for a portion of your usage, after which it might fall back to Sonnet 4. This is important to note, as model performance can vary significantly.

Getting Started with the Flutter App & Initial Requirements

(Based on 04:24 - 07:34)

I started with a completely empty Flutter project – no extra dependencies, just the default "hello world" app.

Before writing any code, my most important piece of advice when using AI coding tools is this: Always start by writing detailed and specific instructions. This dramatically increases the chances that the AI will produce the code you want and significantly reduces later refactoring.

For this app, I created a specs folder with an initial-requirements.md file. This document outlined both functional and non-functional requirements:

Functional Requirements:

• Single-page iOS app built with Flutter.
• Voice-activated timer for calisthenics.
• Basic UI: Timer display showing elapsed time, Start/Stop button, Reset button (like the iOS stopwatch). Use a Stopwatch object.
• Voice Mode: Request microphone and speech recognition permissions on startup. Disable features if denied.
• Voice Commands: Respond to "start" and "stop". Start/continue timer on "start", stop on "stop".
• Audio Feedback: Play a beep sound when a voice command is recognized (initially planned as a TODO).

Non-Functional Requirements:

• Dark mode only, theming done in MaterialApp (no hardcoded colors/sizes).
• Proper separation of concerns (suitable folder structure like features, shared, core).
• Prefer small, composable widgets.
• Prefer flex values over hardcoded sizes for responsive UI.
• Use log from dart:developer for logging instead of print or debugPrint.

These opinionated requirements are crucial. Without them, Claude might produce code that functions but doesn't align with your preferred architecture, styling, or conventions, leading to tedious refactoring down the line. For larger projects, I'd add even more detail on linting, dependency injection, testing practices, etc.

Structuring the Workflow with Claude Code

(Based on 07:34 - 20:15)

Claude Code offers features that help structure your AI-assisted development workflow.

1. /init and CLAUDE.md: Running /init analyzes your project and generates a CLAUDE.md file. This file acts as a permanent context for Claude across sessions. It captures project overview, key requirements it inferred, proposed architecture, coding guidelines, and detected assets. It's a good idea to review and edit this file to ensure it accurately reflects your project's state and guidelines. While Claude might initially be a bit overzealous with bash commands during /init, you can guide it to focus on generating the .md file itself.
2. Plan Mode: Accessible by pressing Shift + Tab twice, Plan Mode is specifically designed for reasoning and breaking down requirements into actionable steps. I used it, referencing my initial-requirements.md, to generate an implementation plan.

Think hard about how to implement all the requirements described in @specs/initial-requirements.md. Make a plan with all the proposed tasks and subtasks, focusing on the UI first. Write all the proposed tasks and subtasks to PLAN.md.

1. Iterating on the Plan: Claude generated a detailed plan with phases, tasks, and subtasks in PLAN.md. I reviewed it and provided feedback to adjust the order, specify technical details (like using a Ticker for UI updates, formatting time as SS.S, using a Stopwatch directly in the UI, removing the "lap" button), and ensure the plan allowed for testing at each step. This iterative planning phase in Plan Mode is invaluable before writing any code.
2. PLAN.md as Master Plan: Once the plan was satisfactory, I explicitly told Claude to write it to a file (PLAN.md). This document becomes your single source of truth for the project's implementation steps. Adding a line referencing this file in CLAUDE.md ensures Claude always has access to it.
3. Custom Commands: A powerful feature is the ability to create custom, project-specific commands by adding files to the .claude/commands folder. I created an update-plan-commit command that automatically updates PLAN.md with completed tasks, stages all changes, and creates a clear Git commit message. This command streamlines the process of keeping the plan and version control in sync after completing each step.

1. Executing the Plan: With the plan in place, you tell Claude to proceed step-by-step, stopping after each one for review.
2. Using @ References: When giving instructions or asking Claude to modify a specific file, using the @ symbol followed by the file path (e.g., @lib/theme/app_theme.dart) is highly effective. It focuses Claude's attention, uses fewer tokens, and generally leads to better results than letting it guess which file you mean.
3. Managing Context with /compact: Long conversation histories can consume tokens. The /compact command shrinks the existing chat history while retaining a summary of key information in the context, helping manage token usage without losing important project knowledge. Alternatively, use the /clear command which resets the context completely; as long as CLAUDE.md and other referenced files like PLAN.md are present, Claude will pick up the project context.

This structured workflow, leveraging planning, context management, and automation, is key to getting consistent results from Claude Code.

Building the Core Timer UI

(Based on 20:15 - 41:37)

Following the plan, Claude Code started implementing the core UI:

• Project Setup & Theming: It correctly set up the project structure, added the specified font to pubspec.yaml, and configured the basic dark theme in MaterialApp and app_theme.dart, following the non-functional requirements. It even caught a linter warning about a deprecated property and fixed it, demonstrating its ability to understand and act on analyzer feedback.
• Timer Display & Page: Claude created the TimerDisplay widget, correctly using a Ticker for smooth updates based on the screen refresh rate and implementing the requested SS.S time formatting. It also created the TimerPage widget to hold the Stopwatch and pass it down to the TimerDisplay. This initial UI implementation was one-shotted perfectly based on the plan.
• Timer Controls (Buttons): It then implemented the Start/Stop and Reset buttons. Claude correctly used widget composition, creating a reusable TimerControlButton and then specific StartStopButton and ResetButton widgets that wrapped it. This demonstrated good code structure and saved manual refactoring.

At each step, I reviewed the generated code (often using the source control diff view in Cursor) and committed the changes using my custom update-plan-commit command.

Using Screenshots for UI Design (28:27):

Wanting a more visually appealing UI, I decided to give Claude Code a screenshot of the desired design from the production app. This is a fantastic feature – you can drag and drop an image into the prompt.

Using the provided screenshot as inspiration, update the styling and design of the timer display, start and stop button, reset button, and voice indicator widget (we'll use this later). Note the start and reset button should still appear side by side inside the row. Keep as much styling as possible in the top level theme, declaring constants with meaningful names in a separate file rather than hard coding values in the widget themselves.

• First Attempt (with Sonnet 4): Claude Code attempted to match the design. It created an app_constants.dart file for colors and sizes, updated the theme, and modified the UI widgets. However, the result wasn't perfect – it added an unwanted linear gradient, some constants were too widget-specific for a global file, the app bar title didn't use the correct font, and there was a layout overflow issue. This attempt ran after Opus 4 usage limit was reached, potentially impacting the result.
• Decision Point: I had a choice: manually refactor or discard and try again with a better prompt (and hopefully Opus 4). I chose the latter to see if Claude Code could nail it with clearer instructions.
• Second Attempt (with Opus 4): I discarded the changes, explicitly added a file with my desired AppColors, and modified the prompt. I emphasized using the provided colors, ensuring all text used the correct font, and adjusting layout factors. This time, running on Opus 4, the result was much better. Claude correctly used the provided colors, applied the font consistently via the theme, and produced a layout much closer to the screenshot, fixing the overflow issue. While some minor tweaks were still needed (like adding button labels or adjusting the voice indicator border), the result was good enough to proceed or make final adjustments manually.

Using the updated screenshot as inspiration, update the styling and design on the timer display, start stop button, reset button, and voice indicator widget. Keep as much styling as possible in the top level theme and ensure all text widgets use the Babas new font. When styling the UI, use the colors in @lib/constants/app_colors.dart.

This demonstrated that providing clear guidance, managing context (by providing the color file), and leveraging the best model (Opus 4) significantly improves the quality of the output, especially for complex tasks like UI design from an image.

Implementing Permissions

(Based on 41:37 - 54:48)

Next, we moved on to integrating native permissions for microphone and speech recognition:

• Adding Dependencies & Platform Setup: Claude correctly identified the need for the permission_handler package and added it to pubspec.yaml. Crucially, it also figured out the necessary platform-specific configuration for iOS, adding the privacy usage descriptions to Info.plist and the required build configurations to the Podfile based on the package's README. This ability to read documentation and apply platform setup is a major strength.
• Requesting Permissions: Claude created a PermissionService class to encapsulate the permission logic. It correctly used the permission_handler API to request both microphone and speech recognition permissions simultaneously, returning true only if both are granted.
• Integrating into UI Lifecycle: Initially, Claude placed the permission request logic in main.dart. I guided it to move this logic to the initState method of the TimerPage widget, which made more sense for this single-page app and kept UI-related state management within the page widget. Claude successfully refactored the code as requested.
• Handling Denials with Alerts: The requirements specified showing an alert if permissions are denied. Claude implemented this, but initially used a standard Material AlertDialog. To match the native iOS look, I introduced my own show_alert_dialog.dart helper file (which uses showAdaptiveDialog) and instructed Claude to use it instead. Claude successfully integrated my helper function, including wiring up the "Open Settings" button action.

Debugging the permission flow required running on a real device (simulator behavior can differ). We encountered an issue where the native permission dialog wasn't appearing on first launch. Claude Code, with some prompting ("Is some more platform-specific configuration needed?"), correctly identified the missing Podfile configuration requirement from the permission_handler README, which resolved the issue. This again showcased its strength in understanding documentation and platform-specific setup.

Building Voice Recognition

(Based on 54:48 - 1:10:52)

Implementing the continuous voice recognition loop was the most complex part and where Claude Code faced the biggest challenge in the live demo.

• Detailed Requirements: Given the complexity, I created a specific voice-recognition.md document outlining the desired behavior: initialize the service if permissions are granted, start a continuous listening loop, stop listening as soon as a command ("start" or "stop") is recognized, process the command, play a beep (TODO), and restart the listening loop. It also included guidelines for simple, stateless implementation and graceful error recovery.
• Planning the Feature: Using Plan Mode and referencing the new requirement document, Claude generated a plan for implementing the voice recognition feature, including adding the necessary package (speech_to_text), creating a VoiceCommandService, integrating it with the TimerPage, and updating the voice indicator UI. Ensuring Claude took the detailed voice-recognition.md into account required a specific prompt in Plan Mode.
• Initial Implementation: Claude added the speech_to_text package and created the VoiceCommandService. The initial code had some issues: it held state variables (isListening, isInitialized) that ideally belonged in the UI layer, used non-idiomatic Dart (setCallbacks), and the continuous listening logic was complex, involving Future.delayed calls and recursive method calls (startListeningLoop). The onSpeechResult handling had duplicate logic.
• Iterating for Improvements: Recognizing the code wasn't ideal, I created a detailed voice-recognition-improvements.md document listing specific suggestions: make the service stateless, remove setCallbacks and Future.delayed, use an enum for commands, improve the startListening API to return a Future<TimerCommand>, use a Completer to signal command recognition and stop listening before completing, and remove unnecessary helper methods.
• Second Attempt: I provided this document to Claude Code. It made significant changes, resulting in a much simpler and cleaner VoiceCommandService that used a Completer as suggested. It successfully made the service stateless and updated the TimerPage to manage the state and the listening loop logic.
• Testing Challenges: Testing on a real device confirmed that voice recognition worked for the first command ("start" or "stop"), but the listening loop would get stuck if any other speech was detected. While Claude Code's code was much improved, this specific bug in the continuous listening loop logic was complex and proved difficult to resolve within the demo session, requiring manual trial and error later in the production app.

This experience highlighted that while Claude Code is excellent at understanding requirements and generating complex patterns (like using a Completer or generating tests, as seen later), intricate state management and lifecycle issues (like a robust continuous listening loop) can still be challenging for it to perfect without extensive guidance or manual debugging.

Beyond the Demo: Production App Examples

(Based on 1:11:38 - 1:14:19)

While the live coding session showed the process and some challenges, the completed production app (available on the App Store) demonstrates Claude Code's ability to handle even more:

• Custom UI (_StadiumBorderPainter): The animated circling border around the voice indicator is a custom painter. I showed Claude a screenshot of a similar effect and described what I needed. It generated the entire _StadiumBorderPainter class with animation logic, saving significant time on complex drawing code.
• Info Button & Action Sheet: Implementing the info button that brings up a native-looking action sheet with voice commands was a one-shot success based on a single prompt.
• Advanced Time Formatting & Unit Tests: The ability to display and speak the time in different formats was a complex task. I defined a TimeFormat enum with formatTime (for UI) and formatTimeForSpeech methods. Generating the nuanced speech formatting logic for each format based on examples I provided was impressive. Even more so, Claude Code generated a comprehensive suite of unit tests for this logic and used its agentic capabilities to run them, find failures, and help me fix bugs in the generated code. This combination of complex logic generation and test-driven bug fixing was a major win.

These production examples show that when properly guided, Claude Code can generate complex UI elements, handle nuanced logic, and even write tests, significantly accelerating development.

Key Takeaways and Tips for Effective Use

(Based on 1:14:00 - 1:16:40)

So, what are the key lessons learned from using Claude Code to build this app? It boils down to this: Claude Code is a powerful skill multiplier, but it's not a magic wand. The value you get is directly proportional to how well you use it.

Here are my top tips for effective AI-assisted development with Claude Code:

• Be Specific & Write Detailed Requirements: Forget "vibe coding." Invest time upfront to write clear, detailed requirements covering functional needs, UI details, desired behavior, and crucial non-functional preferences like code style (in a spec document like @docs/initial-requirements.md). The more precise you are, the better Claude will understand your intent and the less refactoring you'll need later.
• Use Planning & Structure Your Workflow: Break down the project into smaller, manageable tasks using Claude's Plan Mode (PLAN.md). Keep the plan updated and follow it step-by-step. This structured approach, combined with reviewing and committing changes after each task, maintains a working state and makes it easy to revert if needed. Consider asking Claude to ensure your app is testable at each step.
• Actively Guide & Review Code Ruthlessly: Don't blindly accept Claude's output. Read the code, make sure you understand it, and be critical. If it's not what you want – maybe it's overly complex or doesn't fit your patterns – be prepared to discard the changes and provide more specific guidance or a better prompt. Like when it first attempted the VoiceCommandService, I had to provide specific feedback to steer it in the right direction. Remember: Generating code is cheap; maintaining bad code is expensive.
• Optimize Context & Use @ References: Be specific in your prompts and use @ references to relevant files (@docs/initial-requirements.md, @PLAN.md, specific code files) to ensure Claude has the necessary context without wasting tokens.
• Leverage Opus 4: Use the most powerful model available. I found Opus 4 significantly better than Sonnet 4 for planning, complex problem-solving, and generating more accurate code upfront.
• Automate Repetitive Tasks: Identify recurring actions (like updating the plan, committing, or running specific checks) and create custom commands for them to streamline your workflow.
• Speed Up Verification with Tests: Use Claude to help write unit tests for the code it generates. Since Claude is agentic, it can then run these tests after making changes, automating part of the verification process and helping you catch bugs faster.

Applying these principles makes Claude Code a powerful skill multiplier. It can handle boilerplate, figure out API usage from documentation, generate complex logic and tests, and write most of the code for you, which honestly feels quite magical sometimes. This structured, deliberate approach makes all the difference between "Vibe coding" (which often only produces sloppy products) and "AI-assisted software development" (which helps you build robust and maintainable apps). I'd much rather be in that second category!

From Prototype to Production-Ready App

(Based on 1:16:40 - 1:17:33)

As we saw, the app built during the video was a working prototype, and a pretty good one thanks to Claude Code. However, a truly production-ready app requires more: polish, robust error handling, analytics, potentially backend integrations, continuous integration, etc.

The final app I published includes crucial features like analytics, user feedback mechanisms, and error monitoring with Sentry. Many of these are standard boilerplate or patterns I already had battle-tested in my other apps. For those, it was often quicker for me to copy-paste and adapt my existing code rather than asking Claude to implement them from scratch.

So, while Claude Code is fantastic for building core features and tackling new problems, don't hesitate to reuse your own proven code for standard infrastructure pieces. You could even explore writing custom Claude commands to help integrate your pre-existing code patterns more easily into new apps.

Conclusion

(Based on 1:17:33 - 1:18:42)

Ultimately, Claude Code can do a lot of the heavy lifting for you and significantly accelerate development. So, my advice is to give it a go. If you're a professional software developer and you can afford it, the Max plan is absolutely worth the investment, and Opus 4 is a big step forward compared to other models available in different tools.

Now, you might be thinking: What about Cursor? Should you still use it, or is it better to use Claude Code for everything? As you've seen, I've been using Claude Code extensively for planning, generating code, and tackling complex tasks. However, I still find Cursor incredibly useful for its deep IDE integration – things like seamless tab-autocompletion directly in the editor, and for making quick, small inline changes or refactors manually. So, at the moment, I'm actually still paying for both tools. This hybrid approach allows me to leverage Claude Code's powerful model and agentic capabilities for larger tasks and planning, while still benefiting from Cursor's tight IDE features for day-to-day coding and manual adjustments. Using them both strategically lets me maximize my productivity.

On a final note, we've only scratched the surface of what Claude Code can do in this video. If you want to learn more about its features or dive deeper into AI-assisted development, you can find some useful links and resources below.

Additional Resources

• Mastering Claude Code in 30 minutes
• Claude Code: Best practices for agentic coding
• Claude Code - 47 PRO TIPS in 9 minutes
• AI-assisted coding for teams that can't get away with vibes
• Prompt engineering overview

Puro is a powerful tool that lets you install multiple versions of Flutter and easily switch between them in your projects.

It's very fast and can automatically configure your IDE to use your desired Flutter version.

Before Puro, I was using FVM.

But after trying it, I have converted:

• Faster downloads
• Better IDE integration
• Nicer CLI interface

Learn more and install here:

• Puro

Happy coding!

Below is an AI summary of the video. Here's the GitHub repository.

App Overview and Success Metrics

Cashew stands as a testament to what a single developer can achieve. The finance budgeting app boasts:

• Over 100,000 downloads on Google Play
• 4.9-star rating from 15,700+ reviews
• Similar high ratings on the App Store
• Featured multiple times on YouTube channels with substantial followings
• Cross-platform availability (iOS, Android, Web)

The app was actively developed from September 2021 to October 2024, spanning over three years of continuous development—far exceeding the typical lifespan of side projects. However, the last release occurred in July 2024, suggesting potential development challenges.

Getting the App Running: Version Compatibility Challenges

The first hurdle in reviewing this codebase was simply getting it to run. The project's extensive dependencies created immediate compatibility issues with current Flutter versions. Rather than upgrading dozens of packages individually, the solution involved downgrading to Flutter 3.22 using tools like Puro for version management.

This approach highlights a critical lesson: when inheriting legacy codebases, sometimes working backward to a compatible environment is more efficient than forcing everything forward. The experience underscores the importance of version management tools for developers working across multiple projects.

Android setup required manual Gradle script updates, while iOS proved more straightforward after removing the old Podfile.lock and running pod install. Interestingly, the repository includes Firebase configuration files—a security concern for open-source projects that should be addressed through proper backend security measures.

Architecture and Dependencies Analysis

Package Dependencies

The pubspec.yaml reveals a complex dependency structure:

• Database: Drift with SQLite for local storage
• Authentication: Google Sign-In integration
• Backend: Firebase packages for cloud synchronization
• State Management: Provider (notably absent: dedicated solutions like BLoC or Riverpod)
• Development: Build Runner for code generation

The absence of dedicated state management frameworks suggests custom-built solutions, which can work effectively when implemented properly but require careful architectural planning.

Codebase Scale

Using the cloc tool reveals staggering numbers:

• 103,000 lines of Dart code (excluding empty lines and generated files)
• Largest files include database tables and schema versions
• Individual pages reaching nearly 5,000 lines of code
• The addTransactionsPage.dart file alone contains massive complexity

Testing Infrastructure

Perhaps the most concerning discovery: the project contains no meaningful tests beyond the default Flutter project template. For a production application of this scale serving thousands of users, the absence of automated testing represents significant risk. Any code changes could potentially break existing functionality without detection.

Code Architecture Deep Dive

Global State Management Issues

The application relies heavily on global variables for dependency management, declared in files like databaseGlobal.dart. Dependencies such as SharedPreferences, database instances, and notification payloads are initialized as global variables rather than through proper dependency injection systems.

This approach creates several problems:

• Unclear initialization order: Functions like loadCurrencyJSON set global variables without explicit return values
• Mutable global state: Variables can be modified from anywhere in the application
• Testing difficulties: Global state makes unit testing nearly impossible
• Maintenance challenges: Dependencies between components become opaque

Navigation and State Updates

The app employs a complex system of global navigation keys defined in navigationFramework.dart. These keys enable widgets to force rebuilds of other widgets throughout the application using patterns like:

homepageStateKey.currentState.refreshState();

This approach creates problematic interdependencies where widgets can trigger rebuilds of seemingly unrelated components. The refreshState method typically contains empty setState() calls that force complete widget rebuilds—a brute-force approach to UI updates that can cause performance issues.

Main Application Structure

The main.dart file demonstrates inconsistent initialization patterns:

• Some dependencies initialized as global variables in the main method
• Others handled through inherited widgets at the widget tree's root
• Error handling relies on runZonedGuarded primarily for development logging
• No integration with production error monitoring services like Crashlytics or Sentry

UI Implementation Analysis

Homepage Complexity

The homepage widget exemplifies the architectural challenges throughout the codebase:

• Build method spans nearly 200 lines
• Complex conditional logic based on global app settings
• Dynamic widget mapping using string keys
• For loops within the build method creating widgets based on context

This monolithic approach means any state change potentially rebuilds the entire homepage, creating performance bottlenecks and making the code difficult to reason about.

The 5,000-Line Monster: AddTransactionsPage

The addTransactionsPage.dart file represents the extreme end of the complexity spectrum:

• Over 5,000 lines in a single file
• 44 setState() calls throughout the file
• Massive build method spanning from line 1,050 to 2,218
• Business logic, UI code, database operations, and animations all intertwined

The addTransactionLocked method demonstrates the architectural problems:

1. Opens bottom sheets for user input
2. Performs data validation
3. Creates transaction objects
4. Handles conditional logic for related transactions
5. Updates the database
6. Manages animations
7. Sets notifications
8. Updates global app settings
9. Handles error cases

This single method mixing UI, business logic, database operations, and side effects makes testing and maintenance extremely challenging.

Database Implementation

Schema Complexity

The database implementation in tables.dart spans over 7,000 lines, containing:

• Table definitions with extensive column specifications
• Complex converter classes for data transformation
• Migration strategies across multiple app versions
• Intricate SQL queries for financial calculations

Migration Strategy Evolution

The migration code reveals evolving development practices:

• Early migrations: Simple await calls without error handling
• Later migrations: Try-catch blocks with print statements for debugging
• Complex multi-step migrations for schema changes
• Inconsistent error handling patterns

Query Complexity

Database queries demonstrate sophisticated financial calculations but raise maintainability concerns:

• Methods like watchTotalNetBeforeStartsDateTransactionCategoryWithDay perform complex aggregations
• Some queries depend on global app settings variables
• Commented-out code suggests ongoing experimentation
• Query optimization appears secondary to functionality

Folder Structure and Organization

The project's organization reflects organic growth rather than planned architecture:

• struct folder: Contains miscellaneous utilities (data formatting, animations, Firebase auth, biometrics)
• widgets/util folder: Another catch-all containing app links, debouncing, animations, mixins, file I/O
• Inconsistent naming conventions
• No clear separation between layers (presentation, domain, data)

This structure makes navigation difficult and suggests code was placed wherever convenient rather than following established architectural patterns.

Performance and Maintainability Concerns

State Management Issues

The combination of global mutable state, massive widget classes, and forced rebuilds creates several performance risks:

• Unnecessary widget rebuilds due to global state changes
• Complex interdependencies making optimization difficult
• Memory leaks potential from global state retention
• Difficult debugging due to unclear state flow

Code Maintainability

Several factors compound maintenance difficulties:

• Massive files requiring extensive scrolling and mental mapping
• Mixed concerns within single classes
• Global dependencies making isolated testing impossible
• Inconsistent architectural patterns throughout the codebase

Learning Opportunities and Best Practices

What Went Right

Despite architectural challenges, the Cashew app demonstrates several positive aspects:

• Successful product delivery: The app serves real users effectively
• Feature completeness: Comprehensive budgeting functionality
• User satisfaction: Exceptional ratings indicate strong user experience
• Open source contribution: Provides learning opportunities for the community
• Solo developer achievement: Remarkable accomplishment for a single person

Critical Issues Identified

1. No error monitoring

• Problem: Errors are silenced or only logged to console
• Solution: Implement Crashlytics or Sentry for production error tracking

2. No automated tests

• Problem: No automated tests for a 103,000-line codebase
• Solution: Start with integration tests for critical user flows before major refactoring

3. No linter tool

• Problem: No linting or static analysis
• Solution: Implement Flutter lints package, consider DCM (Dart Code Metrics) for advanced analysis

4. Poor separation of concerns

• Problem: Business logic, UI, and data access mixed throughout
• Solution: Implement layered architecture (presentation, domain, data layers)

5. Lack of dependency injection system / service locator

• Problem: Global variables for dependency injection
• Solution: Adopt proper DI system (Riverpod, GetIt) for dependency management

6. Global mutable state

• Problem: App settings and other state accessible/modifiable globally
• Solution: Implement proper state management (Riverpod, BLoC) with immutable state

7. Widget rebuilds via global navigator keys

• Problem: Widgets forcing other widgets to rebuild by directly accessing their navigator keys and resetting their state
• Solution: Move to reactive state management solutions for better control of widget rebuilds

8. Massive widget classes

• Problem: Massive widget classes with complex interdependencies
• Solution: Break down into smaller, focused widgets with clear responsibilities

Refactoring Strategy

For a codebase of this scale, refactoring must be incremental:

1. Establish safety nets: Add integration tests for critical paths
2. Implement error monitoring: Gain visibility into production issues
3. Add code quality tools: Enable automated detection of issues
4. Gradual architectural improvements: Apply Boy Scout Rule—leave code better than found
5. Dependency injection migration: Slowly replace global variables with proper DI
6. State management evolution: Introduce reactive state management incrementally
7. Widget decomposition: Break large widgets into smaller, testable components

Technical Debt Impact

The Cashew app illustrates how technical debt accumulates in successful projects:

• Initial velocity: Quick development enabled rapid feature delivery
• Growing complexity: Each new feature became harder to implement
• Maintenance burden: Changes risk breaking existing functionality
• Developer fatigue: Complex codebase becomes overwhelming to maintain

The lack of recent releases (since July 2024) may indicate the technical debt has reached a tipping point where continued development becomes prohibitively difficult.

Architectural Recommendations

Immediate Priorities

1. Error monitoring implementation: Essential for production app stability
2. Critical path testing: Integration tests for core user journeys
3. Dependency injection: Replace global variables with proper DI container
4. State management: Introduce reactive patterns to reduce forced rebuilds

Long-term Improvements

1. Layered architecture: Separate presentation, domain, and data concerns
2. Widget decomposition: Break monolithic widgets into manageable components
3. Code organization: Restructure folders following architectural principles
4. Performance optimization: Address unnecessary rebuilds and memory issues

Development Process Improvements

1. Code review practices: Implement standards for future changes
2. Automated testing: Build comprehensive test suite incrementally
3. Continuous integration: Automate quality checks and testing
4. Documentation: Create architectural decision records and coding standards

Lessons for Flutter Developers

For Solo Developers

• Balance speed with quality: Technical debt compounds quickly in successful projects
• Invest in testing early: Manual testing doesn't scale with codebase growth
• Establish architectural patterns: Consistency prevents complexity explosion
• Plan for success: Consider maintenance burden as the app grows

For Teams

• Code review importance: Multiple perspectives prevent architectural drift
• Shared standards: Team conventions prevent inconsistent patterns
• Refactoring time: Budget time for technical debt reduction
• Knowledge sharing: Prevent single points of failure in understanding

Universal Principles

• Separation of concerns: Keep UI, business logic, and data access distinct
• Dependency management: Avoid global state; use proper injection patterns
• Error handling: Plan for failure scenarios from the beginning
• Performance considerations: Design for scale, even in early stages

Conclusion

The Cashew app represents a fascinating case study in Flutter development. While the business success is undeniable—serving over 100,000 users with exceptional satisfaction—the technical implementation reveals the challenges of scaling a codebase without proper architectural foundations.

The developer's achievement in creating a successful app single-handedly deserves recognition. However, the codebase serves as a cautionary tale about technical debt accumulation and the importance of sustainable development practices.

Key takeaways for the Flutter community:

1. Technical debt is real: It accumulates silently and can eventually halt development
2. Architecture matters: Even solo projects benefit from proper structural planning
3. Testing is essential: Manual testing doesn't scale with complexity
4. Refactoring is investment: Regular code improvement prevents future paralysis
5. Tools help: Linting, error monitoring, and quality metrics provide early warnings

The open-source nature of Cashew provides invaluable learning opportunities. By examining both its successes and challenges, developers can make more informed decisions about their own projects, balancing delivery speed with long-term maintainability.

For developers facing similar technical debt situations, the path forward involves incremental improvement, establishing safety nets through testing, and gradually introducing better architectural patterns. The Boy Scout Rule—leaving code better than you found it—becomes essential for managing legacy codebases while continuing to deliver value to users.

The Cashew app ultimately demonstrates that while technical perfection isn't required for business success, sustainable development practices become crucial as projects scale and mature. The challenge lies in finding the right balance between shipping features and maintaining code quality—a balance that becomes increasingly important as applications grow in complexity and user base.

As usual, this newsletter is all about the latest from the Flutterverse:

• The new Flutter 3.32 and Dart 3.8 releases
• Flutter’s path towards seamless interop
• A peek at Material 3 Expressive
• New videos and articles from the community
• All the latest from Code with Andrea

Let's dive in!

📝 What's new in Flutter 3.32

Flutter 3.32 is here, unlocking new features like web hot reload, Cupertino squircles for native fidelity, and new AI integrations with Firebase. The release addresses various improvements across web, framework, Cupertino, Material, accessibility, text input, desktop, iOS, Android, and engine components.

Here are some highlights:

• Web Hot Reload (Experimental): Now available with the --web-experimental-hot-reload flag, as explained here.
• Cupertino Squircles: Added rounded superellipse shape for iOS fidelity in CupertinoAlertDialog and CupertinoActionSheet.
• Progress on multi-window support on desktop by Canonical.
• Flutter Property Editor: New tool for easily editing widget properties and reading documentation within the IDE (here's a preview).
• Accessibility: Introduced a new SemanticsRole API for precise control over how UI elements are interpreted by assistive technologies.

Read on for all the details:

• What's new in Flutter 3.32

Detailed release notes for Flutter 3.32 are available here.

📝 Flutter’s path towards seamless interop

Flutter is launching an early access program for plugin authors to test and provide feedback on FFIgen and JNIgen, codegen solutions that aim to simplify access to native platform APIs by directly bridging Dart and native code.

These tools seek to replace method channels, which are time-consuming to implement and maintain, with a more efficient and seamless developer experience. For all the details and how to apply, read on:

• Flutter’s path towards seamless interop

📝 Announcing Dart 3.8

Flutter 3.32 includes Dart 3.8, which brings some welcome improvements:

• Formatter updates, including a new option to preserve trailing commas.
• Null-aware elements, allowing you to add elements to a collection if they are not null, using a simplified syntax.

Read the announcement for all the details:

• Announcing Dart 3.8

📹 Decoding Flutter: How Flutter Works (Video Series)

The Flutter team shared an excellent 6-part video series that takes you on a deep dive into Flutter's internals. From high-level architecture to low-level engine details, this comprehensive series explains how Flutter actually works under the hood.

The series starts with Flutter's overall architecture and gradually builds up your understanding through the widget system, state management, rendering pipeline, and platform integration. You'll learn about the three trees (Widget, Element, and RenderObject), how state management really works, what happens during layout and painting, and how Flutter interfaces with native platforms.

It's a great watch if you want to understand the framework at a deeper level:

Here are all the episodes:

• Architecture #DecodingFlutter (1/6)
• The Three Trees #DecodingFlutter (2/6)
• The State class #DecodingFlutter (3/6)
• The RenderObjectWidget #DecodingFlutter (4/6)
• The RenderObject #DecodingFlutter (5/6)
• The Flutter Engine and Embedders #DecodingFlutter (6/6)

The official docs also include a high-level overview of the architecture of Flutter, including the core principles and concepts that form its design. Learn more here: Flutter architectural overview.

Upcoming: Material 3 Expressive

Have you heard? Material 3 Expressive was announced this month, and it's expected to ship with the upcoming Android 16 later this year:

According to this umbrella issue on the Flutter repo, the team is not actively developing Material 3 Expressive at this stage, but I'm sure we'll hear more about it in the coming months, so keep an eye out.

Community Articles

This month, two useful articles that caught my attention. 👇

📝 Building Local-First Flutter Apps with Riverpod, Drift, and PowerSync

If you want to build offline-ready apps that stay fast and responsive, even without internet, you'll need to shift from the traditional online-first approach to a local-first model.

This article by Dinko Marinac offers a great overview of key challenges like change tracking, conflict resolution, and error handling, and shows how PowerSync solves them. A practical implementation is included, showing how to integrate Riverpod, Drift, and PowerSync in a sample TODO app:

• Building Local-First Flutter Apps with Riverpod, Drift, and PowerSync

📝 The Definitive Guide to Navigator 2.0 in Flutter

Flutter’s navigation system has had a bit of a troubled past:

• Navigator 1.0 is easy, but breaks down on the web and in complex apps.
• Navigator 2.0 is powerful but under-documented and hard to reason about.
• GoRouter tries to simplify it, but brings its own set of bugs and edge cases.

Given GoRouter's recent troubles, I decided to use Navigator 2.0 directly when implementing URL-navigation in my Flutter Tips app.

While I'm happy with the result, it was challenging to make it work, and this latest article by Tadas Petra has helped me get a better conceptual understanding of all the moving parts:

• The Definitive Guide to Navigator 2.0 in Flutter

Latest from Code with Andrea

Over the last month, I shared a bunch of new tips and published two new articles.

📝 How to Update Your Android Gradle Files to the Kotlin DSL

Since Flutter 3.29, new Flutter projects use the new Kotlin DSL for Gradle files by default. This has some implications for projects that rely on custom Gradle configurations, such as flavors, code signing, and more.

If you need help with migrating to the new Kotlin DSL, this article breaks down what changed, how it affects you, and how to avoid common pitfalls:

• Kotlin DSL in Flutter 3.29: How to Update Your Android Gradle Files

📝 Flutter App Analytics: Scalable Architecture & Firebase Setup

App analytics are very useful because they help you make product decisions based on data, rather than guesswork.

My latest article shows how to track analytics in your Flutter app, including:

• What to track: Choosing the right events.
• How to structure it: Simple and scalable architectures for event tracking.
• Firebase Analytics setup: How to wire everything up in a real app.

Read on for all the details:

• Flutter App Analytics: Scalable Architecture & Firebase Setup

I've also updated a previous article, explaining how to configure the updated code formatter in Dart 3.8.

Until Next Time

Lately, my brain has already been churning new content ideas, including a new video series where I'll be reviewing popular OSS Flutter apps to see how they're built.

I'll be on vacation over the next week, but I'll be recording the first episode as soon as I get back, so stay tuned!

Happy coding!

Dart 3.8 introduces a new formatting option to preserve trailing commas.

Enable this to override the default formatter behaviour (introduced in Dart 3.7), which is to remove trailing commas when parameter lists fit within the max page width.

Some other formatter configuration options are available.

For all the details, read this updated article:

• How to Configure the Updated Code Formatter in Dart 3.8

Happy coding!

Dart 3.8 introduces null-aware elements!

This allows you to add nullable elements to a collection with a single character (?).

Much shorter than using the collection-if syntax. 👍

Here are some more examples (from the docs) showing how you might use this:

More details on the feature specification:

• Null-aware elements

Happy coding!

If your app uses GoRouter with shell routes, tracking screen views reliably requires some workarounds.

Here's how I do it (using Riverpod):

1. Declare GoRouter inside a Riverpod provider
2. Create a stateful GoRouter listener to track screen views
3. Return it inside MaterialApp.builder

Here's a PR showing how I implemented this in my Time Tracker app:

• Add GoRouterDelegateListener class to track screen views

And here's the original GoRouter issue showing that NavigatorObserver doesn't work with shell routes:

• ShellRoutes seem to cause NavigatorObserver to not fire (5.0.1)

Happy coding!

Material 3 supports 5 types of buttons:

• Elevated
• Filled
• Filled tonal
• Outlined
• Text

Here's how to use them in Flutter 👇

Example with source code:

• Flutter button style example

More complex example with custom icons and LTR/RTL support:

• Flutter button style example with icons, LTR/RTL support

Happy coding!

By overriding ThemeData.platform inside MaterialApp, you can quickly test all your adaptive UI code, such as:

• all adaptive widgets
• any conditional code that checks the platform

Much faster than choosing a different emulator/device and running from scratch 👍

Happy coding!

But wait…

How will you know what’s working?

• How many users complete onboarding?
• How many sign up and create an account?
• How many reach the paywall—and convert?

Without analytics, you’re flying blind.

You’re making product decisions based on vibes, not data. That’s a fast way to stall growth, waste dev time, or worse—lose your users.

The Importance of Analytics

Analytics give you the data you need to grow. They help you:

• Measure engagement: Who’s using your app, how often, and for how long?
• Understand retention: Where are users dropping off—and why?
• Track feature usage: What’s popular? What’s ignored?
• Optimize revenue: Monitor purchases, subscriptions, and churn.
• Know your users: Demographics, devices, platforms.
• Follow the journey: Map user flows across the app and spot friction points.

With this info, you can stop guessing and start making product decisions that actually improve your app.

What You'll Learn

In this article, I’ll show you how to track analytics in your Flutter app—from basic event logging to a scalable architecture that works with multiple providers like Firebase and Mixpanel.

Here’s what we’ll cover:

• What to track: Choosing the right events—and why they matter.
• How to structure it: Simple and scalable architectures for event tracking.
• Firebase Analytics setup: How to wire everything up in a real app.

Let’s dive in. 👇

This article will guide you through the fundamentals. If you want to go deeper, check out my Flutter in Production course, which contains an entire module about app analytics.

Introduction to Event Tracking

Ask five developers how they implemented analytics, and you’ll likely get five different answers (I know because I did).

As usual with software engineering, there’s no one-size-fits-all solution—just tradeoffs.

So before we dive into the code, let’s zoom out and answer a few key questions:

• What events should we track?
• How should we track them?
• What requirements should our solution meet?

Once we’ve nailed that down, we’ll pick a suitable architecture.

What Events Do We Need to Track?

In simple terms, events represent interactions between the user and your app.

Take my Flutter Ship app as an example:

The app helps you "tick all the boxes" before releasing your Flutter apps. It’s basically a pre-filled TODO list.

If you wanted to add analytics to this app, what would you track?

Focus on events that:

• Help the user succeed (e.g. completing tasks)
• Help your business succeed (e.g. user signups, retention, monetization)

For this app, meaningful events are:

1. Create a new app
2. Edit an existing app
3. Delete an app
4. Complete a task

Everything else is optional. Don’t track for the sake of tracking.

Tracking Events with Firebase Analytics and Mixpanel

Now, suppose you want to track these events in your Flutter app.

If you're using the firebase_analytics package, you can do it like this:

final analytics = FirebaseAnalytics.instance;
analytics.logEvent('app_created');
analytics.logEvent('app_updated');
analytics.logEvent('app_deleted');
analytics.logEvent('task_completed', parameters: {'count': count});

Or, if you're using the mixpanel_flutter package, this is the way:

final mixpanel = await Mixpanel.init(
  Env.mixpanelProjectToken,
  trackAutomaticEvents: true,
);
mixpanel.track('App Created');
mixpanel.track('App Updated');
mixpanel.track('App Deleted');
mixpanel.track('Task Completed', properties: {'count': count});

You can already spot the problem: different APIs, different syntax.

❌ Scattering these calls all over your codebase is a bad idea. ❌

Here's why:

• You lock yourself into specific SDKs
• You duplicate event names everywhere (easy to mistype, hard to refactor)
• You lose type safety and IDE support
• You can’t reuse logic or dispatch to multiple vendors
• You mix business logic with implementation details

We can do much better by defining a clear interface—one that separates event tracking from everything else.

Let’s formalize some requirements next.

App Analytics: Requirements

Before jumping into implementation, let’s define what we actually need from an analytics system.

Here are the key requirements:

1. Separation of concerns: App code should never call vendor SDKs (like Firebase or Mixpanel) directly. Instead, we’ll route all event tracking through a clear interface.

2. Support for multiple clients: We should be able to send events to more than one provider. For example, you might want to log to both Firebase and Mixpanel at the same time.

3. Debug vs Release mode: In development, we only want to log events to the console. In release mode, real analytics providers should be used—with no changes to app logic.

Other things worth thinking about:

• Screen view tracking
• Opt-in/out toggles (e.g. for privacy/GDPR)
• User identification (after login)
• Multiple build flavors (dev/staging/prod)

But for now, we’ll focus on the two most important ones:

• Keeping analytics isolated from app logic
• Supporting multiple analytics providers

Next, let's walk through two possible architectures and break down their tradeoffs. 👇

Super-Simple Analytics Architecture

This setup is adapted from a suggestion I received on X (Twitter):

import 'dart:developer';

import 'package:flutter/foundation.dart';
import 'package:mixpanel_flutter/mixpanel_flutter.dart';
import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsClient {
  const AnalyticsClient(this._analytics, this._mixpanel);
  final FirebaseAnalytics _analytics;
  final Mixpanel _mixpanel;

  Future<void> track(
    String name, {
    Map<String, dynamic> params = const {},
  }) async {
    if (kReleaseMode) {
      await _analytics.logEvent(name: name, parameters: params);
      await _mixpanel.track(name, properties: params);
    } else {
      log('$name $params', name: 'Event');
    }
  }
}

This is about as simple as it gets. It gives you a shared interface for tracking events:

• In release mode, it logs to both Firebase and Mixpanel
• In debug mode, it just prints to the console

If you're using Riverpod, tracking events looks like this:

final analytics = ref.read(analyticsClientProvider);
analytics.track('app_created');
analytics.track('app_updated');
analytics.track('app_deleted');
analytics.track('task_completed', parameters: {'count': count});

As long as your event names follow the Firebase Analytics guidelines (1–40 alphanumeric characters or underscores), you’re good to go.

This approach is surprisingly flexible for how little code it requires. You can swap out analytics providers by updating a single class, and the rest of your app doesn’t care. 👍

But It Has Drawbacks

This architecture starts to break down as your app grows:

• No conditional tracking: You can’t log some events to Mixpanel but not Firebase. This is a problem if you're watching your event volume (and costs).

• Hardcoded strings everywhere: Event names end up duplicated across the codebase. Easy to mistype. Hard to refactor. A big footgun on teams.

• No single source of truth:There’s no centralized list of events or their expected parameters.

• No autocomplete: You lose IDE support. If you had a type-safe API, you'd get helpful autocompletion:

This setup may be good enough for solo devs or small apps where you want minimal friction and full control.

But if you’re working in a larger codebase or with a team, it’s worth investing in something a bit more robust. Let’s look at a more scalable alternative. 👇

More Complex Analytics Architecture

If you want a type-safe analytics API with autocomplete and clear separation of concerns, here’s the approach I recommend.

Start by defining an abstract AnalyticsClient interface. For the Flutter Ship app, it might look like this:

abstract class AnalyticsClient {
  Future<void> trackAppCreated();
  Future<void> trackAppUpdated();
  Future<void> trackAppDeleted();
  Future<void> trackTaskCompleted(int completedCount);
}

This way, all the events are defined in a single place, avoiding duplication and potential mistakes.

But how do we support multiple clients?

Here’s one way to structure it:

How this works:

• You define all your events in an abstract AnalyticsClient interface.
• Each concrete implementation (e.g. LoggerAnalyticsClient, FirebaseAnalyticsClient, etc.) handles how those events are logged.
• An AnalyticsFacade class implements AnalyticsClient too—but just dispatches to all registered clients.
• Finally, the app uses a analyticsFacadeProvider to access the facade and call the appropriate tracking methods.

Now, from your app code, tracking an event is as simple as:

final analytics = ref.read(analyticsFacadeProvider);
analytics.trackEditApp();

And since each event is a dedicated method, you get autocomplete and type safety out of the box:

How Do We Implement This?

This is just the high-level architecture. To make it work, we’ll need to answer:

• How do we register multiple clients in AnalyticsFacade?
• How are events dispatched to each client?
• What do concrete AnalyticsClient subclasses look like?

Let’s walk through the implementation details next. 👇

App Analytics: Implementation Details

To implement the architecture we just discussed, we’ll need a few key building blocks:

1. An AnalyticsClient interface that defines all the events we want to track.
2. An AnalyticsFacade that implements AnalyticsClient, and delegates calls to multiple clients.
3. A LoggerAnalyticsClient for local dev—logs events to the console.
4. Additional clients like FirebaseAnalyticsClient, MixpanelAnalyticsClient, etc., that wrap vendor SDKs.

To keep things organized, I recommend putting all of this in a monitoring folder:

‣ lib
  ‣ src
    ‣ monitoring
      ‣ analytics_client.dart
      ‣ analytics_facade.dart
      ‣ logger_analytics_client.dart
      ‣ firebase_analytics_client.dart

Here’s how each part works:

1. The AnalyticsClient Cnterface

This is the contract. It defines all the events your app supports.

abstract class AnalyticsClient {
  // Custom events for the Flutter Ship app.
  // TODO: Replace with your own events.
  Future<void> trackNewAppOnboarding();
  Future<void> trackNewAppHome();
  Future<void> trackAppCreated();
  Future<void> trackAppUpdated();
  Future<void> trackAppDeleted();
  Future<void> trackTaskCompleted(int completedCount);
}

Since this class is abstract, all methods are declarations only—no implementations.

2. The LoggerAnalyticsClient Class

This one’s simple: it logs events to the console. Useful for local dev and tests before wiring up a real analytics backend:

import 'dart:async';
import 'dart:developer';

import 'package:flutter_ship_app/src/monitoring/analytics_client.dart';

class LoggerAnalyticsClient implements AnalyticsClient {
  const LoggerAnalyticsClient();

  static const _name = 'Event';

  @override
  Future<void> trackNewAppHome() async {
    log('trackNewAppHome', name: _name);
  }

  @override
  Future<void> trackNewAppOnboarding() async {
    log('trackNewAppOnboarding', name: _name);
  }

  @override
  Future<void> trackAppCreated() async {
    log('trackAppCreated', name: _name);
  }

  @override
  Future<void> trackAppUpdated() async {
    log('trackAppUpdated', name: _name);
  }

  @override
  Future<void> trackAppDeleted() async {
    log('trackAppDeleted', name: _name);
  }

  @override
  Future<void> trackTaskCompleted(int completedCount) async {
    log('trackTaskCompleted(completedCount: $completedCount)', name: _name);
  }
}

We’ll add a FirebaseAnalyticsClient later. For now, focus on what you want to track—not how it’s sent.

Is There a Better Way to Define Events?

This approach works—but it’s not DRY. You’re copy-pasting a lot when adding new events:

// copy-paste when creating new events
@override
Future<void> trackAppCreated() async {
  log('trackAppCreated', name: _name);
}

Alternatives worth considering:

• Enums: Define an AppEvent enum and list all the possible events as values. This doesn't work if different events need different arguments.
• Sealed classes: Use a base AppEvent sealed class and create a subclass every time we need a new event. More flexible, but verbose.
• Freezed union types: Terse syntax and pattern matching—but requires codegen.

Each option has tradeoffs. For now, we'll stick with our initial approach.

3. The AnalyticsFacade Class

The AnalyticsFacade implements the AnalyticsClient interface and forwards each method call to all registered clients.

import 'package:flutter/foundation.dart';
import 'package:flutter_ship_app/src/monitoring/analytics_client.dart';
import 'package:flutter_ship_app/src/monitoring/logger_analytics_client.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'analytics_facade.g.dart';

// https://refactoring.guru/design-patterns/facade
class AnalyticsFacade implements AnalyticsClient {
  const AnalyticsFacade(this.clients);
  final List<AnalyticsClient> clients;

  @override
  Future<void> trackAppOpened() => _dispatch(
        (c) => c.trackAppOpened(),
      );

  @override
  Future<void> trackNewAppHome() => _dispatch(
        (c) => c.trackNewAppHome(),
      );

  @override
  Future<void> trackNewAppOnboarding() => _dispatch(
        (c) => c.trackNewAppOnboarding(),
      );

  @override
  Future<void> trackAppCreated() => _dispatch(
        (c) => c.trackAppCreated(),
      );

  @override
  Future<void> trackAppUpdated() => _dispatch(
        (c) => c.trackAppUpdated(),
      );

  @override
  Future<void> trackAppDeleted() => _dispatch(
        (c) => c.trackAppDeleted(),
      );

  @override
  Future<void> trackTaskCompleted(int completedCount) => _dispatch(
        (c) => c.trackTaskCompleted(completedCount),
      );

  Future<void> _dispatch(
    Future<void> Function(AnalyticsClient client) work,
  ) async {
    for (final client in clients) {
      await work(client);
    }
  }
}

The _dispatch method removes duplication and broadcasts each event to all the registered clients.

Setting Up the Provider

Here’s how to expose the AnalyticsFacade via Riverpod:

@Riverpod(keepAlive: true)
AnalyticsFacade analyticsFacade(Ref ref) {
  return const AnalyticsFacade([
    if (!kReleaseMode) LoggerAnalyticsClient(),
  ]);
}

In debug builds, you get console logging. In release builds, you can add real clients like FirebaseAnalyticsClient (more on this later).

This setup gives you a clear, modular, and scalable way to track analytics events—without coupling your app logic to any vendor-specific SDK.

Which Architecture Is Better?

The architecture we just built gives you:

• A type-safe event tracking API
• Autocomplete and IDE support
• Clear separation of concerns
• Support for multiple analytics backends

Here’s a visual recap:

It’s flexible, scalable, and production-ready.

But it comes at a cost.

Every time you add a new event, you need to:

• Add a method to the AnalyticsClient interface
• Implement it in the AnalyticsFacade
• Implement it in every concrete client (e.g. Logger, Firebase, Mixpanel)

When the Simple Approach Is Enough

For small apps or quick MVPs, the simple approach may be enough:

import 'dart:developer';

import 'package:flutter/foundation.dart';
import 'package:mixpanel_flutter/mixpanel_flutter.dart';
import 'package:firebase_analytics/firebase_analytics.dart';

class AnalyticsClient {
  const AnalyticsClient(this._analytics, this._mixpanel);
  final FirebaseAnalytics _analytics;
  final Mixpanel _mixpanel;

  Future<void> track(
    String name, {
    Map<String, dynamic> params = const {},
  }) async {
    if (kReleaseMode) {
      await _analytics.logEvent(name: name, parameters: params);
      await _mixpanel.track(name, properties: params);
    } else {
      log('$name $params', name: 'Event');
    }
  }
}

This gets the job done—fast. But you lose:

• Autocomplete
• Type safety
• Centralized event definitions
• Vendor-level control and filtering

Bottom line: For anything beyond a throwaway prototype, go with the more structured architecture. It’s more verbose up front, but it pays off in maintainability, testability, and developer experience.

Now let’s see how to actually call the analyticsFacadeProvider to track events in real app code.

Tracking Custom Events

We’ve defined an interface like this:

abstract class AnalyticsClient {
  Future<void> trackNewAppOnboarding();
  Future<void> trackNewAppHome();
  Future<void> trackAppCreated();
  Future<void> trackAppUpdated();
  Future<void> trackAppDeleted();
  Future<void> trackTaskCompleted(int completedCount);
}

But unless you actually call these methods, nothing gets tracked.

So where should you put these calls?

• In widgets?
• In controllers?
• Somewhere else?

Let’s look at both options.

Tracking Events in Widgets and Controllers

Here’s a simple example—a + button on the home page:

The event tracking code looks like this:

IconButton(
  onPressed: () {
    // event tracking code
    unawaited(ref.read(analyticsFacadeProvider).trackNewAppHome());
    // navigation code
    Navigator.of(context).pushNamed(AppRoutes.createApp);
  },
  icon: Icon(Icons.add),
)

In this case, the analytics call is placed directly in the onPressed callback.

💡 The unawaited function is used here to fire the event without blocking. These are fire-and-forget calls—you don’t need to wait for them. More on that here: Use unawaited for your analytics calls.

But if your logic is more complex, it’s better to move analytics calls into a controller.

Here’s an example from a custom controller class:

/// This class holds the business logic for creating, editing, and deleting apps
/// using the underlying AppDatabase class for data persistence.
/// More info here: https://codewithandrea.com/articles/flutter-presentation-layer/
@riverpod
class CreateEditAppController extends _$CreateEditAppController {
  @override
  void build() {
    // no-op
  }

  Future<void> createOrEditApp(App? existingApp, String newName) async {
    final db = ref.read(appDatabaseProvider);
    // * Update the DB
    if (existingApp != null) {
      await db.editAppName(appId: existingApp.id, newName: newName);
    } else {
      await db.createNewApp(name: newName);
    }
    // * Analytics code
    if (existingApp != null) {
      unawaited(ref.read(analyticsFacadeProvider).trackAppUpdated());
    } else {
      unawaited(ref.read(analyticsFacadeProvider).trackAppCreated());
    }
  }

  Future<void> deleteAppById(int appId) async {
    await ref.read(appDatabaseProvider).deleteAppById(appId);
    ref.read(analyticsFacadeProvider).trackAppDeleted();
  }
}

This controller handles mutations and database interactions—so it’s the perfect place to also track related analytics events.

Key Guidelines for Tracking Events

• ❌ Never track events in build(). It can be called dozens of times per second during animations. Same goes for initState() and other lifecycle methods.
• ✅ Track in widget callbacks like onPressed. If the logic is complex, move it out into a controller or service class.
• ✅ Tracking in controllers is ideal. They’re UI-free, easier to test, and already house the logic that triggers the events.
• ❌ Avoid tracking events in the data/networking layer. Events should be tracked at the source (UI layer) for better accuracy.
• ✅ Use unawaited() for all analytics calls. Don’t block UI or care about results—just fire and forget.

Firebase Analytics Integration

So far, we’ve been using the LoggerAnalyticsClient to print events to the console.

But for production apps, you’ll want to plug in a real analytics backend—like Firebase Analytics, Mixpanel, or PostHog.

Thanks to our AnalyticsFacade, you can do this without changing your app code. Just add a new client, register it, and you’re done. That’s the power of separation of concerns.

Let’s walk through integrating Firebase Analytics.

Adding Firebase to your Flutter app

Follow the official guide to add Firebase to your Flutter app.

If your app uses multiple flavors (e.g. dev, staging, prod), the setup is more involved. I cover that in detail here:

• How to Setup Flutter & Firebase with Multiple Flavors using the FlutterFire CLI

Creating the FirebaseAnalyticsClient Class

This is a straightforward implementation of the AnalyticsClient interface using the Firebase SDK:

import 'package:firebase_analytics/firebase_analytics.dart';
import 'package:flutter_ship_app/src/monitoring/analytics_client.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'firebase_analytics_client.g.dart';

class FirebaseAnalyticsClient implements AnalyticsClient {
  const FirebaseAnalyticsClient(this._analytics);
  final FirebaseAnalytics _analytics;

  @override
  Future<void> trackNewAppHome() async {
    await _analytics.logEvent(name: 'new_app_home');
  }

  @override
  Future<void> trackNewAppOnboarding() async {
    await _analytics.logEvent(name: 'new_app_onboarding');
  }

  @override
  Future<void> trackAppCreated() async {
    await _analytics.logEvent(name: 'app_created');
  }

  @override
  Future<void> trackAppUpdated() async {
    await _analytics.logEvent(name: 'app_updated');
  }

  @override
  Future<void> trackAppDeleted() async {
    await _analytics.logEvent(name: 'app_deleted');
  }

  @override
  Future<void> trackTaskCompleted(int completedCount) async {
    await _analytics.logEvent(
      name: 'task_completed',
      parameters: {'count': completedCount},
    );
  }
}

@Riverpod(keepAlive: true)
FirebaseAnalyticsClient firebaseAnalyticsClient(Ref ref) {
  return FirebaseAnalyticsClient(FirebaseAnalytics.instance);
}

Registering the Client with the Facade

Update your analyticsFacadeProvider to include the Firebase client:

@Riverpod(keepAlive: true)
AnalyticsFacade analyticsFacade(Ref ref) {
  final firebaseAnalyticsClient = ref.watch(firebaseAnalyticsClientProvider);
  return AnalyticsFacade([
    firebaseAnalyticsClient,
    if (!kReleaseMode) const LoggerAnalyticsClient(),
  ]);
}

And just like that—no changes to the rest of your app—your events are now being sent to Firebase Analytics.

You’ll see them show up in the Firebase Console:

Here’s what it looks like in my Flutter Tips app:

Flutter App Analytics: Summary

In this article, we covered everything you need to get started with production-grade analytics in your Flutter app:

• ✅ Why analytics is essential for shipping and growing with confidence
• ✅ How to think about and choose the right events to track
• ✅ A simple architecture for quick wins
• ✅ A scalable, type-safe architecture for larger apps and teams
• ✅ How to track events from widgets and controllers
• ✅ How to integrate Firebase Analytics with zero impact on app logic

But hold on—there’s more to shipping analytics in real-world apps.

Before you hit publish, consider:

• Tracking screen views: Use a navigation observer to capture screen transitions automatically.
• Opt-in/out analytics: Let users disable tracking if required (e.g. for GDPR compliance).
• User identification: Link events to logged-in users for cross-device tracking and funnel analysis.
• Mixpanel or PostHog integration: Firebase is free, but tools like Mixpanel offer powerful filtering and reporting—and are much more privacy-friendly.

To go deeper into these topics—and way beyond analytics—check out my latest course. 👇

Flutter in Production

When it comes to shipping and maintaining apps in production, there are many important aspects to consider:

• Preparing for release: splash screens, flavors, environments, error reporting, analytics, force update, privacy, T&Cs.
• App Submissions: app store metadata & screenshots, compliance, testing vs distribution tracks, dealing with rejections.
• Release automation: CI workflows, environment variables, custom build steps, code signing, uploading to the stores.
• Post-release: error monitoring, bug fixes, addressing user feedback, over-the-air updates, feature flags & A/B testing.

My latest course will help you get your app to the stores faster and with fewer headaches.

If you’re interested, you can learn more and enroll here. 👇

• Adaptive mode (Material / Cupertino)
• Default and cancel actions
• Destructive UI style
• Dismissible mode

Super useful for Yes/No, Cancel/Delete scenarios. 👍

Here's a gist with the source code:

• Helper function for showing an adaptive alert dialog (Material, Cupertino)

Feel free to tweak and reuse it in your projects. 🙂

Happy coding!

This has some implications for projects that rely on custom Gradle configurations, such as flavors, code signing, and more.

This article breaks down what changed, how it affects you, and how to avoid common pitfalls.

What's changed?

New projects generated with Flutter 3.29 now have .kts files instead of .gradle:

• android/build.gradle → android/build.gradle.kts
• android/settings.gradle → android/settings.gradle.kts
• android/app/build.gradle → android/app/build.gradle.kts

Before you panic: both Groovy (old) and Kotlin (new) files are fully supported.

If your project is using Groovy .gradle files, you don't need to migrate. Everything will still work with Flutter 3.29.

Only brand-new projects start with .kts files.

That said, if you are working with .kts, there are a few things you’ll want to know. 👇

The New Kotlin DSL Syntax

Let’s play spot-the-difference between these two snippets:

// Example 1 - is this Groovy or Kotlin?
pluginManagement {
    def flutterSdkPath = {
        def properties = new Properties()
        file("local.properties").withInputStream { properties.load(it) }
        def flutterSdkPath = properties.getProperty("flutter.sdk")
        assert flutterSdkPath != null, "flutter.sdk not set in local.properties"
        return flutterSdkPath
    }()

    includeBuild("$flutterSdkPath/packages/flutter_tools/gradle")

    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

plugins {
    id "dev.flutter.flutter-plugin-loader" version "1.0.0"
    id "com.android.application" version "8.1.0" apply false
    id "org.jetbrains.kotlin.android" version "1.8.22" apply false
}

include ":app"

// Example 2 - is this Groovy or Kotlin?
pluginManagement {
    val flutterSdkPath = run {
        val properties = java.util.Properties()
        file("local.properties").inputStream().use { properties.load(it) }
        val flutterSdkPath = properties.getProperty("flutter.sdk")
        require(flutterSdkPath != null) { "flutter.sdk not set in local.properties" }
        flutterSdkPath
    }

    includeBuild("$flutterSdkPath/packages/flutter_tools/gradle")

    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

plugins {
    id("dev.flutter.flutter-plugin-loader") version "1.0.0"
    id("com.android.application") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "1.8.22" apply false
}

include(":app")

Both snippets do the same thing, but there are key differences:

• Groovy uses def for variables; Kotlin uses val.
• Groovy lets you skip parentheses in method calls; Kotlin requires them.
• Groovy assertions use assert; Kotlin uses require.

There are plenty more differences, all neatly documented here:

• Migrate your build configuration from Groovy to Kotlin

But what does this actually mean for your project?

Common Gradle Setup Tasks

Here are the typical things you’ll need to adjust:

1. Set Android NDK, minSdk, targetSdk, Java version
2. Configure code signing
3. Add the com.google.gms.google-services plugin for apps using Firebase
4. Set up multiple flavors

Old tutorials and Stack Overflow answers? Mostly outdated now. Here's how to handle it.

1. Setting the Android NDK, minSdk, targetSdk, Java Version

Same settings as before—just with the correct Kotlin syntax (assignment operator, double quotes for string literals):

...

android {
    namespace = "com.codewithandrea.flutter_ship_app"
    compileSdk = flutter.compileSdkVersion
    ndkVersion = "27.0.12077973" // Updated

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17 // Updated
        targetCompatibility = JavaVersion.VERSION_17 // Updated
    }

    kotlinOptions {
        jvmTarget = JavaVersion.VERSION_17.toString() // Updated
    }

    defaultConfig {
        // TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html).
        applicationId = "com.codewithandrea.flutter_ship_app"
        minSdk = 21 // Updated        
        targetSdk = 34 // Updated
        versionCode = flutter.versionCode
        versionName = flutter.versionName
    }

    ...
}

...

Pro Tip: updating all these values manually is a pain, and I do it so often that I created a script to automate the process. Here's how it works:

• Script to Update the Android Project Settings

Download it here and add it to your project:

• update-android-project.sh

2. Configuring Code Signing

The official Flutter docs about building and releasing an Android app are already updated for the new Kotlin DSL.

Key steps:

• Create an upload keystore
• Reference the keystore
• Configure signing in Gradle

Here's a sample code showing the required changes to the android/app/build.gradle.kts file:

import java.io.FileInputStream
import java.util.Properties

plugins {
   ...
}

val keystoreProperties = Properties()
val keystorePropertiesFile = rootProject.file("key.properties")
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(FileInputStream(keystorePropertiesFile))
}

android {
    // ...

    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties["keyAlias"] as String
            keyPassword = keystoreProperties["keyPassword"] as String
            storeFile = keystoreProperties["storeFile"]?.let { file(it) }
            storePassword = keystoreProperties["storePassword"] as String
        }
    }
    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now,
            // so `flutter run --release` works.
            signingConfig = signingConfigs.getByName("debug")
            signingConfig = signingConfigs.getByName("release")
        }
    }
...
}

3. Adding the com.google.gms.google-services plugin (Firebase)

This is handled automatically when you add Firebase to your app with the FlutterFire CLI.

Resulting settings.gradle.kts:

plugins {
    id("dev.flutter.flutter-plugin-loader") version "1.0.0"
    id("com.android.application") version "8.7.0" apply false
    // START: FlutterFire Configuration
    id("com.google.gms.google-services") version("4.3.15") apply false
    // END: FlutterFire Configuration
    id("org.jetbrains.kotlin.android") version "1.8.22" apply false
}

The same plugin will also be listed in android/app/build.gradle.kts:

plugins {
    id("com.android.application")
    // START: FlutterFire Configuration
    id("com.google.gms.google-services")
    // END: FlutterFire Configuration
    id("kotlin-android")
    // The Flutter Gradle Plugin must be applied after the Android and Kotlin Gradle plugins.
    id("dev.flutter.flutter-gradle-plugin")
}

4. Adding Support for Multiple Flavors

This one is a bit tricky as it requires defining separate product flavors for your app.

The Flutter Flavorizr plugin already handles this for you when you run these processors:

dart run flutter_flavorizr -p android:buildGradle,android:flavorizrGradle,android:androidManifest

If you're doing it manually, open android/app/build.gradle.kts and add this line at the very bottom:

apply { from("flavors.gradle.kts") }

Then, create a android/app/flavors.gradle.kts file with these contents:

import com.android.build.gradle.AppExtension

val android = project.extensions.getByType(AppExtension::class.java)

android.apply {
    flavorDimensions("flavor-type")

    productFlavors {
        create("dev") {
            dimension = "flavor-type"
            applicationId = "com.codewithandrea.flutter_ship_app.dev"
            resValue(type = "string", name = "app_name", value = "Flutter Ship Dev")
        }
        create("stg") {
            dimension = "flavor-type"
            applicationId = "com.codewithandrea.flutter_ship_app.stg"
            resValue(type = "string", name = "app_name", value = "Flutter Ship Stg")
        }
        create("prod") {
            dimension = "flavor-type"
            applicationId = "com.codewithandrea.flutter_ship_app"
            resValue(type = "string", name = "app_name", value = "Flutter Ship")
        }
    }
}

Notes:

• Make sure the flavor names match your flutter run --flavor [name] command.
• Update the applicationId and app name for each flavor.
• In AndroidManifest.xml, set the app label dynamically in the android:label attribute:

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
  <application
    android:label="@string/app_name" <-- updated
    android:name="${applicationName}"
    android:icon="@mipmap/ic_launcher">
    ...
  </application>
  ...
</manifest>

There's much more to adding flavors than what I've shown here. For a full guide, check out my Flutter in Production course.

What If You Need to Recreate Your Android Project?

Old Flutter apps sometimes break on new Android tooling. If you’re stuck, it’s often easier to nuke and recreate the Android folder:

# Commit to git before making any changes
git add . && git commit -m "Working copy"
# Delete android folder
rm -rf android
# Create it again with the Flutter CLI
flutter create . --platforms android --org com.yourorgname
# See what's changed
git diff android
# Reapply previous settings, following steps above
# Run again
flutter run
# All good? Commit to git
git add . && git commit -m "Updated Android project"

When you recreate the Android project from scratch, any old settings you had applied will also be lost. Always run git diff android to see what's changed, and selectively restore any custom settings as needed.

Conclusion

Starting with Flutter 3.29, new projects use the Kotlin DSL for Gradle.

Honestly? I see little real benefit over Groovy. Yet, our tech overlords have decided this is the way, and we have to keep up and learn a new syntax. 🤷‍♂️

My advice:

• If you're not forced to migrate, stick with Groovy.
• If you start fresh or need Kotlin DSL, this guide has you covered.

Need more help shipping your app? Keep reading.

Flutter in Production

Shipping and maintaining apps in production takes more than just writing code:

• Preparing for release: splash screens, flavors, environments, error reporting, analytics, force update, privacy, T&Cs.
• App Submissions: metadata, screenshots, compliance, testing vs distribution tracks, dealing with rejections.
• Release automation: CI workflows, environment variables, custom build steps, code signing, uploading to the stores.
• Post-release: monitoring crashes, fixing bugs, OTA updates, feature flags & A/B testing.

My latest course will help you ship faster and with fewer headaches. Learn more here. 👇

Here's my battle-tested loading strategy:

1. setup fetch interval (flavor-dependent)
2. set default values
3. activate previous values
4. fetch new values (unawaited)
5. add a realtime listener (which is not subject to the minimumFetchInterval)

Want to use this in your apps? Grab it from this gist:

• Flutter Remote Config boilerplate code (using Riverpod)

For more info about common loading strategies, read:

• Firebase Remote Config loading strategies

Flutter in Production

My latest course shows how to use Firebase Remote Config in useful scenarios such as force updates and A/B tests.

Learn more here 👇

Since Flutter 3.29, Impeller is enabled by default on Android, but it can cause some rendering issues on some devices.

If needed, here's how to disable it and revert to the old Skia renderer. 👇

See this changelog for some Impeller issues that were recently fixed:

• Flutter 3.29 Changes

Happy coding!

This month’s newsletter covers:

• Flutter’s updated 2025 roadmap
• What’s new in the latest beta release
• Upcoming formatter changes and new IDE assists in Dart 3.8
• Hand-picked articles about common Flutter mistakes, app security, and more

Let’s dive in! 🚀

🧭 Flutter 2025 Roadmap Update

The Flutter team has shared their official 2025 roadmap, outlining key focus areas for the year.

Highlights include:

• Interoperability on iOS & Android: Continue experimental work to support direct calls from Dart to Swift/Obj-C (iOS) and Kotlin/Java (Android). This includes calling APIs that can only be invoked on the main OS/platform thread.
• Web Platform: Hot reload support, better performance, improved accessibility, and the removal of legacy HTML/JS libraries.
• Core Framework: Investigate changes to reduce verbosity in Flutter widget code and streamline development.
• Dart Language Improvements: Enhancements to code generation, new language features, and a refactored analyzer for better performance and tooling.

Personally, I’m most excited about hot reload for Flutter web (finally!), as well as new Dart language features and build_runner improvements.

Learn more here:

• 2025 Roadmap

🆕 Wanna help Flutter? Try out the beta!

The last stable release—Flutter 3.29—introduced some big changes (like Impeller on Android) and left many developers frustrated with regressions and waiting for hotfixes.

The Flutter team is now encouraging developers to test the latest beta and report bugs early. If you want to help shape the next stable release, now’s a great time to get involved:

• Wanna help Flutter? Try out the beta!

I think this will help iron out potential issues before the next stable release. It also means we can already try out some of the upcoming changes. 👇

⌨️ Dart 3.8: Formatter Improvements

The new formatting style introduced in Dart 3.7 was quite controversial, with many people against the decision to automatically remove trailing commas.

The good news? Dart 3.8 will introduce an opt-in formatter config to preserve trailing commas.

To try it out, upgrade to the latest beta and add the following to your analysis_options.yaml:

formatter:
  trailing_commas: preserve

More info:

• Dart 3.8 will contain an updated formatter that can preserve commas

⚡️ New IDE Assists Coming to Dart 3.8

Dart 3.8 also brings a bunch of new code assists and quality-of-life improvements:

• Smarter code completion
• Quick wraps with FutureBuilder and ValueListenableBuilder
• Rename closure parameters
• Better show/hide combinator assists for imports

For the full list, check the changelog:

• Dart 3.8 Analyzer Changelog

Shoutout to @FMorschel for driving many of these improvements!

⚠️ Hot Restart Bug on iOS (Flutter 3.29)

Some devs (myself included) have hit an annoying issue where hot restart hangs on iOS.

Thankfully, Luke Pighetti filed an issue, and the Flutter team already confirmed that it's fixed on master. If you're affected, read this comment for a temporary workaround.

For more details, here's the full issue:

• hot restart locks up on iOS

📚 Articles from the Community

Here are some standout reads from the past month:

📝 15 Common Mistakes in Flutter and Dart Development (and How to Avoid Them)

From memory leaks and rebuild traps to architectural missteps, Majid Hajian shares hard-earned lessons from 7 years of Flutter development.

This article covers:

• Real-world mistakes in large Flutter apps
• How to catch issues with tools like DCM
• Strategies for better maintainability and performance

Read on to explore common pitfalls and learn how to avoid them:

• 15 Common Mistakes in Flutter and Dart Development (and How to Avoid Them)

🛡️ OWASP Top 10 for Flutter (Security Series)

Majid is also behind this new series on Flutter security, applying the OWASP Mobile Top 10 to real-world Flutter apps.

So far, three parts are out:

• M1: Mastering Credential Security in Flutter
• M2: Inadequate Supply Chain Security in Flutter
• M3: Insecure Authentication and Authorization in Flutter

If you’re building apps that handle sensitive data, this is essential reading.

📝 TypeSet: WhatsApp-Style Text Formatting in Flutter

TypeSet is a small but powerful package that lets you style inline text with a WhatsApp-style syntax:

TypeSet('Hello *bold* _italic_ ~strikethrough~ #underlined# `monospace` text');

Perfect for chat apps or UIs that need rich text formatting without complexity.

To learn more, check out the package on pub.dev or read the full article:

• TypeSet: Bringing WhatsApp-Style Text Formatting to Your Flutter Apps

📢 Latest from Code with Andrea

No new articles from me this month—I’ve been focused on finishing my Flutter in Production course.

The good news? It’s now complete with over 200 lessons! 🎉

To celebrate this, I’m running a Spring Sale next week. If you’ve been thinking about enrolling, here are all the details about the upcoming sale:

• Flutter in Production is Complete – and 50% Off Next Week! 🎉

Until Next Time

I recently stumbled across a new cool site called Is Flutter dead?—glad to see it still says no! 😅

As the Flutter ecosystem continues to grow, I’m already brainstorming new content and ideas for future courses!

So stay tuned, and as always, happy coding!

debugRepaintRainbowEnabled helps you discover widgets/areas that unexpectedly repaint in your app.

Here's how to set it 👇

If you discover widgets that repaint when they shouldn't, wrap them with RepaintBoundary.

This can improve rendering performance, but only use it when necessary (RepaintBoundary has some extra CPU/memory cost).

Learn more here:

• RepaintBoundary class

Happy coding!

When working with forms in Flutter, numeric inputs need special attention.

To improve the user experience:

1. Add keyboardType: TextInputType.number
2. Add FilteringTextInputFormatter.digitsOnly as an inputFormatter

Your users will thank you!

Happy coding!

You can show native-looking URL links on Flutter web using TextSpan:

• Create a Text.rich or SelectableText.rich widget
• Make it look like a web link with a custom text style
• Add a gesture recognizer to open the web link
• Customize the mouse cursor style

As an alternative, wrap the whole thing with a Link widget (from the url_launcher package):

Here's a complete URLTextWidget that implements the whole thing, in 40 lines of code:

• URLTextWidget (GitHub Gist)

Happy coding!

A/B tests help you make data-driven decisions and increase conversions in your app.

To run an A/B test: 1. Choose a metric to improve 2. Formulate a hypothesis 3. Split the audience into cohorts 4. Run an experiment, analyze the results, and roll out the winner 🥇

Tools like Firebase Remote Config and PostHog make it easy to run A/B tests in your apps.

For example, here's a report from an A/B test I ran on my Flutter Tips app:

But how do you implement this in practice?

My latest course includes an entire module about Feature Toggles and A/B Tests.

Learn more here:

Static release toggles let you release unfinished code without activating it in production.

This is common with large projects that practice trunk-based deployment and continuous delivery.

For more flexibility, you can implement this with --dart-define. 👇

Static release toggles are easy to use, but some use cases require more flexibility:

• Experiment by showing different variants to separate user cohorts (A/B and multivariate testing)
• Gradually roll out a feature to users, rather than releasing it to everyone at once

Complex use cases require dynamic toggles and some dedicated infrastructure to manage them, and my latest course covers this topic in much more detail.

Learn more here. 👇

In addition to String.fromEnvironment, Dart also supports:

• int.fromEnvironment
• bool.fromEnvironment

Very handy when reading environment variables from your .env files:

To learn more about environment variables and best practices for storing API keys, read:

• How to Store API Keys in Flutter: --dart-define vs .env files

Happy coding!

Still, there are some exciting updates worth sharing:

• Hot reload finally comes to Flutter web (3.31 beta)
• Practical Flutter Architecture
• Lesser-known Dart & Flutter features you should be using
• Preview of the unified provider syntax for the next Riverpod release
• Latest from Code with Andrea
• Some thoughts on the "vibe coding" trend with AI

Let’s dive in! 🚀

Flutter News and Articles

⚡️ Hot Reload on Flutter Web (Beta)

Hot reload is one of Flutter’s biggest strengths, making development incredibly fast. But until now, Flutter Web didn’t support it—despite being the #2 most upvoted feature request.

That’s finally changing with Flutter 3.31 beta! 🎉 You can now try hot reload on Flutter Web before it hits stable.

To enable it, follow these steps:

• Hot Reload on Flutter Web (Beta)

For all the details, check out the original thread on Reddit:

• Try Out Hot Reload on Flutter Web

📝 Practical Flutter Architecture

App architecture remains one of the hottest topics in Flutter development—a good structure can make or break your app in the long run.

Existing resources include:

• The official Flutter architecture guide
• My own articles: Riverpod Architecture and Comparing Flutter Architectures

Most recently, Thomas Burkhart also decided to share his own take on the topic.

His article reiterates the benefits of layered architecture, offers a summary of approaches such as MVVM, MVC, MVU (none of which are particularly suited for Flutter), and introduces a pragmatic approach that has worked well for him.

Whether you're a seasoned Flutter developer or just starting out, this is well worth a read:

• Practical Flutter Architecture

Bonus: He also forked the Flutter compass app and refactored it using his approach:

• Compass Fork (Refactored)

Like Thomas, I also wasn’t fully satisfied with the official compass app and I've been meaning to refactor it for some time. Hopefully, I'll be able to revisit this soon!

📝 10 Lesser-Known Dart & Flutter Features You Should Use

As you advance in Flutter development, you'll want to make the most of the language and framework features.

In this article, Majid Hajian shares 10 advanced APIs that help various aspects of your code, including:

• Better async handling
• Improved error handling and debugging
• Attaching metadata to objects that can’t be subclassed

Each technique is backed by real-world use cases, making it easy to apply in your projects:

• 10 Lesser-Known Dart and Flutter Functionalities You Should Start Using

💡 New Unified Provider Syntax for Riverpod

While Riverpod is a very popular package, not everyone is happy with the current API:

• ❌ Too many provider types
• ❌ Code generation is slow for large apps

Since Dart macros were canceled (details here), Rémi Rousselet went back to the drawing board and proposed a new, simplified provider syntax that eliminates code-gen.

My first impression? This is a very positive step forward.

If you use Riverpod, you can find the proposal here and share your feedback:

• Unified syntax for providers, without code-generation

While the proposal is still in the early stages, it is very detailed and gives us a glimpse of what Riverpod 3.0 might look like.

Latest from Code with Andrea

Since last month, I have published:

• New Course Modules → Shorebird & Screenshot Automation
• 10 New Flutter Tips → Check them out
• New Article about Refactoring 👇

📝 Why You Should Refactor Before Adding New Features

Refactoring is about making future changes easier. When done right:

• New features integrate smoothly instead of feeling bolted on.
• Tech debt is reduced, making maintenance less painful.
• Code reviews are faster, since changes are smaller and more focused.

In this article, I share a real-world example of how refactoring has helped me ship a new feature while keeping my codebase flexible and maintainable:

• Why You Should Refactor Before Adding New Features

Some Thoughts on Vibe Coding with AI

The term vibe coding was recently coined by Andrej Karpathy (a leading AI researcher and engineer), and it now keeps popping up in my feeds.

The idea?

AI-driven development where LLM-based IDEs (like Cursor) do all the work for you, to an extent where:

"You fully give in to the vibes, embrace exponentials, and forget that the code even exists." — Andrej Karpathy

At first, I assumed that in the hands of inexperienced devs, this would lead to catastrophic security flaws. But I also see the appeal—especially for rapid prototyping and non-production apps.

If you’re curious, here are some thought-provoking takes on vibe coding:

• Not all AI-assisted programming is vibe coding (but vibe coding rocks)
• "Vibe Coding" vs Reality
• Vibe Coding is a Dangerous Fantasy

Have you tried vibe coding with Flutter? I’d love to hear your thoughts!

Until Next Time

With my Flutter in Production course nearing completion, I’m excited to experiment with new ideas and projects.

Who knows—maybe I’ll even try vibe coding myself and see how far I can take it before everything falls apart. 😅

Stay tuned—and as always, happy coding! 🎉

Hot-reload is available on Flutter web! ⚡️

To enable it:

• Upgrade to Flutter 3.32 stable
• Run your app with --web-experimental-hot-reload

For the best experience in VSCode:

• Enable hot reload on save
• Add a web launch configuration 👇

Check this post for all the details:

• Try out hot reload on the web with the latest Flutter beta

Happy coding!

Rather than uploading your app store screenshots manually, you can automate the process with Fastlane!

Here's how 👇

Before uploading to the App Store, fastlane will show a preview so you can check if everything looks good.

You can skip this by passing force: true to the upload_to_app_store lane (useful for non-interactive CI workflows).

Video Preview

Here's a preview showing how to export screenshots from Figma and upload them with Fastlane, in less than one minute:

Flutter in Production

My latest course includes a whole module about screenshot automation, covering:

• ✅ Tips for better screenshots
• ✅ Capturing screenshots with Maestro
• ✅ Editing them with Figma
• ✅ Uploading them with Fastlane (locally & on CI)

Learn more here:

UI testing frameworks like Maestro and Appium rely on Flutter’s semantics tree to interact with your app UI.

If your app is localized, you can make your UI tests more robust by adding a semantic identifier to your widgets:

Here's how. 👇

If you want to dig deeper, here's an excellent article explaining how Flutter's semantics tree maps with the native accessibility tree:

• The power of open-source. Making Maestro work better with Flutter

To learn more about UI testing, screenshot generation, and more, check the latest module in my Flutter in Production course:

• Introduction to Automated Screenshot Generation

Instead of taking screenshots manually for each device & language, you can automate it with Maestro!

Here's a video preview:

How to use this in practice?

Simply write a YAML file to define how Maestro should interact with your app UI and call takeScreenshot as needed.

Super easy—no test harness required! 🚀

Getting Started

To get started, check the official docs:

• What is Maestro?

Flutter in Production course

My latest course includes a whole module about screenshot automation, covering:

• ✅ Tips for better screenshots
• ✅ Capturing screenshots with Maestro
• ✅ Editing them with Figma
• ✅ Uploading to the stores with Fastlane (locally & on CI)

Learn more here:

If you want to take better screenshots for your Play Store listings, you can enable Demo Mode in the Android settings.

Here's how to enable this. 👇

Happy coding!

You can use this command to clean up the iOS status bar before taking screenshots:

xcrun simctl status_bar booted override --time 09:41 --batteryState charged --batteryLevel 100 --cellularBars 4

Then, you can take screenshots manually (CMD+S on macOS), or automate the process with Maestro.

Once you're done, reset the status bar like this:

xcrun simctl status_bar booted clear

Happy coding!

New apps created with Flutter 3.29 use the new Gradle Kotlin DSL on Android.

This may affect you if you rely on CLI tools that don't support the new syntax.

Here's what you need to know. 👇

Happy coding!

You can run flutter run --route /path/to/route to start your Flutter app from a specific route.

This works with named routes (nav 1.0) and the router APIs (nav 2.0).

Super useful for debugging nested routes when you need to hot-restart.

Happy coding!

At this point, you have two choices:

1. Charge ahead—make it work by building on top of the existing code.
2. Take a step back—clean things up first, then implement the feature with confidence.

Option 1 might feel faster, but it usually leads to disaster:

• Your new code works… kind of. But it doesn't feel right—hello, tech debt.
• You’re unsure if everything plays nicely together, and subtle bugs creep in.
• Your PR balloons in scope, making reviews painful and frustrating.

Meanwhile, your boss (who is very easily impressed by those wonderful AI agents) is breathing down your neck and questioning your abilities. 😭😱

Before you quit tech and become a farmer (no shame in that), let me share a story about refactoring—one that helped me ship a feature smoothly instead of wrestling with broken code.

As part of this, we'll explore a real-world example of:

• ephemeral vs application state in Flutter
• how to manage navigation and communication across screens
• how to blend reactive updates with imperative APIs (as needed by ScrollControllers)

A Tale About Refactoring

Recently, I decided to add wide-screen support to my Flutter tips app:

That is, given these two screens that were initially designed for mobile:

I wanted to show them side by side and enable seamless navigation on iPad:

Making this UI adaptive is quite easy. All you need is:

• A responsive layout that uses a split-view on wide screens, and regular push/pop navigation on mobile.
• Some conditional logic based on MediaQuery.sizeOf(context) or LayoutBuilder to choose between the split-view and single-pane layout depending on a layout breakpoint.

When given a task like this, it's tempting to just add the new feature as a single PR.

But, as we're about to find out, there's more than meets the eye.

Ephemeral State, Application State, and Navigation

To set the stage, let's revisit the mobile-only version of the app:

Based on the screenshots above, can you guess how I was keeping track of the currently selected tip index?

Of all possible options, I decided to go with the good old setState approach.

That is, I had a _MarkdownTipsPageViewState class that I was using for:

• storing the _currentTipIndex as ephemeral state
• updating this state via the _updateTipIndex method

class _MarkdownTipsPageViewState extends ConsumerState<MarkdownTipsPageView> {
  // both initialized in initState
  late PageController _pageController;
  late int _currentTipIndex;

  void _updateTipIndex(int tipIndex) {
    setState(() {
      _currentTipIndex = tipIndex;
      // Used to store the tip index in shared preferences (but not too relevant here)
      ref.read(currentTipIndexStoreProvider.notifier).setTipIndex(tipIndex);
    });
  }
  ...
}

In the build method, I had an IconButton with a callback for pushing the tipsList route, and updating the state if a new tip index was returned:

IconButton(
  icon: const Icon(Icons.search),
  tooltip: 'Search tips',
  onPressed: () async {
    // Push the "tips list" route and wait for the result
    final newIndex = await Navigator.of(context).pushNamed<int>(
      AppRoutes.tipsList,
      arguments: _currentTipIndex,
    );
    // If a new tip index is returned
    if (newIndex != null) {
      // Update the state and jump to the new page
      _updateTipIndex(newIndex);
      _pageController.jumpToPage(currentPage);
    }
  },
)

Accordingly, my TipsListViewScreen had an onSelected callback that was used to return the selected tip index via Navigator.pop:

TipsListViewScreen(
  flutterTips: tips,
  initialTipIndex: initialTipIndex,
  // Pop the index so the parent route can update the state
  onSelected: (index) => Navigator.of(context).pop(index),
)

Here's a diagram showing the interaction between the two screens:

In summary:

• The _currentTipIndex variable is the main source of truth that determines the currently selected tip.
• It is stored in the _MarkdownTipsPageViewState class, but it is also passed to the TipsListViewScreen via the initialTipIndex argument and updated via the onSelected callback.

This works just fine on mobile, but let's now consider the wide-screen version of the app:

With the setup described above, the app would behave like this:

• When swiping between pages, the _currentTipIndex would be updated in the page view screen, but this change would not be reflected in the list view screen.
• Calling Navigator.pop from the list view would break the navigation completely (in split view mode, we're already at the root of the navigation stack).

Such inferior and broken UX is absolutely unacceptable. So how did I fix it?

From Ephemeral to Application State

The core issue was that my _currentTipIndex lived as ephemeral state inside a widget, making cross-screen updates clunky.

Here's a better approach:

• Promote the current tip index to application state
• Use a ValueNotifier or Riverpod's own Notifier class to store it

This way, both pages can mutate the notifier and update the UI when needed. Here's an interactive demo of the solution in action:

It works like this:

• When you swipe between pages, the correct item is highlighted and centered in the list.
• When you select an item from the list, the page view immediately jumps to the corresponding tip.

Much better!

You can make this work by using ValueNotifier or Riverpod's own Notifier class. I won't cover all the details here, but you can take this challenge as an exercise if you want: Page View / List View syncing challenge

What About Navigation?

On mobile, we can use the search icon to navigate to the tips list screen:

But on iPad, this icon is hidden since both pages are visible side by side:

To achieve this, I ended up using a small LayoutBreakpoints helper class:

if (!LayoutBreakpoints.isSplitView(screenSize))
  IconButton(
      icon: const Icon(Icons.search),
      tooltip: 'Search tips',
      // Push the tips list screen (application state is updated elsewhere)
      onPressed:
          () => Navigator.of(context).pushNamed(AppRoutes.tipsList),
    ),