Concepts
What problem does .gui actually solve?
The honest version: .gui isn’t trying to replace HTML, CSS, or your design tool. It adds one missing thing: a portable, throwaway design layer for the AI era.
The fair skeptic’s question, asked several ways when the format was first shown publicly, is "what problem does this solve that HTML, CSS, or Figma don’t already?" HTML is as simple as it gets; design tools already exist; AI already writes code. Adding a file format sounds like adding a step. So it’s worth answering directly: .gui is not a better way to build the final product. HTML, SwiftUI, and Compose already do that, and .gui doesn’t try to compete with them (.gui vs HTML). What it adds is a layer that didn’t have an open format before: disposable design ideation.
The gap: there’s no cheap unit of "a UI idea"
Today an interface idea has to be born as one of two heavy things. Either it’s code (which means a repo, a toolchain, a component library, and a design that’s now entangled with an application you have to maintain) or it’s a design-tool document, which lives inside one vendor’s app, in a workspace, behind an account. Both are workspaces. Neither is a file you can generate ten of, glance at, keep one, and delete the rest. A screenshot is that cheap, but a screenshot is a dead end: you can’t edit it, render it at a different size, or convert it to code without starting over (.gui vs a screenshot).
A .gui file is that missing cheap unit: one file is one screen, not a workspace. You can ask an agent for six variations of a checkout screen, get six files, compare them side by side, keep one, and throw the rest away, and none of them ever touched your codebase or your production Figma file. That workflow (rapid, low-commitment, before anything is real) is the one the format is actually built for.
Why now, and not five years ago
The honest answer to "why didn’t this need to exist before" is that until recently the only things authoring and consuming UIs were humans, and humans were fine with tool-specific formats. Now AI generates and reads interfaces too, and an AI agent wants a structured, textual target it can write directly, not a screenshot it has to reason about visually, and not a full application it has to scaffold to express one screen (see the FAQ on AI-readability). The format that fits between "an image" and "a running app" simply had no open standard, the way graphics had none before SVG.
What it is NOT solving
It’s not solving "pixel-perfect designer-to-developer handoff." A .gui file is an exchange and ideation artifact, not a guarantee that generated code matches your internal component library. See Handoff, fidelity, and your component library.
It’s not solving "build and ship a production app from one file." The final app is still HTML/SwiftUI/Compose. .gui is the source-of-truth design those get built from, not the runtime.
It IS solving "give an AI agent, a design tool, and a developer one portable thing they can all read, generate, preview, and convert": the interchange gap, not the runtime.
If your workflow never generates throwaway design ideas and never moves a design between an AI model, a design tool, and code, it’s reasonable to conclude you don’t have the problem .gui addresses. The format is for the workflow where those handoffs happen constantly and each one currently means a re-authoring step.
Frequently asked
Isn’t adding a file format just adding a step to the process?
Only if you were going to move a design between an AI model, a design tool, and code anyway, which today means re-authoring it at each hop. .gui replaces those re-authoring steps with one portable file, and adds a cheap ideation layer (one file = one screen) that didn’t have an open format before. If your workflow never does those handoffs, you likely don’t need it.
Why not just use a single HTML file?
You can, and for a finished web page you probably should. But an HTML file is a runtime artifact tied to the browser, and using it as a design’s source of truth drags in CSS, a toolchain, and eventual entanglement with an app. .gui is a static, closed-vocabulary file meant to be generated, compared, and discarded cheaply, then converted to HTML (or SwiftUI, or Compose) when you commit.
What can .gui do that Figma plus AI can’t already?
Give you a design as a portable open file instead of a document locked inside one vendor’s workspace. A .gui file can be generated by any AI agent, previewed with one script tag, version-controlled as text, and converted to code, without a Figma account or API in the loop. Figma remains a great place to refine one; .gui is what moves between tools.