Review guidelines

LEDABLE displays hang in kitchens, hallways and children's rooms, and people add apps to them because they trust the store. Every version you submit is reviewed against these guidelines before it is listed. A rejection comes with a note that says what to change; read it with developer status.

What review looks at

A reviewer sees your listing, the outcome of every publishing check, the settings the version returned when it was checked, its preview, and what changed since the version the store lists now. Only versions that passed every check can be submitted, so a version that reaches review already fits the store's limits; review is about what checks cannot tell.

It works

• The app does what its listing says, on a 64×32 display, with the settings people can choose.
• With its default settings, or once the person has filled in its required ones, it draws something useful. It does not fail on a first run.
• When a service it reads is down, or a person's account or token no longer works, it draws what the person should know or do, rather than nothing. Handle a null token or credential (Accounts and credentials).
• An app that needs an account, a token or a paid service says so in its description and README, and the README tells people where to get what they need.

The listing is honest

• The name and description say what the app shows. No claims it cannot back, no unrelated keywords, and tags that describe the app.
• The preview, the icon and the screenshots show what this version really draws. Do not show features, data or designs the app does not have.
• Pick the category that fits what the app shows.
• Do not present the app as made or endorsed by LEDABLE, by another developer or by a service it reads, and do not imitate their names or logos. Naming the service your data comes from is fine, and so is following its branding rules when it has them. Your publisher name is your account's nickname: choose one that is yours.
• The app behaves in review as it does for everyone. It does not change what it shows after approval, for example by date or by a switch on your own server.

Content suits a home

• Nothing sexual, no graphic violence, no hate, harassment or threats, and nothing that encourages self-harm or illegal acts. The display may be seen by children and guests who did not choose the app.
• No advertising beyond naming your app or the source of its data.
• No rapid flashing: whole areas of the panel must not flash more than three times a second.
• Text is readable from across a room. Use the SDK's fonts at their own size or larger, keep moving text slow enough to read, and keep colours with enough contrast against the background.

People's data stays theirs

• Reach only the hosts the app needs. The hosts you declare in network.allowed_hosts are shown on your store page.
• Use a person's account, token or settings only to draw what your app describes. Send their token only to the service it belongs to, and their data to no one.
• Do not collect, keep or sell data about the people who use your app or about their displays, and do not use their location or settings to track them.
• Keep one person's data to that person. Share cached data between displays with vary only when it is the same for everyone.
• Ask for an account or a token only when the app needs one, and check a credential against the service it is for.

Respect the services you read

• Follow the terms of every API your app calls: who may use it, attribution, rate limits and commercial use.
• Use a key that belongs to you, kept as a secret, or the person's own account or token where the service requires it. Never ship someone else's key, or a key in code.
• Ask a service no more often than its data changes. Share what is the same for everyone through the cache, and set softTtlMs and hardTtlMs to match how fresh the data must be.

It is light and stays up to date

• Draw quickly. Each step has 10 seconds when the version is checked, and a render that takes most of that is too slow for a display that waits for it.
• Keep images small: animate only what moves, and only for as long as it adds something.
• Keep published versions working. Displays play the version they have until their owner updates it, so keep the secrets they declare and the services they call available, and fix a broken version with a new one promptly.

After listing

LEDABLE can unlist an app that breaks these guidelines or stops working, with a reason you see in developer status. Displays that have the app keep it; a new version that fixes the problem can be submitted and listed again, as Updating your app describes.