Google's Extension Publishing Process

•  Extensions are mini-programs that can tailor a browsing event.
• These small programs allow users to tweak the functionality and features of Chrome to suit their personal requirements. These extensions are developed using web programming languages such as HTML, JavaScript, and CSS.
• Extensions are made available through the "Chrome Developer Dashboard" and published through the "Chrome Web Store."
• Prior to publishing a Google Chrome Web store extension, it has to be run locally and tested first.  
• The loading and testing process steps are shown in the sample "Hello extensions" loading and testing process.
• As soon as the Chrome extension has all the necessary elements such as the manifest, instructions, user interface, layer logic, user options, and others, loading and testing can start.
• The extension can then be loaded into a local computer by going to "chrome://extensions in the Chrome browser." The box next to the "Developer Mode" option will then need to be ticked. Next, the "Load Unpacked Extension" will then need to be clicked. Once done, the directory where the extension is located need to be selected.
• The extension can then be tested to check if it is running correctly on the local computer. The features of the extension will also need to be evaluated if working as designed.  
• Once the testing is completed, the extension can now start to undergo the process of being published in the Chrome Web Store.
• In a nutshell, the steps to publish the extension in Chrome are the following:

•  Creation of the extension's zip file 
•  Creation of a developer account 
•  Extension file upload  
•  Addition of assets  
•  Submission for publishing 

Creation of the Extension's ZIP file

•  Create a ZIP file that includes all the files associated with the extension.
• The extension's manifest file needs to be in the ZIP file and it must have the following fields at the minimum:
•  "name": — name shown in the Chrome Web Store and in the Chrome browser
•  "version": — Metadata version, incremented
• "icons": — An array indicating the icons that the extension will be using
• The ZIP file may also contain other graphics and files that the extension needs.
• The components of the ZIP file and the manifest will also be based on the specifics of the extension as indicated in the extension file guide.
• It is recommended that the initial version number in the manifest be set at a low value (ex. 0.0.0.1).  
• This is to provide more leeway for the version number to increase once updates to the extension need to be loaded.
• If the extension utilizes Native Client, the "application directory hierarchy and the ZIP file" can be arranged strategically to minimize the size of the user download bundle.  

Creation of a Developer Account

• Before an extension on the Chrome Web Store can be uploaded, a user needs to create first a developer account on the site.
• The user will then need to access the developer console, register as a "CWS developer, pay a one-time registration fee," and agree to the terms and conditions.
• If the extension is already in Google Play, there is also an option to have an "Available for Android" text on the Chrome Web Store listing. This can be made possible by ensuring that the extension has the same name on both sites. The developer account used should also be the same.

Extension File Upload and Addition of Assets

• Once the steps above are complete, the extension ZIP file can now be uploaded using the Chrome Developer Dashboard.
• If an item ID is required to complete the item's code, then the extension files need to be uploaded while the code is still being written. If there is no need for the item code, the upload can proceed as planned. The extension files can be uploaded several times before sending them for review.
• Once all the files for upload are ready, the developer can sign in to his or her developer account on the Chrome Developer Dashboard.  
• Once signed in, the developer can click on the "add new item button."  
• After this, the following path needs to be followed: "choose file, select the extension zip file, then click upload."
• If the extension program's manifest and ZIP files are acceptable, the developer can further edit the extension on the succeeding page.

Submission for Publishing

• Once the extension files are uploaded, it can now be seen on the Chrome Web Store dashboard: 

 

Source

 

• The developer will then need to complete the additional listing information before the extension can be submitted for publishing.
• There are four tabs that need to be reviewed and completed.
• The Package tab shows the details of the uploaded extension. The page's fields are grayed out and cannot be edited when the developer first creates an extension entry.
• The Listing tab indicates the details of the extension and how it will appear on the Chrome Web Store.
• The Privacy tab needs to be updated with how the extension handles privacy and security matters.
• The Pricing and Distribution tab allows the developer to indicate the countries that can list the extension and which segments can see it.

• Before publishing the item, the details above need to be completed first.
• Once done, the developer can hit the "Submit for Review" button.
• The dialog shown below will then pop up to confirm if the developer wants to proceed with the review submission.

 

Source

 

• The confirmation popup above can also allow the developer to modify the publishing timing.
• If the checkbox will not be ticked, the extension will not be published as soon as the review is done. The developer can then have the option to publish manually based on his or her preferred timing after the review is completed.
• After the extension is sent for review, the review process will commence. The timing for the review process will be based on the nature of the extension.
• The review completion timing ranges from a few hours to several weeks depending on whether the extension has some elements that might be against Google's standard policies. Other reasons for review delays revolve around powerful permissions that need a thorough review.
• New submissions and updates to current listings will all need to undergo the same review procedure.  

Best Practices when Publishing Extensions (What to Do?)

•  Extensions should deliver a single objective that is sharply defined and simple to grasp.
• These small programs can have several components and various features but they need to harmonize with the overall purpose of the extension.
•  User interfaces should be kept to a minimum. These should also have a definite purpose. These extensions can appear as a simple image like the Google Mail Checker extension. They can also be activated to dominate an entire page.
• Extension files are compressed into one .crx bundle that the users can download and install. This signifies that these extensions are independent of any content from the web as opposed to web apps.
•  Google also recommends using the group publisher in the Chrome Web Store to enable better coordination between extension owners.
• The group should be set to private and seen only by those who are authorized to publish the extension.
• If the group publishing option is not feasible, corporate emails can be used to publish extensions. Personal email addresses should not be used for this purpose to avoid problems when someone in the group leaves the company.
• Avoid filtering emails to ensure that any communication about the extension such as take downs or violation notices can be readily seen and acted upon.
• Developers would also need to configure a strong two-factor authentication security setup on all the accounts involved. The advanced protection program can be used as well.
• Developers are also advised to regularly update their extension code paths to ensure that they can comply with the updated security and privacy guidelines. New Chrome releases should be regularly monitored as well.

Watch-outs When Publishing Extensions (What Not to Do)

• Developers should not have more than 20 apps and extensions published on the "Chrome Web Store." If a higher quantity is needed, developers can request for the limit to be increased.
• The extension should not contain any malware or unwanted programs.  
• It should not go against the developer program policies.  
•  Extensions should not be resubmitted if they have been taken out of the Chrome Webstore in the past due to a legal or policy wrongdoing.
• Due to the recent changes to the Google Chrome Web Store policy to fight against scams, developers will need to strictly comply with these new guidelines to prevent their extensions from being removed from the store.
• Developers should not publish extension duplicates that perform the same function. Each of their extensions should have a unique purpose.
• They should also avoid inputting excessive and misleading information in any part of these extensions. Since testimonials from unknown people are not permitted, developers should veer away from adding testimonials in the extension description.
•  Excessive keywords are not allowed to prevent spamming.
• Adding reviews that are inauthentic and putting counters to artificially increase ratings are also practices that are not allowed.
• Developers should ensure that data requests from their users should be very minimal to comply with Chrome's new privacy policy. This practice can also establish user trust.
• They should also ensure that the extension's privacy policy is just within reach to enable rapid decisions within difficult situations.
• Developers should also thoroughly check the open-source codes that are being used for their extensions. Hackers might be able to penetrate the programs and insert doubtful codes.