DEV Community: flutter

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

Mario Ezquerro — Mon, 17 Aug 2026 09:00:16 +0000

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

When building a lightweight container orchestrator like Gubernator (gbnt) — designed to strike the perfect balance between the simplicity of Docker Swarm and the flexibility of Nomad under a Roman Empire theme — a critical milestone inevitably emerges: Enterprise Security and Access Control.

While a default admin credential works well for local dev environments, moving into enterprise production with multi-disciplinary engineering teams demands:

Corporate Single Sign-On (SSO) with Microsoft Active Directory and OpenLDAP.
Role-Based Access Control (RBAC) to clearly segregate who can deploy stacks, restart containers, or audit telemetries in read-only mode.
Dynamic Group Mapping from corporate security groups (memberOf) to orchestrator roles.
Emergency Break-Glass Access (Local Administrator) in case network directory controllers are unreachable.

In this article, we explore the complete architecture of the enterprise security engine introduced in Gubernator v2.20.0, and how we leveraged Google Antigravity (AGY) as an autonomous AI pair programmer to design, implement, test, and verify this Full-Stack feature (Go + Flutter Web) across a live 3-node cluster.

The Security Architecture

We designed a decoupled, asymmetric architecture connecting identity providers, REST API middleware, and the Flutter Web UI:

 ┌────────────────────────────────────────────────────────┐
 │                   GUBERNATOR WEB UI                    │
 │   - Modern Login Screen with Domain / AD Selector      │
 │   - Header Role Badge: Admin |  Ops |  Read-Only.      │
 └──────────────────────────┬─────────────────────────────┘
                            │ (REST /api/auth/login)
                            ▼
 ┌────────────────────────────────────────────────────────┐
 │             GUBERNATOR CORE AUTH ENGINE (Go)           │
 │  - Local Emergency Admin (admin / admin fallback)      │
 │  - Multi-Server Active Directory / OpenLDAP Dialers    │
 │  - LDAPS (Port 636) & StartTLS (Port 389) Handshake    │
 │  - Dynamic Group DN -> RBAC Role Resolution            │
 │  - Cryptographic HMAC-SHA256 JWT Token Signing         │
 └─────────────┬────────────────────────────┬─────────────┘
               │                            │
               ▼                            ▼
 ┌───────────────────────────┐ ┌──────────────────────────┐
 │  Primary Active Directory │ │ Secondary LDAP Server    │
 │   dc1.corporate.local     │ │   dc2.dr-site.local      │
 └───────────────────────────┘ └──────────────────────────┘

Role-Based Access Control (RBAC) Matrix

We established three distinct operational tiers:

Operational Capability	`admin`	`operator`	`readonly`
Overview, Metrics & SRE Telemetry	✅ Full	✅ Full	✅ Full
Deploy Stacks (`docker-compose.yml`)	✅ Full	✅ Full	❌ Restricted
Redeploy & Duplicate Stacks	✅ Full	✅ Full	❌ Restricted
Delete Stacks	✅ Full	❌ Restricted	❌ Restricted
Task Lifecycle (Start / Stop / Restart)	✅ Full	✅ Full	❌ Restricted
Container & Node Terminal Shell	✅ Full	✅ Full	❌ Restricted
Node Fleet Management (Drain / Activate / Leave)	✅ Full	❌ Restricted	❌ Restricted
Caddy TLS Certificates & Ingress Routes	✅ Full	❌ Restricted	❌ Restricted
Active Directory & LDAP Directory Settings	✅ Full	❌ Restricted	❌ Restricted
Grafana, Jaeger & Weave Scope Dashboards	✅ Full	✅ Full	✅ Full

💻 The Go Backend Engine (`internal/auth/`)

For LDAP/Active Directory interactions, we used github.com/go-ldap/ldap/v3, and for session management github.com/golang-jwt/jwt/v5.

1. Two-Phase Bind & Credential Verification

Authentication follows a secure two-phase pattern:

Connect and perform a Service Account Bind (BindDN / BindPassword) to query the directory.
Search for the user object using a configurable LDAP filter (defaulting to (&(objectClass=user)(sAMAccountName=%s))).
Open a secondary connection and perform a Direct User Bind with the user-submitted password against the domain controller.

func AuthenticateLDAP(cfg db.LDAPConfig, username, password string) (*AuthResult, error) {
    conn, err := ConnectLDAP(cfg)
    if err != nil {
        return nil, err
    }
    defer conn.Close()

    // 1. Initial service account bind
    if cfg.BindDN != "" && cfg.BindPassword != "" {
        if err := conn.Bind(cfg.BindDN, cfg.BindPassword); err != nil {
            return nil, fmt.Errorf("service account bind failed: %w", err)
        }
    }

    // 2. Search for the user
    filter := fmt.Sprintf(cfg.UserFilter, ldap.EscapeFilter(username))
    searchReq := ldap.NewSearchRequest(
        cfg.BaseDN,
        ldap.ScopeWholeSubtree, ldap.NeverDerefAliases, 0, 0, false,
        filter,
        []string{"dn", "displayName", "mail", "memberOf"},
        nil,
    )
    sr, err := conn.Search(searchReq)
    if err != nil || len(sr.Entries) == 0 {
        return nil, errors.New("user not found in directory")
    }

    userEntry := sr.Entries[0]

    // 3. Direct user bind to verify password
    userConn, err := ConnectLDAP(cfg)
    if err != nil {
        return nil, err
    }
    defer userConn.Close()

    if err := userConn.Bind(userEntry.DN, password); err != nil {
        return nil, errors.New("invalid credentials")
    }

    // 4. Map groups to RBAC role
    groups := userEntry.GetAttributeValues("memberOf")
    role := ResolveRole(cfg, groups)

    return &AuthResult{
        UserDN:      userEntry.DN,
        Username:    username,
        DisplayName: userEntry.GetAttributeValue("displayName"),
        Email:       userEntry.GetAttributeValue("mail"),
        Groups:      groups,
        Role:        role,
    }, nil
}

2. Dynamic Group-to-Role Mapping

Gubernator inspects the user's memberOf group list and matches them against the configured group DNs:

func ResolveRole(cfg db.LDAPConfig, userGroups []string) Role {
    matchesGroup := func(targetGroup string) bool {
        if targetGroup == "" { return false }
        target := strings.ToLower(strings.TrimSpace(targetGroup))
        for _, g := range userGroups {
            if strings.ToLower(strings.TrimSpace(g)) == target {
                return true
            }
        }
        return false
    }

    if matchesGroup(cfg.AdminGroupDN) { return RoleAdmin }
    if matchesGroup(cfg.OperatorGroupDN) { return RoleOperator }
    if matchesGroup(cfg.ReadOnlyGroupDN) { return RoleReadOnly }

    return NormalizeRole(cfg.DefaultRole)
}

The Flutter Web UI Experience

Gubernator's Web Dashboard is built with Flutter Web and Material Design 3, compiled and embedded directly into the Go binary (go:embed).

1. Modern Login Screen with Domain Selector

Operators can select their target authentication provider (Corporate Active Directory, DR Site LDAP, or Local Administrator):

2. Active Directory Management & Diagnostics

In the new Seguridad & AD tab, cluster administrators can configure directory servers, TLS certificates, and run a live "Test Connection" diagnostic tool:

3. Real-Time Role Badges & Contextual Guards

The dashboard header displays the active user and their assigned role (ADMIN, ⚡ OPERATOR, READ-ONLY). Mutating actions (e.g., Delete Stack, Drain Node, Shell) are automatically disabled for read-only audit accounts.

How Google Antigravity Accelerated Development

We utilized Google Antigravity (AGY) as an autonomous AI pair programmer to build this feature end-to-end. AGY accelerated the development cycle through several key workflows:

Architectural Planning:
Before writing code, Antigravity produced a comprehensive implementation plan (implementation_plan.md) outlining the GORM schema changes (LDAPConfig), RBAC authorization matrix, and API routes.
Synchronized Full-Stack Implementation:
In a single coordinated session, Antigravity:
- Built the Go internal/auth/ engine with LDAP dialers, JWT session handlers, and Gin middlewares.
- Applied SQLite database auto-migrations.
- Implemented the Flutter Web UI (login_screen.dart, security_page.dart, and state models).
- Updated existing views (legions_page.dart, tasks_page.dart, centurions_page.dart) with RBAC permission guards.
Live Cluster Testing & Verification:
Using automated commands across a 3-node multipass cluster (gbnt-manager, gbnt-worker1, gbnt-worker2), Antigravity:
- Deployed and hot-restarted the ARM64 binaries.
- Tested REST endpoints via curl (valid login, invalid login, LDAP connection tests, configuration lifecycle).
- Executed Go unit tests (go test ./internal/auth/...) with 100% pass rates.
Automated Documentation & Release:
- Generated high-fidelity visual UI showcases.
- Authored complete documentation in docs/auth-rbac.md and validated MkDocs builds in strict mode.
- Bumped the version to v2.20.0, created git release tags, and triggered GitHub Pages publishing.

Conclusion & Open Source

Adding Active Directory SSO and RBAC allows teams to deploy Gubernator in enterprise production environments that require enterprise security compliance without the operational overhead of Kubernetes.

Check out Gubernator and try it out:

GitHub Repository: github.com/mario-ezquerro/gubernator
Official Documentation: mario-ezquerro.github.io/gubernator
Active Directory & RBAC Guide: docs/auth-rbac.md

What do you think about this hybrid approach to container orchestration? Let us know your thoughts and suggestions in the comments!

Building an AI Assistant: flutter nodejs ai browser automation

Umair Bilal — Mon, 17 Aug 2026 04:37:20 +0000

This article was originally published on BuildZn.

Figured out how to tame web automation with an LLM. Everyone talks about AI agents, but getting them to reliably interact with dynamic web pages through a full-stack setup is a whole different beast. Spent weeks wrestling with flaky selectors and race conditions. Here's the blueprint that finally clicked for my personal AI assistant build using Flutter, Node.js, and browser automation. This setup slashed my daily busywork by a solid 60%.

Why Full-Stack AI Browser Automation?

My initial goal was simple: stop wasting time on repetitive online tasks. Think filling out expense reports, aggregating data from specific sites, or managing content on platforms without proper APIs. I needed a personal AI assistant build that could understand high-level commands, translate them into browser actions, and then report back. This isn't just about scripting; it's about an LLM making decisions based on current page state and a broader goal.

I looked at a few options. Pure Python? Nah, I'm a Flutter guy, wanted a native UI. JavaScript-only? Possible, but I prefer Node.js for backend heavy lifting and orchestration. So, the stack solidified:

Flutter: For the cross-platform UI. Desktop support for Windows/macOS was key for a desktop assistant. This gives us flutter desktop automation capabilities on the client side.
Node.js: The brain. This is where the AI agent logic lives, handles API calls to LLMs, and orchestrates Playwright. Essentially, our nodejs playwright agent server.
Playwright: The hands. Robust, fast, and handles modern web elements way better than Puppeteer for my needs.

The core challenge? Bridging the LLM's high-level reasoning with the nitty-gritty of browser interactions. Getting an AI to decide "click this specific button" or "fill this form field" when the page layout changes, or elements appear dynamically, that's where the real work is.

The Architecture: Orchestrating LLM Decisions with Browser Actions

Here's the setup, simplified:

Flutter UI: User sends a command (e.g., "Summarize unread emails from Project X in Gmail").
Node.js Backend (API): Receives the command.
Initial LLM Call (Planner): The backend sends the command to an LLM (e.g., Claude 3.5 Sonnet, or OpenAI's GPT-4o). This "Planner" LLM identifies the initial high-level steps. For Gmail, it might be "1. Navigate to Gmail. 2. Log in. 3. Find unread emails. 4. Filter for Project X. 5. Extract summaries."
Action Executor Loop:
- Node.js initializes Playwright.
- For each step from the Planner, Node.js tells Playwright to perform an action (e.g., await page.goto('https://gmail.com')).
- Observation/Reflection (LLM Call - Actuator): After each action, Node.js grabs the current page content (or specific elements). This observation, along with the overall goal and previous steps, is sent back to the LLM. The "Actuator" LLM's job is to decide the next precise browser action (e.g., click on [aria-label="Email address"], fill with myemail@gmail.com, press 'Enter').
- This loop continues until the overall goal is met or an error occurs.
Result Reporting: Once the task is done, the extracted data or status is sent back to the Flutter UI.

Key Components & Their Roles:

Flutter (Client):
- Sends user intents via HTTP requests to Node.js.
- Displays real-time status updates and final results.
- Provides a simple UI for configuration and task management. It's truly a cross platform ai assistant client.
Node.js (Backend/Agent Orchestrator):
- Express API: Handles requests from Flutter.
- LLM Integration: Uses @anthropic-ai/sdk or openai libraries. I used Claude 3.5 Sonnet for its cost-effectiveness and context window.
- Playwright: @playwright/test for browser control.
- Task Management: Simple state machine to track ongoing browser sessions and agent steps.

Building the Brain: Node.js, LLMs, and Playwright

Let's get into the code.

1. Flutter UI (Simplified)

On the Flutter side, it's pretty standard HTTP stuff.

// lib/services/ai_service.dart
import 'dart:convert';
import 'package:http/http.dart' as http;

class AIService {
  final String baseUrl = 'http://localhost:3000/api/agent'; // Your Node.js backend

  Future<String> runBrowserTask(String taskDescription) async {
    try {
      final response = await http.post(
        Uri.parse('$baseUrl/start'),
        headers: {'Content-Type': 'application/json'},
        body: jsonEncode({'task': taskDescription}),
      );

      if (response.statusCode == 200) {
        final data = jsonDecode(response.body);
        return data['result'] ?? 'Task completed.';
      } else {
        return 'Error: ${response.statusCode} - ${response.body}';
      }
    } catch (e) {
      return 'Network error: $e';
    }
  }
}

// In your Flutter widget:
// import 'package:your_app/services/ai_service.dart';
// final aiService = AIService();
// String result = await aiService.runBrowserTask("Go to Google, search 'FarahGPT', click first link, tell me the title.");
// print(result);

This just kicks off the task. The real magic happens on Node.js.

2. Node.js Backend & Agent Loop

First, set up a basic Express server.

// server.js
const express = require('express');
const { chromium } = require('playwright');
const { Anthropic } = require('@anthropic-ai/sdk'); // Or OpenAI

const app = express();
const port = 3000;

app.use(express.json());

const anthropic = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY, // Make sure you set this!
});

// A simple in-memory store for ongoing sessions (for demo)
const activeSessions = {};

app.post('/api/agent/start', async (req, res) => {
  const { task } = req.body;
  if (!task) {
    return res.status(400).json({ error: 'Task description is required.' });
  }

  const sessionId = Date.now().toString(); // Unique session ID
  activeSessions[sessionId] = { task, browser: null, page: null, history: [] };

  try {
    const result = await runAgentTask(sessionId, task);
    delete activeSessions[sessionId]; // Clean up
    res.json({ sessionId, result });
  } catch (error) {
    console.error(`Agent task failed for session ${sessionId}:`, error);
    delete activeSessions[sessionId];
    res.status(500).json({ error: error.message, sessionId });
  }
});

app.listen(port, () => {
  console.log(`Node.js AI agent backend listening on http://localhost:${port}`);
});

// ... rest of the agent logic below

Now, the runAgentTask function, which orchestrates the LLM and Playwright:

// agent.js (or integrated into server.js)
const { chromium } = require('playwright');
const { Anthropic } = require('@anthropic-ai/sdk');
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY }); // Re-init for clarity

async function runAgentTask(sessionId, initialTask) {
  const session = activeSessions[sessionId];
  if (!session) throw new Error('Session not found.');

  const browser = await chromium.launch({ headless: true }); // Change to false for debugging
  const page = await browser.newPage();
  session.browser = browser;
  session.page = page;

  let currentObservation = `Goal: ${initialTask}. Current URL: ${page.url()}.`;
  let history = [];
  let steps = 0;
  const MAX_STEPS = 10; // Prevent infinite loops

  // Initial planning phase (optional, can be merged into the main loop)
  const initialPlan = await anthropic.messages.create({
    model: "claude-3-5-sonnet-20240620",
    max_tokens: 500,
    messages: [
      {"role": "user", "content": `You are an expert browser automation agent. Your goal is: "${initialTask}". Based on this, what are the high-level steps to achieve this? List them clearly, e.g., "1. Navigate to X. 2. Login. 3. Do Y.". Then, what is the very first specific browser action I should take? Be precise.`}
    ]
  });
  console.log('Initial Plan:', initialPlan.content[0].text);
  history.push({ role: 'assistant', content: initialPlan.content[0].text });


  while (steps < MAX_STEPS) {
    steps++;

    // Add current page state to observation
    let pageContent = '';
    try {
      // Get the outer HTML of the body or a relevant part
      pageContent = await page.evaluate(() => document.body.outerHTML);
    } catch (e) {
      console.warn('Could not get page content:', e.message);
      pageContent = `Error getting page content: ${e.message}`;
    }

    currentObservation = `Current URL: ${page.url()}\nPage content snapshot (truncated): ${pageContent.substring(0, 1000)}\n\nGoal: ${initialTask}\n\nWhat is the NEXT precise browser action to take? Respond ONLY with a JSON object. Format: {"action": "goto"|"click"|"fill"|"type"|"evaluate"|"extract"|"finish", "target": "selector_or_url", "value": "text_to_fill_or_js_code", "reason": "why this action"}. If the goal is achieved, use "finish" action with the extracted result in "value".`;

    const messages = [
      ...history, // Previous interactions for context
      {"role": "user", "content": currentObservation}
    ];

    console.log(`--- Step ${steps} ---`);
    console.log('Sending to LLM, current URL:', page.url());

    const llmResponse = await anthropic.messages.create({
      model: "claude-3-5-sonnet-20240620",
      max_tokens: 500,
      messages: messages
    });

    const responseText = llmResponse.content[0].text;
    console.log('LLM Raw Response:', responseText);

    history.push({"role": "assistant", "content": responseText});

    let action;
    try {
      action = JSON.parse(responseText.replace(/```
{% endraw %}
json\n|\n
{% raw %}
```/g, '')); // Clean markdown code blocks
    } catch (e) {
      console.error('Failed to parse LLM action JSON:', e);
      // Fallback or request LLM to retry
      history.push({"role": "user", "content": "Error: Your last response was not valid JSON. Please provide a valid JSON action."});
      continue;
    }

    console('Parsed Action:', action);

    if (action.action === 'finish') {
      console.log('Agent finished task.');
      await browser.close();
      return action.value;
    }

    try {
      switch (action.action) {
        case 'goto':
          await page.goto(action.target, { waitUntil: 'domcontentloaded' });
          break;
        case 'click':
          await page.click(action.target, { timeout: 5000 }); // Add timeout for flaky elements
          break;
        case 'fill':
          await page.fill(action.target, action.value, { timeout: 5000 });
          // Hard Rule: Playwright 1.40.0+ on type="number" inputs can be weird.
          // If you fill a number input with JS handlers and it doesn't trigger change,
          // sometimes a manual dispatchEvent or a tab press helps.
          // Example: If filling `<input type="number" id="quantity">`, and the JS on blur
          // doesn't trigger, you might need:
          // await page.dispatchEvent(action.target, 'input');
          // I found this specifically with some custom Angular/React number inputs.
          // For simpler cases, page.fill is usually fine.
          break;
        case 'type': // More human-like typing
          await page.type(action.target, action.value, { delay: 100 });
          break;
        case 'evaluate': // Run custom JS on the page
          const evalResult = await page.evaluate(action.value);
          currentObservation = `Evaluated JS: ${evalResult}`;
          break;
        case 'extract': // Extract specific data
          const extractedData = await page.$eval(action.target, el => el.textContent);
          currentObservation = `Extracted data: ${extractedData}`;
          // If this is the final extraction before finishing, LLM should propose 'finish' next.
          break;
        default:
          throw new Error(`Unknown action: ${action.action}`);
      }
      await page.waitForTimeout(1000); // Give page a moment to settle
      // Update observation with new page state for next LLM call
      currentObservation = `Action "${action.action}" on "${action.target}" completed.`;
    } catch (e) {
      console.error(`Browser action failed for ${action.action}:`, e);
      history.push({"role": "user", "content": `Error: Failed to perform action "${action.action}" on "${action.target}". Reason: ${e.message}. Current URL: ${page.url()}. Please suggest an alternative action or try again, or use "finish" if impossible.`});
    }
  }

  await browser.close();
  return "Task reached max steps without completion.";
}

