From Screenshot to Pixel-Perfect UI: An Antigravity Workflow That Actually Works

You drop a screenshot into Antigravity, ask it to "build this," and you get back something that's almost right — but the corner radius is slightly off, the font weight feels too heavy, and the spacing breathes a little too much. If you've shipped any UI work with an AI editor, you know this gap. Multimodal models have come a long way, but recreating a UI pixel-perfectly from a screenshot rarely happens on the first try.

This article is a collection of habits I've built up actually shipping UI from designer handoffs and from "looks-like-this" reference shots. We'll walk through how to prepare the image, how to structure the prompt, and how to close the gap between "almost right" and "ship it" — with concrete examples in SwiftUI, Tailwind, and Flutter. The goal is to get Antigravity's multimodal capabilities working hard for you, instead of generating plausible-but-drifting code that you'll quietly rewrite anyway.

Why one-shot screenshot reproduction never quite lands

When Antigravity reads an image, it loses information your eye fills in for free. A "12px-radius card" looks like a smooth gradient boundary at the pixel level — there's no metadata telling the model that 12 was the intended value rather than 10 or 14. The places this drift shows up most often:

• Font weight (regular vs. medium vs. semibold)
• Spacing units (a 4-pixel grid vs. an 8-pixel grid)
• Subtle shadows (elevation 1 vs. elevation 2)
• Color tokens (#EEE vs. #F2F2F2)
• Icon stroke width (1.5px vs. 2px)

The model isn't failing — it's correctly inferring continuous values from pixels, but those continuous values won't necessarily land on your design system's discrete tokens. The fix is to hand the model the discrete options up front, so it stops guessing and starts choosing.

Three things to decide before pasting the screenshot

Before I drop an image into Antigravity, I write down three things and include them in the prompt. This alone gives me a noticeable jump in fidelity on the first pass.

1. Framework and style system: Tailwind v4, SwiftUI, Flutter Material 3 — be explicit.
2. Discrete design tokens: spacing 4 / 8 / 12 / 16, radius 4 / 8 / 12 / 16, text size 12 / 14 / 16 / 18 / 24. Constrain the choices.
3. Component scope: just the button, the whole card, or the entire screen — name it clearly.

Implement only the centered card from this screenshot.
- Framework: SwiftUI (iOS 26 / Xcode 26)
- Spacing options: 8 / 12 / 16 / 24 (pt)
- Radius options: 8 / 12 / 16
- Typography: .footnote / .body / .headline / .title3
- Prefer Asset Catalog colors: Tint/Primary, Surface/Card, Text/Secondary

Giving the model an explicit list of allowed values stops it from emitting odd numbers like 12.7 and gets you something a code reviewer won't mark up.

Image preparation: what actually moves the needle

A few small image-prep habits do more for accuracy than fancy prompting.

The biggest one is export at 2x. Hand a 1x Retina capture to the model and the glyph edges blur enough that the font-weight estimate gets shaky. Export at 2x from Figma, or use @2x from Sketch, and text and icons read much more reliably.

Next, annotate distances directly on the image. I use the macOS Preview markup tool to draw a red line between two cards and write 16 next to it, then save the image. It feels primitive, but the model treats the annotation as a grounded fact rather than something it has to estimate.

Finally, crop to the target component. Pasting a full-screen capture spreads the model's attention across the whole layout, and the details of the component you actually care about get rougher. A tight crop of just the button or just the header outperforms the full screen by a wide margin.

A prompt template that holds up

Here's the structure I default to whenever I'm asking Antigravity to turn a screenshot into code.

[paste image]
 
Implement the floating action button in the bottom-right of this screenshot in SwiftUI.
 
Constraints:
- Framework: SwiftUI (iOS 17+, no @available wrappers)
- Size and spacing options: 4 / 8 / 12 / 16 / 24 / 32 (pt)
- Shadow options: none / soft (radius 4 y 2) / medium (radius 8 y 4) / strong (radius 16 y 8)
- Colors: Color("Primary"), Color.white
- Icon: pick the closest SF Symbols glyph and list two candidates in a comment
- Always set an accessibility label
 
Output format:
1. Full source for FloatingActionButton.swift
2. Bulleted rationale for the values you chose (spacing, shadow, size)
3. List of details you couldn't read from the screenshot (tap target, pressed state, etc.)
 
Notes:
- Do not emit continuous values like 13.5pt — round to the options above
- Reuse Theme.swift values via import if any of them fit

The trick is the three-part output format. If you only ask for code, you have no view into where the model hesitated. Asking it to enumerate "things I couldn't read" surfaces the questions you should answer, and the second round usually closes most of the remaining gap.

Case study: dialing in a Tailwind card

Let me walk through what an actual session looks like — turning a Dribbble-style card screenshot into Tailwind v4 code.

Round 1: pull out structure and tokens

The first message asks the model to approximate using only Tailwind's built-in scale, no pixel measurements.

[paste image]
 
Implement this card in Tailwind v4.
Don't measure pixels. Approximate using Tailwind's standard spacing
(p-2 / p-3 / p-4 / p-6) and radius (rounded-md / rounded-lg / rounded-xl).
 
Use slate-* and zinc-* shades. Stub the brand color as a CSS variable: --color-brand.

Round 1 typically produces something like:

// Card.tsx — first pass (draft)
export function ProductCard() {
  return (
    <article className="bg-white rounded-xl shadow-md p-6 max-w-sm">
      <h3 className="text-lg font-semibold text-slate-900">Product name</h3>
      <p className="mt-2 text-sm text-slate-600">A short description goes here.</p>
      <div className="mt-4 flex items-center justify-between">
        <span className="text-xl font-bold" style={{ color: "var(--color-brand)" }}>
          $12.00
        </span>
        <button className="rounded-lg bg-slate-900 px-4 py-2 text-sm text-white">
          Buy
        </button>
      </div>
    </article>
  );
}

Expected outcome: structurally correct, visually close, but the shadow's a touch too heavy and the price color and weight don't quite match.

Round 2: hand back diffs, not rewrites

Saying "rewrite the whole thing" is the trap that throws away the structure that already worked. I send a tight diff list instead.

Apply the smallest possible diff to your previous code:
 
- shadow-md -> shadow-sm (the screenshot's shadow is much shallower)
- Keep var(--color-brand), but change font-bold -> font-semibold
- Card padding: p-6 -> p-5 (vertical spacing in the screenshot is tighter)
- Button radius: rounded-lg -> rounded-md
 
Do not change other classes or structure.

The phrase "smallest possible diff" matters. Without it, the model will quietly suggest "improvements" and you'll end up with structural changes you didn't ask for.

Round 3 and beyond: close the last few percent

The final percentage points only close through visual back-and-forth. I keep using Antigravity's diff view to compare a "before screenshot" of the rendered DOM and an "after screenshot," and I only describe what's still different. I wrote up the diff-view workflow in detail in the Antigravity diff view advanced guide.

Notes for SwiftUI and Flutter

In SwiftUI, a bare .padding() quietly applies the framework's default 16pt, which makes the result slightly roomier than the screenshot. In my opening prompt I include "always pass the value explicitly, e.g. .padding(.all, X). Never write .padding() with no argument." It's a small constraint but it removes a whole class of subtle drift.

In Flutter, the opposite problem dominates: nested Padding widgets stack and double up. I add "no nested Padding widgets — express all spacing with EdgeInsets.all or EdgeInsets.symmetric" to the constraints, and adjusting spacing in later rounds becomes much easier.

Small techniques that compound

If you have access to Figma, the Figma MCP integration for frontend work beats screenshots by a wide margin — the model can read actual style properties (fill color, corner radius, auto-layout gap) instead of inferring them.

When all you have is a screenshot, pasting multiple images at once helps a lot. A full-screen shot, a close-up of the target component, and another component using the same design language together let Antigravity discover the shared spacing and radius values. With one image alone, the inference is much noisier.

For bug-fix flows rather than greenfield implementation, the screenshot-paste UI bug fix workflow covers the complementary case. Knowing both gives you a clean answer for "build this from scratch" and "make the live UI match this."

Most of what I do is build up a personal library of prompts I keep reusing, but if you want a starting point, practical prompt engineering for Antigravity is a good companion read. Screenshot-driven implementation is, at the end of the day, the act of rounding inferred values onto your design system's discrete tokens — so the more you can name and template that rounding pattern, the less you have to think it through each time.

What to try today

If you're going to try one thing from this piece, export a single screen of one of your apps at 2x and paste it into Antigravity — but include the discrete-value list and the three-part output format from the start. You should feel the difference on the first response. Don't expect the first pass to be done; expect to land in the right neighborhood, then close the gap with two or three small diff rounds. Pixel-perfect isn't a one-shot trick — it's a careful conversation, and Antigravity is a more reliable partner than it might have looked the first time you tried it.