wonderblok
Get early access

Design iOS and Android screens, play them, then ship.

Wonderblok lets a mobile developer design iOS and Android screens with an AI agent, link frames into a prototype that plays like the app, and draw store screenshots from the same screens. Components and tokens use your code's names, and build checks compare the running app with the design.

Get early accessSee pricing
UniversePrototypeLaunch kitBuild checks

WHO THIS IS FOR

Sound familiar?

You know your platform's code better than its design tools. You still need real screens before you build: the flow from sign in to home, the error when the network fails, the sheet that asks for a permission. And later you need five store screenshots that do not look like an afterthought.

Wonderblok keeps those jobs in one file. Draw or generate the screens at phone sizes, link them, and play the flow in the app. When the build runs, compare it with the design and see where they differ. The launch kit turns the same screens into store images.

  • Designing in a tool you do not use daily

    Heavy design suites slow down a developer who needs a screen, not a studio.

  • Permission and error states left to chance

    System prompts, denied states and offline cases shape the experience and are rarely designed.

  • Store screenshots at the end

    They are drawn in a hurry from whatever the build looks like that day.

AN EXAMPLE WEEK

From a sign-in screen to store screenshots, in a week

A scenario, not a customer story: what a week can look like when your agent works on the canvas with you.

  1. Monday

    The flow gets drawn before the code

    You are building a gym check-in app for iOS and Android. You connect Claude Code and ask for the first flow: sign in with a phone number, a one-time code, a wrong-code state and the success screen. By lunch there are four linked frames at 390 by 844 on the canvas, built on a phone number sign-in pattern from Universe, with your name and colors on it.

  2. Tuesday

    The unglamorous screens

    You ask for the screens that usually get skipped: the location permission prompt before the system dialog, what happens after a no, and what the home screen shows when the network is gone. You read them the way a user who taps Don't Allow would. The denied state needs a clear way forward, so you leave a note on it.

  3. Wednesday

    You play it before you build it

    You link the frames and play the prototype in the app. The one-time code step feels slow, and the agent moves the resend link closer to the field after you leave a note. You share the prototype as a link with your co-founder, who clicks through it and sends back two comments.

  4. Thursday

    Names that map to your code

    Colors, type sizes and spacing become tokens, and the dark values go in beside the light ones. Buttons, list rows and the code field become components. You set code names to match the ones in your Swift and Kotlin projects, so the design and the code point at the same things.

  5. Friday

    The build gets compared

    You build the sign-in flow from the frames. When the app runs, a build check compares it with the design and lists where they differ: a label that wraps, a padding that is off. You fix the code, or you fix the design if the build turned out better.

  6. Next week

    Store screenshots from the same screens

    The launch kit draws store screenshots from your real screens, with short captions in your brand colors. When a screen changes before release, the screenshot follows. You did not redraw anything at the last minute.

BEFORE AND AFTER

What changes once your agent has a canvas.

WITHOUT A DESIGN FILE

  • You design in a tool you open twice a month, so a simple screen takes an afternoon.
  • The permission prompt, the denied state and the offline state are decided while coding, if at all.
  • You only feel the flow once it runs on a device, when changing it is expensive.
  • Design and code use different names for the same thing, and they drift further every release.
  • Store screenshots are drawn in a hurry from whatever the build looks like that day.

WITH WONDERBLOK

  • Your agent drafts the screens at phone sizes and you review them instead of drawing them.
  • Permission, denied, offline and error states are on the canvas before a line of code exists.
  • You play the flow as a prototype first, and share it as a link to get a second opinion.
  • Components and tokens carry names that map to your code, and build checks show where the app differs from the design.
  • Store screenshots come from the same frames as the app and stay current.

HOW IT WORKS

Mobile app developers: the workflow, step by step.

Each step shows what you ask for, what you get, and the features behind it.

  1. 01

    Connect your agent

    Wonderblok sets up the MCP connection for Claude Code, Codex and Claude Desktop. Your agent can then read the file and edit frames, text, components and tokens. The file stays on your device.

    MCPLocal files

    You get: Your agent can see the design and change it.

  2. 02

    Write the platform rules once

    Put what you would repeat in every prompt into the file's guidelines: the frame sizes you design for, how big a tap target should be, the tone of the copy, which navigation pattern the app uses. The agent must read the current version before it may edit.

    GuidelinesRead-before-edit

    YOU SAY

    Read the design guidelines. Then list which of them apply to a sign-in screen and which you would need me to decide.

    You get: A short rulebook that makes every screen start from the same assumptions.

  3. 03

    Start the flow from a pattern

    Universe holds patterns tagged for iOS and Android, such as permission priming and phone number sign-in, drawn from shipped apps as editable frames. Your agent adds the closest one and maps it to your tokens and copy. Frames are not tied to a platform, so you set the sizes you need.

    Universe (Pro)Frames and auto layout

    YOU SAY

    Create the sign-in flow for iOS and Android at 390 by 844: phone number, one-time code, wrong code and success. Use the Universe pattern for phone number sign-in and link the frames.

    You get: Linked frames with the failure case included, on a structure proven in other apps.

  4. 04

    Design the states users meet by accident

    Ask for what the system and the network can do to your app: a denied permission, no connection, a timeout, an empty first run. Each gets its own frame or variant with a clear way forward.

    Components and variantsChange history

    YOU SAY

    Add a denied state for the location permission screen, with a way forward after a no. Then add an offline version of the Home screen.

    You get: The screens that decide whether the app feels finished.

  5. 05

    Link the frames and play them

    Connect the frames and play the prototype in the app to feel the flow, or share it as a link. Where it feels wrong, leave a note on that layer. The agent acts on the note, reports what it changed and marks it done.

    PrototypeShare linksNotes

    YOU SAY

    Apply my notes on the Verify frame and tell me exactly what you changed.

    You get: A flow you have felt before you wrote it, and a link for a second opinion.

  6. 06

    Give things the names your code uses

    Colors, type and spacing become tokens with light and dark modes. Reused pieces become components. Set code names so they match your Swift, Kotlin or React Native identifiers, and have your coding agent build from the design file instead of from a screenshot.

    Tokens and modesCode names

    YOU SAY

    Set the code names for the Verify components to my view names, then list every token the screen uses.

    You get: Design and code that share a vocabulary.

  7. 07

    Compare the build, then ship the screenshots

    Run build checks to compare the running app with the frames. When the app is right, the launch kit draws store screenshots from the same screens, with captions you choose, and you export them as PNG.

    Build checksLaunch kitExport

    YOU SAY

    Make five store screenshots from the main flow with short captions, using my brand colors.

    You get: A list of differences to fix, then store images that match the app.