This runAgentTask function is the core of the flutter nodejs ai browser automation. It iteratively calls the LLM, parses the LLM's suggested action, executes it with Playwright, and then feeds the new page state back to the LLM for the next decision. It's a classic LLM agent "plan, act, observe, reflect" loop.

What I Got Wrong First

Honestly, getting the prompt right for the Actuator LLM was the biggest pain. I started with open-ended prompts like "What should I do next?". Big mistake. The LLM would generate paragraphs, or sometimes just chat back, rather than a structured action.

The Fix: Strict JSON output for actions.
By explicitly telling Claude "Respond ONLY with a JSON object. Format: {...}", it drastically improved reliability. If it messed up the JSON, my Node.js code would catch it, and I'd feed that parsing error back into the LLM's context as a new user message: "Error: Your last response was not valid JSON. Please provide a valid JSON action." This self-correction mechanism is crucial.

Another massive headache was handling dynamic web elements. Sometimes page.click('button#submit') would fail because the button wasn't ready, or an overlay covered it.

The Fix:

page.waitForSelector() before interaction, often with state: 'visible'.
Increased timeouts on Playwright actions (e.g., click({ timeout: 5000 })).
LLM reflection on failure: When Playwright throws an error, I catch it and feed the error message and the current page state (HTML snippet, URL) back to the LLM. The LLM can then decide to try a different selector, wait longer, or navigate elsewhere. This is what truly differentiates a scripted bot from an agent.

One specific issue I hit with Playwright 1.40.0: when filling certain <input type="number"> fields, especially if they had custom JavaScript validation or formatting on blur, page.fill() wouldn't always trigger the necessary change events. The form would look filled, but the internal application state wouldn't update.
The Fix: After page.fill(selector, value), I sometimes had to explicitly call await page.dispatchEvent(selector, 'input') or even await page.press(selector, 'Tab') to force the blur event. This isn't documented as a common necessity for page.fill, but it saved my sanity on specific SPA frameworks.

Quantifying the Time Saved

Before this flutter nodejs ai browser automation setup, I spent roughly 3-4 hours a week on repetitive tasks like:

Collecting specific product data from competitor websites.
Filling out complex internal forms for project updates.
Aggregating analytics data from various dashboards that lack direct API access.

Now, I just type a command into my Flutter app: "Scrape product details for X from site Y and put it in a Notion table." or "Fill out my weekly report for Project Z with these bullet points."

The agent handles it. It navigates, logs in (using secure environment variables), extracts, fills, and even uploads if needed. This literally cut down 2.5-3 hours of that busywork a week. That's a 60-75% reduction on those tasks. The time saved allows me to focus on actual development and strategic thinking, not mind-numbing clicks.

FAQs

Q: Can I run Playwright headlessly on a remote server?

A: Absolutely. Playwright is designed for both headless and headful execution. For production deployments, you'll almost always run it headlessly on a Linux server (e.g., a Vercel serverless function or a dedicated EC2 instance). Just make sure your server environment has the necessary browser dependencies installed.

Q: How do you handle authentication (logins) securely?

A: Never hardcode credentials. For a personal assistant, store sensitive info (usernames, passwords) in environment variables or a secure vault (like Google Secret Manager, AWS Secrets Manager, or a simple .env file for dev, encrypted for prod). Your Node.js backend can retrieve these securely and pass them to Playwright for login forms.

Q: What's the biggest bottleneck for this type of agent?

A: The LLM's latency and its ability to consistently produce correct, actionable JSON. Even with Claude 3.5 Sonnet, which is fast, a complex task with many steps means multiple round trips to the LLM, adding up. If the LLM produces invalid JSON, it adds another round trip for correction. This is where good prompt engineering and robust error handling are critical.

This setup is a game-changer for personal productivity. Honestly, I don't get why more developers aren't building these specialized cross platform ai assistant tools for their own specific workflows. The combination of Flutter for a native feel, Node.js for backend agility, and Playwright for robust web interaction, all powered by a smart LLM, is incredibly powerful. Stop clicking, start automating.

Why BlocSignal Doesn't Need Provider (And Why Classic BLoC Always Did)

Randal L. Schwartz — Sun, 16 Aug 2026 18:12:39 +0000

How shedding package:provider eliminates dependency hell, fixes Flutter's lingering ghost rebuild bug, and delivers fine-grained synchronous reactivity in 2026.

If you browse r/FlutterDev on any given week, you will find the exact same architectural debate playing out:

"Should I use BLoC or Riverpod for my next production app? BLoC has great structure and discipline, but the stream boilerplate is overwhelming. Riverpod is reactive and flexible, but the @riverpod code generation and constant version transitions make it feel heavyweight."

And inevitably, someone in the comments will chime in:

"I just stick with plain package:provider because it's simple and doesn't require code-gen."

This trilemma—BLoC vs. Riverpod vs. Provider—has defined Flutter state management for over six years. But behind this debate lies a little-known architectural secret that explains why Flutter state management felt so fractured in the first place:

Classic flutter_bloc was secretly just package:provider in disguise.

Let's look at why classic BLoC relied on package:provider, the hidden runtime bugs and dependency deadlocks that came with it, why Riverpod had to break away, and how BlocSignal delivers the ultimate resolution: zero provider, zero streams, and zero code generation.

1. Look Under the Hood: Classic BLoC's Hidden Dependency

When developers think of Felix Angelov’s classic flutter_bloc, they think of Streams, Sinks, and unidirectional event architectures. But if you open flutter_bloc/pubspec.yaml, you'll find a foundational dependency:

dependencies:
  bloc: ^8.1.4
  provider: ^6.0.5 # 👈 The hidden foundation!

In classic flutter_bloc:

BlocProvider<T> is literally an extension of package:provider's InheritedProvider.
MultiBlocProvider is just a thin alias over MultiProvider.
RepositoryProvider is literally Provider<T>.

Why Did Classic BLoC Do This?

Back in 2018–2019, writing custom InheritedWidget plumbing in Flutter was verbose and error-prone. Rémi Rousselet’s package:provider was the newly crowned Google-recommended solution for dependency injection and widget tree scoping.

Building flutter_bloc on top of package:provider allowed BLoC to focus on its stream state machine while outsourcing widget tree scoping, lazy instantiation, and disposal to Provider.

It seemed like a great shortcut. But over time, coupling BLoC to package:provider introduced two massive architectural headaches.

2. The Two Fatal Flaws of the Provider Foundation

[ Your Application ] ──► [ flutter_bloc ]
                            │
                            └──► [ package:provider ] ──► [ Transitive Version Lock ]

Flaw #1: "Dependency Hell" & Version Lockouts

Because package:provider is one of the most widely used packages in the Flutter ecosystem, major version updates (such as migrating from v4 to v5 to v6 for null safety) created widespread dependency deadlocks:

Because my_app depends on:
  - legacy_auth_plugin ^2.1.0 (which depends on provider ^5.0.0)
  - flutter_bloc ^8.0.0 (which depends on provider ^6.0.5)

Version solving failed:
Cannot solve dependencies because provider ^5.0.0 is incompatible with provider ^6.0.5!

Every Flutter developer has experienced this nightmare:

You couldn't upgrade flutter_bloc because an analytics or payment SDK pinned an older provider.
Teams were forced to use risky dependency_overrides: in pubspec.yaml and pray that internal breaking changes wouldn't crash production builds.
Engineers had to fork third-party repositories just to bump a provider constraint.

Flaw #2: The "Lingering Dependency" (Ghost Rebuild) Bug

This is the deepest, most subtle flaw in Flutter's InheritedWidget system—and it was the primary catalyst that drove Rémi Rousselet to abandon Provider and create Riverpod.

When an Element calls context.watch<T>() or Provider.of<T>(context), Flutter registers that Element as a dependent of the ancestor InheritedWidget.

The fatal catch: Flutter’s engine never unregisters an element from an InheritedWidget on subsequent builds! Dependencies are only cleared when the widget is completely unmounted.

Consider this common conditional UI pattern:

// 👴 The Classic Provider Ghost Rebuild Trap:
Widget build(BuildContext context) {
  if (isExpanded) {
    // 🚩 Registers a permanent dependency on DetailsModel
    final details = Provider.of<DetailsModel>(context);
    return FullDetailsCard(details);
  } else {
    // 👻 GHOST REBUILD: Even when collapsed, this widget STILL rebuilds 
    // on every single change to DetailsModel forever!
    return const CompactSummaryCard();
  }
}

Once isExpanded is true even once, Flutter permanently binds DetailsModel to that widget. When the card collapses, it continues to rebuild on every DetailsModel emission indefinitely, wasting CPU cycles, battery, and rendering frames on state it isn't even displaying!

3. The Riverpod Exodus: Escaping the Widget Tree

Rémi recognized that Flutter's InheritedWidget and BuildContext had fundamental limitations that could not be fixed within package:provider:

You couldn't easily read state outside the widget tree (for example, in background services or pure Dart logic).
The lingering dependency bug caused unavoidable ghost rebuilds on conditional branches.
Combining two providers required ugly nested widget hierarchies or manual proxies.

So Rémi built Riverpod (ProviderContainer), moving the entire dependency and state graph outside of the Flutter widget tree.

Where Riverpod Got Complicated

While Riverpod solved the BuildContext coupling, it created a new set of challenges:

The @riverpod Code-Gen Dogmatism: To avoid writing boilerplate notifiers, developers were pushed toward build_runner and code generation. If you didn't run a file watcher in the background, development ground to a halt.
Complex Internal Types: Behind a simple provider was a labyrinth of generated classes (AutoDisposeAsyncNotifierProviderElement, ProviderFamily, AsyncValue edge cases).
Two-World Impedance: Managing state in an external container while rendering in Flutter's Element tree required complex retention counters (autoDispose, disposeDelay, cacheTime) to guess when widgets were truly done using state.

4. The BlocSignal Resolution: Zero Provider, Zero Code-Gen

┌────────────────────────────────────────────────────────────────────────┐
│                              BlocSignal                                │
│                                                                        │
│   ┌────────────────────────┐              ┌────────────────────────┐   │
│   │   The Rigor of BLoC    │              │  The Speed of Signals  │   │
│   │  • Unidirectional flow │              │  • Synchronous DAG     │   │
│   │  • Explicit Events     │      ➕      │  • Dynamic Pruning     │   │
│   │  • Strict Transitions  │              │  • Zero Streams        │   │
│   │  • 100% Traceability   │              │  • Zero Code-Gen       │   │
│   └────────────────────────┘              └────────────────────────┘   │
└────────────────────────────────────────────────────────────────────────┘

BlocSignal resolves this historical progression by rethinking the state primitive from the ground up:

1. Native O(1) `InheritedWidget` (Zero Third-Party Dependencies)

In bloc_signals_flutter, BlocSignalProvider does not depend on package:provider.

It is built directly on Flutter's core SDK InheritedWidget.
It performs instant O(1) lookups via getElementForInheritedWidgetOfExactType without intermediate proxy nodes or delegating elements.
It has zero external dependencies—eliminating pub get version deadlocks permanently.

2. Dynamic Per-Frame Dependency Pruning (No Ghost Rebuilds)

Because BlocSignal is powered by fine-grained Signals (signals_flutter), dependencies are tracked dynamically on every single evaluation frame:

// ⚡ In BlocSignal: Zero Ghost Rebuilds!
Widget build(BuildContext context) {
  return Watch((context) {
    if (isExpanded.value) {
      // ✅ Subscribes to detailsCubit in this frame
      return FullDetailsCard(detailsCubit.state.value);
    }
    // ✅ When false, detailsCubit is AUTOMATICALLY UNWATCHED and detached!
    return const CompactSummaryCard();
  });
}

When isExpanded turns false, detailsCubit is immediately pruned and unwatched. If detailsCubit mutates while the card is collapsed, zero rebuilds occur. You get pristine, leak-free reactivity without code generation or external containers.

3. Synchronous State Propagation (No Stream Queue Latency)

Classic BLoC emits state over Dart asynchronous microtask Streams. Every state change yields to the event loop before reaching the screen.

In BlocSignal:

Calling emit(newState) updates the underlying ReadonlySignal<State> synchronously in the exact same frame.
The GPU and widget tree render the new state with zero microtask queue hops and zero 1-frame loading flickers.

4. Streamless BLoC-to-BLoC Coordination

In classic BLoC, coordinating two Blocs requires nesting BlocListener widgets in the UI tree or writing complex Rx stream pipelines.

In BlocSignal, because state is a Signal, containers can observe each other directly in pure business logic:

class CartCubit extends CubitSignal<CartState> {
  CartCubit(this.authCubit) : super(CartInitial()) {
    // Synchronously react to auth changes without UI BlocListeners:
    createEffect(() {
      if (authCubit.state.value is Unauthenticated) {
        clearCart();
      }
    });
  }

  final AuthCubit authCubit;
}

5. The 4-Way Code Shootout

Let's look at how the exact same Counter feature looks across all four paradigms:

Option A: Classic `Provider` (`ChangeNotifier`)

class CounterModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;

  void increment() {
    _count++;
    notifyListeners(); // 🚩 Easy to forget; triggers blanket rebuilds
  }
}

Option B: Classic `flutter_bloc` (Streams + `package:provider`)

class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0);
  void increment() => emit(state + 1); // ⏳ Asynchronous stream microtask
}

Option C: Riverpod 3 (Code Generation + `build_runner`)

@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;

  void increment() => state++; // ⚙️ Requires running build_runner
}

Option D: Modern `BlocSignal` (Pure, Synchronous Dart)

In Dart 3.5 (Baseline Syntax):

class CounterCubit extends CubitSignal<int> {
  CounterCubit([int initial = 0]) : super(initial);
  void increment() => emit(state.value + 1); // ⚡ Synchronous, zero code-gen
}

In Dart 3.13 (Modern Primary Constructor):

class CounterCubit([int initial = 0]) extends CubitSignal<int>(initial) {
  void increment() => emit(state.value + 1);
}

6. The Ultimate Comparison Matrix

Feature	`package:provider`	Classic `flutter_bloc`	`Riverpod` 3	`BlocSignal`
Core Reactive Engine	`ChangeNotifier`	Asynchronous `Stream`	External DAG	Synchronous `Signal` DAG
Depends on `provider`?	N/A	YES (`^6.0.0`)	No	NO (Pure SDK)
Requires Code-Gen?	No	No	YES (`@riverpod`)	ZERO Code-Gen
Ghost Rebuild Fix?	❌ (Leaks on branch)	❌ (Inherited leak)	✅ (External Graph)	✅ (Dynamic Graph Pruning)
State Immutability	❌ (Mutable fields)	✅ (Immutable State)	✅ (Immutable State)	✅ (`ReadonlySignal`)
Execution Timing	Synchronous	Asynchronous microtask	Synchronous	Synchronous (Same Frame)
OpenTelemetry & Observers	❌	✅ (`BlocObserver`)	Partial (`ProviderObserver`)	✅ (Otel + Observers)
Cross-Container Sync	Clunky Proxies	Nested UI Listeners	`ref.watch()`	`createEffect` / `computed`

7. The 60-Second Refactor: Your AI Migration Playbook

Five years ago, migrating a production app away from classic BLoC or Provider was a multi-month engineering slog.

In 2026, with modern AI coding assistants (Antigravity, Cursor, Copilot, Gemini) and BlocSignal, the refactor is practically instantaneous:

PROMPT FOR YOUR AI ASSISTANT:
"Replace `flutter_bloc` with `bloc_signals_flutter`.
Replace `BlocProvider` with `BlocSignalProvider`.
Replace `BlocBuilder` with `BlocSignalBuilder`.
Remove `provider` from `pubspec.yaml` and run `flutter pub get`."

💡 Automated AI Migration Skills: The BlocSignal repository even includes pre-packaged AI Agent Skills & Plugins (under plugins/bloc-signals/skills/bloc-signals/) for Antigravity, Cursor, Gemini CLI, and Claude Code. You can install the skill into your workspace to give your AI agent deep, rule-enforced expertise in migrating classic BLoC and Riverpod apps to BlocSignal with full test verification!

In 60 seconds:

All your Blocs and Cubits keep their exact same event and state models.
The asynchronous stream microtask delay disappears.
package:provider is wiped from your pubspec.yaml forever.
Your unit tests run synchronously with zero pumpAndSettle() microtask draining hacks.

8. Summary: Less is More

Software architecture advances not by adding more layers of abstraction, but by removing the friction between your code and the metal.

By removing package:provider and replacing stream plumbing with fine-grained Signals:

You eliminate version collisions and dependency solver deadlocks.
You fix Flutter’s lingering dependency ghost rebuild bug.
You get synchronous, same-frame UI rendering.
You preserve 100% of BLoC’s enterprise structure and event traceability.

It's everything you loved about BLoC, everything you wanted from Riverpod, and all the simplicity of Provider—with none of the baggage.

🚀 Get Started with BlocSignal

🌐 Official Website & Interactive Showcase: blocsignal.dev
📦 Core Pure-Dart Package: bloc_signals on pub.dev
📱 Flutter UI Package: bloc_signals_flutter on pub.dev
🌊 Riverpod Interop Bridge: bloc_signals_riverpod on pub.dev
💻 Open Source Monorepo: GitHub (RandalSchwartz/BlocSignal)

Offline-First Flutter: Syncing Local and Remote Data Reliably

Bimal Kshetri — Sun, 16 Aug 2026 15:55:08 +0000

Building an offline-first Flutter app is less about caching the network and more about flipping the dependency: the local database becomes your source of truth, and the server becomes a replica you reconcile with later. I've shipped this pattern across several production iOS and Android apps, and the ones that treated the network as optional from day one were dramatically more reliable than the ones that bolted on caching after launch.

This is a practical, example-driven guide for intermediate Flutter developers. We'll cover the architecture, picking a Flutter local database, designing a durable sync queue, choosing a conflict resolution strategy, and — the part most tutorials skip — handling the failures that actually happen in the field.

What "offline-first" really means

The phrase gets thrown around loosely, so let me be precise. An offline-first app has three non-negotiable properties:

