Stitch to Native Android with Antigravity
Turn Stitch designs into native Android: Antigravity and Android CLI setup, the agent workflow, device validation, and a web-pipeline comparison.
Until now, Stitch's design-to-code story has lived on the web: HTML, React, Vue, Next.js. Android developers could see the designs, but never in a native artifact.
That changed this week. In an official Google for Developers demo, hooking Stitch MCP into Antigravity and the Android CLI lets an agent complete the full path from design to native app — not a WebView shell, but real Jetpack Compose components.
This article breaks the workflow into its three moving parts, environment setup, hands-on steps, and the verification loop — and marks which details come from the official demo and which still need real-world testing.
Note: This article is based on the official demo and Android CLI release notes; check the behavior of the Antigravity and Android CLI versions you install.
1. What the Official Demo Covered: Design to Running Device
The demo's workflow comes down to four steps:
- Import UI designs from Stitch.
- Have the agent convert them into native Jetpack Compose components (not a WebView, not React Native).
- Validate the build and screens in the emulator.
- Run the final build on a physical device.
The agent handles all four; humans assign the task and accept the result. The significance: Stitch's landing surface expands from the web to native Android.
2. Three Parts, Three Jobs: Antigravity / Stitch MCP / Android CLI
Each tool has a distinct role:
| Tool | Role | Responsibility |
|---|---|---|
| Antigravity | Host agent environment | Managing agents, tasks, and execution |
| Stitch MCP | Design source integration | Letting the agent read designs from your Stitch project |
| Android CLI | Native toolchain access | Building, render validation, and device deployment |
Background: Antigravity 2.0 has integrated the Android CLI and skills, alongside parallel local agent management, Projects, scheduled tasks (/schedule), and CLI and SDK support.
3. Environment Setup (Including Android CLI)
The Android CLI installs through mainstream package managers. Pick your platform:
# macOS / Linux
brew install android-cli
# Windows
winget install android-cli
# Ubuntu
sudo apt-get install android-cli
Package names and the latest install method may change; check the official release notes. Once installed, set up two things inside Antigravity:
- Configure Stitch MCP so the agent can access your Stitch projects.
- Install Android skills so the agent can build and validate Android projects.
4. Hands On: Design → Jetpack Compose Components
With the environment ready, one task instruction starts the whole chain:
Import the login and home screens from my Stitch project [ID],
convert them into Jetpack Compose components following Material 3,
validate the build in the emulator, then deploy to my connected device.
The instruction encodes four contracts:
- Source: the specific Stitch project and screens (login / home).
- Target: Compose components that follow Material 3.
- Validation: build first in the emulator.
- Delivery: deploy to the connected device.
5. The Verification Loop: Emulator, Journeys, and a Real Device
Android offers richer verification than the web, and the demo uses three layers:
- Emulator build: confirm the code compiles and screens render.
- Journeys: describe a user flow in natural language and let the tool verify the path.
- Physical device: deploy the final build and confirm real-world behavior.
The "emulator → flow → device" order is worth borrowing on its own: even without Stitch, it makes a sensible default acceptance path for Android agent workflows.
6. Compared with the Stitch → React/Vue Web Pipeline
The two pipelines produce different artifacts, so the choice follows your target platform:
| Dimension | Web pipeline (React / Vue) | Native Android pipeline (Compose) |
|---|---|---|
| Artifact | Web pages and components | Jetpack Compose components |
| Verification | Browser | Emulator and device |
| Fits | Websites, web apps, cross-platform | Android apps, native experience |
| Ecosystem | Next.js, Vite, shadcn/ui, and more | Android Studio, Gradle, and more |
The rule is simple: web target, web pipeline; Android target, native pipeline. Both can share the same designs and DESIGN.md spec, but the outputs are not interchangeable.
7. Limitations and Caveats
- Native conversion is not pixel-perfect: designs become Compose components that follow Material conventions; details need manual polish.
- Basic engineering knowledge still pays: build failures, signing, and dependency conflicts are not always solved automatically.
- Version details need testing: the demo confirms the end-to-end chain and artifact type; check your local CLI output for exact flags.
- Start small: convert one or two screens to prove the chain before scaling up.
8. FAQ
Q1: Can I use this pipeline without Android experience?
You can start, but basic Gradle and emulator concepts help a lot; when builds fail, that background shortens debugging dramatically.
Q2: How good is the generated Compose code?
It is a runnable starting point, not a pixel-perfect port. Adjust against Material 3 and verify each step in the emulator.
Q3: How is this different from exporting React code from Stitch?
The artifacts differ: Compose components versus web code. Pick by target platform; they do not substitute for each other.
9. Summary
This official workflow pushes Stitch's boundary from the web to native Android: designs, agents, native components, emulator, and a real device, connected end to end for the first time. For Android teams, the sensible next step is to prove the flow on a small project before adopting it in production.
Keep reading:
- Learn the terminal integration: Stitch CLI guide
- Capture design systems properly: URL to design system
- Build prompt skills: Stitch prompt tutorials