WispOS

Submit your app to the App Store

How to bring your game, tool or agent to the WispOS App Store: what to send, how to send it, what we check, and what happens after you submit.

Updated

Anyone can bring an app to the WispOS App Store: one developer, a team or a company. 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 send it to us, 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, send it to us and we’ll port it to WispOS, or turn it into a .wapp yourself. For a port, send what you’d send below, plus the web build (or the engine’s web export: Unity WebGL, Unreal Pixel Streaming or HTML5, Godot Web) and a link to the listing you have today. We send the package back for you to check before it goes to review.

Before you send it

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 from inside WispOS

If you built your app with Wisper or with any other AI, and it’s installed in your WispOS, you can send it from WispOS instead of by email:

  • From the app’s page: open it from Apps, then press Submit to App Store in its top bar. On the Apps page it’s also in each app’s ··· menu.
  • From the chat: 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.

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.

To send, you sign in once with your App Store developer account, on the submit 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. Developer accounts are set up by us for now: ask at [email protected].

Then follow it on the app’s page or under Sent to the App Store on the Apps page: In review, Approved, Changes needed or Rejected, 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 from the same list; sending a new build replaces the one waiting.

In-app submission is opening now. Until the App Store’s intake is switched on for your WispOS, it checks your app and shows what review is likely to say, but doesn’t send it: email it as below.

What to send

To send it by email, write to [email protected] with the subject App submission: your app’s name, and include:

  1. The app. Zip your app’s folder (the one with manifest.json in it) and attach it. If you already have a .wapp package (how to make one), send that instead; leave it unsigned for now. For a game from an engine, the engine’s web build folder is enough; we package it. Over 25 MB? Send a download link.
  2. What it does, in two or three sentences, and who it’s for.
  3. Who you are: your name or your company’s, the publisher name to show on the listing, a contact email, and a website if you have one.
  4. How to test it: anything a reviewer needs to see every part of the app (sample data, a test account, a level select, the question to ask your agent).
  5. Network use, if any: each address the app talks to, and why.
  6. Third-party parts: any code, art, music or data you didn’t make, and its license.
  7. A line saying you’ve read the review guidelines and agree to the Developer Agreement, and that you have the right to publish everything in the app.

What happens next

  1. We say we’ve got it, usually within two business days, with a submission number.
  2. We pack and check it. If you sent a folder, we build the .wapp from it and run the format checks. Anything that fails comes straight back to you with the exact problem.
  3. We review it: safety first, then quality, then the listing. Most reviews finish within a week of the acknowledgment.
  4. You hear the result:
    • Approved: we tell you when it goes live, and send you the exact package we listed.
    • Changes needed: a numbered list of what to fix. Send a new build with the same id and a higher build, and reply on the same email thread.
    • Not accepted: the reason, and the guideline it falls under. You can reply once to ask us to look again.

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

Updating your app

Every new version goes through review too. Send it the same way, on a new email with the subject App update: your app’s name, with what changed (it becomes the listing’s “What’s New”). Keep the same id and raise build. From WispOS, raise build and version in manifest.json and press Submit to App Store again (the same build twice is refused). 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.