The UI never blocks on the network. Every read and write hits local storage and returns immediately.
Writes are durable before they're sent. A user's edit survives an app kill, a crash, or a dead connection because it's persisted locally first.
Sync is a background reconciliation process, not part of the user's interaction loop.

The mental model I use: the user only ever talks to the local store. A separate sync engine watches a queue of pending changes and negotiates with the server whenever it can. The two are decoupled. If you remember nothing else from this article, remember that the write path and the sync path must not be the same code path.

UI  ──►  Local DB (source of truth)  ──►  Sync queue  ──►  Remote API
 ▲            │                                              │
 └── streams ─┘                            reconcile ◄───────┘

Choosing a Flutter local database

Your local store is the foundation, so pick deliberately. For an offline-first design you want reactive queries (so the UI rebuilds when local data changes) and real transactions (so a write and its queue entry commit atomically). The two I reach for are Drift and Isar.

Option	Model	Reactive queries	Transactions	Best when
Drift	Relational (SQLite)	Yes (`watch()`)	Strong, SQL	Relational data, complex queries, migrations matter
Isar	NoSQL object store	Yes (`watch()`)	Yes	Object graphs, very high read throughput, simple schema
sqflite	Raw SQLite	No (manual)	Yes	You want full control and don't mind wiring reactivity yourself
Hive	Key-value	Limited	No	Simple settings/blobs, not a sync backbone

For anything with relationships and a sync queue, I default to Drift: SQL transactions let me write the row and enqueue the mutation in one atomic step, and watch() gives me a Stream the UI subscribes to. If your data is a big object graph and you care more about raw speed than joins, Isar is excellent. Avoid Hive as a sync backbone — its lack of real transactions will bite you.

Here's a minimal Drift schema with the two tables every offline-first app needs — the domain table and an outbox for pending mutations:

import 'package:drift/drift.dart';

class Todos extends Table {
  TextColumn get id => text()(); // client-generated UUID
  TextColumn get title => text()();
  BoolColumn get done => boolean().withDefault(const Constant(false))();
  IntColumn get updatedAt => integer()(); // epoch millis, our version clock
  BoolColumn get deleted => boolean().withDefault(const Constant(false))();

  @override
  Set<Column> get primaryKey => {id};
}

class Outbox extends Table {
  IntColumn get seq => integer().autoIncrement()();
  TextColumn get entity => text()();    // e.g. 'todo'
  TextColumn get entityId => text()();
  TextColumn get op => text()();        // 'upsert' | 'delete'
  TextColumn get payload => text()();   // JSON snapshot
  IntColumn get attempts => integer().withDefault(const Constant(0))();
}

Two details matter here. First, IDs are generated on the client (a UUID), not the server. This lets a user create records offline that already have stable identity. Second, updatedAt doubles as a logical version clock for conflict detection later.

Designing the sync queue (the outbox pattern)

The outbox pattern is the heart of a reliable sync engine. Instead of firing an HTTP request when the user edits something, you write the change to local storage and append a record to the outbox table — atomically, in one transaction. A background worker drains the outbox.

The atomicity is the whole point. If you write the row but the app dies before you enqueue the sync job, the server never hears about it. A single transaction makes "data changed" and "needs sync" inseparable.

Future<void> upsertTodo(Todo todo) async {
  final next = todo.copyWith(updatedAt: DateTime.now().millisecondsSinceEpoch);
  await db.transaction(() async {
    // toCompanion(true) maps nulls to Value.absent() rather than explicit null.
    await db.into(db.todos).insertOnConflictUpdate(next.toCompanion(true));
    await db.into(db.outbox).insert(OutboxCompanion.insert(
      entity: 'todo',
      entityId: next.id,
      op: 'upsert',
      payload: jsonEncode(next.toJson()),
    ));
  });
}

The UI calls upsertTodo, the local watch() stream emits, and the screen updates instantly — no network involved. Now the draining side. Process the outbox in order, oldest seq first, so causally dependent changes (create then update) reach the server in sequence:

Future<void> drainOutbox() async {
  final pending = await (db.select(db.outbox)
        ..orderBy([(o) => OrderingTerm.asc(o.seq)])
        ..limit(50))
      .get();

  for (final item in pending) {
    try {
      await _push(item);
      await (db.delete(db.outbox)..where((o) => o.seq.equals(item.seq))).go();
    } on ConflictException catch (e) {
      await _resolveConflict(item, e.serverRecord);
      await (db.delete(db.outbox)..where((o) => o.seq.equals(item.seq))).go();
    } on RetryableException {
      await (db.update(db.outbox)..where((o) => o.seq.equals(item.seq)))
          .write(OutboxCompanion(attempts: Value(item.attempts + 1)));
      break; // stop the batch; preserve ordering, retry later
    }
  }
}

Notice the three outcomes: success removes the entry, a conflict resolves and removes it, and a retryable failure bumps the attempt counter and stops the batch so we don't reorder later changes.

Conflict resolution: last-write-wins vs. merge

The hard part of offline-first Flutter is what happens when the same record was edited in two places. There's no universally correct answer — only trade-offs you choose deliberately per entity.

Last-write-wins (LWW)

The simplest strategy: each record carries a version/timestamp, and the most recent write overwrites the older one. It's easy to reason about and stateless. The cost is silent data loss — if two people edited different fields, one set of edits vanishes.

Todo resolveLww(Todo local, Todo remote) {
  return local.updatedAt >= remote.updatedAt ? local : remote;
}

LWW is the right call for low-contention, single-user-per-record data: a user's own settings, a draft only they edit, a "last read position." Use a monotonic clock you control (server-assigned timestamps or a logical counter), because device clocks lie and skew.

Field-level merge

When losing edits is unacceptable, merge at the field level. You compare the local version, the remote version, and ideally a common ancestor (the value at last sync) to detect which side actually changed each field. If only one side touched a field, take that side; if both changed the same field, you have a true conflict to escalate.

Todo merge({required Todo base, required Todo local, required Todo remote}) {
  // Three-way merge for a single field: returns the winning value.
  String pick(String b, String l, String r) {
    if (l == r) return l; // both sides agree
    if (l == b) return r; // only remote changed
    if (r == b) return l; // only local changed
    return r;             // both changed: policy — prefer remote, or flag it
  }

  final mergedDone = local.done == remote.done
      ? local.done
      : (local.done == base.done ? remote.done : local.done);

  return local.copyWith(
    title: pick(base.title, local.title, remote.title),
    done: mergedDone,
  );
}

For collaborative, structured data where even field merges aren't enough, CRDTs (conflict-free replicated data types) let independent replicas converge automatically without a central referee. They're powerful but add real complexity — reach for them only when concurrent editing of shared documents is a core feature, not before.

Here's how I choose:

Strategy	Data loss risk	Complexity	Use it for
Last-write-wins	High (whole record)	Low	Single-owner records, settings, drafts
Field-level merge	Low	Medium	Forms edited from multiple devices
CRDT	None (converges)	High	Real-time collaborative documents

Handling failures and partial sync

A sync engine that only works on a perfect connection isn't offline-first — it's an online app in denial. Plan for the messy reality.

Exponential backoff with jitter. Don't hammer a failing server. Back off geometrically and add randomness so a fleet of devices doesn't reconnect in a thundering herd:

import 'dart:math' as math;

Duration backoff(int attempt) {
  // Cap the base at 30s; everything stays int so Duration is happy.
  final base = math.min(30000, 500 * (1 << attempt));
  final jitter = math.Random().nextInt((base ~/ 2) + 1);
  return Duration(milliseconds: base + jitter);
}

Idempotent writes. A request can succeed on the server but fail before the client sees the 200, so the client retries. Send a client-generated request key (your outbox entityId plus a content hash works) and have the server deduplicate. With idempotency, "did this actually go through?" stops being a question you have to answer.

Poison messages. A mutation that fails forever — a deleted parent, a validation the server rejects — will block the queue if you let it. Cap attempts, move the entry to a dead-letter table, surface it, and keep draining the rest:

if (item.attempts >= 5) {
  await _moveToDeadLetter(item);
  await (db.delete(db.outbox)..where((o) => o.seq.equals(item.seq))).go();
  continue;
}

Trigger sync on the right events. Drain the outbox on app start, when connectivity_plus reports a connection returning, when the app comes back to the foreground, and after every local write (debounced). Treat connectivity as a hint, not a guarantee — a "connected" Wi-Fi with no real internet is common, so the real test is whether a request succeeds.

Pull as well as push. Everything above covers pushing local changes up. You also need to pull remote changes down — ideally a delta endpoint that returns records changed since a stored cursor (updatedSince), then apply each through the same conflict resolver before writing locally. One reconciliation path, used in both directions, keeps the logic honest.

Putting it together: a sync lifecycle

A clean offline-first Flutter app ends up with a small, predictable loop:

Read from the local DB via reactive streams — the UI never waits.
Write locally and enqueue to the outbox in one transaction.
Push the outbox in seq order with backoff, idempotency, and dead-lettering.
Pull deltas since the last cursor and reconcile through your conflict resolver.
Resolve conflicts per entity — LWW for single-owner data, merge for shared.

Keep each stage independent and testable. The biggest reliability win in my experience isn't a clever algorithm — it's the discipline of making the local store authoritative and never letting the network leak into the write path.

Wrapping up

Offline-first isn't a feature you sprinkle on; it's an architecture: a local source of truth, a transactional outbox, a deliberate conflict policy, and failure handling that assumes the network will betray you. Get those four right and your app feels instant on a subway and bulletproof on flaky hotel Wi-Fi.

If you're building something like this and want a second pair of hands, work with me or get in touch — I'm always happy to talk shop about sync engines.

Flutter CI/CD with GitHub Actions and Fastlane: A Real Pipeline

Bimal Kshetri — Sun, 16 Aug 2026 15:55:02 +0000

Flutter CI/CD stops being optional the moment you ship to two stores from one codebase and a manual release eats half a day. In this post I walk through the exact pipeline I run on production apps: GitHub Actions runs flutter analyze and tests on every pull request, then — only when I push a version tag — it builds signed iOS and Android artifacts and uploads them to TestFlight and the Google Play internal track. No clicking through Xcode Organizer, no dragging .aab files into a browser.

I'll cover the workflow YAML, the Fastlane lanes that do the store uploads, and the part everyone gets wrong the first time: getting signing material — the Android keystore and the iOS distribution certificate — into CI without leaking it.

Why split CI and CD on a tag

The single most useful decision in a Flutter CI/CD setup is separating two concerns:

CI (every PR): fast, cheap, runs on Linux, gates merges. Format check, flutter analyze, unit and widget tests. This should finish in a couple of minutes.
CD (on a tag): slow, expensive (macOS minutes for iOS), produces signed builds, talks to the stores. You only want this when you actually intend to release.

Tying release to a Git tag like v1.4.0 gives you a clean, auditable trigger. The tag is the release record. Pushing to main shouldn't ship anything — that's how you end up with surprise TestFlight builds at 2am.

Trigger	Runs on	What it does	Cost
Pull request	`ubuntu-latest`	format, analyze, test	Low / fast
Tag `v..*` (Android)	`ubuntu-latest`	signed `.aab` to Play internal	Low
Tag `v..*` (iOS)	`macos-latest`	signed `.ipa` to TestFlight	High (macOS minutes)

Keep iOS on its own job. macOS runners bill at roughly ten times the per-minute rate of Linux runners on GitHub-hosted machines, so you don't want every PR burning them.

The CI job: analyze and test on every PR

Here's the lint-and-test half of the workflow. It pins the Flutter version (never rely on latest — a Dart SDK bump can break your build on an unrelated PR) and caches pub dependencies so reruns are quick.

name: ci

on:
  pull_request:
    branches: [main]

jobs:
  analyze-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: subosito/flutter-action@v2
        with:
          flutter-version: "3.27.1"
          channel: stable
          cache: true

      - name: Install dependencies
        run: flutter pub get

      - name: Verify formatting
        run: dart format --output=none --set-exit-if-changed .

      - name: Analyze
        run: flutter analyze --fatal-infos

      - name: Run tests
        run: flutter test --coverage

A few things I insist on:

dart format --set-exit-if-changed fails the build on unformatted code. It ends the "whitespace-only diff" wars permanently.
--fatal-infos treats analyzer infos as failures. If your analysis_options.yaml flags something, the PR should be red. Half-honored lint rules are worse than none.
cache: true on flutter-action caches the SDK and the pub cache between runs, which shaves a minute or more off most runs.

If you run integration tests or golden tests, gate the expensive ones behind a separate job or a label so day-to-day PRs stay fast.

Fastlane: lanes that talk to the stores

flutter build produces the artifact; Fastlane handles delivery — uploading that artifact to the right track with the right credentials. You keep two fastlane folders, one under android/ and one under ios/, each with its own Fastfile.

Android: upload to the Play Store internal track

For Android you authenticate with a Google Cloud service account JSON that has been granted access in the Play Console. The upload_to_play_store action (the supply integration) does the upload.

# android/fastlane/Fastfile
default_platform(:android)

platform :android do
  desc "Upload a signed AAB to the Play Store internal track"
  lane :internal do
    upload_to_play_store(
      track: "internal",
      aab: "../build/app/outputs/bundle/release/app-release.aab",
      json_key_data: ENV["PLAY_STORE_SERVICE_ACCOUNT_JSON"],
      release_status: "draft",
      skip_upload_apk: true,
      skip_upload_metadata: true,
      skip_upload_images: true,
      skip_upload_screenshots: true
    )
  end
end

I pass the service-account JSON as raw data via json_key_data (read from an env var) rather than a file on disk, so nothing sensitive is ever written to the runner's filesystem. release_status: "draft" leaves a human to do the final promote — automate the upload, keep the publish deliberate.

iOS: upload to TestFlight

For iOS, upload_to_testflight (Pilot) talks to App Store Connect. Use an App Store Connect API key, not your Apple ID and an app-specific password — API keys don't trip two-factor auth and don't break the moment Apple decides your session looks suspicious.

# ios/fastlane/Fastfile
default_platform(:ios)

platform :ios do
  desc "Upload the signed IPA to TestFlight"
  lane :beta do
    app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"], # base64-encoded .p8
      is_key_content_base64: true
    )

    upload_to_testflight(
      ipa: "../build/ios/ipa/Runner.ipa",
      skip_waiting_for_build_processing: true
    )
  end
end

app_store_connect_api_key stores the key in Fastlane's shared lane context, so upload_to_testflight picks it up automatically — no need to thread the hash through by hand. skip_waiting_for_build_processing: true returns as soon as the upload finishes instead of blocking the runner (and your billed minutes) while Apple processes the build. The trade-off: you can't auto-assign testers in the same run, which is fine — I let a later step or TestFlight's own settings handle distribution.

Secrets and signing material without leaking them

This is where Flutter CI/CD pipelines go wrong. You can't commit your keystore or .p8, and you can't flutter build a release without your signing material. The bridge is GitHub Actions encrypted secrets plus base64 encoding for binary files.

Encode the binaries locally once:

# Android upload keystore
base64 -i upload-keystore.jks | pbcopy   # paste into secret KEYSTORE_BASE64

# App Store Connect API key (.p8)
base64 -i AuthKey_ABC123.p8 | pbcopy      # paste into secret ASC_KEY_CONTENT

Then add these repository secrets (Settings, then Secrets and variables, then Actions):

Secret	Used by	Notes
`KEYSTORE_BASE64`	Android	base64 of the upload keystore
`KEYSTORE_PASSWORD` / `KEY_PASSWORD` / `KEY_ALIAS`	Android	signing config
`PLAY_STORE_SERVICE_ACCOUNT_JSON`	Android	full JSON, pasted raw
`ASC_KEY_ID` / `ASC_ISSUER_ID`	iOS	from App Store Connect
`ASC_KEY_CONTENT`	iOS	base64 of the `.p8`
`MATCH_GIT_URL` / `MATCH_PASSWORD`	iOS	certs repo + decryption passphrase

On the runner, decode the keystore into place and have Gradle read the signing config from environment variables, so nothing is hardcoded in build.gradle:

echo "$KEYSTORE_BASE64" | base64 --decode > android/app/upload-keystore.jks

// android/app/build.gradle
android {
    signingConfigs {
        release {
            storeFile file(System.getenv("KEYSTORE_PATH") ?: "upload-keystore.jks")
            storePassword System.getenv("KEYSTORE_PASSWORD")
            keyAlias System.getenv("KEY_ALIAS")
            keyPassword System.getenv("KEY_PASSWORD")
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

The file("upload-keystore.jks") path resolves relative to android/app/, which is exactly where the decode step writes it.

For iOS code signing in CI, the cleanest path is Fastlane Match, which stores your distribution certificate and provisioning profiles encrypted in a private Git repo and installs them on the runner. This matters more than it looks: a bare flutter build ipa on a fresh macOS runner has no certificate in its keychain and will fail to sign. Add a sync_certificates (Match) lane and call it before the build:

# ios/fastlane/Fastfile  (add inside platform :ios)
desc "Install distribution signing assets via Match"
lane :certificates do
  setup_ci # creates a temporary keychain on CI
  match(
    type: "appstore",
    readonly: true,
    api_key: app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"],
      is_key_content_base64: true
    )
  )
end

setup_ci spins up a throwaway keychain so the imported certificate doesn't linger, and readonly: true means CI consumes existing certs but never mints new ones (certificate creation stays a deliberate local action). If you're not on Match yet you can import a base64 .p12 into a temporary keychain by hand, but Match scales better across machines and teammates, and it's what I reach for on any app with more than one engineer.

Two rules I never break:

Never echo a secret to stdout. GitHub masks known secret values in logs, but a base64 round-trip or a substring can slip through. Pipe directly into base64 --decode.
Scope credentials minimally. The Play service account only needs release-manager permission on that one app; the ASC API key can be limited in role. Least privilege contains the blast radius if a token leaks.

The release job: build signed artifacts on a tag

Now the CD half. This triggers only on version tags and runs Android and iOS as parallel jobs. Note the iOS job is the only one on macos-latest, and it installs signing assets via Match before the build.

name: release

on:
  push:
    tags:
      - "v*.*.*"

jobs:
  android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: "3.27.1"
          channel: stable
          cache: true
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.3"
          bundler-cache: true
          working-directory: android

      - name: Decode keystore
        run: echo "$KEYSTORE_BASE64" | base64 --decode > android/app/upload-keystore.jks
        env:
          KEYSTORE_BASE64: ${{ secrets.KEYSTORE_BASE64 }}

      - name: Build AAB
        run: flutter build appbundle --release
        env:
          KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
          KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
          KEY_ALIAS: ${{ secrets.KEY_ALIAS }}

      - name: Upload to Play Store
        working-directory: android
        run: bundle exec fastlane internal
        env:
          PLAY_STORE_SERVICE_ACCOUNT_JSON: ${{ secrets.PLAY_STORE_SERVICE_ACCOUNT_JSON }}

  ios:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: "3.27.1"
          channel: stable
          cache: true
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.3"
          bundler-cache: true
          working-directory: ios

      - name: Install signing assets (Match)
        working-directory: ios
        run: bundle exec fastlane certificates
        env:
          ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }}
          ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
          ASC_KEY_CONTENT: ${{ secrets.ASC_KEY_CONTENT }}
          MATCH_GIT_URL: ${{ secrets.MATCH_GIT_URL }}
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}

      - name: Build IPA
        run: flutter build ipa --release --export-options-plist=ios/ExportOptions.plist

      - name: Upload to TestFlight
        working-directory: ios
        run: bundle exec fastlane beta
        env:
          ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }}
          ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
          ASC_KEY_CONTENT: ${{ secrets.ASC_KEY_CONTENT }}

