Guide summary
Prepare a review-ready store submission
Boot Store quality depends on evidence. A reviewer should see what the pack is, who made it, where it works, what it contains, and why it is safe to publish.
Cover image, motion note, screenshots, and style tags help users understand the pack quickly.
Declare original work, source material, licenses, permissions, and attribution needs.
List device family, resolution, boot/shutdown path, fps, and known limits.
Attach Package Doctor report, package hash, frame count, and reviewer notes.
| Access type | Free, Premium, clean-export related, or future paid-pack labels must be clear and not misleading. |
|---|---|
| Paid packs | App-side digital purchases should use Google Play Billing where required. Website pages stay discovery and app handoff surfaces. |
| Rejection reasons | Unsafe package, missing ownership proof, misleading compatibility, low-quality preview, broken structure, or policy risk. |
| Creator changes | Creators may need to resubmit metadata, previews, package files, or compatibility notes after review feedback. |
| Deletion | Creator deletion and admin removal should follow admin rules and audit records. |
Workflow
Use this sequence
A practical flow that maps the public docs back to app behavior and support evidence.
Create cover, preview, and readable description.
Run Package Doctor and fix structure issues.
Add creator/source/permission notes.
Send title, device notes, access type, and package evidence.
Handle approved, rejected, pending, or edit-request states.
Related CRYA docs
Continue with the next useful page
The docs should move users between package work, safety, billing, store review, and support without exposing private admin systems.