Native Client

Distributing Your Application

This document describes how to distribute Native Client applications through the Chrome Web Store (CWS).

Introduction

Chrome Web Store

At this time Native Client is only enabled by default for applications distributed through the Chrome Web Store (CWS). That means that Native Client applications must be distributed through the Chrome Web Store. The CWS requirement is in place to prevent the proliferation of Native Client executables (.nexe files) compiled for specific architecures (e.g., x86-32 or x86-64). The Native Client team is hard at work on Portable Native Client (also known as "PNaCl"), a technology that enables processor-independent executables. When PNaCl is available, Native Client will be enabled in Chrome for all pages and web apps, including those distributed outside the Chrome Web Store.

The Chrome Web Store provides a number of benefits, such as reaching a large number of potential customers, making it easy for users to discover your applications, and providing a way to earn revenue from your applications. You can upload your applications to the CWS for free, and distribute them for free or for payment.

CWS application types

Before you upload an application to the Chrome Web Store, you must choose how you want to distribute the application. The CWS can be used to distribute three types of applications: hosted applications, packaged applications, and extensions.

  • A hosted application is an application that is hosted somewhere other than the Chrome Web Store (such as your own web server or Google App Engine). The CWS only contains metadata that points to the hosted application.
  • A packaged application is an application that is bundled into one file, hosted in the Chrome Web Store, and downloaded to the user's machine.
  • An extension is similar to a packaged application—the application is bundled into one file, hosted in the Chrome Web Store, and downloaded to the user's machine—but the application is specifically designed to extend the functionality of the Chrome browser.

The main factors to consider in choosing between these application types are:

hosting
You must make your own arrangements to host a hosted application (and pay for hosting services). Packaged applications and extensions are hosted in the Chrome Web Store.
size
Hosted applications do not have a size limit; packaged applications and extensions are limited to 100 MB in size.
behavior
Hosted applications and packaged applications are like normal web applications (they present their main functionality using an HTML page); extenstions can add functionality to the Chrome browser.

For help choosing how to distribute your application, refer to Choosing an App Type.

The next section of this document provides details about how to distribute each type of application.

Distribution details

Hosted application

A hosted application is a normal web application with some extra metadata for the Chrome Web Store. Specifically, a hosted application consists of three parts:

  1. A Chrome Web Store manifest file (manifest.json) and an icon uploaded to the Chrome Web Store. The manifest file points to the Native Client application, essentially a web site, hosted on your web server. You must put the CWS manifest file and the icon into a zip file for upload to the Chrome Web store, and then convert that file to a special zip file with a .crx extension. Refer to the Chrome Web Store Tutorial: Getting Started or to the Hosted Apps documentation for information about how to create and upload this metadata to the CWS.
  2. All the regular Native Client application files. These files are hosted on your web server or Google App Engine at a location pointed to by the CWS manifest file.
  3. Binary assets. These files are hosted on your web server, Google App Engine, or Data Storage for Developers.

Hosting options

Google offers a couple of hosting options you might consider instead of your own:

  • Google App Engine allows developers to release their applications on the same platform that Google uses for applications such Gmail. Refer to Google App Engine - Pricing and Features for pricing information.
  • Google Storage for Developers allows developers to store application data using Google's cloud services and is available on a fee-per-usage basis. Refer to Pricing and Support for pricing information.

Additional considerations for a hosted application

  • The .html file, .nmf file (Native Client manifest file), and .nexe files (compiled Native Client modules) must be served from the same domain, and the Chrome Web Store manifest file must specify the correct, verified domain. Other files can be served from the same or another domain.
  • In the description of your application in the CWS, make sure to mention that your application is a Native Client application that only works with the Chrome browser. Also make sure to identify the version of Chrome that your application requires.
  • Hosted and packaged applications have a "launch" parameter in the CWS manifest. This parameter is present only in apps (not extensions), and it tells Google Chrome what to show when a user starts an installed app. For example:
    "launch": {
      "web_url": "http://mail.google.com/mail/"
    }
  • If you want to write local data using the Pepper FileIO API, you must set the 'unlimitedStorage' permission in your Chrome Web Store manifest file, just as you would for a JavaScript application that uses the HTML5 File API.
  • You can place your application in the Google Web Store with access only to certain people for testing. See Publishing to test accounts for more information.

Packaged application

