Hey everyone.
My name is Mike Tsao, and I'm on the Chrome Apps team.
I'm here to tell you what's happened
with the platform since I/O 2013,
and why it makes sense for you to write a Chrome app.
But first a refresher-- why'd we build the Chrome Apps platform
in the first place?
The answer is simple.
We're the Chrome team.
We love the web.
HTML, CSS, and JavaScript make a pretty awesome browser
platform.
And we wanted to use that platform outside the browser.
For us that meant three things.
Unlocking additional capabilities that
aren't available to normal web pages,
making web apps as discoverable and sticky as native apps,
and doing all this while preserving
and even improving upon the amazing reach of today's web.
This is what Chrome apps offer you as a developer.
Chrome apps capabilities fall into three groups.
Immersive UI gives you the developer complete control
over your applications appearance,
all the way from window size and position
to full screen with pointer lock.
Your apps also have low level access to device hardware,
such as USB, Bluetooth, and raw sockets.
And our offline by default model ensures
that your users will always be able to launch
your app regardless of connectivity.
Again, through standard web technology,
immersive UI that has powerful hardware access and runs
offline.
That's the core of what you get with the Chrome Apps platform.
Now building a powerful Chrome app is easy,
but how do you get it to your users?
We offer a distribution flow that's
familiar to any mobile user.
The Chrome Web Store takes care of listing, discoverability,
ratings, reviews, purchasing, and installation.
Just upload your app and we'll take care of the rest.
After your users have installed your app,
the Chrome App Launcher provides a convenient surface
for your users to return to it.
The App Launcher is familiar to any user
of other mobile or desktop OSs.
And just in case your users forget to launch your app,
rich notifications remind users of important events
even if your app isn't running.
The Chrome Web Store App Launcher and rich notifications
take care of distribution and user retention,
letting you focus on making a great app.
OK, you've written an immersive and capable offline Chrome app.
You're using the Chrome Web Store to distribute it.
The App Launcher and rich notifications help
keep up your active user account.
But exactly who can you reach with your Chrome app?
This is easy.
If a device can run Chrome, it can run your Chrome app
as well.
Chrome apps are available on every desktop OS supported
by Chrome.
Through the Apache Cordova project,
you can deploy your Chrome app in iOS and Android as well.
And thanks to app_shell, the Chrome Apps platform
will soon have a reach even greater than Chrome.
I'll come back to app_shell in a bit.
All right, so now you understand what the Chrome Apps platform
is.
And if you haven't yet seen Erik Kay's State of the Union talk
from I/O 2013, that's still a great reference.
But I wanted to talk about what's changed since then.
There have been quite a few exciting developments.
First of all, shortly after I/O 2013,
we officially launched Chrome apps
for all supported desktop platforms, giving
your apps the same reach that Chrome
has on Windows, OS X, Chrome OS, and Linux.
Next, we officially launched mobile Chrome apps on Cordova.
Apache Cordova implements the Chrome Apps platform
for iOS and Android.
Both these ecosystems have their own distribution mechanisms,
and Cordova helps you package your app accordingly.
Between Chrome and Cordova, your Chrome app
has incredible distribution and reach
across all major desktop and mobile platforms.
Check out our other I/O presentations this year
to learn more about mobile Chrome apps.
Now, the initial September 2013 launch had some minor caveats.
I'm happy to report that we've taken care of many of them
since then.
First and foremost, the Chrome Apps platform
is at feature parity across all four desktop operating systems,
including most recently App Launcher and rich notifications
on Linux.
The Chrome team has made architectural changes
under the hood that will make it easier
for us to continue rolling out new platform
features on all desktop operating systems
simultaneously.
In addition to reaching feature parity,
we've also improved our suite of platform capabilities.
Managed in app payments handles licenses
you sell for digital goods in your Chrome app.
Free trials allow you to explore freemium models for your app.
The new unified Google Cloud Messaging API, or chrome.gcm,
is now in stable channel.
If you've already rolled out an Android GCM based product,
is now much easier for you to include the equivalent
functionality in a Chrome app.
We've added better media scanning capabilities
to the media gallery API, which ensures that your apps will get
appropriate access to more user media files.
We've completely revamped many of our hardware access APIs
to work properly with Chrome event pages,
in the process making your code simpler, more efficient,
and significantly faster.
The sync file system API now has directory support,
giving your Chrome app a fully featured sandbox
subset of the user's Google Drive.
And finally, for those cases where a sandbox just won't do,
Chrome apps can communicate directly
with native applications through native messaging.
These are just some of the improvements
we've made to the core platform in the last year.
Check out our developer documentation
to get the complete set.
Of course, more platform features are always welcome,
but a good platform needs good developer tools as well.
While we're big fans of the diversity of tools
and technologies available to web developers,
it's also a good idea to provide a well lit path that
helps beginner and intermediate developers
fall into the pit of success.
That's why we've been working on a couple Chrome apps of our own
specifically designed to improve the developer experience.
First is Chrome Apps and Extensions Developer Tool.
This is what we've always wanted chrome:extensions to become.
If you're developing a Chrome app or extension and have been
using chrome:extensions in developer mode, give it a try.
The work flows much better.
Next is a project code named Spark.
It's a code editor for Chrome apps and web apps.
With Spark and a machine that runs Chrome,
you have everything you need to publish your own Chrome
app on Chrome Web Store.
The Spark team is unveiling their developer preview at I/O,
and I encourage you to check out their talk.
OK, great.
Now you're up to speed on Chrome apps as of today.
So what's next?
We generally don't talk about unannounced products,
but because Chromium is an open source project,
I can help direct your attention to recent source code changes
that you might find interesting.
Disclaimer-- many of these changes
represent experiments that might or might not
ship depending in part of your feedback.
So please try them out and let us know what you think.
Earlier I mentioned stickiness.
In most cases it's a good thing to encourage your users
to return to your app after initial launch.
But what if your app really isn't meant to be sticky?
What if your app is associated with a calendar
event or a sight seeing location?
What if your app is so lightweight
that the installation step is a burden?
Ephemeral Chrome apps have a simpler life cycle
that optimizes the installation and removal steps.
The vision is simple.
Make installation optional, replacing the Add button
with Launch.
Several versions of this experiment are available now
on chrome:flags.
Back to the core of the platform,
we're expanding and improving hardware support
and improving existing functionality based on feedback
from app developers.
If you've tried out the Chrome Apps USB API,
there's a good chance you've run into a roadblock
that it can't see devices describing themselves
in whole or in part as HID class.
To clear this roadblock, we have a new USB HID
API in dev channel now for Windows and OS X.
And we're working on Linux and Chrome OS support now.
Many newer Bluetooth devices are BLE, or Bluetooth Low Energy
devices.
BLE is part of Bluetooth 4.
It calls for a new API.
And we're building that API so your apps can connect
to fitness bands, wrist watches, home sensors, medical monitors,
and other smart devices.
Check out chrome.bluetoothlowenergyapi
for more.
Next, manifest v3.
Bumping a Chrome app Manifest Version
is a chance to bring forward best practices
and deprecate discouraged ones.
It's also a chance to introduce cool new platform
features, such as a promises based version of our platform
APIs.
We're getting ready to define what v3 is going to look like,
and we look forward to hearing from you about it.
Earlier I mentioned a project called app_shell.
app_shell is a Chromium build target
that offers a stripped down version of the Chrome app's
runtime suitable for two major use cases.
First, kiosk style applications where
you know the only thing the kiosk is going to do
is run your app, and there's no reason
why you'd need a full web browser.
Second, limited resource environments
running on bare bones embedded hardware.
The app_shell team is already demonstrating
that a Chrome app can run on a small fraction of the memory
and storage of the full Chrome browser,
and they're investigating ways to shrink it even further.
We'd like Chrome apps to go places that Chrome can't, and
app_shell is leading the way.
Now, as I said before, we're the Chrome team
and we love the web.
And the Chrome Apps team is excited about sharing
parts of what we've developed with the web.
Elsewhere at I/O, you'll hear Alex Russell and Jake Archibald
telling you about an upcoming contender
for web standard called service worker.
Service worker is at its heart an event page for the open web.
If you're already a Chrome app developer,
then you'll recognize Chrome apps
event pages and Service Worker's lineage.
Event pages provide a richer app lifetime model.
And we're excited to see wider adoption of that model.
We're also using our Chrome apps experience
to research different ways to present open web content.
The streamlined hosted apps experiment
let's end users treat regular websites like Chrome apps,
with top level windows and a spot in the App Launcher.
For a lot of sites, this presentation mode
makes a lot of sense.
Give it a try in chrome:flags.
OK, now you're caught up with today's Chrome apps platform.
Using standard safe web technology,
you get immersive UI, hardware access, great offline behavior,
easy distribution and retention, and a familiar native app
experience across desktop and mobile.
We built the Chrome Apps platform
because we believed it would be a better way
to safely deliver application functionality to users.
Every day, more and more people are
convinced, and every day more and more
people are buying Chromebooks as second and sometimes
first computers.
If you want to reach the users who are buying into the Chrome
app sandbox model, then you need to build a Chrome app.
We think we're onto something big,
and we'd like you to be a part of it.
Now is a great time to capture the attention of millions
of Chromebook users with your Chrome app.
So go build it.
To get started, visit the Chrome app site here.
Thanks for watching.