NOTE: The timeline has been updated, please see our October 2021 post for more details.

In January 2020, we announced that we are expanding our phased approach for ending the support of Chrome Apps. That announcement was made due to significant progress of the modern Web and its ability to deliver first class user experiences for users. We continue to invest in rich new capabilities on the Web platform and are committed to pushing the Web forward.

Based on feedback from our customers and partners, we are making the following adjustments to the Chrome app support timeline, with modifications highlighted in bold:

Scheduled Date	Action
March 2020	Chrome Web Store stopped accepting new public Chrome apps. Developers will be able to update existing Chrome apps through June 2022. Enterprise administrators may continue to submit new private and unlisted Chrome apps to the Chrome Web Store.
June 2021	General support for Chrome Apps on Windows, Mac, and Linux will end June 2021. Organizations will be able to use a policy setting to extend support on Windows, Mac, and Linux through June 2022.  General support for Chrome Apps on Chrome OS will remain enabled, without requiring any policy setting, through June 2022.
June 2022	Chrome Web Store will stop accepting new and updated private and unlisted Chrome apps. End support for Chrome Apps, NaCl, PNaCl, and PPAPI for all platforms.

This change does not impact support for Chrome Extensions. Google will continue to support and invest in Chrome Extensions on all existing platforms. Fostering a robust ecosystem of extensions is critical to Chrome's mission and we are committed to providing a useful extension platform for customizing the browsing experience for all users. 

For additional support with Chrome app migration, please visit our Chrome Apps migration site. This page will be kept up to date as we progress together through this process.

We thank our community of developers who have provided feedback to help us shape this modified and simplified approach. We are inspired by a future beyond Chrome apps, where the ecosystem continues forward progress leveraging open Web standards across all modern browsers.

Posted by Anthony Laforge, Technical Director, Chrome Platform Team

Note: The timeline has been updated, please see our October 2021 post for more details.

The web platform has made substantial progress since the launch of Chrome Apps in 2013. As community members, we continue to work with other browsers and invest to bring rich new capabilities to the platform, as seen in the announcements made at the Chrome Developer Summit last November.

The progress of modern browsers puts the Web in a good position to answer the vast majority of use cases - evident in the success of companies like Figma and our own products like Google Earth. We are confident that the Web can deliver first class experiences on an open platform.

With this continued progress, we are expanding upon our earlier announcement and will begin phasing out support for Chrome Apps across all operating systems as follows:

• March 2020: Chrome Web Store will stop accepting new Chrome Apps. Developers will be able to update existing Chrome Apps through June 2022.
• June 2020: End support for Chrome Apps on Windows, Mac, and Linux. Customers who have Chrome Enterprise and Chrome Education Upgrade will have access to a policy to extend support through December 2020.
• December 2020: End support for Chrome Apps on Windows, Mac, and Linux.
• June 2021: End support for NaCl, PNaCl, and PPAPI APIs.
• June 2021: End support for Chrome Apps on Chrome OS. Customers who have Chrome Enterprise and Chrome Education Upgrade will have access to a policy to extend support through June 2022.
• June 2022: End support for Chrome Apps on Chrome OS for all customers.

This change does not impact support for Chrome Extensions. Google will continue to support and invest in Chrome Extensions on all existing platforms. Fostering a robust ecosystem of extensions is critical to Chrome's mission and we are committed to providing a useful extension platform for customizing the browsing experience for all users.

For additional details (e.g., timelines, recommendations, a FAQ, etc.) please visit our Chrome Apps migration site. This page will be kept up to date as we progress together through this process.

On behalf of the Chrome team, we thank the community of developers for building great experiences using Chrome Apps and look forward to seeing similar experiences that leverage open Web standards (e.g., PWAs) across all modern browsers.

Posted by Anthony Laforge, Technical Director, Chrome Platform Team

Event pages keep apps and extensions efficient by allowing them to respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if you need to respond to something that occurs outside of Chrome, such as a news alert, a message sent to a user or a stock hitting a price threshold? Until now, you had to do this by repeatedly polling a server. This process consumed bandwidth and reduced the battery life of your users’ machines. For a more efficient solution, starting today you can use Google Cloud Messaging for Chrome (GCM) - across all channels of Chrome.

GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:

1. Request a token (channel ID) via chrome.pushMessaging.getChannelId(). 
2. Pass the returned token to your server. 
3. Whenever you need to send a message to your app or extension, post the message along with the token to the GCM server-side API. 

Your message is then delivered in near real time to Chrome. This makes your event page wake up (if it’s not already running), and the message is delivered to your chrome.pushMessaging.onMessage listener.



To use GCM, your users must be signed into Chrome, as the service relies on an efficient push channel that’s only established for signed-in users. Messages are automatically delivered to all the devices where the user has signed in and installed your app/extension.

To add GCM to your app/extension, take a look at the overview of the service or start with some of the sample apps—and start pushing!

Posted by Mark Scott, Product Manager

Last year, Chrome introduced manifest V2 to Apps and Extension developers, which brings a variety of security and API improvements such as a default Content Security Policy. As of Chrome 18, manifest V1 was officially deprecated. At the time, we published our manifest version support schedule to give developers transparency and insight into our plans for migrating to the new version.

Today, we’re announcing a slight update to that schedule, to let developers know that they have until Monday, March 4, 2013 to make updates to their existing manifest V1-based items. After that date, the Chrome Web Store will block all updates to products based on manifest V1 unless the update includes switching it to manifest V2.

Developers are strongly encouraged to migrate their items to manifest V2 now. Follow the migration tutorial, and you can always contact us on the chromium-apps forum and our G+ page with any questions you may have.

Posted by Joe Marini, Developer Advocate

Many popular applications today help users consume, share, manage, and edit media content, as evidenced by the rise of web apps like Google Play Music and YouTube. For Chrome packaged app developers, the new Media Galleries API introduces a simple way for apps to access media stored on a user’s device (with the user’s permission, of course).

To use the API, you first have to determine what kind of permission your app needs to access user’s media:

• read-only: allows media content to be read, but not modified 
• read-write: allows media content to be read and modified 
• add-files: allows media to be added to the galleries but prevents modifying existing media files. 

Currently, only read-only access is supported. Support for read-write and add-files will be introduced in a future release.

To retrieve media content, use getMediaFilesystems(). If this is the first time your app is accessing the user’s media libraries, the system will prompt the user to grant access:



You can also make your app explicitly ask the user to designate specific galleries. This is useful if, for example, your app is only interested in pictures. Once access is granted, your app can then retrieve a list of LocalFileSystem structures. At that point, you can use the W3C FileSystem API to access the media gallery content.



NOTE: The file system APIs will only return files that the Chrome platform natively supports, and only the asynchronous version of the FileSystem API is currently supported.

We’re eager to see what great applications you will build with the Media Galleries API and the Chrome Packaged Apps platform. To get started, clone our samples repository and look at the Media Galleries sample application. Have questions or comments? Subscribe to chromium-apps and follow us on our Google+ page!

Posted by Joe Marini, Developer Advocate