A couple of notes that save real debugging time:

Pin your version source. Pass --build-name and --build-number derived from the tag (for example, strip the v and feed the rest to --build-name, and use ${{ github.run_number }} for --build-number) so the binary's version matches the Git tag exactly. A TestFlight build whose version doesn't match its tag is a forensic nightmare later.
Commit a Gemfile in both android/ and ios/ and use bundle exec fastlane — this pins the Fastlane version so a Fastlane release doesn't silently change behavior mid-flight. bundler-cache: true makes the install cheap.
--export-options-plist controls the iOS export method (app-store for TestFlight). Generate it once, check it in, and don't let Flutter guess. The team identifier and signing style in that plist must line up with what Match installed.

Automate Flutter releases without losing the safety rails

The goal isn't to remove humans from releases — it's to remove toil so the human decisions are the only ones left. To automate Flutter releases responsibly:

Keep the final publish/promote manual (release_status: "draft", internal track first). The pipeline gets a build into testers' hands; a person decides when it goes to production.
Fail loudly. If signing fails, the whole job should go red — never let a half-uploaded release look green.
Make tagging the only release ritual. git tag v1.4.0 && git push origin v1.4.0 should be the entire release procedure. If it isn't, you've left a manual step that someone will eventually forget.
Smoke-test the artifact where you can — install the internal-track build on a real device before promoting. CI proves it builds and signs; it doesn't prove it runs.

Once this is wired up, GitHub Actions Flutter releases get boring in the best way: open a PR, get green checks, merge, tag, and walk away while TestFlight and the Play Store internal track fill up on their own.

Wrapping up

A solid Flutter CI/CD pipeline is mostly discipline encoded as YAML: fast checks on every PR, slow signed builds only on a tag, and signing material handled so nothing sensitive ever lands on disk in plaintext. Get those three right and releasing two apps collapses into a single git push. I've stood this exact pipeline up on production iOS and Android apps more than a few times — if you'd like help wiring it into your project you can hire me, or just get in touch and we'll talk through your setup.

Clean Architecture in Flutter with BLoC: A Practical Guide

Bimal Kshetri — Sun, 16 Aug 2026 15:36:26 +0000

Clean architecture in Flutter is the single biggest reason the production apps I ship stay maintainable after a year of feature churn. Over 4+ years building iOS and Android apps, I've watched "just put the logic in the widget" turn setState spaghetti into a codebase nobody wants to touch. This guide walks through how I actually split a Flutter app into domain, data, and presentation layers with BLoC — using one concrete feature so you can copy the structure into your own project today.

I'll build a small "Todos" feature end to end: an entity, a use case, a repository with a DTO mapper, and a Cubit that drives the UI. The point isn't the todo list — it's the boundaries between layers and why each one earns its keep.

Why clean architecture in Flutter pays off

The core idea is the dependency rule: source-code dependencies point inward. The UI knows about the domain; the domain knows about nothing. Your business rules never import Flutter, Firebase, Dio, or Supabase.

That inversion buys three things I care about on every project:

Testability. Domain logic runs in plain Dart unit tests — no widget pump, no emulator, no network.
Swappable infrastructure. Move from REST to GraphQL, or Firestore to a local SQLite cache, by rewriting one data-layer class. The domain and UI don't change.
Parallel work. Once the domain contract exists, one person builds the API client while another builds the screen against a fake.

Here's the layer breakdown I use, and what's allowed to live in each:

Layer	Knows about	Contains	Depends on
Domain	Nothing external	Entities, repository interfaces, use cases	Pure Dart only
Data	Domain + the outside world	DTOs, mappers, repository implementations, data sources	Domain
Presentation	Domain	Blocs/Cubits, states, widgets	Domain

Notice the data and presentation layers both depend on domain, and domain depends on neither. That's the whole game.

Folder structure that scales

I organise by feature first, then by layer. A flat models/, services/, screens/ split looks tidy on day one and becomes a scavenger hunt by feature five. Feature-first keeps everything you touch for one change in one place.

lib/
  features/
    todos/
      domain/
        entities/todo.dart
        repositories/todo_repository.dart   # abstract
        usecases/get_todos.dart
      data/
        models/todo_dto.dart                # JSON -> DTO + mapper
        datasources/todo_remote_data_source.dart
        repositories/todo_repository_impl.dart
      presentation/
        cubit/todos_cubit.dart
        cubit/todos_state.dart
        pages/todos_page.dart
  core/
    error/failures.dart
    usecases/usecase.dart

The core/ directory holds cross-feature primitives — failure types, a base UseCase contract, shared extensions. Everything feature-specific stays inside its feature folder.

The domain layer: entities and use cases

The domain is pure Dart. No package:flutter, no JSON, no annotations. Start with the entity — the shape your app reasons about, not the shape the API returns.

// domain/entities/todo.dart
import 'package:equatable/equatable.dart';

class Todo extends Equatable {
  const Todo({
    required this.id,
    required this.title,
    required this.isCompleted,
  });

  final String id;
  final String title;
  final bool isCompleted;

  @override
  List<Object?> get props => [id, title, isCompleted];
}

I extend Equatable so two todos with the same fields compare equal — that makes Cubit state comparisons and tests painless.

Next, the repository interface. This is the contract the domain demands from the outside world. It lives in domain, but it's implemented in data. That's the dependency inversion that keeps Firebase or Dio out of your business rules.

// domain/repositories/todo_repository.dart
import 'package:dartz/dartz.dart';
import '../../../../core/error/failures.dart';
import '../entities/todo.dart';

abstract interface class TodoRepository {
  Future<Either<Failure, List<Todo>>> getTodos();
  Future<Either<Failure, Todo>> toggle(String id);
}

I return Either<Failure, T> from dartz instead of throwing across layers. Failures become values you must handle, not exceptions that silently bubble into the UI. Failure is a sealed type in core/:

// core/error/failures.dart
sealed class Failure {
  const Failure(this.message);
  final String message;
}

class ServerFailure extends Failure {
  const ServerFailure([super.message = 'Something went wrong']);
}

class NetworkFailure extends Failure {
  const NetworkFailure([super.message = 'No internet connection']);
}

Now the use case. A use case is one application action with a single public method. It reads almost like a sentence: get todos. This is where orchestration lives — call a repository, maybe combine two, apply a business rule — without the Cubit ever knowing how data is fetched.

// core/usecases/usecase.dart
import 'package:dartz/dartz.dart';
import '../error/failures.dart';

abstract interface class UseCase<Type, Params> {
  Future<Either<Failure, Type>> call(Params params);
}

class NoParams {
  const NoParams();
}

// domain/usecases/get_todos.dart
import 'package:dartz/dartz.dart';
import '../../../../core/error/failures.dart';
import '../../../../core/usecases/usecase.dart';
import '../entities/todo.dart';
import '../repositories/todo_repository.dart';

class GetTodos implements UseCase<List<Todo>, NoParams> {
  const GetTodos(this._repository);

  final TodoRepository _repository;

  @override
  Future<Either<Failure, List<Todo>>> call(NoParams params) {
    return _repository.getTodos();
  }
}

People ask whether use cases are overkill when they just forward to a repository. Early on, many do — and that's a fair criticism. But the seam is what matters: the day "get todos" needs to filter archived items, merge a local cache, or log analytics, you change one file and every caller benefits. That discipline is what makes the domain/data/presentation split scale instead of rot.

The data layer: DTOs, mappers, and the repository

The data layer is where the messy outside world lives — and where it stays. The key move is a DTO (data transfer object) that mirrors the JSON exactly, plus a mapper that converts it to a clean domain entity. Never let raw JSON shapes leak into your domain.

// data/models/todo_dto.dart
import '../../domain/entities/todo.dart';

class TodoDto {
  const TodoDto({
    required this.id,
    required this.title,
    required this.completed,
  });

  final String id;
  final String title;
  final bool completed;

  factory TodoDto.fromJson(Map<String, dynamic> json) {
    return TodoDto(
      id: json['id'] as String,
      title: json['title'] as String,
      completed: json['is_done'] as bool? ?? false,
    );
  }

  Todo toEntity() => Todo(
        id: id,
        title: title,
        isCompleted: completed,
      );
}

See the value here: the API uses is_done, my domain uses isCompleted, and the API might send null. All of that ugliness is quarantined in one mapper. If the backend renames a field tomorrow, exactly one file changes.

The data source owns the transport — Dio, http, Firestore — and speaks DTOs:

// data/datasources/todo_remote_data_source.dart
import 'package:dio/dio.dart';
import '../models/todo_dto.dart';

abstract interface class TodoRemoteDataSource {
  Future<List<TodoDto>> fetchTodos();
}

class TodoRemoteDataSourceImpl implements TodoRemoteDataSource {
  const TodoRemoteDataSourceImpl(this._dio);

  final Dio _dio;

  @override
  Future<List<TodoDto>> fetchTodos() async {
    final res = await _dio.get<List<dynamic>>('/todos');
    final data = res.data ?? const <dynamic>[];
    return data
        .map((e) => TodoDto.fromJson(e as Map<String, dynamic>))
        .toList();
  }
}

Finally, the repository implementation stitches it together: call the data source, map DTOs to entities, and convert exceptions into Failure values. This is the only class that implements the domain's TodoRepository.

// data/repositories/todo_repository_impl.dart
import 'package:dartz/dartz.dart';
import 'package:dio/dio.dart';
import '../../../../core/error/failures.dart';
import '../../domain/entities/todo.dart';
import '../../domain/repositories/todo_repository.dart';
import '../datasources/todo_remote_data_source.dart';

class TodoRepositoryImpl implements TodoRepository {
  const TodoRepositoryImpl(this._remote);

  final TodoRemoteDataSource _remote;

  @override
  Future<Either<Failure, List<Todo>>> getTodos() async {
    try {
      final dtos = await _remote.fetchTodos();
      return Right(dtos.map((d) => d.toEntity()).toList());
    } on DioException {
      return const Left(NetworkFailure());
    } catch (_) {
      return const Left(ServerFailure());
    }
  }

  @override
  Future<Either<Failure, Todo>> toggle(String id) async {
    // Omitted for brevity — same try / map / Either shape as getTodos.
    throw UnimplementedError();
  }
}

This is the repository pattern doing its real job: the domain asked for List<Todo> or a typed failure, and got exactly that — with every Dio detail absorbed here.

The presentation layer: a Cubit driving the UI

For most screens I reach for Cubit over the full event-based Bloc. Cubit is simpler — you call methods directly and emit states — and it covers the majority of UI logic. I switch to a Bloc when I genuinely need an event stream: debouncing search input, transforming concurrent events, or keeping an audit trail of what triggered each transition.

I model state as a sealed class, so the widget layer is forced to handle every case and the compiler catches the one I forgot.

// presentation/cubit/todos_state.dart
import 'package:equatable/equatable.dart';
import '../../domain/entities/todo.dart';

sealed class TodosState extends Equatable {
  const TodosState();
  @override
  List<Object?> get props => [];
}

class TodosInitial extends TodosState {
  const TodosInitial();
}

class TodosLoading extends TodosState {
  const TodosLoading();
}

class TodosLoaded extends TodosState {
  const TodosLoaded(this.todos);
  final List<Todo> todos;
  @override
  List<Object?> get props => [todos];
}

class TodosError extends TodosState {
  const TodosError(this.message);
  final String message;
  @override
  List<Object?> get props => [message];
}

The Cubit depends only on the use case — never on a repository or Dio directly:

// presentation/cubit/todos_cubit.dart
import 'package:flutter_bloc/flutter_bloc.dart';
import '../../../../core/usecases/usecase.dart';
import '../../domain/usecases/get_todos.dart';
import 'todos_state.dart';

class TodosCubit extends Cubit<TodosState> {
  TodosCubit(this._getTodos) : super(const TodosInitial());

  final GetTodos _getTodos;

  Future<void> load() async {
    emit(const TodosLoading());
    final result = await _getTodos(const NoParams());
    result.fold(
      (failure) => emit(TodosError(failure.message)),
      (todos) => emit(TodosLoaded(todos)),
    );
  }
}

And the widget switches over the sealed state — exhaustively, with no default branch needed:

// presentation/pages/todos_page.dart (excerpt)
BlocBuilder<TodosCubit, TodosState>(
  builder: (context, state) => switch (state) {
    TodosInitial() || TodosLoading() =>
      const Center(child: CircularProgressIndicator()),
    TodosError(:final message) => Center(child: Text(message)),
    TodosLoaded(:final todos) => ListView.builder(
        itemCount: todos.length,
        itemBuilder: (_, i) => CheckboxListTile(
          value: todos[i].isCompleted,
          title: Text(todos[i].title),
          onChanged: (_) {},
        ),
      ),
  },
)

Wiring it all together happens once, at the composition root, with a DI container like get_it (here sl is the shared GetIt service-locator instance). Each layer receives its inward dependency through the constructor — that's what makes everything mockable.

final sl = GetIt.instance;

sl.registerLazySingleton<TodoRemoteDataSource>(
  () => TodoRemoteDataSourceImpl(sl()));
sl.registerLazySingleton<TodoRepository>(
  () => TodoRepositoryImpl(sl()));
sl.registerLazySingleton(() => GetTodos(sl()));
sl.registerFactory(() => TodosCubit(sl()));

How clean architecture in Flutter wins on testing

Here's the payoff. Because every dependency is an interface injected through a constructor, I can test each layer in isolation with a fake — no Flutter, no network:

// test/todos_cubit_test.dart
import 'package:bloc_test/bloc_test.dart';
import 'package:dartz/dartz.dart';
import 'package:mocktail/mocktail.dart';
import 'package:flutter_test/flutter_test.dart';

class MockGetTodos extends Mock implements GetTodos {}

void main() {
  late MockGetTodos getTodos;
  setUp(() => getTodos = MockGetTodos());
  setUpAll(() => registerFallbackValue(const NoParams()));

  blocTest<TodosCubit, TodosState>(
    'emits [Loading, Loaded] when the use case succeeds',
    build: () {
      when(() => getTodos(any())).thenAnswer(
        (_) async => const Right([
          Todo(id: '1', title: 'Ship it', isCompleted: false),
        ]),
      );
      return TodosCubit(getTodos);
    },
    act: (cubit) => cubit.load(),
    expect: () => [
      const TodosLoading(),
      const TodosLoaded([Todo(id: '1', title: 'Ship it', isCompleted: false)]),
    ],
  );
}

This test runs in milliseconds and never touches a real API. I can write the failure-path test the same way by returning Left(NetworkFailure()). Testability stops being a chore because the architecture made the dependencies fake-able by default. The same property is what lets these projects grow: a new feature is a new folder with the same four shapes, not a new way of doing things.

Wrapping up

Clean architecture in Flutter isn't about ceremony — it's about putting boundaries where change happens: entities and use cases that never import infrastructure, a data layer that quarantines every API quirk behind a mapper, and a Cubit that only knows the domain. Start with one feature folder, resist letting Dio or JSON leak inward, and the structure compounds: faster tests, swappable backends, and parallel teamwork.

If you're untangling a Flutter codebase or want a second pair of eyes on your BLoC layering, get in touch — and if you're staffing a project that needs this done right from the start, you can hire me.

Apple Pay in Flutter: The Easiest Implementation

Gulshan Yadav — Sun, 16 Aug 2026 13:30:00 +0000

So, in this article, I will be showing you how you can integrate Apple Pay into your Flutter app — and yes, this one is genuinely the easiest of the mobile wallets, because Apple has wrapped the entire flow into a native payment sheet. No card form, no bank list, no OTP. The user double-clicks the side button, confirms with Face ID, and the payment token is out.

The reason Apple Pay integration is easy is that Apple does almost everything for you: the card vault, the biometrics, the tokenization, the UI. What is not easy — and what stops most people for a full day — is the Apple Developer setup on the way in. This article covers both: the configuration you have to get right before Flutter, and the minimal Dart you need after.

Let's jump into the coding part.

Adding the Dependencies

For this purpose, we need to add this dependency in your pubspec.yaml file:

dependencies:
  flutter:
    sdk: flutter
  pay_ios: ^1.0.0

pay_ios is Apple's official Flutter plugin for Apple Pay (part of the flutter-pay-plugins). It wraps PassKit's PKPaymentAuthorizationViewController, so you never touch Swift. That single package is the whole dependency story — one line, no extra UI packages, no separate button package.

Step 1: Apple Developer Setup (The Part Everyone Misses)

Before you write a single line of Dart, three things must exist on the Apple side, or your payment sheet will silently refuse to show:

A Merchant ID. In the Apple Developer portal, go to Certificates, Identifiers & Profiles → Identifiers, create a Merchant ID like merchant.com.yourcompany.yourname. This is the ID your code references, and it must be enabled for your App ID.
The Apple Pay capability. In Xcode, open the Runner target → Signing & Capabilities → add "Apple Pay" and select your merchant ID. If you use flutter build, verify this in the generated Xcode project before building the app.
A Payment Processing Certificate. In the Merchant ID settings, create a merchant identity certificate. Apple uses this to encrypt the payment token. If you use a payment provider (Stripe, Adyen, Braintree), they generate this certificate for you; otherwise you create a CSR from Apple.

The classic failure: everything works in code, and the payment sheet says "Apple Pay is not available." Nine times out of ten it is the entitlement or the merchant ID mismatch, not your Dart.

Step 2: The Minimal Dart Implementation

Here is the entire Flutter side. Create a checkout page and present the Apple Pay sheet:

import 'package:flutter/material.dart';
import 'package:pay_ios/pay_ios.dart';

class CheckoutPage extends StatefulWidget {
  const CheckoutPage({super.key});
  @override
  State<CheckoutPage> createState() => _CheckoutPageState();
}

class _CheckoutPageState extends State<CheckoutPage> {
  late final ApplePayClient _client;

  @override
  void initState() {
    super.initState();
    _client = ApplePayClient(
      paymentConfiguration: PaymentConfiguration.fromJsonString(
        '''
        {
          "merchantId": "merchant.com.yourcompany.yourname",
          "merchantName": "Your App Name",
          "countryCode": "US",
          "currencyCode": "USD"
        }
        ''',
      ),
    );
  }

  Future<void> _payWithApplePay() async {
    try {
      final result = await _client.presentApplePay(
        displayItems: const [
          ApplePayItem(
            label: 'Premium Plan',
            amount: '9.99',
            type: ApplePayItemType.final_,
          ),
        ],
        merchantCapabilities: const [
          MerchantCapability.threeDSecure,
        ],
        supportedNetworks: const [
          ApplePayCardNetwork.visa,
          ApplePayCardNetwork.mastercard,
          ApplePayCardNetwork.amex,
          ApplePayCardNetwork.discover,
        ],
        requiredBillingContactFields: const [
          ApplePayContactField.postalAddress,
        ],
        requiredShippingContactFields: const [
          ApplePayContactField.email,
          ApplePayContactField.phone,
        ],
      );

      if (result is ApplePayResult.success) {
        // Send result.token to YOUR backend for verification.
        await _verifyOnServer(result.token);
      } else if (result is ApplePayResult.canceled) {
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('Payment cancelled')),
        );
      }
    } catch (e) {
      debugPrint('Apple Pay error: $e');
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Checkout')),
      body: Center(
        child: ElevatedButton(
          onPressed: _payWithApplePay,
          child: const Text('Pay with Apple Pay'),
        ),
      ),
    );
  }
}

