SnapAI: an OpenAI and Gemini icon CLI for React Native and Expo

What SnapAI replaces for a React Native or Expo developer

Every mobile project needs a 1024x1024 icon, and every Google Play listing needs a 1024x500 feature graphic. Those are two design tasks that usually sit between finishing a build and shipping it, and they are exactly the tasks a solo developer or a small team has no designer for. SnapAI is a command line tool that produces both. The README describes it as built for React Native and Expo developers while noting that the generated assets work with any mobile stack, which is the honest framing: the output is a PNG, so nothing about it is React Native specific except the audience and the agent skill that wires the result into app.json.

The project is TypeScript, published to npm as snapai, and licensed MIT. The repository lists a bin entry pointing at ./bin/snapai.js and an engines field requiring Node.js 18 or newer. There is no SnapAI account, backend, telemetry or tracking, according to the README, which means the only credentials involved are the provider keys you supply yourself. That matters for anyone who has been asked to justify sending app artwork through a third-party service.

The scope is deliberately narrow. SnapAI does not resize icons into the platform-specific sizes Expo expects, it does not write your app.json for you unless you go through the agent skill, and it does not manage a library of past generations. It is a generator with a prompt pipeline in front of it.

How the CLI turns a prompt into a provider call

The architecture visible in package.json is thin. The CLI framework is @oclif/core with @oclif/plugin-help, so each subcommand (icon, fg, feature-graphic, config) is a separate oclif command class. Provider access goes through two official SDKs: openai for the GPT image models and @google/genai for the Gemini ones. Image post-processing uses sharp, and fs-extra handles writing files. There is no server component and no database.

What sits between your prompt and the API is prompt enhancement. The README lists prompt previews before spending API credits as a feature, and the recipe `--prompt-only` exists precisely to print the enhanced prompt without generating anything. So the flow is: your text goes through a mobile-artwork-tuned enhancement step, optionally with a style hint from the built-in styles or a custom one, and the resulting prompt is sent to whichever model you selected. The image comes back, sharp handles any format or background work, and the file lands in ./assets by default.

The model table is where the real decisions live. The default is gpt-2, which maps to OpenAI's gpt-image-2 and supports icon and feature graphic commands but, per the README, no transparent background. gpt-1.5 and gpt-1 map to the previous OpenAI generations. On the Gemini side, banana maps to gemini-2.5-flash-image and returns one image, banana-2 maps to gemini-3.1-flash-image-preview with an optional thinking level, and `banana --pro` maps to gemini-3-pro-image-preview with multiple images and 1K, 2K or 4K quality. Variations, via `-n`, are only available on models that support them, which the README ties to the pro Gemini path and to the OpenAI models in its variation recipe.

Installing SnapAI and generating a first icon

You need Node.js 18 or newer and a key from either OpenAI or Google AI Studio. Nothing else is required, and the README's quick start runs everything through npx so you can inspect the tool before committing to an install.

Start by listing the commands without installing anything:

npx snapai --help

That prints the oclif command list. Next, store a key locally. The config command takes the key as a flag:

npx snapai config --openai-api-key "sk-your-openai-api-key"

With the key saved, generate an icon. Images are written to ./assets by default:

npx snapai icon --prompt "minimalist weather app with sun and cloud"

If you would rather use Gemini, configure a Google key and pick a Banana model. The README gives this example:

npx snapai config --google-api-key "your-google-ai-studio-key"
npx snapai icon \
  --prompt "music player with an abstract sound wave" \
  --model banana

Before spending credits on a prompt you are unsure about, print the enhanced version instead of generating:

npx snapai icon \
  --prompt "calculator app" \
  --style minimalism \
  --prompt-only

For a Play listing, the feature-graphic command is also available as fg, and it accepts an app name and a composited logo:

npx snapai fg \
  --prompt "clean productivity banner with space on the left" \
  --logo ./assets/icon.png \
  --logo-position left

If you want it permanently on the machine, the README also gives `npm install -g snapai`. The alternative path is the Code with Beto app-icon skill, installed with `npx skills add https://github.com/code-with-beto/skills --skill app-icon`, which the README says prepares the Expo icon assets and updates the iOS and Android configuration for you.

Where SnapAI stops being the right tool

