How app review works

Every app is reviewed by a person before it’s listed in the WispOS App Store. Review has one job: when someone presses Get, the app should be safe, do what its listing says, and work.

This page is for people submitting apps. To send one, see Submit your app. Submitting also means agreeing to the Developer Agreement.

The stages

Stage	What happens	Usually takes
1. Intake	We confirm we have your submission and give it a number.	Within 2 business days
2. Package checks	We pack it (if you sent a folder) and run the format checks.	Same day as intake
3. Safety review	A reviewer reads the code and the agent’s files, and runs the app.	Part of the week
4. Quality review	We use the app on a desktop and on a phone, in light and dark.	Part of the week
5. Listing review	We check the listing against the app.	Part of the week
6. Decision	Approved, changes needed, or not accepted, with reasons.	Within 7 business days of intake
7. Listing	Approved apps go into the store’s catalog.	Within 2 business days of approval

A resubmission after Changes needed is usually decided within 5 business days. We tell you if one will take longer.

1. Intake

Your email gets a reply with a submission number. Keep replies on that thread. If something is missing (no app, no contact email, no way to test), we ask for it before the clock starts.

2. Package checks

These are automatic, and a failure here comes straight back to you with the exact error. We check that:

• the package is a valid WispOS app: the container, the file names, and a manifest that matches the format exactly;
• every file is listed in the package’s checksums, with nothing missing or extra;
• the app loads nothing from the internet (no remote scripts, styles, frames or media);
• the package is within the size limits (256 MB packed, 512 MB unpacked, 10,000 files);
• the id is yours: a new app’s id isn’t taken, and an update’s id matches an app you publish, with a higher build than the one listed.

3. Safety review

A reviewer reads what’s in the package, not only what it shows. We look for:

• Malicious code: anything that tries to escape the app’s sandbox, mine, spy, or hide what it does. Obfuscated or minified code must come with readable source.
• Code that changes after review: downloading and running code, eval of fetched text, or remote switches that turn on behavior we didn’t see.
• Network use that matches the listing: every address in web.network is needed for what the app says it does, and nothing is sent that the privacy label doesn’t mention.
• Permissions that are used: each one is needed, asked for when it’s needed, and its reason is true.
• Agents that stay in their lane: the instructions and knowledge files don’t try to get Wisper to ignore you, act outside the agent’s subject, reveal other information, or follow hidden instructions. An agent’s card.json says honestly what it knows and who may ask it.
• Chat cards that behave: a card shows what Wisper sent it and links where it says.

4. Quality review

We use the app the way people will:

• It opens and works, with no crash, no blank screen and no dead buttons.
• It fits a desktop window, at its minimum size and a large one, and an upright phone, with nothing scrolling sideways and controls inside the safe area.
• It follows WispOS’s light and dark theme, or has one look on purpose.
• It pauses when hidden and keeps its state.
• Its help pages explain how to use it.
• It does enough to be worth installing: not a single web page wrapped as an app, and not a near-copy of an app already listed.

5. Listing review

• The name, icon, summary and description describe this app, and don’t imitate another app, brand or person.
• The screenshots are of the real app.
• The age rating fits the content.
• The privacy label matches what the app does.
• The publisher name is you, or an organization you can speak for.
• Nothing says or suggests the app is official, built in, or made or endorsed by WispOS. The only use of our names allowed is the plain line “Available on the WispOS App Store”.

The guidelines

An app is not accepted if it:

• is malicious, deceptive, or collects data it doesn’t declare;
• tracks people across other apps or sites;
• impersonates another developer, product, organization or person;
• contains illegal content, sexual content, content that sexualizes minors, or content that promotes violence or hatred against people;
• is real-money gambling, or offers anything illegal where it’s used;
• uses code, art, music or data you don’t have the right to publish;
• is spam: many near-identical apps, or keyword-stuffed listings.

It’s also not accepted if it:

• tries to get around review: behaves differently while it’s being reviewed, hides features, or turns on behavior after approval;
• tries to get around WispOS: escapes or weakens the sandbox, its permissions, the package checks or our signing, or uses WispOS in ways that aren’t documented;
• acts as a store or installer: offers, downloads or runs other apps, agents, plug-ins or code that haven’t been through review;
• reaches for data that isn’t its own: a user’s HQ folder, Wisper’s memory or conversations, their teams, projects or files, or another app’s or agent’s data, beyond what its permissions and listing say;
• abuses Wisper or other agents: hidden instructions, prompt injection, pretending to be Wisper, a WispOS system message or the user, or pushing an agent outside its subject;
• misuses our names: puts WispOS or Wisper (or something like them) in its name, icon or publisher name, or uses our logos;
• passes itself off as WispOS: says it’s official or made by us, or copies WispOS’s own screens, features or wording so closely it could be mistaken for part of WispOS (doing a similar job in your own design is fine);
• charges money, shows paid ads, or sends people elsewhere to pay to unlock it (the store is free apps only for now);
• breaks the Developer Agreement in any other way.

Changes needed is the usual result for anything that’s fixable: a missing reason on a permission, a privacy label that’s out of date, a layout that breaks on a phone, a screenshot that isn’t the app.

Decisions

Every decision comes with reasons, each tied to a guideline or a stage above.

• Approved. We tell you the day it goes live, and send you the exact package we listed (with its SHA-256) so you can see what people get.
• Changes needed. A numbered list. Fix them, raise build, and reply on the same thread. You can resubmit as often as you need to.
• Not accepted. The reason and the guideline. You can reply once to ask for a second look; a different reviewer makes that call, and it’s final for that submission.

Updates

Every new build is reviewed before it replaces the listed one. Fixes and new content get a lighter look. A new permission, a new network address, a new kind of data collected, or a change in what an agent knows gets the full safety review. Until the update is approved, the store keeps listing the previous build.

After it’s listed

An app can be taken out of the store if it turns out to break these guidelines or the Developer Agreement, for example if it starts sending data it didn’t declare. We tell the publisher why. If it’s urgent (it’s harming people), we pull it first and explain after.

Found a problem with an app in the store? Email [email protected] with the subject App report: the app’s name.