That is the whole implementation. presentApplePay launches the native sheet, the user confirms with Face ID or Touch ID, and you receive an ApplePayResult with the token.

Step 3: Verify the Token on Your Backend

Same rule as every wallet integration, and it is non-negotiable: the device gives you a token, not money. Send it to your backend, and let your backend decrypt and charge it through your payment provider. On the backend, with Stripe it looks roughly like this:

// POST /api/verify-apple-pay
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

const paymentMethod = await stripe.paymentMethods.create({
  type: 'card',
  card: { token: req.body.applePayToken },
});

const intent = await stripe.paymentIntents.create({
  amount: 999,
  currency: 'usd',
  payment_method: paymentMethod.id,
  confirm: true,
});

Confirm success from the gateway's response (or its webhook), never from the app. The app can always lie; the gateway cannot.

The Full Flow in Plain English

Here is the sequence end to end, so you know what happens between the double-click and the money landing:

The user taps your Pay button.
Your app calls presentApplePay, and iOS builds the payment sheet natively — the card, the merchant name, the price, the shipping and contact fields you requested.
The user authenticates with Face ID, Touch ID, or their device passcode.
Apple wraps the selected card into an encrypted, single-use token and returns it to your app.
Your app sends the token to your backend.
Your backend forwards it to your payment provider.
The provider decrypts the token (using the payment processing certificate), charges the card, and confirms — plus fires a webhook.
Your backend marks the order paid and tells the app.

Steps 5 through 8 are where the actual money moves, and they must never be skipped. If steps 3 and 4 work but step 6 never happens, the user believes they paid while you hold nothing.

Adding Line Items Properly

A small detail that trips people: Apple Pay wants every item you show in the sheet to match what you eventually charge. If you show '9.99' but your backend computes tax and charges 10.74, the user approved a different number than the one they paid. The clean pattern:

Build the full order server-side — items, shipping, tax — before presenting the sheet.
Pass the computed total as your ApplePayItem amount.
Send the same order reference to your backend when you forward the token, so the charge uses exactly what was quoted.

If you cannot finalize the amount upfront (variable shipping, tips), use ApplePayItemType.pending, then update the charge server-side to the final value. Keeping the quoted number and the charged number identical avoids a whole category of refund requests and chargeback disputes.

Alternative Approaches

Three variations are worth knowing before you commit:

Button-only, without the manual client. If your checkout is a fixed set of items, some payment providers' Flutter SDKs (Stripe, Adyen) expose a one-call Apple Pay button that handles the sheet and the provider confirmation together. Less code, but it ties you to that provider's SDK for both the UI and the charging.
Stripe/Adyen Flutter SDK with Apple Pay. Rather than managing the token and the backend forward yourself, these SDKs accept your merchant configuration and return a confirmed PaymentMethod you then charge server-side. If you already use one of those providers, this is usually the pragmatic choice — fewer moving parts, one vendor.
Manual PKPaymentRequest via a channel. You can write the PassKit integration yourself in Swift and call it over a MethodChannel. This gives you total control but also total responsibility — entitlement handling, the full authorization delegate, error mapping. The pay_ios plugin exists precisely so you do not have to do this.

Handling the Failure Paths

The sheet succeeds or cancels, and both are real user behavior you must render. Handle them explicitly:

final result = await _client.presentApplePay(...);
if (result is ApplePayResult.success) {
  await _verifyOnServer(result.token);           // confirmed server-side
} else if (result is ApplePayResult.canceled) {
  ScaffoldMessenger.of(context).showSnackBar(
    const SnackBar(content: Text('Payment cancelled')),
  );
} else {
  ScaffoldMessenger.of(context).showSnackBar(
    const SnackBar(content: Text('Payment failed. Please try again.')),
  );
}

A subtle trap: users cancel the sheet by swiping it away or locking the phone — a surprising share of "failed" payments are actually cancels. Handle cancel distinctly, and never show an error screen for a cancel. And never treat the app-level result as proof of charge; only the provider's confirmation counts.

Important Notes & Pitfalls

Real device required. Apple Pay does not work in the iOS Simulator for card payments. Test on a physical iPhone with a sandbox card. This is the #1 thing that makes people think their code is broken.
Sandbox cards. Add a test card (e.g., 4242 4242 4242 4242) in Settings → Wallet on your device. It passes the full flow with no real charge.
Merchant ID must match everywhere. The ID in your code, the ID in Xcode's entitlement, and the ID in Apple's portal must be identical. A single typo and the sheet never appears.
Region availability. Apple Pay only works in supported countries, and your app's region settings matter. An App Store region without Apple Pay will fail gracefully — handle it.
amount is a string with the decimal point. '9.99', not 9.99. Keep the string format consistent with your currency rules.
Token is single-use and short-lived. Do not cache or log it. Forward it to your backend immediately and only once.
ApplePayItemType.final_ vs pending. Use final_ for a fixed charge. Use pending if you'll finalize the amount later (e.g., tips or variable delivery), then update it server-side.
Handle the canceled case explicitly. Users abort the sheet all the time; your UI should return to a clean state, not show a spinner forever.

Testing Checklist

Before you ship, run through this list:

[ ] Sandbox card completes the full flow on a physical device
[ ] Cancel returns the user to a clean state
[ ] Token reaches the backend and the provider confirms the charge
[ ] Webhook updates order status server-side
[ ] Merchant ID is identical in code, entitlement, and portal
[ ] Fallback payment method exists for regions/unsupported devices
[ ] No secrets or merchant IDs committed to the repo

FAQ

Is pay_ios maintained? Yes — it is part of the official Flutter pay plugins maintained by Apple, alongside pay_android for Google Pay.

Do I need my own payment processing infrastructure? No. You need a payment provider agreement (Stripe, Adyen, Braintree) to decrypt the token. Apple Pay itself has no integration fee; you pay your provider's processing fee.

Can I use the same backend as Google Pay? Mostly, yes — both give you a token your backend forwards to the same gateway. That is why a single checkout backend can serve both wallets.

Why does the sheet show "Apple Pay is not available"? Almost always one of: no entitlement in the Xcode target, a merchant ID mismatch between the code and the portal, a payment processing certificate missing, or running on the Simulator. Walk the Step 1 checklist in order — it is a configuration problem, not a code problem.

Is a development device enough for testing? Yes. A physical iPhone with a sandbox card exercises the entire flow. Just remember the sandbox card only works in sandbox mode with the test entitlement — keep that pairing consistent in your build config.

Does Apple Pay work in every country? No. It is available in a growing list of countries, and availability is tied to both the App Store region and the card issuer. Test on a device configured for a supported region, and provide a fallback for everything else.

That's it — a complete Apple Pay integration in Flutter. The Dart is genuinely this short; the configuration is where you will lose time, and I hope the setup section here saves you that day.

I have also written integrations for Google Pay, PayPal, and UPI/Razorpay — comment below with your payment gateway and I'll cover it next.

*Gulshan Yad

One-Shot UI Side Effects in BlocSignal: Snackbars, Dialogs, and Navigation Without State Pollution

Randal L. Schwartz — Sat, 15 Aug 2026 18:45:56 +0000

Every Flutter developer has run into the Sticky State Dilemma.

You build a login screen. When authentication fails, your state container emits an error. You catch it in your UI and show a SnackBar. Everything works—until the user rotates their phone, pulls down the notification shade, or types on the virtual keyboard.

Suddenly, the widget tree rebuilds. The state container is still holding AuthErrorState("Invalid password"). The UI listener fires again. And a duplicate snackbar appears out of nowhere.

In this article, we’ll explore why domain state machines struggle with transient UI events, how the classic BLoC community worked around this with package:bloc_presentation, and how BlocSignal lets you handle one-shot side effects cleanly with zero additional package dependencies.

1. The Root Problem: Persistent State vs. Ephemeral Actions

State management in Flutter is designed to model persistent truth over time:

Is the user logged in? AuthState.authenticated(user)
Is data loading? TodoState.loading
What is the cart total? $49.99

Persistent state answers: "What is the system's current condition?"

In contrast, UI presentation actions are ephemeral pulses:

Show a brief SnackBar toast.
Pop up an alert confirmation dialog.
Push a new route on the Navigator stack.
Vibrate the haptic motor.

These actions answer: "What just happened that requires a one-time reaction?"

 ┌────────────────────────────────────────────────────────┐
 │                   State vs. Effects                    │
 ├────────────────────────────┬───────────────────────────┤
 │ Persistent State           │ Ephemeral Side-Effect     │
 ├────────────────────────────┼───────────────────────────┤
 │ • Survived by UI rebuilds  │ • Consumed once & gone    │
 │ • Represented in signals   │ • Triggered by an event   │
 │ • Backed by equality diffs │ • Zero domain state footprint │
 └────────────────────────────┴───────────────────────────┘

2. The Legacy Workarounds (And Their Hidden Costs)

Historically in package:bloc and package:flutter_bloc, developers used one of three approaches:

Workaround A: The "Reset State" Ping-Pong

// Emitting a reset state immediately after error
emit(AuthFailure(error));
emit(AuthInitial()); // Extra emission, extra microtask, extra rebuild!

Downside: Causes two separate microtask queue ticks and multiple widget rebuild cycles just to reset a transient flag.

Workaround B: "Consumed" Wrapper Flags

class AuthState {
  final String? errorSnackbarMessage;
  final bool hasShownSnackbar; // Manual bookkeeping everywhere!
}

Downside: Clutters state classes with imperative UI tracking flags that violate domain purity.

Workaround C: `package:bloc_presentation`

LeanCode created package:bloc_presentation, adding a separate secondary StreamController.broadcast() to Blocs so developers could call emitPresentation(MyEvent()) independently of emit(state).

While bloc_presentation solved the problem well for classic BLoC, maintaining third-party wrapper packages in your monorepo introduces versioning churn, boilerplate, and dependency overhead.

3. The `BlocSignal` Advantage: 0ms Synchronous Guarantees

In BlocSignal, state propagation is synchronous.

Unlike classic BLoC which queues updates asynchronously on microtask-queue Streams, calling emit(newState) in BlocSignal updates the underlying reactive signal and settles dependencies immediately in the exact same frame.

Because state updates are synchronous, you often don't need any presentation streams at all!

Pattern 1: Direct Async UI Handlers (Recommended)

When an action is initiated by a user interaction (like tapping a button), the simplest and cleanest pattern is handling the reaction right in the button's onPressed callback:

ElevatedButton(
  onPressed: () async {
    final cubit = context.read<AuthCubit>();

    // 1. Await domain logic completion
    await cubit.signIn(emailController.text, passwordController.text);

    // 2. Safe async context guard
    if (!context.mounted) return;

    // 3. Inspect settled state synchronously with Dart pattern matching
    switch (cubit.stateValue) {
      case AuthSuccess(:final user):
        Navigator.of(context).pushReplacementNamed('/dashboard');
      case AuthFailure(:final error):
        ScaffoldMessenger.of(context).showSnackBar(
          SnackBar(content: Text(error)),
        );
      case _:
        break;
    }
  },
  child: const Text('Log In'),
)

Why this works so well in BlocSignal:

Zero Race Conditions: The moment cubit.signIn(...) finishes, cubit.stateValue is 100% up to date.
Zero Duplicate Triggers: Screen rotations or unrelated rebuilds will never re-execute the button handler.
Zero Extra Code: No special listeners, no extra streams, no consumable wrapper classes.

4. The Zero-Dependency `PresentationMixin` Recipe

What if your domain state machine triggers side-effects autonomously (for example, an incoming WebSocket disconnects, a background sync finishes, or you are migrating an existing codebase from bloc_presentation)?

You can drop in a 100% compatible presentation architecture in ~25 lines of pure Dart without adding any 3rd-party dependencies.

Step 1: The Mixin (`BlocSignalPresentationMixin`)

import 'dart:async';
import 'package:bloc_signals/bloc_signals.dart';

/// Mixin that adds one-shot presentation event broadcasting to any [BlocSignalBase].
mixin BlocSignalPresentationMixin<Event, State> on BlocSignalBase<State> {
  final _presentationController = StreamController<Event>.broadcast();

  /// Stream of one-shot presentation events.
  Stream<Event> get presentationStream => _presentationController.stream;

  /// Dispatches a one-shot presentation event to active UI listeners.
  void emitPresentation(Event event) {
    if (!isClosed) {
      _presentationController.add(event);
    }
  }

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

Step 2: The Flutter Listener (`BlocSignalPresentationListener`)

import 'dart:async';
import 'package:flutter/widgets.dart';
import 'package:bloc_signals_flutter/bloc_signals_flutter.dart';

/// Listens to one-shot presentation events from a [BlocSignalBase] with [BlocSignalPresentationMixin].
class BlocSignalPresentationListener<
        B extends BlocSignalPresentationMixin<Event, dynamic>, Event>
    extends StatefulWidget {
  const BlocSignalPresentationListener({
    required this.listener,
    this.bloc,
    this.child,
    super.key,
  });

  final B? bloc;
  final void Function(BuildContext context, Event event) listener;
  final Widget? child;

  @override
  State<BlocSignalPresentationListener<B, Event>> createState() =>
      _BlocSignalPresentationListenerState<B, Event>();
}

class _BlocSignalPresentationListenerState<
        B extends BlocSignalPresentationMixin<Event, dynamic>, Event>
    extends State<BlocSignalPresentationListener<B, Event>> {
  StreamSubscription<Event>? _subscription;
  B? _resolvedBloc;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    final bloc = widget.bloc ?? context.read<B>();
    if (_resolvedBloc != bloc) {
      _unsubscribe();
      _resolvedBloc = bloc;
      _subscribe();
    }
  }

  void _subscribe() {
    _subscription = _resolvedBloc?.presentationStream.listen((event) {
      if (mounted) widget.listener(context, event);
    });
  }

  void _unsubscribe() {
    _subscription?.cancel();
    _subscription = null;
  }

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

  @override
  Widget build(BuildContext context) => widget.child ?? const SizedBox.shrink();
}

5. Putting It Together: A Real-World Example

Let's see how clean our Cubit and UI look when composed together:

1. Events & Cubit Definition

import 'package:bloc_signals/bloc_signals.dart';

// 1. Define one-shot presentation events as a sealed hierarchy
sealed class CheckoutPresentationEvent {}

class ShowErrorToast extends CheckoutPresentationEvent {
  ShowErrorToast(this.message);
  final String message;
}

class LaunchPaymentGateway extends CheckoutPresentationEvent {
  LaunchPaymentGateway(this.invoiceUrl);
  final String invoiceUrl;
}

// 2. Attach the mixin to your Cubit or Bloc
class CheckoutCubit extends CubitSignal<CheckoutState>
    with BlocSignalPresentationMixin<CheckoutPresentationEvent, CheckoutState> {
  CheckoutCubit() : super(initialState: CheckoutInitial());

  Future<void> processPayment() async {
    emit(CheckoutProcessing());
    try {
      final invoice = await paymentApi.createInvoice();
      emit(CheckoutSuccess());

      // Emit one-shot navigation/payment launch event
      emitPresentation(LaunchPaymentGateway(invoice.url));
    } catch (e) {
      emit(CheckoutFailure(e.toString()));

      // Emit transient error toast event
      emitPresentation(ShowErrorToast("Payment failed: ${e.toString()}"));
    }
  }
}

2. The Flutter UI

class CheckoutView extends StatelessWidget {
  const CheckoutView({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocSignalPresentationListener<CheckoutCubit, CheckoutPresentationEvent>(
      listener: (context, event) {
        switch (event) {
          case ShowErrorToast(:final message):
            ScaffoldMessenger.of(context).showSnackBar(
              SnackBar(
                content: Text(message),
                backgroundColor: Colors.redAccent,
              ),
            );
          case LaunchPaymentGateway(:final invoiceUrl):
            launchUrl(Uri.parse(invoiceUrl));
        }
      },
      child: Scaffold(
        appBar: AppBar(title: const Text('Checkout')),
        body: const CheckoutBody(),
      ),
    );
  }
}

6. Migration Comparison Matrix

Feature	Legacy `bloc_presentation`	`BlocSignal` Presentation Recipe
External Dependencies	`package:bloc_presentation` + `nested`	0 external dependencies
Architecture	Stream-based side channel	Stream-based side channel
Emission Syntax	`emitPresentation(event)`	`emitPresentation(event)`
Listener Widget	`BlocPresentationListener`	`BlocSignalPresentationListener`
Automatic Cleanup	Manual stream closing	Managed in `close()` lifecycle
State Reactivity	Microtask Streams	Synchronous Signals (0ms)

Summary

Handling one-shot side-effects shouldn't require complex state hacks or heavy external packages:

For user interactions: Use Direct Async UI Handlers (await cubit.action())—BlocSignal's synchronous emissions make this glitch-free and safe.
For asynchronous domain broadcasts: Use the 25-line BlocSignalPresentationMixin recipe for 100% bloc_presentation parity with zero dependencies.
Keep domain state clean: Keep persistent data in stateValue and ephemeral UI triggers in presentation streams.

Resources & Links

📦 bloc_signals on pub.dev
🌐 Official Website: blocsignal.dev
💻 GitHub Repository: RandalSchwartz/BlocSignal

Google Pay Integration in Flutter with One Button

Gulshan Yadav — Sat, 15 Aug 2026 13:30:00 +0000

So, in this article, I will be showing you how you can add Google Pay to your Flutter app with literally one button. No card-number form, no CVV field, no "add a payment method" screen. The user taps the Google Pay button, picks a card that Google Pay already knows, confirms with their fingerprint, and the payment data is on its way.

I keep getting asked about payments in Flutter, and after PayPal and Stripe, Google Pay is the one people want next. The good news: it is the easiest of the three, because Google has done the hard work. In this article I'll show you the exact dependencies, the button, the flow, and the pitfalls I hit when I first shipped it — so you don't lose a day to the same setup trap.

Let's jump into the coding part.

Adding the Dependencies

For this purpose, we need to add these dependencies in your pubspec.yaml file:

dependencies:
  flutter:
    sdk: flutter
  pay_android: ^1.0.0
  google_pay_button: ^0.1.0

pay_android is the official Google-maintained Flutter plugin for Google Pay. It wraps the native Android Google Pay API, so you don't need to write Kotlin.
google_pay_button renders the actual branded Google Pay button, so you comply with Google's button guidelines without hand-drawing the G logo.

If you only want the button and prefer to write the payment logic yourself, skip google_pay_button. But if you want the one-tap experience described above, take both.

Step 1: Configure Android

Before any Dart runs, the Android side needs two things:

Your app's minSdkVersion must be 21 or higher (in android/app/build.gradle).
Add the Google Pay meta-data to your AndroidManifest.xml:

<meta-data
    android:name="com.google.android.gms.wallet.api.enabled"
    android:value="true" />

Now add your payment configuration as an asset. This is a JSON file that tells Google Pay which networks, auth methods, and gateway to use. Create assets/google_pay.json:

{
  "provider": "google_pay",
  "environment": "TEST",
  "merchantName": "Your App Name",
  "merchantId": "BCR2DN4TXXXXXXXXXX",
  "allowedCardNetworks": ["VISA", "MASTERCARD", "AMEX"],
  "allowedAuthMethods": ["PAN_ONLY", "CRYPTOGRAM_3DS"],
  "gateway": {
    "gateway": "stripe",
    "gatewayMerchantId": "pk_test_..."
  }
}

A few important notes on this file:

environment: "TEST" means you can run the whole flow with test cards and no real money moves. Switch it to "PRODUCTION" only for release builds.
merchantId is your Google Pay merchant ID from the Google Pay & Wallet Console. You can leave it empty in TEST, but production requires it.
allowedAuthMethods: PAN_ONLY is the card on file, CRYPTOGRAM_3DS is the encrypted token. Using both maximizes the number of users who can pay.
The gateway section tells Google which payment processor will decrypt the token — Stripe, Adyen, Braintree, etc. You need a live account with that gateway before production.

flutter:
  assets:
    - assets/google_pay.json

Step 2: The One Button

Here is the whole Flutter side. Create a checkout page and drop the button in:

import 'package:flutter/material.dart';
import 'package:google_pay_button/google_pay_button.dart';
import 'package:pay_android/pay_android.dart';

class CheckoutPage extends StatefulWidget {
  const CheckoutPage({super.key});
  @override
  State<CheckoutPage> createState() => _CheckoutPageState();
}

class _CheckoutPageState extends State<CheckoutPage> {
  late final PaymentConfiguration _config;

