The way to get AI to match a design is one screen at a time, one image at a time.
Send one image per screen, and ask for one screen per message. That is the method Newly's own engineers give people whose redesign came back as a rough approximation. It is close to the opposite of what most people try first, which is to upload one sheet with twelve screens on it and ask for the app. The sheet feels efficient. It is the thing that loses the detail. The rest of this page is how to cut a design up, what to say with each image, the attachment limits that decide how you split the work, and the two places where matching your mockup exactly is wrong. If the images are fine and the wording is the problem, start with prompting tips instead.
Everything about the product here is taken from the Newly documentation as it reads on 3 October 2026. The platform numbers come from Apple's and Google's own current guidance, read the same day, and they are dated where they appear.
Plan what to send, in what orderThe short version
A composite gives the model nothing to go on about which details you meant.
Changing the design is one of the most common things people ask an app agent for, and a design that came back nearly right is one of the most common disappointments. Part of the reason is simple arithmetic. Twelve screens in one picture is twelve times less of each screen. A button edge, a 4 pixel corner radius, the exact grey of a caption: each is a few pixels wide before the file is ever compressed.
The part that matters more is intent. In a picture of one screen, nearly everything in the frame is the answer. In a sheet, the model also gets the order you arranged the screens in, the gaps between them, your own labels and arrows, and the background colour of the sheet itself. Some of that is the design and some of it is packaging, and nothing in the image says which is which. So it averages, and an average of twelve screens is exactly what people describe getting back.
Cut the design into one image per screen
Asking an AI to build an app from a design is really a run of smaller requests, and the first one is file management. Export each frame on its own, at the size you designed it. Name each file after its screen, so Home, Cart and Settings arrive with those names. The file name does work you would otherwise do in the prompt: you can write "match the attached Cart screen" and the words and the image agree. Crop each image to the screen edges too. A frame floating on a grey artboard teaches the model a grey background you never asked for.
The supported formats are PNG, JPG, WebP and GIF. Anything else is refused by name, and the message tells you which file it was: an iPhone photo of a whiteboard is usually HEIC, so convert it or screenshot the photo and paste that. A file can be up to 10 MB, and one chat holds 40 files or 100 MB in total. Attach an image by clicking + in the prompt box and choosing Files & Images, by pasting it, or by dragging it onto the window.
One limit decides the whole shape of the work. A single message stops at five attachments, which the changelog records on 2 October 2026. Twelve screens cannot go in one message, whatever you do. That is worth knowing before you spend an hour laying out a style sheet, because the product will not let you send it as one thing anyway.
There is one case with no images at all. If the design already runs as a published Lovable app, the Lovable to Mobile App starter takes its address, and the agent opens the live app in a browser and walks its screens itself. The documentation is clear about the trade: that path gets the look and the flows, and for the data model you start from the repository instead.
Then go screen by screen, and name the screen
A redesign instruction that covers a whole app is one task with twelve answers in it. One screen is one task. Newly's documentation says the same thing in its own words: ask for one change per message, and name things the way the app does, using the screen titles and button labels it already has. On a new project the agent builds the smallest working version first, on purpose, usually one screen with sample data. Meeting it screen by screen is meeting it where it starts.
Order matters more than people expect. Begin with the screen that sets the system, normally the main list or the home screen, because the palette, the type sizes, the spacing step and the shape of a card all get decided there and every later screen inherits them. Agree that first screen in Plan mode, where the agent writes back how it would do the work and, in a cloud chat, cannot change files. Then switch to Build and tell it to build the plan it just wrote. Fixing the spacing step once, in words, beats fixing it on eleven screens.
Then each round is the same three things: attach that screen's image, name the screen, say what must match exactly and what can be approximate. Screenshot the result from the preview and attach that next to the reference, so the comparison is in front of the agent rather than in your head. A mobile app wireframe per screen is a better input than one polished composite for the same reason: it is one screen's worth of decisions, and the decisions are legible.
Two mechanics make the method work rather than just sound tidy. In a long chat the agent sees only the most recent images, about the last thirty, and the screenshots it takes while testing your app count toward that, so re-attach the reference for the screen you are on instead of pointing back at message four. And when a screen goes the wrong way, Restore to here under an earlier message puts the code back. Talking the agent out of a bad redesign over five messages costs more than starting that screen again.
Try it
What to send, in what order
Say how many screens your design has and what form it is in. The plan below is the one that holds up.
13 messages, 12 images
- First: Export every frame on its own as a PNG and name each file after the screen.
- Message 1, in Plan mode: attach the screen that sets the look, and agree the colours, type sizes and spacing in words before any code exists.
- Then one message per screen, in Build mode: attach that one image, name the screen, and say what must match exactly.
- Attachments: a message stops at five files, so 12 images is at least 3 messages even if you ignore everything above.
- Past screen eight: the agent keeps only the most recent images, about thirty, and its own test screenshots count. Attach the reference again with the screen you are on.
Where you should not match the design
Most mockups are drawn on a desktop, in a tool made for the web, at web density. Two kinds of detail in them should not survive the translation to a phone, and a model that matches your design faithfully will carry both across. Tell it which parts are fixed and which may give.
The first is the size of anything tappable. Apple's accessibility guidance, read on 3 October 2026, lists 44x44 pt as the default control size on iOS and iPadOS and 28x28 pt as the minimum, and it says spacing between controls matters as much as size: about 12 points of padding around an element with a bezel, and about 24 points around one without. An icon button drawn at 32 pixels looks unremarkable in a browser and sits under both platforms' numbers on a phone.
The second is contrast. The same Apple page gives the values Accessibility Inspector checks against, from WCAG Level AA: 4.5:1 for text up to 17 pt, 3:1 at 18 pt, and 3:1 for bold text. A pale grey caption on white looks refined in a design tool at full brightness and fails that outright. The page also asks that people ideally be able to enlarge text by at least 200 percent, which is what breaks a row you gave a fixed height to. None of this is a reason to abandon the design. It is a reason to say "match the colours, the type and the spacing, raise any tap target under 44 points, and let the rows grow", which is one sentence. The rest of the groundwork is app design basics.
Apple Human Interface Guidelines, Accessibility, read 3 October 2026
One design, two platforms, two sets of numbers
Your design is one set of frames and it has to land on both phones, where the official numbers are not the same. Google's accessibility guidance for Android, read on 3 October 2026, recommends a touch target of at least 48dp by 48dp and says larger is even better. Apple's default is 44 points. Design the tappable area to 48 and you are inside both, which is the simplest instruction you can give an agent on this.
Contrast nearly agrees and then diverges in one place. Google asks for 4.5:1 when text is smaller than 18sp, or bold and smaller than 14sp, and 3:1 for everything else. Apple's table gives bold text 3:1 at any size. So a small bold label is the one case where the stricter requirement is Google's, and a design full of 12 point bold captions is the design most likely to be judged differently on the two platforms.
There is also a difference in what you get for free. Google's page says that in Jetpack Compose, Material components such as Button, IconButton and ListItem already enforce the minimum size, while a custom interactive element is yours to size. The same logic survives the move to any toolkit: ask for the app's standard button component wherever the design allows it, and keep the hand built tappable areas for the places the design genuinely needs one. Every custom control is a place where the number has to be remembered.
Check both before you call it matched. The cloud preview runs an iPhone 17 Pro on iOS 26 and a Pixel 8 on Android, and you cannot pick another model or OS version, so a design drawn to some other frame width is being re-flowed either way. That is why the instruction to the agent should be a spacing step and a type scale rather than a set of absolute positions. What to do once the first version of a screen exists is a separate job, covered in iterating after the first build.
Android Developers, Make apps more accessible, read 3 October 2026
What each platform asks for, where a mockup usually disagrees
| Design detail | Apple, iOS and iPadOS | Google, Android | What it means for your mockup |
|---|---|---|---|
| Size of a tappable control | 44x44 pt default, 28x28 pt minimum | At least 48dp by 48dp, larger is better | Draw it at 48 and both are satisfied |
| Space between controls | About 12 pt of padding with a bezel, about 24 pt without | Not stated on this page | Web spacing is usually too tight to carry over |
| Contrast for small text | 4.5:1 up to 17 pt | 4.5:1 under 18sp | Pale grey captions fail on both |
| Contrast for bold text | 3:1 at any size | 4.5:1 if bold and under 14sp | Small bold labels are the one place Android is stricter |
| Who enforces the minimum | Not stated on this page | Material Button, IconButton and ListItem do; custom elements do not | Prefer the standard component over a hand built one |
What this looks like in Newly, including where it falls short
Newly is an AI app builder: you describe an app and it writes a real React Native and TypeScript project you own, runs it on cloud simulators while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month, there is no free plan, and turns are charged as effort-based credits. For this job the parts that matter are small ones: attachments are saved into your project so the agent can open them while it works, and you can take a screenshot straight out of the preview by hovering over the cloud simulator and pressing its camera button, Save screenshot to Downloads. That is the loop. Reference in, build out, both images in the next message.
Two honest limits. There is no Figma import: nothing in the documentation describes reading a design file, so you are exporting frames to PNG either way. And attached images and screenshots are named in the documentation as one of the things that make a turn cost more, so a twelve image pass does cost more than one prompt with one sheet. It buys you fewer rebuilds, which is usually the better trade, but it is a trade rather than a free win. There is also a Design mode that draws screens before any app code is written, and it is worth knowing that it is listed for Local chats in the Mac app only, and that the documentation says Newly for Mac is not available to download yet. Do not plan a design pass around it today.
Last, stop repeating yourself. Standing instructions go in a file named AGENTS.md or CLAUDE.md at the top level of the project, up to 20,000 characters each, and they are read in every chat. A project skill does the same job with a name and a one line trigger. Put the palette, the type scale, the spacing step and the component rules in one of those once, and a new chat three weeks from now starts from your design system instead of from your memory of it.
Questions people ask about matching a design
Attach one image per screen rather than one sheet of all the screens, and ask for one screen per message. Name the screen in the message the way the app names it, say what has to match exactly and what can be approximate, then screenshot the result and attach it next to the reference so the agent can see the difference you are describing.
Send the first screen
Export the screen that sets the look, crop it to its edges, name the file after the screen, and agree the colours, type sizes and spacing on that one screen before you go near the other eleven.
Start building