The app icons generator that clicks its own Export button before handing you the zip
Every other page on this topic describes the same upload-and-download pipeline. I want to describe a different one. You describe the generator. mk0r builds a real Vite app at /app, writes the canvas and export code, then a Claude agent opens Chromium at http://localhost:5173 and drives the UI until the exports render cleanly.
The gap in every other app icons generator
Open the first five pages that currently answer this question. The shape is identical: drop a 1024 master PNG, pick target platforms, download a zip. That shape is fine for the common case. It quietly breaks for three things that bite in production.
One, a canvas export that silently taints from a cross-origin font or image. toDataURL throws, the error bubbles into a click handler nobody reads, the UI still announces "download ready," and the PNG is empty. Two, an ICO that looks like an ICO and has the wrong byte layout for Windows Explorer. Three, a maskable icon that passes PNG validation and fails the PWA spec because the safe-area inset is too small, so Chrome crops into the glyph on install.
None of these are theoretical. They are the reason app submissions get bounced. And none of the hosted generators verify for them because their pipeline ends the moment the zip is written.
What a verified pipeline looks like
The hub in the middle is your prompt. The agent splits it into every target kit in parallel and, after rendering, drives Chromium to open each output.
One prompt, four verified kits
The anchor fact: step 4 of the in-VM workflow
Every mk0r sandbox boots with a Claude config file at /root/.claude/CLAUDE.md. That file is defined in src/core/vm-claude-md.ts and is injected into the VM image. Its Workflow section tells the agent exactly how to finish a task. Step 4 reads:
4. Open the browser and navigate to http://localhost:5173 to verify
A few lines further, the Browser Testing section is stricter. It lists five steps, and step 5 is the one nobody else will show you:
5. Do not report completion until the browser shows the expected result
That single line is what makes the difference for icons. The agent cannot hand you a zip it did not open. The Chromium that opens it runs with a persistent profile at /root/.chromium-profile/ and is driven through Playwright MCP. If an export throws, the agent sees the console error and edits the code until it does not.
A prompt that produces a real generator
You do not need to write the canvas. You describe the generator you want and the kits it should emit. The agent picks the libraries. The example below produces a working app you own.
What the verification loop actually looks like
This is a trimmed view of the Playwright MCP session the agent runs against its own generator after the last file edit. The command lines come from the agent, the output lines come from the sandbox, and the two checkmarks at the bottom are the "shows the expected result" gate from step 5.
Every size the standard kits cover
The full list of raster targets in a current-year iOS, Android, PWA, and favicon pipeline. A generator that misses any of them will fail one store submission or another. Hover to pause.
What the five-step build actually does
Describe the generator
Tell mk0r what an app icons generator for your brand should look like. Which inputs, which kits, which file formats. One paragraph is enough.
VM boots with Vite at /app
A sandbox spins up with Vite + React + TypeScript + Tailwind v4 pre-installed. The dev server listens on port 5173. Chromium is ready with a persistent profile at /root/.chromium-profile/.
Agent writes the canvas code
A Claude agent edits src/ files. Canvas draws the master. Helpers downscale to every target size. Download buttons trigger each export format. All of it streams to your screen.
Agent opens Chromium and exports
Via Playwright MCP, the agent navigates to localhost:5173, clicks every generate button, downloads each kit, and inspects the resulting blobs. If toDataURL throws or a PNG comes back empty, the agent fixes the code and tries again.
You get the generator and the zip
When the browser shows clean exports, the agent reports done. You get the running generator app and the icon kits it produced during verification.
Why this is shaped like a bento, not a form
The things that make a mk0r-built generator different are not one feature. They are a handful of decisions that only make sense together.
A real Vite project, not a hosted tool
The generator is scaffolded at /app with Vite + React + TypeScript + Tailwind v4. You can git clone it, deploy it, or embed the export logic in an internal design-system app.
Chromium on port 5173
The dev server runs inside the sandbox with HMR. The agent connects a real Chromium instance to http://localhost:5173 via Playwright MCP and drives the UI the way a user would.
Verified before it reports done
The in-VM config says not to report completion until the browser shows the expected result. The agent literally clicks Export and inspects the downloaded blob before handing the generator back.
All the standard kits
iOS (13 sizes from 20 to 1024), Android (48 through 192 plus adaptive-icon foreground/background), PWA (192, 512, 512 maskable), apple-touch (180), favicon.ico at 16/32/48.
Canvas, SVG, and ICO
Raster sizes rendered from a 1024 canvas master. SVG output stringified from an offscreen DOM subtree. ICO assembled in JavaScript (favicon.ico is a packed bitmap container, not a renamed PNG).
Your brand, your controls
The generator exposes the knobs you asked for: letter, gradient stops, corner radius, safe-area inset. Change them, export again, download a new kit.
Hosted generator vs. mk0r
| Feature | Hosted generator | mk0r |
|---|---|---|
| What you walk away with | A zip of PNGs | A running generator app plus a zip of PNGs |
| Inputs | Upload a 1024 master | Any inputs you ask for (letter, colors, radius, safe-area, fonts) |
| Verification | None. Hopes the files open | Agent clicks Export in Chromium and opens each blob before reporting done |
| Ownership | Bookmark and repeat | Vite + React + TS code you can git push |
| Signup required | Usually yes | No account to start |
| Where the verification rule lives | Not exposed | src/core/vm-claude-md.ts, injected into /root/.claude/CLAUDE.md |
Numbers that actually matter here
Raster sizes in a full kit
Port the agent verifies on
Master canvas side in pixels
Accounts needed to try it
When the upload-a-PNG generator is still the right call
If you need one kit, once, from a master you already have, and you trust the pipeline, grab the first hosted tool that ranks for your query. Opening a tab is cheaper than prompting an agent.
mk0r pays off when the generator itself needs to live somewhere. Inside a design system. Inside a white-label product where the customer picks the inputs. Embedded in your internal tools so brand changes never require a designer round-trip. That is a generator, not an icon.
Want the verification loop running against your brand tonight?
Book a 20-minute walkthrough. We will build an icons generator for your product live on the call and you will watch the agent click Export in Chromium before you leave the room.
Book a call →Frequently asked questions
What does an app icons generator actually need to produce in 2026?
At minimum: a 1024x1024 master PNG, iOS sizes (20, 29, 40, 58, 60, 76, 80, 87, 120, 152, 167, 180, 1024), Android densities (48, 72, 96, 144, 192) plus an adaptive icon foreground and background, a maskable 512 for PWA installs, 192/180 for the standard apple-touch-icon, and a 48x48 favicon.ico. Good generators also return a Contents.json stub for Xcode and a mipmap-anydpi-v26/ic_launcher.xml for Android Studio. Most of the pages that currently answer this question stop at 'upload a 1024 and download a zip'.
How is mk0r different from an upload-a-PNG generator?
You do not upload anything. You describe the generator. 'Build an app icons generator that takes a letter, a gradient pair, and a roundness value, renders a 1024 master on a canvas, and exports iOS, Android, PWA, and favicon kits.' mk0r scaffolds a Vite + React + TypeScript + Tailwind v4 project at /app inside a sandbox, writes the Canvas drawing code, wires the export buttons, and then the agent opens Chromium and clicks every button to verify the downloaded files open before telling you it is done.
Where is the self-verification step actually enforced?
In the in-VM Claude config at /root/.claude/CLAUDE.md. The workflow section lists step 4 as 'Open the browser and navigate to http://localhost:5173 to verify.' The Browser Testing section is stricter: step 5 says 'Do not report completion until the browser shows the expected result.' That file is defined in src/core/vm-claude-md.ts and lives inside the VM image the agent boots into. Chromium runs with a persistent profile at /root/.chromium-profile/, driven by Playwright MCP.
Why does verification matter for app icons specifically?
Canvas exports fail in quiet ways. A tainted-canvas error from a cross-origin font kills toDataURL without a visible exception. An SVG stringify can embed an unresolved @font-face URL and still validate. A maskable PNG can be valid PNG and invalid maskable because the safe-area inset is too tight. An ICO can be a valid image and the wrong byte layout for Windows. None of those surface until somebody actually runs the export and opens the resulting file. The agent is that somebody.
What do I actually get back at the end?
Real code. The whole generator is Vite + React + TypeScript at /app, ready to deploy. You can git push it, embed the export logic in an internal tool, or hand it to a designer as a brand-tool with controls over the master letter, colors, and radius. You also get the zip it produced during verification. You own both.
What size limits can this realistically hit?
Canvas in a modern Chromium handles 4096x4096 without stress. For icon work you rarely go above 1024 master. If your generator rasterizes at larger sizes (marketing hero icons, App Store preview art at 2048), the agent notices the OOM in the Chromium console during verification and drops the render size before reporting done. The relevant loop is in step 3 of the Browser Testing section: 'Check browser_console_messages for runtime errors.'
Do I need an account to start?
No. Open mk0r.com, type the prompt, watch the streaming build. The whole session happens in an ephemeral sandbox and the generator app loads via HMR as files change. Accounts only matter when you want to save a session or publish the generator to its own subdomain.
Describe the app icons generator you want. Everything else is the sandbox.
Build Your Icons Generator