MōIcons generates macOS app icons with an image model and exports a proper icns bundle

Full bleed artwork, and why the mask matters

MōIcons is a desktop app for generating macOS app icons in the icns format with AI. The repository description is two words long, generate macOS app icons using AI, and the README gives a slightly fuller picture of the flow. You describe what you want, optionally attach a reference image, pick from several variants, refine the chosen design, then save a proper icns bundle and the iconset folder with all standard sizes.

The export detail is the most useful thing in the README, and it is easy to skim past. The saved icns uses full bleed artwork, so macOS can apply its own mask, and the README gives the reason in parentheses: it avoids the gray plate and shrunken icon you get from pre-clipped corners.

That is a real workflow problem for anyone who has tried to make an icon by hand. If you draw a square and ship it, macOS either shows your square inside the default rounded plate, or you clip the corners yourself and end up with artwork that does not fill the shape. Modern macOS icons are a system mask applied to a square canvas, so the correct input is a full bleed square and the correct output is an icns that lets the system do the rounding.

The image model used for generation is the OpenAI API, according to the README. The generated image is therefore square artwork that the system will mask, and the app is essentially a prompt interface plus an icns assembler plus a preview that shows the squircle mask so you can judge the result before you save.

The prompt is wrapped in fixed system constraints

The first feature in the list is prompt-based generation, and the mechanism behind it is the interesting part. The README says your text is wrapped in fixed system constraints, so outputs stay on-brand for macOS-style icons, with the examples given being a centered subject, no text and squircle-friendly composition.

This is a design decision with consequences. A bare prompt to an image model will happily produce a logo with a wordmark in it, an off-centre composition or a background that will look wrong once the system mask cuts into the corners. By wrapping the user text in constraints the app controls, the author is removing the most common failure modes of generated icons rather than leaving them to the person typing the prompt.

The prompt itself is still the user's lever, and the README is specific that short phrases work well, giving the example "blue clipboard with folded corner". That is a compositional description rather than a mood board, which matches what an image model can actually render as an icon.

The project layout shows where this happens. The main process directory, src/main, holds the window, the IPC layer, prompt building, provider selection and icns assembly. The renderer directory, src/renderer, holds the React UI, the squircle preview and the generation pipeline state. So prompt construction and provider choice live on the main side, and the renderer is concerned with the interface and the state of the generation flow.

Three variants, then a refine loop with the chosen one as reference

The generation loop has two stages, and the second is what makes the tool usable rather than a novelty.

Each generation returns three images, so you can compare quickly, and the README's usage steps spell out the flow: describe the icon in the prompt field, optionally attach a reference image, press Generate or Enter, wait for three previews, then pick a variant to move into refine mode or generate again from scratch.

In refine mode you adjust the prompt and generate again, and the confirmed icon is used as the reference for the next batch. This is a genuinely different mechanism from a plain regenerate. Because the chosen variant is fed back in as the reference, the second batch is a variation on the same artwork rather than a fresh guess at the same prompt, so the subject stays recognisable while the details change. Attach the same idea to the first round: an optional reference image, which the README describes as a PNG that can steer the model, for example a sketch, a logo or an earlier render.

Two small behaviours are worth knowing. The preview shows icons with a squircle mask so you see something close to the final result rather than a flat square. And quitting with an unsaved icon triggers a confirmation dialog, which is the sort of detail that only appears after someone lost work.

Running it needs Node, the MōBrowser runtime and an Apple Silicon Mac

The requirements list is short and specific: macOS 14 on Apple Silicon or later, Node.js 24.14.1 LTS or later, and MōBrowser 2.13.0 or later. MōBrowser is the desktop app framework the project is built on, and the package.json shows the SDK packages pinned at 2.13.0 for darwin-arm64, linux-x64 and win-x64.

The setup is a single install step:

npm install

Development mode starts the app with the framework's dev command:

npm run dev

And there is a variant that runs the interface without calling any image API, which the README describes as local UI work without APIs:

npm run dev:mock

That mock mode is the one to reach for first when you are working on the interface, because it means you can iterate on the React layer without spending image generation calls or waiting on the network. The package.json shows how it is wired, with the provider selected by an environment variable on the command:

    "dev": "mobrowser dev",
    "dev:mock": "ICON_PROVIDER=mock mobrowser dev",
    "build": "mobrowser build",

