Feedback loop
Every upload runs through automated validation. Results come back as tickets you can read and resolve, and you also receive email notifications as your version moves through its lifecycle.
From findings to tickets
On upload, the platform statically checks your build — signing, version-code increment, permission policy, size, and listing assets. Each finding becomes a ticket on that app version, with a severity:
- info — informational, no action required.
- warning — should be addressed; does not necessarily block.
- blocking — must be resolved for a clean release.
Reading and resolving tickets
Open the version in the portal to see its tickets. Each ticket has a title, a
severity, a status (open → in_progress → resolved → closed), and a comment
thread you can use to discuss with the store team. To resolve a finding, fix it in
your build and re-upload a new revision (with an incremented versionCode).
The new upload re-runs validation; resolved findings do not reappear.
Email status notifications
You receive transactional email notifications at key points so you do not have to poll the portal, including when:
- a new validation run produces findings on your version,
- a ticket is created or commented on,
- your version is approved or rejected in review,
- your version goes live.
Notifications are outbound only — there is no inbound mailbox to reply to; use the ticket comment thread in the portal to communicate.
Multiple versions
Findings and tickets are tracked per app version. Two versions of the same app can have different open issues and different review states at the same time, so you can iterate on a new version without affecting one that is already live.