  @override
  void initState() {
    super.initState();
    PaymentConfiguration.fromAsset('assets/google_pay.json')
        .then((config) => setState(() => _config = config));
  }

  Future<void> _onGooglePayPressed() async {
    // 1. Confirm the device can actually pay.
    final client = PaymentsClient(environment: Environment.test);
    final isReady = await client.isReadyToPay(
      paymentConfiguration: _config,
      allowedCardNetworks: const [CardNetwork.visa, CardNetwork.mastercard],
      allowedAuthMethods: const [AuthMethod.cryptogram3ds, AuthMethod.panOnly],
    );
    if (!isReady) return;

    // 2. Present the Google Pay sheet.
    final result = await client.presentPaymentSheet(
      merchantName: 'Your App Name',
      paymentConfiguration: _config,
      paymentItems: const [
        PaymentItem(
          label: 'Premium Plan',
          amount: '9.99',
          status: PaymentItemStatus.finalPrice,
        ),
      ],
    );

    // 3. Handle the result.
    if (result is PaymentResult.success) {
      // Send result.token to YOUR backend for verification.
      await _verifyPaymentOnServer(result.token.paymentData);
    } else if (result is PaymentResult.canceled) {
      ScaffoldMessenger.of(context).showSnackBar(
        const SnackBar(content: Text('Payment cancelled')),
      );
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Checkout')),
      body: Center(
        child: GooglePayButton(
          paymentConfiguration: _config,
          onPressed: _onGooglePayPressed,
          type: GooglePayButtonType.buy,
        ),
      ),
    );
  }
}

That's it. That is the entire integration. The GooglePayButton widget handles the tap; presentPaymentSheet opens Google's native sheet where the user picks a card and confirms with biometrics; and you get a PaymentResult to react to.

Step 3: Verify the Token on Your Backend

Here is the part most beginners get wrong, and it matters: the Google Pay token is not money collected. It is a one-time encrypted payment credential. Your app must send it to your own backend, and your backend must pass it to your payment gateway (Stripe, Adyen, etc.) which decrypts it and actually charges the card.

Flutter app ──▶ Your backend ──▶ Payment gateway (decrypt + charge)
                    ▲
                    └── webhook: payment.succeeded ──▶ mark order paid

Never trust the app to tell you the payment succeeded. Always confirm the charge server-side, ideally via the gateway's webhook. On the backend, for Stripe it looks roughly like this:

// POST /api/verify-payment
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

const paymentMethod = await stripe.paymentMethods.create({
  type: 'card',
  card: { token: req.body.googlePayToken },
});

const intent = await stripe.paymentIntents.create({
  amount: 999,
  currency: 'usd',
  payment_method: paymentMethod.id,
  confirmation_method: 'manual',
  confirm: true,
});

Different gateways have different calls, but the pattern is identical: forward the token, wait for the gateway to confirm, then mark the order paid.

The Full Flow in Plain English

Here is the whole sequence, so you know exactly what happens between the tap and the charge landing in your account:

The user taps the Google Pay button.
Your app calls isReadyToPay to confirm the device has Google Pay set up with an eligible card.
Your app calls presentPaymentSheet, and Google's native sheet opens — the card list, the price, the pay button.
The user authenticates (fingerprint, face unlock, or PIN) and approves.
Google returns an encrypted, single-use payment token to your app.
Your app sends the token to your backend.
Your backend forwards it to the payment gateway.
The gateway decrypts the token, charges the card, and returns a confirmation (and fires a webhook).
Your backend marks the order paid and tells the app.

Steps 6 through 9 are the ones you must never skip. If steps 4 and 5 work but step 7 never happens, the user believes they paid and you never receive the money. That is the exact failure mode that looks like a successful integration in the demo and collapses in production.

Alternative Approaches

Two variations are worth knowing before you commit:

Button-only, without the manual PaymentsClient. The GooglePayButton widget can present the sheet and return the result through its own onPaymentResult callback, skipping the explicit isReadyToPay check and the manual presentPaymentSheet call. It is less code, but you lose fine-grained control — per-run payment items and explicit readiness handling. For a single fixed product price, the button-only path is fine; for dynamic carts, keep the explicit client.
WebView fallback with Google Pay's JavaScript API. You can render the Google Pay web experience inside a webview_flutter and bridge the token back to Dart. This is useful when your backend already runs the web checkout and you want to reuse the same flow on mobile. The cost: no native sheet, a JavaScript bridge you own, and message-passing and error handling that live in your code. I have used this for a legacy app with an existing web checkout. For a new build, I would take the native plugin every time.

Handling the Failure Paths

The happy path is one line of code; the failure paths are where payments are actually won or lost. Cover at least these cases in your UI:

final result = await client.presentPaymentSheet(...);
if (result is PaymentResult.success) {
  await _verifyPaymentOnServer(result.token.paymentData);
} else if (result is PaymentResult.canceled) {
  // User closed the sheet — return them to a clean cart state.
  ScaffoldMessenger.of(context).showSnackBar(
    const SnackBar(content: Text('Payment cancelled')),
  );
} else {
  // Any other failure — do NOT silently stay on a spinner.
  ScaffoldMessenger.of(context).showSnackBar(
    const SnackBar(content: Text('Payment failed. Please try again.')),
  );
}

Never leave the button in a loading state after a failure, and never show success based on the app's result alone — success must be confirmed by your backend.

Important Notes & Pitfalls

Never hardcode Environment.test in release. Read the environment from a config flag, not from editing the file per build.
The token is single-use. Do not cache it, do not log it to console, do not display it. One charge attempt per token.
Google Pay is Android-only. This plugin does nothing on iOS. For iOS you integrate Apple Pay separately.
Requires Google Play Services. Test on an emulator with Play Services enabled, or on a real device. On a bare emulator the button will simply not work.
PaymentItem amounts are strings, not numbers. '9.99', not 9.99. Round to the currency's smallest unit display — a missing decimal place has shipped real-world pricing bugs.
Test with real test cards. In TEST mode use your gateway's test cards (e.g., Stripe's 4242 4242 4242 4242). The flow is 100% real except no money moves.
Handle isReadyToPay == false. Some devices/browsers won't support Google Pay. Show a fallback payment method instead of a dead button.
Don't forget the gateway agreement. The token is encrypted to a gateway. You must have a live account with the gateway listed in your google_pay.json or production decryption fails with a confusing error.

Testing Checklist

Before you ship, walk through this list:

[ ] TEST environment payment with a test card completes end-to-end
[ ] Cancellation flow returns the user to the app with a clear message
[ ] Token reaches your backend and the gateway confirms the charge
[ ] Webhook updates the order status server-side (not just the app)
[ ] isReadyToPay == false falls back to another payment method
[ ] PRODUCTION environment switch is config-driven, not manual
[ ] No secret keys or merchant IDs committed to the repo

FAQ

Is pay_android still maintained? Yes. It is part of the official Flutter pay plugins maintained by Google, with active releases.

Can I use this with any backend language? Yes. The Flutter side just sends the token to your backend; the backend can be Node, Python, Go, anything that talks to your gateway.

Does Google Pay support recurring subscriptions? Google Pay returns a single-payment token. For recurring billing, use that token to create a customer and a subscription in your gateway (Stripe, Razorpay, etc.) on your backend, then charge it on your own schedule. Do not expect Google Pay itself to manage recurring charges.

Why did TEST work but production fails? The three classic causes, in order: the environment is still TEST, the merchant ID is missing or wrong, or the gateway listed in google_pay.json does not match the gateway actually processing the token. The token is encrypted to a specific gateway, so a mismatch fails at decryption time with a confusing error.

Does Google Pay cost money to integrate? No integration fee from Google. You pay the standard processing fee to your payment gateway.

That's it — a complete Google Pay integration in Flutter, with one button. The whole thing took me less than an hour once I had the google_pay.json right, and I hope this saves you the setup trap I hit on my first attempt.

I have also written integrations for PayPal, Stripe, and UPI/Razorpay — comment below with your payment gateway and I'll cover it next.

*Gulshan Yad

Flutter app development company: 7 questions that expose a partner in 2026

Manu Shukla — Sat, 15 Aug 2026 10:56:35 +0000

Flutter app development company: 7 questions that expose a partner in 2026

Summary. Flutter 3.47 reached stable on 12 August 2026, alongside Dart 3.13, on a published cadence of four stable releases a year. That release made Impeller the default renderer on macOS, Windows and Linux, raised the iOS minimum from 13 to 15 and macOS from 10.15 to 12, and confirmed that the Material and Cupertino design libraries are scheduled for formal deprecation in the November 2026 stable release. Google Play requires new apps and updates to target API level 36 from 31 August 2026. Apple has required the iOS 26 SDK for App Store Connect uploads since 28 April 2026. Google reported over 1.5 million monthly Flutter developers at I/O 2026, up 50% year on year.

None of that is exotic. All of it is public. And a Flutter partner who cannot walk you through it is going to hand you a codebase that needs three forced migrations in its first year.

The useful way to evaluate a Flutter company in 2026 is not to look at their portfolio. It is to ask them what is about to break.

Question 1: what stable release are you on, and what is the cadence?

The current stable is Flutter 3.47.0, listed at the top of the Flutter release notes, with 3.44.0, 3.41.0 and 3.38.0 behind it. Dart 3.13.0 shipped the same day; the Dart what's new page records "Released on: August 12, 2026" and covers changes from 18 May 2026 onward. Its headline language feature is primary constructors, which we covered when it landed in Dart 3.12 primary constructors and dot shorthands.

The cadence is published a year ahead. Flutter's install archive lists the 2026 schedule as 3.41 in February, 3.44 in May, 3.47 in August and 3.50 in November, each with a branch cutoff roughly five weeks before release, and notes that roughly every third beta is promoted to stable.

That matters commercially because it makes maintenance predictable and therefore quotable. A partner proposing an annual "upgrade project" is either padding or has not read the schedule. Four stable releases a year, absorbed continuously, is a small standing cost. Four skipped, absorbed at once, is the expensive version.

Ask which release their last three delivered projects run on. If the answer is more than two stables behind, ask why.

Question 2: what did you do about Impeller?

Impeller has quietly finished replacing Skia almost everywhere. Flutter's Impeller documentation is unambiguous by platform.

On iOS, "Impeller is the only supported rendering engine on iOS with no ability to switch to Skia." On Android, it "is available and enabled by default on Android API 29+", falling back to the legacy OpenGL renderer on lower versions or devices without Vulkan, with an opt-out still available through --no-enable-impeller or the io.flutter.embedding.android.EnableImpeller manifest key. On macOS, Windows and Linux the documentation now reads that Impeller "is available and enabled by default as of Flutter 3.47" and that "in a future release, the ability to opt out of using Impeller will be removed."

Web is the exception. Flutter on the web still uses Skia and "might use Impeller in the future."

A partner who shipped a desktop Flutter app before August 2026 has a renderer change to validate, particularly around custom shaders and platform views. One who does not know that is not tracking the engine. We wrote about this transition when it became mandatory on mobile in Impeller becoming mandatory on Flutter Android and iOS.

Question 3: are you off CocoaPods yet?

This is the cleanest single test of whether a partner is current, because it has a public scoreboard.

Swift Package Manager replaced CocoaPods as the default dependency manager for iOS and macOS Flutter apps in Flutter 3.44. The Flutter 3.47 release post states that "because CocoaPods is now in maintenance mode, plugins that do not migrate to SwiftPM will eventually stop working", that unmigrated plugins "also receive lower pub.dev scores", and that 92 of the top 100 iOS plugins have now migrated.

The scoreboard is the useful part. If a partner's proposed plugin list includes packages still on CocoaPods, that is a visible, checkable risk in the estimate rather than an argument about quality. Our walkthrough of the mechanics is in the CocoaPods sunset and SwiftPM migration for iOS and Flutter.

Question 4: what is your plan for Material and Cupertino leaving the SDK?

This is the largest forced migration on the Flutter horizon and it is three months away.

The Flutter 3.47 release post states that "the original design libraries inside the core SDK are scheduled for formal deprecation in the upcoming Fall stable release in November." Flutter provides an automated path, dart fix --apply --code=migrate_design_widgets, and the direction was set out in the 2026 Flutter and Dart roadmap, which describes "decoupling the Material and Cupertino design systems into standalone packages" as part of moving to an open and sustainable operating model.

Automated migrations handle the common cases and leave the interesting ones. Heavily themed apps, custom widget subclasses and anything that reaches into Material internals will need hands on it. A partner quoting a fixed-price build for delivery in Q4 2026 without a line for this migration is quoting a number they will come back to renegotiate. We set out the detail in the Flutter Material and Cupertino UI package migration.

There is a related survey signal worth knowing. Flutter's Q2 2026 developer survey, run 8 to 22 June 2026 with over 3,500 complete responses, reported 93% positive satisfaction overall and trust in Flutter rising from 77% to 83%, but recorded that "Cupertino widgets dropped 6 points to 61% top-2 box, marking the steepest decline anywhere in the survey." The iOS-fidelity story is the soft spot, and it is the one being restructured.

Question 5: which OS floors did you just lose?

Flutter 3.47 raised minimums, and that has product consequences before it has engineering ones.

The 3.47 release post records the iOS minimum moving from 13 to 15 and macOS from 10.15 to 12, the latter explicitly to support Xcode 27. The current supported platforms matrix gives Android 24 to 37 supported with 23 and earlier unsupported, iOS 15 to 26 supported with 14 and earlier unsupported, macOS Monterey through Tahoe, Windows 10 and 11, and web on the latest two versions of Chrome, Edge and Firefox plus Safari 15.6 and above.

Android toolchain requirements moved with it. The 3.47 post pins Java 17 as the minimum, KGP 2.4.0, AGP 9.1.0 and Gradle 9.3.1, with compileSdkVersion and targetSdkVersion defaulting to API 36 and minSdkVersion to API 24. The Kotlin plugin change is a hard build break, not a warning: Flutter's built-in Kotlin migration guide states that "built-in Kotlin is the default in AGP 9 and later. Apps that use the kotlin-android plugin, also known as the Kotlin Gradle Plugin (KGP), will fail to build." Our migration notes are in the Flutter AGP 9 and KGP migration decision.

One more, driven by Apple rather than Flutter: the 3.47 post warns that "the iOS 27 SDK now mandates the UIScene lifecycle for all UIKit-based apps. Apps built with Xcode 27 that do not adopt UIScene will fail to launch on startup."

Migration	Landed or lands	Nature	Automated path
Impeller on desktop	Flutter 3.47, Aug 2026	Default renderer, opt-out to be removed	None; requires validation
CocoaPods to SwiftPM	Default since 3.44, May 2026	Dependency manager, plugins degrade	Partial, plugin-dependent
Material and Cupertino out of SDK	Scheduled Nov 2026 stable	Formal deprecation, packages split out	`dart fix --apply --code=migrate_design_widgets`
KGP to built-in Kotlin	Flutter 3.44	Hard build failure under AGP 9	Documented manual migration
iOS and macOS minimum floors	Flutter 3.47	iOS 13 to 15, macOS 10.15 to 12	None; a product decision
UIScene lifecycle	iOS 27 SDK	App fails to launch if unadopted	None; required adoption

Question 6: how are you handling the store deadlines?

Two dates bind every Flutter app this year, and only one of them is in the future.

Google Play's target API level policy states that "starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play", with Wear OS and Android Automotive at API 35 and Android TV and Android XR at API 34. The consequence of missing it is worth reading precisely, because it is routinely overstated: non-compliant apps "will stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app's target API level." Existing installs are unaffected, and an extension to 1 November 2026 can be requested.

Apple's requirement is already live. Apple's developer news post of 3 February 2026 set out that "starting April 28, 2026, apps and games uploaded to App Store Connect need to meet the following minimum requirements: iOS and iPadOS apps must be built with the iOS 26 & iPadOS 26 SDK or later", and Apple's submission guidance now states the same requirement in the past tense.

Flutter 3.47's defaults already put you at targetSdkVersion 36, so a current toolchain satisfies Google Play by construction. That is the actual argument for staying current: the deadline is free if you are up to date and a project if you are not.

Question 7: what evidence do you have, and what do you not have?

This is the question that separates an engineering partner from a sales one, and the honest answer disqualifies most Flutter marketing.

There is no credible, independently measured Flutter versus React Native benchmark in the public record. The startup-time and cost-reduction figures that circulate, including a widely repeated cold-start comparison, appear only in agency blogs with no traceable measurement behind them. If a partner quotes you a percentage for how much faster or cheaper Flutter is, ask for the source. There usually is not one.

The defensible evidence is narrower and more useful.

Adoption, from Google directly: the Flutter 3.44 release post from I/O 2026 states Flutter is "the second most popular development SDK for mobile on both major app stores with over 1.5 million monthly developers, a 50% increase in just one year", with over 1.3 billion package downloads in the preceding 30 days and more than 1,700 contributors landing 5,800 changes in the core repository over the year.

Survey position, from a neutral source: the Stack Overflow 2024 Developer Survey put Flutter at 9.4% and React Native at 8.4% among all respondents, and 9.4% against 9.0% among professional developers. That is the most recent Stack Overflow edition carrying the comparison; the 2025 survey did not publish one, so any Flutter percentage attributed to a 2025 Stack Overflow survey is mis-sourced.

A first-party migration account: LG Electronics wrote in its webOS Flutter experiment post that "without any optimization whatsoever, our Flutter rewrite launched twice as fast as our original app, consumed less runtime memory, and felt more responsive", and that Flutter gave them "increased developer productivity, better runtime app performance, and ... a smoother experience finding and hiring talented developers." The caveat belongs with the quote: LG was comparing Flutter to a React-based TV app, not to React Native on a phone, and the figure is LG's own.