USE CASES

Six jobs you can hand to your agent this week.

  • Sign in with a phone number

    Most of your users arrive on this flow, and a wrong code is the thing that goes wrong most often.

    PROMPT Create the sign-in flow for iOS and Android at 390 by 844: phone number, one-time code, wrong code and success. Link the frames.

    Result: Four linked frames you can play, including the failure case.

    UniversePrototype

  • Permission priming and denial

    You get one system prompt for notifications or location. If the user says no, getting them back is hard.

    PROMPT Add the permission priming pattern from Universe for location, then a denied state with a way forward after a no.

    Result: A screen that explains the ask before the system dialog, and a path for people who decline.

    Universe (Pro)States

  • Offline, loading and error

    The network fails on a train, and your app shows a spinner forever.

    PROMPT For each frame in the Home flow, add loading, offline and error variants, and list what you added.

    Result: A coverage list you can check, and the frames to match.

    Components and variantsChange history

  • A subscription screen

    You are adding a paid plan, and the screen that asks for money is the one you can least afford to guess.

    PROMPT Draw a paywall with monthly and yearly plans, a restore purchases link, a failed payment state and a confirmation. Use my tokens.

    Result: Every state of the paywall, including the ones that go wrong.

    UniverseTokens

  • Dark mode on every screen

    iOS and Android users expect the app to follow the system theme.

    PROMPT Give the color tokens dark values, then show the sign-in flow in dark mode and list any text that fails contrast.

    Result: Dark mode from the same frames, driven by token values.

    Tokens and modesLint

  • Store screenshots from your real screens

    Release day is close and the screenshots are still gray placeholders.

    PROMPT Make five store screenshots from the main flow with short captions, using my brand colors.

    Result: Screenshots drawn from the same frames as the app, ready to export as PNG.

    Launch kitExport

WHAT TO LOOK AT

The features that matter most to you.

  • MCP connection

    Your coding agent works on the design file directly, so you stop retyping decisions between tools.

  • Frames with auto layout

    Screens at phone sizes resize and reflow like the real thing, so the design is a fair preview of the build.

  • Universe patterns

    Permission priming, phone number sign-in and more, tagged for iOS and Android, as a starting point instead of a blank frame. Part of Pro.

  • Playable prototypes

    Feel the flow before you build it, and share it as a link.

  • Components and variants

    A button or a list row is drawn once, and its states and sizes follow.

  • Tokens with light and dark modes

    Dark mode and brand changes are value changes, not a second set of screens.

  • Guidelines the agent must read

    Your platform rules are applied without repeating them in every prompt.

  • Notes on layers

    Feedback sits on the layer it is about. The agent acts on it and reports what it did.

  • Code names and build checks

    Design and code share names, and the running app is compared with the frames.

  • Launch kit

    Store screenshots are drawn from your real screens and stay current.

QUESTIONS

Straight answers.

Can I prototype a mobile app in Wonderblok?

Yes. Link frames to each other and play the prototype in the app, then share it as a link.

Does it make App Store screenshots?

The launch kit draws store screenshots from your own screens, so they match the app and update when the screens do.

How do I check that the build matches the design?

Build checks compare the running app with the frame and report where they differ.

Does it support both iOS and Android?

Frames are not tied to a platform. Universe patterns are tagged iOS and Android, and you set the frame sizes you need.

Is the Free plan enough to try this?

Free includes 100 MCP calls a week, which is enough to design a sign-in flow and a few states with your agent. Designing a whole app with an agent will use more, which is what Pro and its much higher limit are for. Universe patterns are part of Pro.

Does it work with Swift, Kotlin, Flutter or React Native?

Frames are not tied to a framework. You set component and token names to match your code, and your coding agent builds from the design file in whatever stack you use.

Is the prototype a real app?

No. It plays inside Wonderblok and as a shared link, so you can feel the flow and collect opinions. It is not a native build. The real app comes from your code, and build checks compare it with the design.

HONEST LIMITS

What to know before you start.

  • Wonderblok runs on macOS today. Windows, Linux and Android and iOS tablets are coming soon.
  • The prototype plays inside Wonderblok and as a shared link; it is not a native build.
  • Universe is part of Pro.

ALSO FOR

More in Build a product and every other group on the Solutions page.

Try it on one real job.

Download for macOS and start on Free. Windows, Linux and tablets are coming soon. No card needed.

Get early accessSee pricing