A packaged application is a special zip file (with a .crx extension) hosted in the Chrome Web Store. This file contains all of the application parts: A Chrome Web Store manifest file (manifest.json), an icon, and all of the regular Native Client application files. Refer to Packaged Apps for more information about creating a packaged application file.

Once you have a CWS manifest file and an icon for your application, you can zip up all the files for your packaged application into one zip file for upload to the Chrome Web Store. Refer to Step 5 of the CWS Getting Started Tutorial to learn how to zip up your packaged application and upload it to the Chrome Web Store.

Additional considerations for a packaged application

  • In the description of your application in the CWS, make sure to mention that your application is a Native Client application that only works with the Chrome browser. Also make sure to identify the version of Chrome that your application requires.
  • Hosted and packaged applications have a "launch" parameter in the CWS manifest. This parameter is present only in apps (not extensions), and it tells Google Chrome what to show when a user starts an installed app. For example:
    "launch": {
      "web_url": "http://mail.google.com/mail/"
    }
  • If you want to write local data using the Pepper FileIO API, you must set the 'unlimitedStorage' permission in your Chrome Web Store manifest file, just as you would for a JavaScript application that uses the HTML5 File API.
  • For packaged applications, you can only use in-app purchases.
  • You can place your application in the Google Web Store with access only to certain people for testing. See Publishing to test accounts for more information.

Extension

An extension consists of a special zip file (with a .crx extension) hosted in the Chrome Web Store containing all of the application parts: A Chrome Web Store manifest file (manifest.json), an icon, and all of the regular Native Client application files. Refer to the Google Chrome Extensions Overview to learn how to create an extension.

Once you have a CWS manifest file and an icon for your application, you can zip up all the files for your packaged application into one zip file for upload to the Chrome Web Store. Refer to Step 5 of the CWS Getting Started Tutorial to learn how to zip up your extension and upload it to the Chrome Web Store.

Additional considerations

Registering Native Client modules to handle MIME types

If you want Chrome to use a Native Client module to display a particular type of content, you can associate the MIME type of that content with the Native Client module. Use the nacl_modules attribute in the Chrome Web Store manifest file to register a Native Client module as the handler for one or more specific MIME types. For example, the bold code in the snippet below registers a Native Client module as the content handler for the OpenOffice spreadsheet MIME type:

{
   "name": "My Native Client Spreadsheet Viewer",
   "version": "0.1",
   "description": "Open spreadsheets right in your browser.",
   "nacl_modules": [{
      "path": "SpreadsheetViewer.nmf",
      "mime_type": "application/vnd.oasis.opendocument.spreadsheet"
   }]
}

The value of "path" is the location of a Native Client manifest file (.nmf) within the application directory. For more information on Native Client manifest files, see Files in a Native Client application.

The value of "mime_type" is a specific MIME type that you want the Native Client module to handle. Each MIME type can be associated with only one .nmf file, but a single .nmf file might handle multiple MIME types. The following example shows an extension with two .nmf files that handle three MIME types.

{
   "name": "My Native Client Spreadsheet and Document Viewer",
   "version": "0.1",
   "description": "Open spreadsheets and documents right in your browser.",
   "nacl_modules": [{
     "path": "SpreadsheetViewer.nmf",
     "mime_type": "application/vnd.oasis.opendocument.spreadsheet"
   },
   {
      "path": "SpreadsheetViewer.nmf",
      "mime_type": "application/vnd.oasis.opendocument.spreadsheet-template"
   },
   {
      "path": "DocumentViewer.nmf",
      "mime_type": "application/vnd.oasis.opendocument.text"
   }]
}

The nacl_modules attribute is optional—specify this attribute only if you want Chrome to use a Native Client module to display a particular type of content.

Using CWS inline install

Once you've published an application, you may be wondering how users will find and install the application. For users who browse the Chrome Web Store and find your application, installing the application is a simple one-click process. However, if a user is already on your site, it can be cumbersome for them to complete the installation—they would need to navigate away from your site to the CWS, complete the installation process, and then return to your site. To address this issue, you can initiate installation of applications "inline" from your site—the applications are still hosted in the Chrome Web Store, but users no longer have to leave your site to install them. See Using Inline Installation for information on how to use this feature.

Monetizing applications and extensions

Google provides three primary monetization options for Native Client applications: in-app payments, one-time charges, and subscriptions. Refer to Monetizing Your App to learn about these options. The Chrome Web Store Overview also has information on different approaches to charging for your application.

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.