A production build is the same command with a different target:

npm run build

The repository also carries mobrowser.conf.json for the framework configuration, vite.config.ts for the bundler, components.json for the shadcn component setup, and Tailwind 4 with PostCSS for styling. The UI stack is React 19 with shadcn, Radix and Base UI components, and the icon set is Hugeicons with lucide-react also present.

What the Save step actually writes to disk

The last steps of the usage flow are the ones that produce the deliverable. When you are satisfied, you click Save, choose a path for an icns file, and the app writes both YourName.icns and YourName.iconset in that folder, replacing existing files only if you confirm.

Writing both is the correct behaviour rather than redundancy. The iconset folder is the working directory that Apple's icon tooling consumes, containing the artwork at the standard size variations, and the icns file is the compiled bundle that an application bundle actually references. A tool that produced only a PNG would leave you to run iconutil yourself; a tool that produced only the icns would hide the intermediate. Producing both means you can drop the iconset into Xcode, or hand the icns to whatever packaging step you use.

The success interface also offers Reveal in Finder, so you land in the folder rather than hunting for it.

The project layout names where this work happens. The main directory handles icns assembly, so the format handling lives on the main process side, and the renderer owns the squircle preview and the pipeline state. The separation is what lets the preview be a rendering concern while the file output is a native capability.

Signed releases, optional telemetry, and a version 1.x project

You can download the app from the releases page, and the README states that all releases are signed and notarized by Apple. That detail matters more than it might look for a tool that runs on a developer machine and makes network calls to an image API, since a notarised, signed application is what Gatekeeper will accept without friction.

Telemetry is opt in at build time rather than at run time. Production Sentry telemetry is included only when SENTRY_DSN is set during the build, and release builds read it from the SENTRY_DSN GitHub Actions secret. So the behaviour depends on how the binary was compiled, not on a settings toggle inside the app, which is a clean way to keep a locally built copy quiet.

The release history shows a project that reached 1.0 and then kept shipping: v1.0.2 on 2026-05-13, v1.0.3 on 2026-06-04 and v1.0.4 on 2026-07-09. The repository is not archived, and the last push was on 2026-08-21.

The licence is MIT, with the text in the LICENSE file, which for a tool you run locally means you can read it, modify it and ship it without obligations beyond keeping the notice. There is also AGENTS.md, CLAUDE.md and a .github directory, and a moicons-demo.mp4 in the root that shows the app in action alongside the video linked from the README.

Where MōIcons is the wrong tool

The first wrong case is a brand system. An image model can give you a good single icon, and the refine loop lets you steer that one icon. What it cannot give you is a family of icons that read as a set, with a consistent grid, a shared corner radius and a palette rule applied across a dozen applications. If your product needs that, you need a designer or a vector tool, and the AI generation is at best a starting sketch.

The second is platform coverage. The stated requirement is macOS 14 on Apple Silicon or later, and the SDK packages are per architecture. An Intel Mac is out, and so is any workflow that needs the same icon produced for a non-Mac target from this tool.

The third is offline or restricted network use. The app calls the OpenAI API for image generation, so it needs an API key and network access, and the mock mode covers the interface rather than the actual generation. There is also a dependency chain that has to be satisfied before any of this works, Node 24.14.1 LTS and MōBrowser 2.13.0 or later, so this is not a tool you can hand to a colleague as a single file.

The alternative approach for the same job is a vector drawing tool plus Apple's own icon workflow, where you draw a full bleed square, mask it yourself and run iconutil to produce the icns and iconset. That route gives you exact control over every curve and is the right answer for a product icon, while MōIcons is the right answer for a developer who needs a decent icon for a side project in ten minutes and has the runtime already installed.

Editorial conclusion

Adopt MōIcons if you ship a Mac app and want an icon in minutes without opening a design tool, and you are on Apple Silicon with Node 24 and the MōBrowser runtime available. Do not adopt it if you need a brand system with several coordinated sizes, or if your machines are Intel Macs, since the stated requirement is macOS 14 on Apple Silicon or later. Before you trust the output, check the generated artwork at full size rather than in the squircle preview, and note that the app is MIT licensed, that releases are signed and notarised by Apple, and that Sentry telemetry is only compiled in when SENTRY_DSN is set at build time.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mo-browser-apps/icons on GitHub
4. README
5. Releases