Corona Marketplace Product Submission Guidelines


Thank you for your interest in participating in our Marketplace! Please read the following guidelines to help prepare for your product submission to expedite the process and avoid any common pitfalls that may arise. The goal of products offered on the Marketplace are aimed to be used in professional and useable projects for Corona Lab’s development community. These guidelines are meant to be a resource for you to better understand what our review team are looking for in the products we will approve to be distributed on the Marketplace.

In the circumstance that your product is not approved, we will provide the reasons why a Product has not passed approval and work together with you to bring your product to a final acceptable level of quality. Please be aware of the possibility that your product may be ultimately unfit for the Marketplace as we strive to cultivate it as a key resource for developers to facilitate the creation of their projects.

These guidelines are meant to be interpreted as a set of general points that our review team will use in our review process and the final decision of approval will rest upon their judgement. Since the possibilities of products that will be submitted will undoubtedly exceed whatever we can anticipate, we will further update these guidelines as we gain experience to help improve the Marketplace’s experience as a whole.

If you have any questions about these guidelines or if there are any qualities unique to your product that these guidelines don’t seem to address please do not hesitate reach out to us and ask at

General Guidelines

  • All the contents in a product submission will be carefully reviewed by us before they go live.
  • Corona Labs reserves the right to accept or reject the content provided for review.
  • All the guidelines will be strictly followed, and the submission will be rejected, if the content doesn’t meet our standards.
  • Please try to do a search on the Marketplace for any similar products beforehand. We will only approve any products that try to add more value than already existing products whether that may be judged on the basis of performance, functionality, ease of use, and/or documentation.

General Restrictions

  • Contents that you do not hold the proper rights/license to resell or redistribute will be rejected.
  • Copying/redistributing the content that you downloaded from an open source domain are not accepted.
  • The content must not use any trademarks/logos/brands that you do not own.
  • The content must not contain anything that may be deemed inappropriate. Overly sexual, violent, gruesome, hateful (race/religion/gender/identity/etc.) will be rejected.
  • Content which attempts to perform any negative actions that are not anticipated from the user will be rejected. Negative actions may include:
  • a. Unknowing tracking a user’s data.
  • b. Attempt to install any malicious programs or virus, or noncritical background services.
  • Content must be usable “out of the box” and not require any special additional software or service to operational unless it’s requirements are innately understood.


  • In general, monetization plugins packaged around a particular service provider is not allowed. If you are the said service provider and are interested in providing a Corona Plugin for your service, we would love to work with you. Please contact for more information.
  • Please go through our Plugin Submission Guidelines for our guidelines specifically pertaining to Corona Plugins.


  • Please submit your assets in a .zip file.
  • Include a README file, either .txt or .pdf format, in the base directory to provide any good to know information such as general guidelines on how to use the assets, any copyright or licensing information, or any issues to consider.

Content Structure

  • Ensure your folder structure is as clean and easy to understand as possible.
  • Folder and file names should be in English and sorted by type.
  • Within a singular folder should only contain one type of file. There should not be a range of file types. For example, a folder containing PNG image assets should only contain PNG images and would not have PSD or audio files along with it.
  • Remove all non-critical files, such as duplicate, unused or redundant files.

Asset Specific Guidelines


  • Raster (pixel) images should be in either PNG or JPEG for single layer files. JPEG's should be limited to solid image without transparency (backgrounds, etc.). Multi-layer raster images should be in PSD format.
  • Vector images should be in .EPS, .SVG or .AI formats.
  • If you include images with multiple sizes, please save each size in their own sub-folder. For instance if you offer 50px and 100px files, you would have a folder named assets/images/png/50px and assets/images/png/100px.
  • Images should be of sufficient resolution to support modern screen sizes but be respectful of maximum texture sizes. Image file sizes should be as small as possible without compromising the quality of the image.
  • Tileable image assets should able to tile without obvious corners or gaps.


  • Audio files must only be in formats that are supported by the Corona audio system. More information what formats are supported see our Corona Supported Audio Formats.
  • Submissions of audio collections should maintain a consistent format, naming convention, and quality.

Naming Conventions

  • Files and Folders must have a consistent and clear naming convention throughout your submission.
  • File and Folder names should be representative of the content.
  • The File and Folder names should be as simple as possible without complex namings. For example, cat_yellow.png is acceptable but catSittingInTheGroundWithYellowEyes.png is not.
  • Lowercase file names are preferred but not required.


  • Your asset should contain local documentation if the proper use of the asset will require any instructions or if your asset’s use is not self explanatory.
  • Documentation can be supported with more extensive online documentation but the local documentation should be thorough enough to stand on it’s own to give a clear understanding of the whole asset’s functionality.
  • Documentation must be in English and comprehensible. Documentation in other localized languages can be included in addition to the English version.