Speeding Up Generative UI with Async A2UI Caching in Flutter

A new deep dive on the Flutter blog tackles one of the least glamorous but most important problems in generative UI: startup latency. In agentic Flutter apps, the interfaces users see are frequently produced by a large language model in real time. But when an app relies on calling an LLM at startup to generate its initial interface, users end up waiting for the model to process system prompts, make function calls to fetch records, and construct UI payloads. That delay can stretch well past what people expect when navigating to a new screen.

Generating UI Ahead of Time

The solution explored in the post is to separate the generation of the UI from the runtime lifecycle of the client app. Instead of waiting for the model at launch, the developer pre-generates and caches the A2UI messages in the background before the user ever opens the application. By decoupling these two phases, the app can serve a dynamic, AI-generated interface instantly from a pre-computed layout rather than blocking on a fresh model call.

The technique is demonstrated through a sample application called Commis, an intelligent assistant aimed at commercial kitchens and catering teams. Its experience centers on a conversational chat interface where a chef can discuss upcoming catering jobs with an AI assistant to coordinate recipe assignments and guest counts. The challenge is that when the chef opens the app, they should not have to begin from an empty chat. The agent ought to offer pre-generated UI with information and actions relevant to each job right away.

How Async Caching Works

The architecture has two halves. On the backend, generation happens asynchronously whenever underlying data changes. In the Commis example, whenever a catering job record is modified, a trigger fires that retrieves the updated data, sends a prompt to a Gemini model to construct the UI, and writes the resulting JSON payload to a Firestore collection. The client then pulls that pre-computed UI straight from the database at startup, bypassing the LLM entirely, and adds it to both the conversation history and the genui transport layer.

• UI generation is decoupled from the client runtime, so users never wait on a model call
• A Firestore trigger regenerates cached layouts whenever source data changes
• The LLM gets a tightly-scoped instruction set describing which components it may generate
• Stale or no-longer-relevant cached feeds are pruned when an event is no longer upcoming
• The dynamic, model-generated interface is preserved despite instant startup

This experiment relies on the new and technically experimental Dart support in Firebase Cloud Functions, complete with Firestore triggers that are currently only supported when running within the Firebase Emulator Suite. Inside a ContentGenerator class, the developer encapsulates a system instruction that includes the catalog of UI components the app can render and their properties, a chosen model such as gemini flash, and logic describing what to return when there is no UI appropriate for a given job.

What It Means for GenUI Apps

The practical significance for the broader Flutter community is that generative UI does not have to come at the cost of perceived performance. The pattern of generating layouts asynchronously and caching them ahead of time keeps the flexibility of a fully dynamic, AI-driven interface while giving users an instant startup experience. It is a thoughtful middle path between shipping a fixed static UI and forcing users to wait for the model on every screen transition.

The approach also touches on a recurring theme across recent Flutter releases: the genui package and the A2UI message format for rendering AI-driven components on the fly. This deep dive is one of several recent posts exploring how to integrate generative UI into production-grade apps without sacrificing the responsiveness users have come to expect from native applications.

For developers building conversational or agentic apps with Flutter, the async caching pattern offers a concrete, reusable recipe. By pushing the expensive model work to the backend, keeping the LLM's output scope narrow, and storing generated layouts where the client can load them instantly, the technique resolves the central tension of generative UI. It also demonstrates the value of the emerging full-stack Dart story, where shared packages and experimental Dart Cloud Functions let a single language span both the frontend and the generation pipeline.

As generative UI matures, expect more patterns like this one that treat the model as a background service rather than a blocking dependency. The blog walkthrough closes by walking through the full implementation in the Commis sample, giving Flutter developers a clear template for applying the same asynchronous generation and caching strategy to their own agentic applications.