App store review readiness #

This page is for app developers and product owners who submit an app that shows Exponential content. It is general advice about the parts of a review that depend on the content server. The rules of each store change and are not repeated here: read the current guidelines of the store you submit to, and treat this page as a list of things to prepare on the Exponential side.

Contents #

1. A reviewer can use the app
2. Sign-in and accounts
3. Privacy statements
4. Content that users add
5. Accessibility

A reviewer can use the app #

• To do: The review build points at production or at a stable staging installation, never at a public demo that is rebuilt on a schedule (Testing against a demo).
• To do: If the app needs a sign-in, there is a reviewer account on that installation with the same role as real users, and its credentials go only into the store's review notes.
• To do: The folders the app shows have content during the review; an empty list looks like a broken app.
• To do: The reviewer account cannot change or remove real content.

Sign-in and accounts #

• To do: If users sign in with their Exponential account through OAuth, the sign-in opens in the system browser and comes back to the app (OAuth2 authorization code flow).
• To do: Users who lack oauth/authorize see a clear message instead of a dead end (the site redirects with error=access_denied).
• To do: If the app lets people create accounts, plan how a user asks for the account to be deleted; deleting users is an administrator's task on the site, so the app needs a route to that process (a form, a support address).
• To do: Sign-out works and removes tokens (Storing secrets on devices).

Privacy statements #

Store forms ask what data the app collects and sends. On the Exponential side, list honestly:

• To do: Which user data the app sends to the installation (sign-in, content the user creates).
• To do: That requests are recorded by the server: API key and token events in the audit trail with the client address for key use (Auditing and limits), and the web server's logs.
• To do: Which third parties your back end or analytics add.
• To do: Where the installation is hosted, if your privacy text names it. The organization's data protection basics: GDPR basics (basics, not legal advice).

Content that users add #

• To do: If users can post content, new items land in a folder or state that editors review before the public sees them, or there is a way to report and remove content quickly.
• To do: Editors know where app submissions arrive and who moderates them.
• To do: Writes are limited by role to that folder (Permissions for app users).

Accessibility #

• To do: Every image has an accessibility label; use the alternative text from expimage::alt or expimage::info, and ask editors to fill it (Images in REST answers).
• To do: Text from rich text fields scales with the user's font size settings (Rich text in apps).
• To do: Right-to-left languages mirror the layout if the app supports them (Multilingual content).

Related pages #

• Launch checklist for apps
• Security checklist for apps
• Testing accessibility
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.