Submit your app to the App Store

Anyone can bring an app to the WispOS App Store: one developer or a whole team. Build it with Wisper, with any AI you like, or by hand: nothing in the package says which, and the checks don’t ask. You submit it from WispOS, we review it, and once it passes it’s listed for everyone using WispOS. Submitting an app means you agree to the Developer Agreement: what you let us do with your app, what you promise, and when we can reject or remove it.

What you can submit

Kind	What it is	Shows up under
Game	A web app (HTML, JavaScript, CSS) that’s played, or a Unity, Unreal, Godot or other engine game converted to a web build (how).	Games
Tool	A web app that does a job. It can also add cards to Wisper’s chat.	Apps
Agent	Instructions and the files it answers from. No screen of its own; Wisper asks it.	Agents

An app can carry both parts: a tool with an agent, or an agent with a settings page.

For now the store lists free apps. Paid apps and in-app purchases are in the package format and work today as test purchases (no money moves), but a submission with a price or purchases is held for the reviewer, not published, until payments open. When they open, WispOS keeps 15% of each sale and you get the rest; free apps stay free to list.

Already on another store?

If your app or game is already on another store, turn it into a .wapp yourself and submit it like any other, or we’ll port it to WispOS for you. For a port, email support@wisp-os.com with the subject Port: your app’s name, and send the web build (or the engine’s web export: Unity WebGL, Unreal Pixel Streaming or HTML5, Godot Web), a link to the listing you have today, and a few lines about it. We send the package back for you to install and check, then you submit it from WispOS like any app.

Before you submit

Read Building apps for WispOS and run through its checklist. Then make sure your app’s folder has:

• manifest.json: its id, name, kind, version and build, summary, description, publisher, age rating, languages, icon, screenshots, permissions and privacy label.
• app/: the web app, for a game or a tool. Everything it runs is inside the package.
• docs/: at least one help page, .html or .md.
• agent/: for an agent, its card.json, its instructions (PROMPT.md) and its knowledge/ files.
• store/: the icon (icon.svg, or a square PNG at least 512 × 512, full bleed: WispOS rounds the corners) and screenshots, ideally two of a desktop window and two on a phone.

A few things trip up most first submissions:

• The id never changes. Pick it once: lowercase letters, numbers and dashes. Every update uses the same id.
• build goes up with every release, by at least one. Updates are compared by build, not by version.
• Nothing from the internet at load. No scripts, styles, fonts or media from a CDN. If the app fetches data, list each origin in web.network and ask for the network permission with a reason.
• Every permission has a reason people will understand, and the app actually uses it.
• The privacy label is true. If you collect nothing, say so (collects: [], tracking: false). If you do, list it.
• Screenshots are of the real app, not mockups.
• No hidden files (.DS_Store, .git) and no file names with spaces.

Submit it from WispOS

You submit from inside WispOS, with the app installed there: one Wisper built, or one you or any other AI made and opened in Apps.

1. Open the Submit sheet. On the Apps page, open the app’s ··· menu and press Submit to App Store. Or open the app and press Submit to App Store in the bar at the top of it. Or ask Wisper, “submit my cookbook to the App Store”: she can send an app you installed, or the folder she (or a coding agent) built it in. A new version of an app you sent before says Submit update.
2. Become a developer, for free. The first time, the sheet signs you up right there: your name, your email, the publisher name your apps go under, a password, and a tick for the Developer Agreement. It’s free and works at once. Already have an account? Sign in on the same sheet, or in Settings → Apps & stores → Sending apps to the App Store. Your password goes to the App Store once and isn’t kept. Your account publishes under one publisher id, and every app you send must carry that id in manifest.json (publisher.id); the sheet tells you before anything is sent if it doesn’t.
3. Answer the content questions. What your app is and who it’s for, then what’s in it: violence, swearing, fear, gambling, content from other people, and the rest. Your answers set its age rating, and some send it to a person first, which takes longer. There’s a box for the reviewer too: how to try it, and what changed. An update asks again only what changed.
4. Send it for review. WispOS packs the app into a .wapp with the App Store’s own packer (wapp.mjs, the same tool as on Building apps), runs the same format checks we do, and shows you exactly what will be sent and where. Nothing leaves your computer until you press Allow (when Wisper sends it, she asks on the same Allow card, on your Mac and your phone). Packing needs Node.js 18 or newer.

Then follow it on the app’s page or in the Developer portal the sheet and Settings open: In review, Approved, Changes needed or Not accepted, with the reviewer’s reasons. WispOS checks every few minutes while one is waiting, and when the review moves, Wisper tells you in her chat. Ask her “how’s my submission doing?” any time. While it’s still in review (or changes are asked for) you can Withdraw it; sending a new build replaces the one waiting.

What happens next

1. The App Store checks it arrived whole and runs the format checks again. Anything that fails comes straight back to the sheet with the exact problem; fix it and submit again.
2. It’s in review: safety first, then quality, then the listing. Most reviews finish within a week.
3. You hear the result, on the app’s page, in Wisper’s chat and by email:
   • Approved: it goes live with the store’s next publish.
   • Changes needed: a numbered list of what to fix. Fix it, raise build, and press Submit update.
   • Not accepted: the reason, and the guideline it falls under.

The full process, the timelines and the guidelines are in How app review works.

Updating your app

Every new version goes through review too. Keep the same id, raise build and version in manifest.json, and press Submit update where you pressed Submit to App Store (the same build twice is refused). Say what changed on the sheet: it becomes the listing’s “What’s New”. People who installed your app see Update on its page, and their stored data is kept.

Small updates (fixes, new levels, new knowledge files for an agent) usually take a lighter look than a first submission. A new permission, a new network address or a new kind of data collected gets the full review.