The README does not document rollback. That is the first thing to weigh. The CLI writes into ./assets by default, and if you already keep hand-made assets there, nothing in the documented behaviour tells you whether an existing file is overwritten, versioned or skipped. The agent skill goes further and updates the iOS and Android configuration, which means a natural-language request can touch app.json. For a project under version control that is recoverable; for a project without a clean working tree it is a bad afternoon.

The second limit is the model matrix itself. Transparent backgrounds are not available on the default gpt-2 model, according to the README's own note, so if your icon needs transparency you are choosing a different model, and the README's model table is the place to check which one. Variations are similarly conditional: `-n 3` works in the documented OpenAI recipe, but the Gemini flash models are described as returning one image. Passing `-n` to a model that does not support it is a mismatch the README does not resolve for you.

Third, SnapAI is a generator, not an asset pipeline. It does not produce the full set of platform icon sizes, and it does not verify that a generated 1024x1024 image will read well when scaled down to a home-screen tile. If you need a deterministic, reproducible icon set that never changes between builds, a vector source you export from is a better fit than a text-to-image model, because the same prompt will not return the same pixels twice.

Finally, cost sits outside the tool. SnapAI holds your key and calls the provider directly, so image generation is billed by OpenAI or Google on your account. The README's prompt preview exists for this reason, and it is worth treating `--prompt-only` as the default first step rather than an advanced option.

SnapAI against calling the OpenAI or Gemini SDK directly

The obvious alternative is a short script against the openai or @google/genai package, both of which SnapAI itself depends on. The difference is what the wrapper adds. A direct SDK call gives you the raw request and response, so you control the exact parameters and you can log whatever you want. SnapAI adds three things on top: a prompt enhancement layer tuned for mobile app artwork, a fixed set of model aliases (gpt-2, gpt-1.5, gpt-1, banana, banana-2) that hide the provider-specific model IDs, and output handling through sharp that writes a correctly named file into ./assets. It also gives you the same command shape across two providers, which a hand-rolled script does not, because the OpenAI and Gemini image APIs are not shaped alike.

For a one-off icon, a direct SDK call is less machinery. For a team that regenerates icons across several apps and wants the same flags every time, the alias layer is the point: switching from gpt-2 to banana is a single flag rather than a rewrite of the request body. The trade-off is that you inherit SnapAI's prompt enhancement whether or not you want it, which is why `--prompt-only` and the raw prompt control the README mentions are worth knowing about early.

Licence, maintenance and what an upgrade costs you

SnapAI is MIT licensed. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text travel with it. It says nothing about the images you generate, because those are governed by the terms of whichever provider produced them, not by SnapAI's licence. If you plan to ship generated artwork in a paid app, the provider terms are the document to read, not the LICENSE file in this repository. None of this is legal advice.

The last push to the repository was on 2026-07-20, and v1.0.0 was released the same day, following v0.9.0 on 2026-07-16 and v0.6.0 on 2026-02-11. The repository is not archived. The gap between v0.6.0 in February and v0.9.0 in July suggests the project moved in bursts rather than continuously, and the 1.0.0 tag is recent enough that the surface is still settling.

Upgrade cost is dominated by the model aliases. The README's model table maps SnapAI option names onto provider model IDs, and two of those entries are preview models on the Gemini side. When a provider retires a preview model, the alias stops working until SnapAI is updated, so pinning a version in CI is safer than tracking latest. The package is ESM (`"type": "module"`) with a tsc build and a webpack bundle step, so a global install and an npx run are not pulling identical artifacts, which is worth remembering if you file a bug.

Editorial conclusion

Adopt SnapAI if you already have an OpenAI or Google AI Studio key and you want icon and feature-graphic drafts produced from a terminal command, with prompt previews before spending credits. Do not adopt it if you need a guarantee about which files in your project get rewritten, or if you want a hosted service with an account and a history of past generations. Before running it against a real app, run `npx snapai icon --prompt "calculator app" --style minimalism --prompt-only` to inspect the enhanced prompt, and check whether the default output directory `./assets` collides with assets you already keep there.

Frequently asked questions

Official sources

1. Code-with-Beto/snapai on GitHub
2. License: MIT
3. Project website
4. README
5. Releases