Last updated: November 12, 2020
Introduction & Overview
We're glad you've decided to submit your work to the Unity Asset Store! The goal of this guide is to give new and existing publishers a comprehensive understanding of what is expected of packages that are submitted to the Unity Asset Store. Published products are intended to be professional and useful projects for Unity’s development community. In order to provide content with consistent standards, our curation team will hold your incoming submissions to these guidelines during your product’s review. You will find it worthwhile to read these guidelines thoroughly since it will save you time and in the end, possibly lead to a more successful product.
You will always be notified of your rejection if your project does not uphold these standards. If there are corrections that need to be made to your product, you will be provided with as specific as possible reasoning as to why your submission was rejected. Any issues mentioned in your rejection will need to be fixed before resubmitting your product. While our review process has the best intentions of catching and informing you of all reasons why your product has been rejected, more issues may be found in your product even if your resubmission has addressed all the initial issues. If needed, you will be required to address issues throughout multiple resubmissions before your product is in a state that is ready to be published on the Unity Asset Store. In rare instances, even if your submission has gone through multiple resubmissions, some products may be deemed unfit for the Unity Asset Store. If we feel that your content is not compatible with the Asset Store, the Content Curation Team reserves the right to reject the submission without giving specific feedback.
This is a living document that will be periodically updated and is meant to oversee the broad cases of content that are brought to the Asset Store. If specifics of your submission are not explicitly covered by these rules, the decision of how your submission will be handled ultimately comes down to Unity’s Content Curation Team during your product’s review. The beauty of our development community is that we continuously see projects that we never expected would be developed. If there are specific qualities of your project related to unique or emerging technologies that you do not see in these guidelines, please contact us at AssetStore@unity3d.com to discuss any questions or concerns.
1. Restricted Content
1.1 Legal Restrictions
1.1.a Submissions that include content you do not hold the license to resell or redistribute will be rejected.
1.1.b Submissions that include content that is not allowed to be resold, not allowed to be utilized in commercial products, or is required to remain open-sourced due to its EULA will be rejected.
1.1.c Certain asset file types are protected by proprietary licenses and may not be applicable for resale such as models generated from Speedtree or Mixamo’s Fuse. Submissions including these types of assets that are not allowed to be resold due to their EULA will be rejected.
1.1.d Submissions that include any content from another Asset Store package is a violation of the Asset Store Provider Agreement and will be rejected.
1.1.e Unless expressly forbidden, any products that are developed and published under the Unity Technologies account on the Asset Store are allowed to be incorporated into submitted products for demonstration purposes. To avoid needless file size and clutter, we require that you only include Unity Technology content that is directly being utilized in your demos.
1.1.f To avoid legal conflicts, you may be asked to remove any third party libraries or SDKs that are included in your project but not directly incorporated into your product. Rather than being included directly with your project, your users will need to be informed where to download the libraries/SDKs through your documentation.
1.1.g Submissions must not have unauthorized trademarked names or branded content being referenced anywhere in your package. This includes in images, names, description text, nor in content/file names. Any brands or names that hold active trademarks related to your product in public databases such as the US Patent and Trademark Office website, will be rejected.
1.1.h References of the Unity brand must adhere to our naming guidelines. I.e. Unity Technologies, Unity, Unity Personal, Unity Plus, Unity Pro, and Unity Enterprise. Any reference to Unity3D, Unity Free, Unity Indie, etc. will be edited or rejected.
1.1.1 Licenses in your Products
1.1.1.a All content published on the Asset Store is provided under the Asset Store EULA. To maintain a consistent experience for our users, products are not allowed to be sold under any unique licenses.
1.1.1.b Submissions of free products that you, the submitter, have developed and are providing open sourced through other sites, will be allowed to include a EULA. As long as that content meets all other applicable requirements of this doc, is perpetually free and that EULA is compatible with our own. The compatible licenses that we mainly allow are MIT, BSD 3-Clause, and Apache. Any licenses that require a product to maintain open-sourced or limit usability in commercial products such as GNU/GPL Mozilla Public License, or any Creative Commons/Apache 2.0 that requires attribution will not be allowed. Please reach out to AssetStore@unity3d.com if you would like clarification about any specific license before submitting.
1.1.1.c Any third party libraries/sdks that are incorporated into your product with a provided license will be required to have a license text file that clearly states which third party files are being included and from what source.
1.1.1.d Any fonts, audio, and other third party components with dependent licenses being included in your submission must be compatible with our EULA and include a license file detailing the component that it is covering. A Third-Party Notices text file will also need to be included within the package to provide clear guidance on which components are under the appropriate license.
1.2.a While it is understandable that some projects are designed around open source libraries or frameworks, submissions to the Asset Store should have a majority of their content developed directly by the publisher. If we believe a package is a compilation of found content/products or the direct result of public tutorials, it will likely be rejected.
1.2.b Any project or content submissions we feel are already excessively available to our development community may be held to higher quality standards during review. In extreme circumstances, if your content does not realistically offer anything unique, your submission may be rejected solely on these grounds.
1.2.c No aspect of a package will be allowed to promote or redirect users to other marketplaces or digital stores.
1.2.d Packages can not throw any generic errors after setup is complete. Any errors present in your projects should only be those that are from caught and handled exceptions.
1.2.e Asset submissions should perform and function as advertised without the need to download additional components from the same provider through distribution outside of the Asset Store.
1.2.f Submissions that include executables will be rejected. For more information about submitting Applications, please see 4.6 for more information.
1.2.g Assets with dependencies from Package Manager should only include the necessary packages for the asset to work. Use the “Include Dependencies” feature in the Asset Store Tools to include the packages.
1.3 Versions of Unity
1.3.a Submissions are tested on the most recent publicly available version of Unity. Your project will be required to meet all of our standards in that version of Unity or whichever version(s) your content is explicitly stated to be intended for.
1.3.b The version of Unity used to upload your package determines the version of Unity needed by customers to download or buy your package. We recommend that you upload your package from the earliest version of Unity that you know works with your package. You can download and install an earlier version of Unity from the Unity Download Archive. New assets should not be submitted through Unity versions earlier than 2018.4.0 LTS.
1.3.c If you are unable to make your package compatible across Unity versions, you can choose to upload your package using multiple versions of Unity. We require that you test your asset for compatibility with the latest released version of Unity before submitting to the Asset Store.
1.3.1.a Packages may not be submitted exclusively with beta versions of Unity unless they are specifically designed around features in that specific Unity beta version.
1.3.1.b Packages that are submitted with any beta version of Unity will be required to resubmit their product when a beta or release candidate is officially published to accommodate any changes or fixes.
1.3.1.c Packages submitted in a beta version of Unity must explicitly state in their description text which versions are supported.
1.4.a If you are an Online Service, such as a monetization service, ad-network, back-end hosting service, analytics system or other service where a variable amount of money changes hands after the user downloads your SDK or plugin, you may not upload your SDK or plugin. Services must register as an Asset Store Service in order to distribute on the Unity Asset Store. Services can register by filling this form. Service submissions that include non-proprietary content will be rejected unless non-proprietary content is a registered Asset Store Service or is under an open-source license that we support.
1.5 Inappropriate Content
1.5.a Any content that we deem to be defamatory or libelous will be rejected.
1.5.b Packages that we believe to be marketed or presented with the intention of being overtly violent, gruesome, or sexualized will be rejected.
1.5.c Submissions that display targeted hatred of any kind (Race/Religion/Gender/Identity/etc.) will be rejected.
1.5.d Base characters or Avatars are allowed to be completely nude under the condition that they are marketed and presented tastefully.
1.5.e Any models with detailed genitalia or internal anatomy will be rejected.
1.5.f Titles, descriptions, keywords, tags and other marketing material should not contain vulgar or abusive language
1.6 Malicious Content
1.6.a Submissions with functionality implemented to track or collect a user’s data will be rejected.
1.6.b Submissions that attempt to install any programs/viruses onto a user's computer or run any background services will be rejected.
1.7 Restrictive Content
1.7.a Submissions that include any DRM or functionality in place that restrict users from directly using content or features to their full extent will be rejected.
1.7.b Submissions that require a user to register, sign up or pay extra costs for a package to fully function will be rejected.
1.7.c Packages that include watermarks or otherwise obstruct the use of the product will be rejected.
1.7.d Packages that are only functional for a set amount of time or uses will be rejected.
1.7.e Submissions that have any artificial limits implemented on functionality or usability will be rejected.
1.8 Lite Products
1.8.a Any submissions that are trial or restrictive versions of products will be rejected. To familiarize users with your product, you may provide a ‘lite’ (smaller/cheaper/indie/free) version of your package. Lite and Free versions must not have limitations implemented on the functionality of your product’s features. Lite packages should only have a reduced set of features compared to your full product.
2. Preparing Your Product
2.1 Publisher Information
2.1.a Publisher information must be included and is expected to meet our standards. Any missing information will lead to your submissions being rejected. Required information includes profile picture, publisher name, website, promo media, promo paragraph, customer support contact, and customer support website.
2.1.b Publisher names must not violate any trademarks or brands.
2.1.c You may not insinuate from your publisher profile that you are an individual or public figure that you have no affiliation with.
2.1.d You may not insinuate from your publisher profile that you are affiliated with a company or organization that you have no connection with.
2.1.e Publisher descriptions must provide details about who you are as a professional and include information about your skills or specialties.
2.1.f Publishers must have and maintain an active website that shows relevant work and skill sets. Publisher websites should be built specifically as a portfolio page or utilize professional 3rd-party service such as ArtStation and etc. If we believe the website does not adequately represent you as a professional, we will reject your submissions.
2.1.g Publisher website pages are not allowed to include a redirect link.
2.1.h Publishers must provide and maintain an active customer support email.
2.1.i Publisher social media links should not include personal profiles
2.2 Product Titles
2.2.a Titles must be unique from any other live package on the Asset Store. Duplicate names will not be allowed.
2.2.b Titles should be a reasonable length and not exceed the area provided.
2.2.c Titles should not include your publisher name.
2.2.d Titles should not include extended descriptions of your packages.
2.2.e Titles should not convey that your package is affiliated with any company/product that you are not directly associated with.
2.2.f Each word in your title should lead with a capital letter followed by lowercase letters unless referencing a brand that does not conform to that structure.
2.2.g Titles should only use spaces to separate words without punctuation, unless conforming to an established brand.
2.2.h For legal and branding purposes, any packages starting with a brand name or inferring an affiliation with a brand will be rejected. I.e. ‘Tools for Unity’ is acceptable. ‘Unity Tools’ will be rejected.
2.3 Description Text
2.3.a The Curation Team will reject submissions with incorrect spelling/grammar in the description. This includes your package’s title, category, description text, tags and keywords.
2.3.b Description text should accurately cover all important aspects of your product including dependencies or other requirements for use of the asset.
2.3.c Description text for art assets should list out the number of unique assets included in your project. We also ask you to provide detailed information such as the average polygon count, texture size, and types of texture maps included for each asset.
2.3.d Description text for code assets should list out all key features of your product.
2.3.e All description text needs to be formatted properly with html tags. Submissions will be rejected if the product description looks like a single block of text. Use the below formatting tags to make the description easy to read and understand.
<br> - Line Break
<a href="/website">text</a> - hyperlinks
<strong></strong> - Bold
<em></em> - Italics
Packages using <p></p>, </br> or other unsupported tags may be rejected.
2.3.f All descriptions must be in English and have proper spelling/grammar. Excessive spelling/grammar issues will result in your submission being rejected.
2.3.g An English version of your description text is required but localized versions for other languages are allowed.
2.3.h All hyperlinks must be formatted correctly <a href="/website">text</a> and lead to active, non-malicious websites.
2.3.i Hyperlinks text should be adequately relevant to the link it leads to.
2.3.j Hyperlinks should only link to external sites, not direct downloads.
2.3.k Hyperlinks are not allowed to include a redirect link.
2.3.l Descriptions should not reference IP’s, brands, or trademarks that are similar to your product that you are not affiliated with.
2.3.m No aspect of your description text should promote or redirect users to other marketplaces or digital stores, unless allowed by Unity Technologies.
2.3.n Your description should only pertain to the content of the package. Your description text should not promote any other products unless they are an extension of your product, directly compatible with your product, or required for your product to function.
2.3.o Submissions promoting any “special offers” (free tutorial, free guidebooks, try before you buy, etc) will be rejected, as there is no system to oversee that offers are being responsibly fulfilled.
2.3.p You must post a notice within the description on the Asset Store that states the fact that your asset uses third-party software. For example:
"Asset uses [name of component] under [name of license]; see Third-Party Notices.txt file in package for details."
2.4 Key Images
2.4.a Having high-quality key images improves your packages marketing presence and is a substantial portion of being successful on the Asset Store.
2.4.b Key images that are not a clear representation of your content may be rejected.
2.4.c Key images should not be an unedited screen capture of your content inside the Unity editor or a digital photograph of your computer monitor.
2.4.d Key images that only have plain text will be rejected.
2.4.e Key images should not include excessive description text. Publisher name, asset title, and branding is acceptable within the images.
2.4.f Key image may not include any sale related graphics or banners.
2.4.g Including Icons of third party content that your product is compatible with will not be allowed if that logo’s brand guidelines are being violated or if any direct affiliation between your product and the third party content is being insinuated.
2.4.h Key images that attempt to recreate any official Asset Store sale or promotional graphics will be rejected.
2.4.i Key images should not include the Unity logo, unless allowed by Unity Technologies.
2.4.j Social Media Image should not have any text or logo overlays.
2.5.a Your package should be in the category that is most closely related to your product.
2.6 Tags and Keywords
2.6.a Tags and keywords should be relevant to your package.
2.7.a You are able to price your package at whatever price point you like. If we feel your content may be better priced in a different range, we will let you know. We suggest examining the pricing of similar assets on the store and following their example. Do not be afraid to ask for a high price for your package. It represents your hard work! Interestingly, the top-selling packages, in terms of quantity sold, are all over $50!
2.7.b Products that are hosted on other stores/marketplaces must match the price of your project on the Asset Store. Attempting to grossly undercut pricing of similar products is actively discouraged.
2.7.1 Personal Sales
Providing packages at a sale price is allowed but under the following circumstances. Failure to follow these guidelines may result in your product being disqualified from future official sale or promotional opportunities.
2.7.1.a Personal sales can not last longer than a two week period. Failure to restore your original price within two weeks may result in any mention of a sale being removed from your products details without notice.
2.7.1.b Sale periods should be separated by at least 2 months.
2.7.1.c Details of your sale must be provided in your description text. Sale period and regular price must be mentioned.
2.7.1.d You are not allowed to include any sale related graphics throughout your package’s imagery.
2.7.1.e You may not promote your product as being included in any sales or features hosted by Unity Technologies that you are not actually included in.
2.7.1.f To be considered for an official Unity organized sale, your package must maintain a consistent price for 2 months. A price increase due to a large update will not disqualify you from being included in a sale.
2.7.1.g After being included in an official sale, your package’s price must not be reduced for 6 weeks.
2.7.1.h New assets may begin on sale for the first two weeks of launch, as long as this sale is stated in the product description with the regular price listed.
3. Preparing your Content
3.1 Content Organization
3.1.a In order to keep the process of importing packages as clean as possible, packages should be nested under a folder with either your publisher name, or package name as the title. Exceptions include assets in the folders outlined in the Special Folders and Script Compilation Order documentation (e.g. "Gizmos" or "Editor Default Resources").
3.1.b Assets should be properly sorted into folders with English titles depending on their type (Mesh/Script/Material/etc). Packages should not have a range of file types included under a singular folder.
3.1.c To help users navigate your package and avoid unnecessary clutter, all duplicate, unused or redundant files must be removed from your project before submitting.
3.1.d Content should not be included under any folder named ‘AssetStoreTools’ or any variation of that name as that folder is automatically stripped while uploading your content.
3.1.e Your files must follow a consistent naming convention throughout your submission.
3.1.f Asset file names need to represent the content they are providing.
3.1.g Any incremental files should be appropriately named with proper number padding. I.e ‘asset01’ if you have over 10 assets, instead of ‘asset1’.
3.1.h File names should not be excessively lengthened with descriptors such as ‘High Quality’, ‘Low Poly’, ‘PBR’ etc. All details of your product should be left to your description text or keywords. File paths for assets should be kept under 140 characters.
An example of what we would expect for organized and properly named folders.
3.2.a All projects submitted to the Unity Asset Store that require information on how to set up and properly utilize your project, are required to have local documentation.
3.2.b Documentation file types must be in .txt, .pdf, .html or .rtf file types. In editor tutorials, inline documentation, and tooltips are appropriate as well.
3.2.c Documentation should be thorough and encompass all aspects of your project. If after reading through your documentation, there is not a clear understanding of how to use your product, you may be rejected.
3.2.d You are allowed to maintain more extensive documentation of your product online, but your documentation included in your project must include enough instruction for the user to understand the basic functionalities of your submission. Links to any online documentation must be mentioned at the beginning of your local documentation.
3.2.e Documentation must include a support email for users to contact you.
3.2.f Documentation must be in English and free from spelling/grammatical errors. You may include additional documentation that is localized in other languages alongside the required English documentation.
3.2.g Any video documentation or tutorials should be uploaded online (Youtube, Vimeo, etc.) and not included in your projects. A link to your video should be mentioned in your written documentation.
3.2.h Shader documentation must explain each shader property. Do not assume that the property names alone are enough for the user to figure out what it does.
3.2.i Documentation for server-based plugins (PHP, SQL, etc.) should assume users have a basic understanding of server hosting and setup. Your documentation only needs to be specific to setting up your plugin and how to use it.
3.3 Demo Scenes
3.3.a Most submissions should include a demo scene. If your product has content to show off, they should be displayed in a demo scene.
3.3.b Projects that include a collection of assets must include a scene that showcases all of their assets laid out in a grid or continuous line.
3.4 Compressed Files
3.4.a Submissions with .Unitypackage files solely to obscure or compress content will be rejected.
3.4.b Submissions that include set up preferences, settings or supplemental files for another Asset Store product must be nested in a .unitypackage file.
3.4.c .zip or .rar files will only be accepted if they are compressing files that do not natively function in the Unity editor. (I.e. Blender, HTML Documentation, Visual Studio Projects, etc.)
3.5 File Size
3.5.a Please Note: Users may experience problems importing large packages. Make sure all of your assets are as optimized as they can be or if applicable, your submission should be split into multiple packages to help prevent issues with users downloading your content.
3.5.b Due to technical restraints, submissions over 6GB will be rejected.
4. Content Specific Guidelines
4.1 Art Content
4.1.a Packages that do not hold a consistent artistic style may be rejected.
4.1.b Content submitted should display a certain degree of professional design and construction. Any assets that we do not believe could realistically be utilized in a development pipeline may be rejected.
4.1.c Mesh assets should be submitted as either .FBX or .OBJ. Procedural or other types of meshes generated at runtime are acceptable as well.
4.1.d All visible meshes are required to have a paired set of textures and materials assigned to them.
4.1.e Each mesh should have a corresponding prefab set up with all variations of the texture/mesh/material that you are providing.
4.1.f Submissions of untextured meshes solely for prototyping purposes will be rejected.
4.1.g Large environments or scenes must be broken up into individual meshes. Submissions with entire environments being included as one object will be rejected.
4.1.h Prefabs must have their position/rotation set to zero upon import, and should have their scale set to 1.
4.1.i All Meshes must have a local pivot point positioned at the bottom center of the object, consistently in a corner of any modular objects, or where the object would logically pivot/rotate/animate.
4.1.j All meshes should be rotated to have their positive Z facing forward.
4.1.k Meshes need to be at a 1 Unit : 1 Meter scale. A default Unity cube can be used for reference.
4.1.l Photoscanned data must be retopologized and optimized to a state that users could reasonably edit if needed before submission. Any meshes that are the direct result of scans will be rejected.
4.1.m Assets that have an unreasonably excessive mesh density will be rejected.
4.1.n Assets that appear to have their UV’s automatically unwrapped will be rejected.
4.1.o Mesh prefabs need to be set up with a collider component that fits your mesh.
4.1.1.a Character models must be weighted to an accompanying rig. The rig can either be set up with Unity’s Mecanim system or can include your own animations.
4.1.1.b When set to animations, rigs should not show any obvious creases or unusual deformations.
4.1.2.a Bipedal animations should be ready to use with Unity’s default “Humanoid” avatar.
4.1.2.b Projects of non-Bipedal animations need to include a demonstration mesh with a well documented rig breakdown so that users can create meshes designed for the animations.
4.1.2.c Animations need to be sliced and named prior to submission. Submissions with a single long animation clip will be rejected.
4.1.2.d Submissions including raw mocap data will be rejected. Any animations that are developed from mocap data need to be cleaned up into sliced and usable animations.
4.1.2.e Animations should have fluid movement without any jarring transitions.
4.1.2.f All animation asset submissions should have a video demonstration in their marketing material, showcasing the included animations.
4.1.2.g Animations for unique characters should be contained in their own prefab.
4.1.3 Textures & Materials
4.1.3.a Submissions that include .jpgs files will be rejected. Texture files need to be in a lossless compression format such as PNG, TGA, or PSD.
4.1.3.b Any package that is submitted and claims to be PBR, or that is using our Standard Shaders must include at least an albedo, normal, metallic (or specular) and smoothness texture map. For more information see our blog post on PBR in Unity.
4.1.3.c Tileable textures must tile without any seams or obvious edges.
4.1.3.d Maps with an alpha channel need to be paired with a material that can read said alpha.
4.1.3.e All imported materials that aren’t being used in your final product must be removed before submission.
4.1.3.f Normal maps need to be marked as a “Normal Map” in the import settings.
4.1.3.g Content intended to be run on mobile or lower-end hardware should have atlased textures in order to reduce performance impact.
4.1.3.h Assets should not have an excessive number of materials assigned to them.
4.1.3.i .SBSAR and other procedural materials need documentation or a demo scene showcasing the parameters included.
4.1.3.j Dimensions of textures should be pixel counts that are a power of 2 when appropriate.
4.1.3.k Materials should include all appropriate textures and be properly set up.
4.1.4.a All sprite sheets must be imported with the “Sprite” import settings.
4.1.4.b Sprites need to be properly sliced and named using the import settings.
4.1.4.c Sprite animations need to be spliced, named and set up as proper clips before submission.
4.1.5 Gui Packs
4.1.5.a Submissions of GUI packs must include a functional demonstration scene that showcases all of the components being usable.
4.1.5.b GUI components need to have their elements separated and named either before import or through our sprite editor settings.
4.2 Particle Systems
4.2.a Particle systems should be saved as a prefab for customers to easily drag and drop into their scene.
4.3.a Scripts should not throw any compiler or generic errors. Any potential errors must be properly caught and presented to the user through the debug log.
4.3.b All submitted code must be commented and readable with no spelling/grammatical errors.
4.3.c Code comments must be in English. You may include code comments in other languages alongside the required English comments.
4.3.d Commented code is not an alternative to proper documentation.
4.3.e Functions and variables should be named appropriately.
4.3.f Scripts must include namespaces within which all named entities and identifiers must be declared.
4.3.g Assets that support Android builds should target 64 bit architecture
4.3.1 Editor Extensions
4.3.1.a Editor extension file menus must be placed under an existing entry. If no existing menus are a good fit, you can place it under a custom menu titled "Tools". This keeps the editor clean and organized.
Example of an ideally nested Editor Extension
4.3.1.b Undo operations must be supported. Refer to the Unity documentation for information about Undo Support
4.3.1.c We allow unique windows to be created for practical support or informative purposes. Submissions with any unique windows that we feel are created for spamming purposes or distract the user’s workflow may be rejected.
4.3.2 Server-Based Plugins
4.3.2.a Submissions that are utilizing a Server-Based Plugin must automatically populate any new databases with necessary tables.
4.4 Complete & Template Projects
4.4.a Complete and Template Projects should be designed as instructional, tutorial or framework products.
4.4.b Complete project’s documentation must include in-depth information about how the project is designed and how users can edit and expand on your project. Your documentation must explain more than just how to run the project.
4.4.c If we believe a package is a compilation of found content/products or the direct result of public tutorials, it will likely be rejected.
4.4.d If we believe a package has been designed with the sole purpose to directly recreate a popular game’s design, art style and aesthetic, it will likely be rejected. Products should offer some unique aspect to our development community and should not violate any copyright protections.
4.4.e If you have published a game and are interested in releasing/selling your source project, please keep in mind that purchasers of your product are technically allowed to directly build and sell that project commercially. To avoid users impacting your game’s success by directly submitting your game to marketplaces such as Google Play, App Store, Steam, etc, you should maybe consider replacing your art with professional but generic placeholders.
4.4.f The Project Settings of your project will be automatically included with any submission being uploaded in the “Complete Projects” category or subcategories. Users will receive a notification that their Project Settings will be replaced when importing your project.
4.5.a All audio asset submissions must link to a preview web server or service such as SoundCloud™.
4.5.b Audio files must be normalized before submitting.
4.5.c Audio files must play properly inside the Unity inspector.
4.5.d Submissions of audio collections must maintain a consistent format, naming convention, and quality.
4.5.e Submissions must only include supported Unity audio formats. For more information on supported formats, please see Unity's Audio File Documentation
4.5.f Due to its lossy compression, we will reject submissions with only mp3 versions of their content. We recommend using a lossless format for audio files such as .wav files.
4.6.a Until further notice, the Asset Store is not accepting any Applications. (For now all content on the Asset Store is required to operate within the Unity Editor and we are not taking third party tools/applications. If you are interested in providing your product that is an application on the Asset Store, please contact AssetStore@unity3d.com)
5. Outro/Support message
We appreciate you reading through these guidelines in their entirety! If you have an issue with a specific package of yours that has been either accepted or declined, reply directly to that email and you will be able to get in contact with the team member who vetted your package. If you are having any other issues regarding your submission, package, or publisher account, please email AssetStore@unity3d.com to open a support ticket. Please include as much information as possible in your email, so that our support team can better help resolve your issues.