If the decision is genuinely open between the two frameworks, the hiring market is usually the deciding variable rather than the runtime, which is the case we make in the React Native versus Flutter hiring decision framework and in our react native app development company page.

Governance: who actually maintains this now

Worth knowing before you commit a five-year product to it.

Canonical is now lead maintainer of Flutter Desktop. The 3.44 release post announced "an expanded partnership with Canonical, who will now serve as the lead maintainer and Strategic Steward for Flutter Desktop", leading the desktop roadmap and overseeing the Linux, Windows and macOS embedders.

Google is no longer the majority contributor. The Q2 2026 survey post states that "over 70% of currently open PRs in the Flutter project come from contributors outside of Google", and describes a proposed four-tier Contributor Ladder running Contributor, Reviewer, Committer, Maintainer, with public data-driven promotion in a new flutter/contributors repository, "replacing the old informal sponsorship model entirely."

Two related claims are circulating that we could not source to anything primary, so treat them as unfounded: there is no "Flutter Foundation", and 2026-dated claims about Google layoffs hitting the Flutter team trace to no primary source.

One nuance for Mac-based teams: Flutter's supported platforms page warns that "as Apple phases out Intel-based Macs, Flutter is phasing out support for Intel (x64) hardware", and the 3.47 post confirms automated test runs on Intel hardware are disabled with CLI warnings that "will become errors in a future release." No release number or date has been published for the removal. If a partner gives you one, they are guessing.

India-specific considerations

Two things shift the calculus for an India-based build.

Talent depth in Flutter is genuinely good and the rate differential is real, but the migration calendar above is where offshore engagements most often go wrong. A team hired on a fixed scope quoted before August 2026 has no contractual room for the November Material deprecation. Contract for a maintenance allowance tied to the four published stable releases rather than treating each one as a change request.

Second, if the app handles personal data of users in India, the Digital Personal Data Protection Rules commence in tranches with consent and notice duties landing 13 May 2027. That is an architecture decision to take during the build, not a compliance task afterwards. Our view is in the DPDP Act engineering playbook for Indian startups.

What we build, and how the engagement runs

eCorpIT builds Flutter applications for mobile and, where it fits, desktop, with the migration calendar written into the plan rather than discovered later. Our delivery process is discovery and platform-floor decisions, architecture and state-management selection, build in two-week increments with a running app from sprint two, hardening and security review under our ISO 27001:2022 practices, and launch with an agreed upgrade cadence covering the four stable releases a year.

We were founded in 2021, are based in Gurugram, and hold CMMI Level 5, MSME certification and ISO 27001:2022, with partner relationships including AWS, Microsoft and Google. On engagement models we run a fixed-scope build where the specification is settled and the delivery window sits clear of a known migration, a dedicated senior-led team on a monthly retainer where the roadmap is still moving, and a milestone-based build-and-transfer where you plan to take the code in-house. For a Q4 2026 delivery we will usually recommend against fixed scope, for the Material reason set out above, and we would rather say that up front than invoice for it later.

If you are assembling requirements, our mobile app development RFP template covers the questions above in a form you can send to several firms at once, and our Flutter 3.44 production upgrade guide shows the level of detail an upgrade actually involves. For a view on delivery models, see agency versus freelancer for mobile app builds.

FAQ

What is the current stable version of Flutter?

Flutter 3.47.0, released on 12 August 2026, alongside Dart 3.13.0 the same day. It sits at the top of the official release notes ahead of 3.44.0, 3.41.0 and 3.38.0. Flutter ships four stable releases a year on a published schedule, with 3.50 due in November 2026.

Is Skia still used in Flutter?

Only on the web. Impeller is the only supported renderer on iOS, is enabled by default on Android API 29 and above with an OpenGL fallback below that, and became the default on macOS, Windows and Linux in Flutter 3.47. The documentation says desktop opt-out will be removed in a future release.

What is happening to Material and Cupertino widgets?

They are moving out of the core SDK into standalone packages. Flutter's 3.47 release post states the original design libraries inside the core SDK are scheduled for formal deprecation in the November 2026 stable release. An automated migration exists as dart fix with the migrate_design_widgets code, but themed apps need manual work.

What minimum OS versions does Flutter 3.47 support?

The supported platforms matrix gives Android API 24 to 37 and iOS 15 to 26, with Android 23 and earlier and iOS 14 and earlier unsupported. Flutter 3.47 raised the iOS minimum from 13 to 15 and the macOS minimum from 10.15 to 12, the latter to support Xcode 27.

When do we have to target Android API 36?

From 31 August 2026, new apps and app updates must target Android 16, API level 36, to be submitted to Google Play. Missing it does not remove the app; it stops being discoverable to users on newer Android versions. An extension to 1 November 2026 can be requested if needed.

Is Flutter more popular than React Native?

The most recent Stack Overflow survey carrying the comparison is 2024, which put Flutter at 9.4% and React Native at 8.4% among all respondents. Google reported over 1.5 million monthly Flutter developers at I/O 2026, a 50% year-on-year increase. The 2025 survey published no such figure.

Are Flutter benchmarks against React Native reliable?

Generally not. There is no independently measured public benchmark comparing the two, and the startup-time and cost-saving percentages that circulate appear only in agency marketing without traceable measurement. Ask any partner quoting such figures for the primary source before treating the number as real.

Who maintains Flutter now?

Google still leads the project, but Canonical became lead maintainer and Strategic Steward for Flutter Desktop in May 2026, overseeing the Linux, Windows and macOS embedders. Flutter reports that over 70% of currently open pull requests come from contributors outside Google, with a formal Contributor Ladder proposed.

How eCorpIT can help

eCorpIT builds and maintains Flutter applications with the release calendar treated as a planning input rather than a surprise. We are a Gurugram-based technology company founded in 2021, holding CMMI Level 5, MSME certification and ISO 27001:2022, with senior-led engineering teams working across mobile, desktop and backend. If you are choosing between firms, the seven questions above work as a screening instrument whether or not you send them to us. If you would like us to review an existing Flutter codebase against the 2026 migration calendar before you commit to a rebuild, contact us and we will tell you what we find.

References

Last updated: 15 August 2026.

Flutter Desktop Input Design — Where Does the Enter Key Actually Go?

yuelinghuashu — Sat, 15 Aug 2026 09:37:15 +0000

From "pressing Enter does nothing" to "the Enter on the arrow-key area still inserts a newline", these desktop input field pitfalls ultimately trace back to a Focus model problem.

Prologue: a bug reported by a user

"After typing in the input field, the first Enter inserts a newline, and only the second one actually submits."

This is an extremely representative problem in Flutter desktop development: mobile input logic cannot be directly transplanted to desktop. On mobile, the "send" button on the soft keyboard naturally triggers onSubmitted; on desktop, there's a physical keyboard where Enter, Shift, and arrow keys are independent visible physical events whose semantics must be defined by the developer.

(Background: this input field comes from an AI-driven interactive narrative app, where the user enters instructions as a "Fate" and the AI unfolds the story. The input field and the streaming reply are the two core interaction entry points of this app, so their details deserve careful polishing.)

My initial approach was very "intuitive": wrap the TextField with an outer Focus and intercept the Enter key inside it. That produced the exact bug at the start of this article — the first Enter became a newline.

1. The real propagation path of keyboard events

Why the intuition is wrong

Most people (including me) write it like this:

Expanded(
  child: Focus(
    onKeyEvent: _handleKeyEvent, // outer Focus intercepts
    child: TextField(
      focusNode: _focusNode,
      maxLines: null, // desktop: multiline
      textInputAction: TextInputAction.newline,
    ),
  ),
)

It looks like onKeyEvent should receive every key press. But in reality, a keyboard event first reaches the node that actually has focus — the EditableText inside the TextField — not the Focus wrapper you put around it.

With maxLines: null + textInputAction: newline, when EditableText receives Enter it:

Inserts a newline internally
Returns KeyEventResult.handled (marking the event as consumed)

Once an event is handled, it no longer bubbles up to the outer Focus. Your _handleKeyEvent never receives the event and obviously can't intercept it. The first Enter becomes a newline; the second one "happens" to submit.

The word "bubbling" naturally makes frontend readers think of JS DOM event bubbling. The two do share a commonality: the event starts at a point, propagates up a chain, and can be stopped midway if consumed. But the details of "propagation path" and "midway stop" are completely different:

	JS DOM events	Flutter keyboard events
What determines the propagation path	DOM tree	Focus Chain
Is visual containment = propagation path?	Yes	No (focus relation ≠ containment relation)
Propagation direction	capture down → target → bubble up	focus node → up the focus chain
Midway stop	`stopPropagation()`	return `KeyEventResult.handled`
Key difference	any DOM ancestor receives the event	inner node can consume early; the event is cut off before bubbling reaches ancestors

In JS, an outer div wrapping an inner input always receives the event — visual containment is the propagation path, so intercepting at the outer layer is natural. But in Flutter, the event travels along the focus chain, not the widget containment tree: the EditableText inside the TextField is the current focus node, and the event starts there and propagates up the focus chain. The outer Focus, as an ancestor of EditableText, is indeed on the focus chain — but the problem is that EditableText returns KeyEventResult.handled when handling Enter, so the event bubble is cut off before it reaches the outer Focus. That's the real reason "wrapping the TextField with an outer Focus fails to intercept Enter": it's not that the node is off the chain, but that the event is already consumed before it arrives.

The correct mounting point

Bind the keyboard event handler directly to the TextField's own FocusNode:

late FocusNode _focusNode;

@override
void initState() {
  super.initState();
  _focusNode = FocusNode(onKeyEvent: _handleKeyEvent);
}

// No outer Focus wrapper needed in build
Expanded(
  child: TextField(
    focusNode: _focusNode,
    // ...
  ),
)

This way _handleKeyEvent runs before EditableText processes the event. Enter (without Shift) returns handled to prevent the newline and send; Shift+Enter returns ignored to let the TextField insert a newline.

Lesson: in Flutter, "wrapping a widget" is not the same as "being able to intercept keyboard events from descendant widgets". If you want to intercept something, mount the listener on the node the event actually passes through.

2. The same "Enter", two key codes

After fixing the "first Enter creates a newline" bug, another user reported: "the Enter on the arrow-key area still inserts a newline."

Same Enter key — why does the letter area work but the arrow-key area doesn't?

Because in Flutter, these two "Enters" are different key codes:

Key	`LogicalKeyboardKey`
Main keyboard Enter	`enter`
Enter above the arrow-key area / on the numpad	`numpadEnter`

And my check was:

if (event.logicalKey == LogicalKeyboardKey.enter) {

numpadEnter doesn't match, so _handleKeyEvent returns ignored for it, the event passes through to the TextField, and a newline is inserted as usual.

The fix is simply to match both key codes:

if (event.logicalKey == LogicalKeyboardKey.enter ||
    event.logicalKey == LogicalKeyboardKey.numpadEnter) {

Lesson: a desktop keyboard is not "one key = one semantic". The same physical action (pressing Enter) can map to different key codes in different areas — especially when matching keys, think about the existence of areas beyond the main keyboard.

3. The Shift+Enter semantics must not be lost

Desktop has a common convention: Enter to send, Shift+Enter for a newline. This is nearly universal in chat apps, terminals, and editors.

The implementation detail is that Shift+Enter should pass through to EditableText rather than constructing a newline yourself:

if (HardwareKeyboard.instance.isShiftPressed) {
  // Shift+Enter → let the TextField insert a newline
  return KeyEventResult.ignored;
}

Why is "passing through" more reliable than "constructing a newline yourself"?

Letting EditableText handle the newline correctly maintains the cursor position, selection, and IME composition state
Pushing \n into the controller yourself can corrupt the cursor context during input method (e.g., Chinese pinyin) composition

The Shift state check uses HardwareKeyboard.instance.isShiftPressed — the global hardware keyboard state query Flutter currently provides. Worth noting: KeyDownEvent itself does not carry modifier state (KeyEvent only has fields like physicalKey / logicalKey / character / timeStamp, no modifiers), so checking Shift must rely on the HardwareKeyboard global singleton.

The global state has a boundary worth noticing: it reflects the hardware state "right now", not "at the instant of that event". In scenarios like rapid successive key presses, or releasing a modifier key right after a dialog steals focus, it could theoretically read a lagged state. Flutter's future KeyEvent API direction is to have events carry a modifiers snapshot (like Web's KeyboardEvent), at which point event-level checks will be more reliable than global state — but in the current Flutter version, HardwareKeyboard.instance.isShiftPressed is the standard, usable approach.

Also worth mentioning: here you neither need nor should build your own "modifier state cache" (manually setting true on KeyDown and false on KeyUp) — because HardwareKeyboard itself is a global state maintained by the Flutter framework: it keeps its state strictly consistent with the event stream through KeyDown/KeyUp events plus a synthesized-event synchronization mechanism. For example, when focus switching causes a Shift release event to be lost, Flutter injects a synthesized event to correct the state. A hand-rolled cache is actually more likely to fail in edge cases like focus switching and synthesized events — that's exactly the complexity the framework handles for you.

4. Input history: Widget lifecycle ≠ data lifecycle

Problem: ↑ / ↓ stops working after leaving and re-entering

After adding the "↑ / ↓ to recall the last 5 inputs" shortcuts on desktop, the first round of testing was fine — send a few messages, press ↑ to recall them one by one. But a user said: "after leaving and re-entering, the ↑ key doesn't work."

The reason is simple:

class _InputBarState extends State<InputBar> {
  final List<String> _history = []; // ← pure memory, cleared when the widget is destroyed
}

The input history lives in State. While playing, InputBar stays alive and history accumulates normally; once you leave the narrative page and InputBar is destroyed and rebuilt, _history is reset to empty.

Widget lifecycle ≠ data lifecycle. State exists for "UI state" (scroll position, current input-box content), not for "user data" (input history that must survive across sessions). Putting persistent data in State is an anti-pattern.

The right approach: state lifting + persistence

Following Riverpod's Notifier pattern, lift the input history to a global Provider and persist it with SharedPreferences:

class InputHistoryNotifier extends Notifier<List<String>> {
  static const int maxHistory = 5;
  static const String key = 'mephisto_input_history';

  @override
  List<String> build() => const [];

  Future<void> push(String text) async {
    if (state.isNotEmpty && state.last == text) return; // adjacent dedup
    final next = [...state, text];
    if (next.length > maxHistory) next.removeAt(0);
    state = next;
    final prefs = await SharedPreferences.getInstance();
    await prefs.setString(key, jsonEncode(next));
  }
}

// An optional initializer: restore from persistence

After changing InputBar from State to ConsumerState:

List<String> get _history => ref.watch(inputHistoryProvider);

Write to the Provider on send, read from the Provider after rebuild — history survives across sessions.

A design decision: global sharing, or per-contract isolation?

A user raised a very reasonable concern: "if I have multiple sub-versions in progress, are all their histories saved? Does it affect performance?"

I ultimately chose a global single list:

Constant storage: one SharedPreferences key, at most 5 short text entries (a few KB), does not grow with the number of sub-version files
Reasonable semantics: different scripts/branches often use similar directional words ("investigate", "ask", "go to"), so global sharing is actually more convenient
Simple to implement: no Map<fileName, List<String>> serialization

Per-sub-version isolation (Map structure) would pose no performance pressure either (each sub-version is just a few KB), but it's more complex to implement for limited benefit. For a personal project, a global single list is the right "good enough and simple" trade-off.

A forward-looking risk: the global single list's write is an async setString; if you ever support multi-window / multi-tab simultaneous editing, there's a theoretical chance of concurrent write clobbering (two windows each push and overwrite each other). The current design fits single-window serial scenarios; if multi-window arrives, writes need debounce merging, or switch to file locks / a database (e.g., sqlite) for atomicity.

And one more extreme-scenario trade-off: SharedPreferences.setString is an async write. If the user closes the app or the system hard-kills the process before the await completes, the last write can be lost. Since input history is "auxiliary convenience" rather than "core asset" (losing it only means the ↑ key recalls one less entry; it doesn't corrupt narrative data), this extremely-low-probability loss is acceptable — hence no double-write or transaction log over-engineering.

5. How to test these interaction boundaries

Keyboard events: simulating the desktop platform

testWidgets runs under FakeAsync by default, and you can use sendKeyEvent to simulate key presses directly. The key is specifying the platform — InputBar._isDesktop is determined by Theme.of(context).platform, and by default it's Android, not desktop:

await tester.pumpWidget(buildInputBar(onSend: sent.add)); // internally sets ThemeData(platform: linux)
await tester.enterText(find.byType(TextField), 'fate instruction');
await tester.sendKeyEvent(LogicalKeyboardKey.enter, platform: 'linux');
await tester.pump();

expect(sent, ['fate instruction']); // submits on the first Enter

The same applies to testing Numpad Enter and ↑ / ↓ recall.

The FakeAsync limitation: real async IO doesn't complete automatically

When a test involves "persist → rebuild → restore", I hit a snag: inside testWidgets' FakeAsync, the SharedPreferences read Future doesn't complete automatically — pumpAndSettle only drives scheduled frames, not pure async IO.

My initial "input history persistence" widget test never passed: write history in the first session → destroy and rebuild → press ↑ and get nothing. I tried runAsync, multi-stage pump, and there was always a timing contradiction between the two.

Conclusion: don't force "persistence round-trip" and "UI recall" into a single widget test. Splitting the tests is more stable:

Provider-level unit test: verify push writes, restore after recreating the container (round-trip), dedup, cap, and JSON-corruption tolerance
Widget-level test: verify ↑ / ↓ recall interaction behavior (on top of an already-mocked persistent Provider)

Each focuses on its own concern, and neither is affected by the FakeAsync-vs-real-IO timing contradiction of the combined test.

The Provider-level test skeleton looks like this — SharedPreferences.setMockInitialValues handles the in-memory mock in one line:

test('round-trip: push then restore after recreating container', () async {
  SharedPreferences.setMockInitialValues({});

  final container1 = ProviderContainer();
  await container1.read(inputHistoryProvider.notifier).push('test history');
  container1.dispose();

  // Recreate the container (simulating an app restart) → AutoLoadNotifier restores from the in-memory mock
  final container2 = ProviderContainer();
  await container2.read(inputHistoryProvider.notifier).load();
  expect(container2.read(inputHistoryProvider), ['test history']);
});

Note: the Provider-level load() is a pure async method that you can await directly in a normal test() without touching testWidgets' FakeAsync — this is the testability dividend of extracting persistence logic out of widgets.

A further architectural direction: abstract persistence behind an interface (e.g., InputHistoryStore), letting the Provider depend on the interface instead of directly on SharedPreferences — tests inject an in-memory implementation, completely escaping the FakeAsync-vs-real-IO timing contradiction. setMockInitialValues is Flutter's built-in lightweight mock, sufficient for the current scenario; interface injection is the upgrade path when you need stricter isolation.

Conclusion

The "boundary sense" of a desktop input field comes from understanding three things:

The propagation path of keyboard events: the interceptor must be mounted on the real focus node (FocusNode), not an outer wrapping widget — events don't bubble after handled
The physical identity of key codes: when matching physical keys (Enter), consider numpadEnter; when modifier state (Shift) isn't carried by the event, query it via HardwareKeyboard global state (and be aware of its "right now, not event-instant" boundary)
The data lifecycle: whether data goes in State or is lifted to a Provider + persistence depends on whether it must survive across Widget lifecycles — and verify with layered tests (round-trip at the Provider layer, UI interaction at the widget layer)

These details almost never appear on mobile — mobile has only one soft keyboard Enter, and no concept of "files whose state must survive leaving and re-entering". But once you build for desktop, "functionally correct" and "experientially correct" diverge into a boundary that demands careful thought.

Glossary

Term	Description
`LogicalKeyboardKey`	Flutter's "logical key" abstraction (after key-position + layout mapping), e.g., `enter` / `numpadEnter`
`PhysicalKeyboardKey`	Physical key position (USB HID code), independent of keyboard layout
`KeyEventResult`	Keyboard event handler result: `handled` (consumed, no longer propagates) / `ignored` (passed through, continues propagating)
Focus Chain	The path along which keyboard events propagate from "focus node → ancestors", unrelated to widget containment
`HardwareKeyboard`	Flutter's maintained global keyboard state (keys / modifiers / lock keys) query entry

Project: Mephisto (MIT License)

Hybrid app development company: the 4 platform deadlines that decide your 2026 build

Manu Shukla — Sat, 15 Aug 2026 05:46:45 +0000

Hybrid app development company: the 4 platform deadlines that decide your 2026 build

Summary. Google Play requires new apps and app updates to target Android 16 (API level 36) from 31 August 2026, with an extension available only to 1 November 2026. Apple has required every App Store Connect upload to be built with Xcode 26 and an iOS 26 SDK since 28 April 2026. Flutter 3.47, released 12 August 2026, moved Material and Cupertino into standalone material_ui and cupertino_ui packages and scheduled the in-SDK originals for formal deprecation in November. React Native 0.87, released 11 August 2026, raised its floor to Node.js 22, Android Gradle Plugin 9 and Kotlin 2.0. Four mandates in seven months, all touching the same codebase. That is the number a buyer should be looking at, and it is why the cost of a hybrid app in 2026 is dominated by upgrade cadence rather than by the initial build.

Most pages that answer "hybrid app development company" compare Flutter against React Native on rendering performance. That comparison stopped deciding anything useful around 2024. Both stacks now compile to genuinely native UI, both ship on quarterly cadences, and both will force you into a migration this year whether you planned one or not. The question that decides your total cost is narrower: how quickly can your partner absorb a platform mandate without stopping feature work?

The four deadlines currently in force

Mandate	Owner	Date	What breaks if you miss it
Xcode 26 + iOS 26 SDK for all uploads	Apple	Since 28 April 2026	App Store Connect rejects the upload
Target API 36 for new apps and updates	Google Play	31 August 2026	Submission blocked; extension only to 1 November 2026
Existing apps must target API 35	Google Play	31 August 2026	App stops being discoverable to new users on newer Android
Core Material and Cupertino deprecated	Flutter	November 2026 stable	Design libraries move to `pub.dev` packages

Google's Play Console documentation is specific about the second row and it is the one buyers underestimate. An app that stays on API 34 does not get removed. It becomes invisible: Google Play tells the user "this app is not available to install on their device because it was made for an older version of Android" when they arrive on a newer handset. Existing installs keep working. New acquisition stops. For a consumer app in India, where most new installs arrive on recent Android builds, that is a silent revenue cut rather than an outage anyone pages you about.

The extension is narrower than it sounds. Google states that only apps already out of compliance receive a policy warning, and the extension form appears through that warning on the Policy status page. You cannot request one pre-emptively.

"Hybrid" now means three different architectures

The word covers three technical approaches with different failure modes. A company that says it "does hybrid" without naming which one is selling you a resourcing plan, not an architecture.

Approach	How the UI renders	2026 flagship release	Best fit
Flutter	Own engine (Impeller), draws every pixel	3.47, 12 August 2026	Design-heavy consumer apps, one visual language on both stores
React Native	Maps to real platform widgets via Fabric	0.87, 11 August 2026	Teams with existing React and TypeScript engineers
Capacitor	Web app in a system WebView with native plugins	8.x, `targetSdkVersion` 36	Content, commerce and internal tools where an existing web app exists

Flutter's renderer is now Impeller everywhere. Version 3.47 made it the default on macOS, Windows and Linux after Android and iOS, and the Flutter team's stated reason is that Impeller "compiles a fixed set of shaders at build time rather than compiling them dynamically at runtime", removing first-play animation stutter. Version 3.47 also raised Flutter's minimum supported iOS from 13 to 15 and macOS from 10.15 to 12.

React Native took the opposite route and finished a different job. Release 0.82 in October 2025 was, in the team's words, "the first React Native that runs entirely on the New Architecture", and 0.84 made Hermes V1 the default JavaScript engine in February 2026. There is no longer a legacy bridge to fall back to. That is good for performance and unforgiving for old dependencies.

Capacitor is the honest choice when a working web application already exists. Capacitor 8 sets compileSdkVersion and targetSdkVersion to 36 and minSdkVersion to 24 in variables.gradle, requires Xcode 26 with an iOS deployment target of 15.0, and requires Node.js 22 or greater. It also removed android.adjustMarginsForEdgeToEdge in favour of a System Bars core plugin, so edge-to-edge handling moves to CSS environment variables.

What each stack actually demands from you this year

Flutter: a design-system migration with a November clock

Flutter 3.47 shipped material_ui and cupertino_ui at version 1.0 on pub.dev. Migration runs through one command, dart fix --apply --code=migrate_design_widgets, which rewrites imports. The deadline is explicit in the release post by Emma Twersky of the Flutter team: "The original design libraries inside the core SDK are scheduled for formal deprecation in the upcoming Fall stable release in November."

Two other items in 3.47 carry real migration weight. The iOS 27 SDK mandates the UIScene lifecycle for UIKit-based apps, and Flutter warns that apps built with Xcode 27 which have not adopted UIScene will fail to launch. The Flutter CLI handles this automatically for most projects; custom AppDelegate code and plugins on the legacy lifecycle need manual work. Separately, 92 of the top 100 iOS plugins have moved to Swift Package Manager, and CocoaPods is in maintenance mode, so unmigrated plugins will eventually stop working and already score lower on pub.dev.

Flutter 3.47 verifies against Java 17, Kotlin Gradle Plugin 2.4.0, Android Gradle Plugin 9.1.0 and Gradle 9.3.1, with flutter.compileSdkVersion and flutter.targetSdkVersion both at API 36. A Flutter project on 3.47 is already Play-compliant for 31 August. A Flutter project three releases behind is not, and the Gradle chain is what makes that upgrade slow.

React Native: a toolchain floor, not a rewrite

React Native 0.87, published 11 August 2026 by Zeya Peng and colleagues at Meta and Expo, is blunt about the cost: "This release makes the Strict TypeScript API the default JavaScript API, updates Metro to 0.87, adds experimental support for Swift Package Manager (SwiftPM). It also raises the minimum toolchain requirements: Node.js 22, Android Gradle Plugin 9, and Kotlin 2.0+."

Strict TypeScript by default is the item that surprises teams. It was opt-in from 0.80 and was always described as a one-time breaking change; on a large codebase with untyped native modules, it surfaces work that has been deferred for two years. The AGP 9 requirement is separately awkward for apps carrying old native libraries.

The upgrade path is gentler than Flutter's on the UI side. React Native 0.83 and 0.86 both shipped with no user-facing breaking changes, and 0.86 added edge-to-edge support on Android 15 and above, which is exactly what API 36 pushes you toward anyway.

Capacitor: cheapest to build, thinnest margin for platform change

Capacitor's upgrade to 8 is mostly configuration, and npx cap migrate does much of it. The residual risk sits in plugins and in Android's behaviour changes. Capacitor's own migration notes record that scanOrientation in the Barcode Scanner and lock in Screen Orientation have no effect on large screens from Android 16, that the opt-out property is temporary, and that it will stop working on Android 17. A tablet-facing app that pins orientation has a dated problem, not a preference.

What we build

eCorpIT builds hybrid applications in all three stacks, and the selection is made against your existing engineering staff and your release cadence rather than a house preference. Typical work: consumer apps with a shared design system across both stores, commerce and D2C applications where an existing web front end is worth reusing, field-force and internal tools with offline data synchronization, and migration of ageing Cordova or legacy-architecture React Native apps onto a supported baseline.

The migration work is now the larger half of the market. The real cost of a hybrid app is usually the upgrade you did not budget for, not the screens you did budget for.

Our five-step delivery process

Baseline audit. Application portfolio analysis of the current build: target SDK, Gradle and Kotlin versions, plugin inventory, and which of the four mandates above you currently fail. Output is a dated compliance position, not an estimate.
Architecture decision. Stack selection written down with the reason, including the case against the stack we chose. Where an existing React or web codebase exists, that weighs more than framework benchmarks.
Build in two-week increments. Working builds on TestFlight and Play internal testing from the first increment, so store-level problems surface early rather than at submission.
Store readiness. Target API and SDK compliance, privacy manifests, age-rating responses in App Store Connect, and edge-to-edge behaviour verified on current Android before submission.
Cadence maintenance. A standing quarterly upgrade slot mapped to the Flutter and React Native release trains, so a platform mandate consumes a planned sprint rather than an emergency.

The stack

Flutter with Dart and Impeller; React Native with the New Architecture, Hermes V1 and TypeScript; Capacitor with Angular, React or Vue where a web application already exists. Server side: Node.js, Python and .NET on AWS, Azure or Google Cloud. Offline data synchronization, push via Firebase Cloud Messaging or APNs, and server-side rendering for the web surface where SEO matters. CI/CD through GitHub Actions or Azure DevOps with signed builds to both stores.

Why eCorpIT

eCorpIT is eCorp Information Technologies Private Limited, founded in 2021 and based in Sector 83, Gurugram. We are assessed at CMMI Level 5, certified to ISO 27001:2022, and MSME registered. We are partners of AWS, Microsoft, Google and Shopify. Teams are senior-led and multi-disciplinary rather than staffed from a bench.

For regulated work we design applications aligned with DPDP Act 2023 requirements and with the framework your auditor applies. We do not claim to certify your app against a framework we do not hold.

Engagement model and indicative bands

We work in three models. A fixed-scope build suits a defined app with a signed specification and a store deadline. A dedicated team suits continuous product work and is billed monthly per engineer. A maintenance retainer covers the quarterly upgrade slot described above and is sized by the number of active plugins and native modules.

We publish an engagement model rather than a rate card, because a hybrid quote that arrives before anyone has read your plugin inventory is a guess. The audit in step one is short and produces a fixed number. For current commercial terms, contact us through /contact-us/.

India-specific considerations

Android share is high enough in India that the 31 August discoverability rule matters more here than in most markets: an app stuck on API 34 loses new installs on the handsets that are actually selling. Device fragmentation also makes Impeller's build-time shader compilation worth more on mid-range hardware than benchmark charts on flagship devices suggest.

On privacy, the DPDP Act 2023 governs personal data in your app regardless of stack, and the obligations follow the data rather than the framework. A WebView-based Capacitor app and a Flutter app handling the same consent flows carry the same duties.

Cost comparison against offshore alternatives is covered in our India versus US app development cost analysis, and the framework selection question specifically for hiring is in the React Native versus Flutter hiring decision framework. The Android deadline itself is covered in depth in our Android target API 36 migration guide, and the wider architectural picture sits in our enterprise mobile app development guide.

FAQ

What is a hybrid app development company?

A hybrid app development company builds applications that run on both iOS and Android from one codebase, using Flutter, React Native or Capacitor rather than separate Swift and Kotlin projects. The useful distinction in 2026 is which of those three architectures the company actually maintains, because their upgrade obligations differ.

Is hybrid still cheaper than native in 2026?

The initial build usually costs less because one team writes one codebase. The saving narrows over the life of the app, because a hybrid project inherits platform mandates from Apple and Google plus its own framework release train. Budget for a quarterly upgrade slot and the comparison stays favourable.

Which is better, Flutter or React Native?

Neither wins on rendering any more. Flutter 3.47 draws its own pixels through Impeller; React Native 0.87 maps to real platform widgets. Choose Flutter when a single visual language across both stores matters most, and React Native when you already employ React and TypeScript engineers who can maintain it.

What happens if my app misses the 31 August 2026 Play deadline?

New submissions and updates are blocked. An existing app below API 35 stops being discoverable to new users on Android versions newer than its target, and Google Play tells those users the app was made for an older version of Android. Existing installations keep working normally throughout.

Can I still get an extension for the Android API 36 requirement?

Google allows an extension to 1 November 2026, but only through the policy warning raised against a non-compliant app on the Policy status page in Play Console. You cannot request one in advance. Apps already compliant with API 35 have no warning and therefore no form.

Does Capacitor still make sense in 2026?

It does when a maintained web application already exists and the mobile app is largely the same product. Capacitor 8 targets API 36 out of the box and defaults new iOS projects to Swift Package Manager. Verify orientation behaviour first, since Android 16 restricts orientation locking on large screens.

How long does a hybrid app build take?

A defined first release with a signed specification typically runs in two-week increments with working store builds from the first increment. The variable that moves the date most is not screen count. It is the plugin and native-module inventory, which is why our baseline audit runs before any estimate.

Do I need to migrate my Flutter app to material_ui now?

Not immediately, but the window is short. Flutter 3.47 shipped material_ui and cupertino_ui at 1.0 as opt-in, and the in-SDK originals are scheduled for formal deprecation at the November stable release. The dart fix --apply --code=migrate_design_widgets command handles most import rewriting automatically.

How eCorpIT can help

We audit your current build against all four mandates in force, tell you which ones you fail today, and give you a fixed number to clear them. Where a new build is the right answer, we select the stack against your existing engineers rather than our preference, and we write down the case against the choice as well as for it. Teams are senior-led, and the quarterly upgrade slot is part of the engagement rather than a change request. Start with a short baseline audit through /contact-us/.

References

Target API level requirements for Google Play apps, Play Console Help, Google
What's new in Flutter 3.47, Emma Twersky, The Flutter Blog, 12 August 2026
What's new in Flutter 3.44, The Flutter Blog, 20 May 2026
Upcoming Requirements: SDK minimum requirements, Apple Developer
React Native release announcements, versions 0.82 to 0.87, Meta and Expo, October 2025 to August 2026
React Native architecture overview, Meta
Updating from Capacitor 7 to Capacitor 8, Capacitor Documentation, Ionic
Updating to Capacitor 8.5, Capacitor Documentation, Ionic
Setting target SDK in Capacitor for Android, Capacitor Documentation, Ionic
Swift Package Manager in Capacitor for iOS, Capacitor Documentation, Ionic
Swift Package Manager migration guide for plugin authors, Flutter documentation
Flutter breaking changes and migration guides, Flutter documentation
material_ui package, version 1.0, pub.dev
cupertino_ui package, version 1.0, pub.dev
Migrating to a newer target SDK level, Android Developers

Last updated: 15 August 2026.

DEV Community: flutter

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

Building Enterprise Active Directory, LDAP & Dynamic RBAC in Go & Flutter with Google Antigravity

The Security Architecture

Role-Based Access Control (RBAC) Matrix

💻 The Go Backend Engine (internal/auth/)

1. Two-Phase Bind & Credential Verification

2. Dynamic Group-to-Role Mapping

The Flutter Web UI Experience

1. Modern Login Screen with Domain Selector

2. Active Directory Management & Diagnostics

3. Real-Time Role Badges & Contextual Guards

How Google Antigravity Accelerated Development

Conclusion & Open Source

Building an AI Assistant: flutter nodejs ai browser automation

Why Full-Stack AI Browser Automation?

The Architecture: Orchestrating LLM Decisions with Browser Actions

Building the Brain: Node.js, LLMs, and Playwright

1. Flutter UI (Simplified)

2. Node.js Backend & Agent Loop

What I Got Wrong First

Quantifying the Time Saved

FAQs

Q: Can I run Playwright headlessly on a remote server?

Q: How do you handle authentication (logins) securely?

Q: What's the biggest bottleneck for this type of agent?

Why BlocSignal Doesn't Need Provider (And Why Classic BLoC Always Did)

How shedding package:provider eliminates dependency hell, fixes Flutter's lingering ghost rebuild bug, and delivers fine-grained synchronous reactivity in 2026.

1. Look Under the Hood: Classic BLoC's Hidden Dependency

Why Did Classic BLoC Do This?

2. The Two Fatal Flaws of the Provider Foundation

Flaw #1: "Dependency Hell" & Version Lockouts

Flaw #2: The "Lingering Dependency" (Ghost Rebuild) Bug

3. The Riverpod Exodus: Escaping the Widget Tree

Where Riverpod Got Complicated

4. The BlocSignal Resolution: Zero Provider, Zero Code-Gen

1. Native O(1) InheritedWidget (Zero Third-Party Dependencies)

2. Dynamic Per-Frame Dependency Pruning (No Ghost Rebuilds)

3. Synchronous State Propagation (No Stream Queue Latency)

4. Streamless BLoC-to-BLoC Coordination

5. The 4-Way Code Shootout

Option A: Classic Provider (ChangeNotifier)

Option B: Classic flutter_bloc (Streams + package:provider)

Option C: Riverpod 3 (Code Generation + build_runner)

Option D: Modern BlocSignal (Pure, Synchronous Dart)

In Dart 3.5 (Baseline Syntax):

In Dart 3.13 (Modern Primary Constructor):

6. The Ultimate Comparison Matrix

7. The 60-Second Refactor: Your AI Migration Playbook

8. Summary: Less is More

🚀 Get Started with BlocSignal

Offline-First Flutter: Syncing Local and Remote Data Reliably

What "offline-first" really means

Choosing a Flutter local database

Designing the sync queue (the outbox pattern)

Conflict resolution: last-write-wins vs. merge

Last-write-wins (LWW)

Field-level merge

Handling failures and partial sync

Putting it together: a sync lifecycle

Wrapping up

Flutter CI/CD with GitHub Actions and Fastlane: A Real Pipeline

Why split CI and CD on a tag

The CI job: analyze and test on every PR

Fastlane: lanes that talk to the stores

Android: upload to the Play Store internal track

iOS: upload to TestFlight

Secrets and signing material without leaking them

The release job: build signed artifacts on a tag

Automate Flutter releases without losing the safety rails

Wrapping up

Clean Architecture in Flutter with BLoC: A Practical Guide

Why clean architecture in Flutter pays off

Folder structure that scales

The domain layer: entities and use cases

The data layer: DTOs, mappers, and the repository

The presentation layer: a Cubit driving the UI

How clean architecture in Flutter wins on testing

Wrapping up

Apple Pay in Flutter: The Easiest Implementation

💻 The Go Backend Engine (`internal/auth/`)

1. Native O(1) `InheritedWidget` (Zero Third-Party Dependencies)

Option A: Classic `Provider` (`ChangeNotifier`)

Option B: Classic `flutter_bloc` (Streams + `package:provider`)

Option C: Riverpod 3 (Code Generation + `build_runner`)

Option D: Modern `BlocSignal` (Pure, Synchronous Dart)

Workaround C: `package:bloc_presentation`

3. The `BlocSignal` Advantage: 0ms Synchronous Guarantees

4. The Zero-Dependency `PresentationMixin` Recipe

Step 1: The Mixin (`BlocSignalPresentationMixin`)

Step 2: The Flutter Listener (`BlocSignalPresentationListener`)