Summary: This article outlines the general preparation and technical requirements needed for Flutter items.
Table of Contents
Technical Requirements
- The ZIP must include at least one Flutter project folder.
- The Main Preview Image needs to be of good quality and appealing to buyers, preferably containing the illustrative icons of the frameworks used in the item, or with good quality screenshots *and* striking design background (not only screenshots).
- The item preview must include screenshots of the real app.
- It is important that you have screenshots of all item screens, *without scrolling* recommended (vertical: 460 x 900; horizontal: anything with an aspect ratio of 16:9).
- The item description must list and link to any API used. Make sure to add the main feature. In addition, striking titles are important.
- The item must include offline documentation with steps for:
- setting up,
- running,
- renaming,
- renaming the package,
- changing the logo, and
- basic project edits.
If the item uses an API, the documentation must include instructions for changing the API key by buyers. Please also include images and links if necessary.
- Make sure all images are properly licensed for commercial use.
- Make sure to follow the Envato Guidelines for Excellent Titles, Descriptions and Tags for item titles, descriptions, and tags.
-
When submitting a new project make sure it has a logical folder structure with individual folders for:
- models,
- blocs,
- reducers,
- providers,
- widgets,
- utils,
- pages, and
- screens.
- The folders that contain the project’s package dependencies to run must not be included in the uploaded file, since these can be easily downloaded again.
- Make sure to use lists, and grids must use lazy loading to display the data. Use the builder methods of container widgets to do this. (e.g., `Listview.builder()`)
See more information in the official docs here:
- When the widget tree gets big enough you must use a state management alternative when sending data from a parent widget to its grandchildren or vice versa. Consider using bloc, redux, provider, inherited widget, etc.
- We do not recommend making the main.dart too extensive or bloated. Consider declaring routes, themes and other initial configuration variables in separate files to shorten the main file.
- Use “flutter analyze” to track down common issues as the review team will run it first and items with obvious issues will be rejected right away.
- If your project needs an API, Firebase or similar, please include a quick way to test the integration with the app.
Documentation Requirements
- Every item in CodeCanyon requires a basic documentation file to help customers use your item.
- The documentation must be written in English with basic information about how to use or customize the template and formatted as PDF or HTML.
- The file structure of your template must be documented, preferably with screenshots and descriptions.
- All necessary credits & resource URLs must be included (e.g., for any 3rd party fonts, images, etc. used in the template and/or item preview).