The headline is very non-specific. Here's what's going on:
In a multi-stage, two year effort, the Chrome App Store is being deprecated on Windows, Mac, Linux, but not ChromeOS. They're asking people to migrate to websites/webapps instead. Extensions and themes are unaffected. By 2018, only ChromeOS will be able to run apps in the Chrome App Store.
This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't even on the radar (so good luck programming a board like BBC micro:bit, Arduino, etc. without a native app), and efforts like WebUSB are still extremely early and not even a full standard. I feel like the product managers making this decision are completely oblivious to the major gaps between chrome app support & HTML5 support. This line in particular is basically a giant middle finger to folks in this situation: "Developers who can’t fully move their apps to the web can help us prioritize new APIs to fill the gaps left by Chrome apps."
So in short, Google proves once again to _never_ take a bet on their technology.
Websites with hardware access? what could possibly go wrong?
Browsers already are a overly complex security nightmare. Moreover the recent example of this stupid but rather simple battery API has shown us several, some more and some less obvious ways of how it can be abused. But sure Google will implement WebUSB and all sort of other shit they may imagine, the others will follow as always. In the end the browser will finally be the OS in your OS but worse and with a huge attack surface.
What's the alternative? If an app needs such functionality to work and it cannot work within a browser, the user will have to install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).
> the alternative? [...] install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).
err, the sandboxing works because web APIs don't already expose things which are suggested to be exposed here. Exposing them will break that "sandbox", to a certain (major) degree, atleast.
Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. In addition to that better redirect the work that would go into these browser features to improve the native sandboxing mechanisms of the operating systems.
Sure nothing is perfect and I did not say that we shouldn't improve sandboxing but I do not think that moving everything into the browser is the better alternative. The problem doesn't get easier only because it's in the browser and as a nice topping every random website is now free to try to break the sandbox.
UWP is sandboxed, Mac App Store apps are sandboxed, Mac apps from outside the store can opt-in to sandboxing, flatpaks are sandboxed, snaps are sandboxed.
In terms of maturity, all of these techniques are probably more mature than any WebUSB/Browser hardware access thing/abysmal-of-the-day.
Reading your comment on a Chromebook that hasn't failed me once including all the others i have had makes me scratch my head. If anything this, to me, seems the most secure approach compared to what's out there. Doesn't it make to you? A secure, lean Linux hosting a lean UI layer that sandboxes web and native apps.
The BBC micro:bit happens to be a bad example, since the editors [1] are exactly web apps with no hardware access. The editors compile the code in the browser and provide the ARM binary as a .hex file that the user downloads onto the micro:bit, which is a USB mass storage device.
Yeah but not every board can do USB storage bootloader, and there are troubles with it like ignoring Mac OSX .DS_store files, etc. Been there, done that, USB mass storage bootloading kinda sucks.
Also if you load stuff like MicroPython on the micro:bit you can't access its serial REPL from the web. That sucks, plain and simple.
It's possible but it's not an easy switch. And god help you if you have to mix native code with Electron. Getting a node-gyp toolchain spun up on Windows is a complete and total nightmare. Add Electron and its very specific version of Node into the mix (which totally confused node-gyp) and it's really awful.
Different sets of APIs[1]. For example Socket, USB are only App APIs. Though I guess they could roll app APIs into extensions… hopefully. Socket API especially.
Just last December, Open Whisper Systems announced Signal Desktop, a Chrome Web App[0]. I am not sure how significant you would consider the Web to a messaging platform, but most of their competition has a Web app by now.
there are workarounds, for usb device over wifi there is this: https://github.com/cnlohr/espusb
if you are hardcore enough it is possible to add usb host support too
To us as developers, the biggest advantage of Chrome Store is discoverability, reviews, and store front organizations. As a fairly new developer, we also have a web app, but it is late in the game and there is no way to out-SEO the existing players through Google Search. Chrome Web Store was the place where we felt a fair game where we can compete on product quality and getting better reviews and out-rank the same competitors who also have chrome apps.
Don't you really only have that discoverability there because almost nobody is actually in the Chrome Web Store? For the most popular browser on the planet, Chrome's store is incredibly sparse.
I was always surprised Google didn't fold it into the Play Store as a separate category, now that it serves movies, books, etc. that aren't Android-specific. And the Play Store is a far more mature product than the Chrome Web Store.
It is pretty much a replica of the top search results of "online photo editor" or "web photo editor". It is as competitive as web but I think the layout/review/star information in the store is still more useful than looking at a linear table returned by search.
It seems like Play Store is going to replace the Chrome Web Store. Speaking as app developer, the only advantage for searching for apps on Chrome Store is that most apps are optimized for a laptop/chrome book with a mouse and keyboard, and the apps work better for desktops.
I was thinking the same thing -- the Chrome Store has been a huge boon for my product (https://write.as). But a lot of people are on Chrome OS, and since they're keeping apps there at least, I don't think this is a terrible thing. And it makes sense from a product perspective: the store stays focused on the platform it was originally built for, and doesn't try to extend its reach to a storefront for the entire web.
I've always been somewhat confused by chrome apps. How do (did) they differentiate themselves from extensions? Even Google seemed unsure about that as Hangouts has been available as both an extension as well as an app for quite some time.
As a user I'm really glad to see this move, along with the move towards android apps on Chrome OS since I'm hoping it will unify the Google-driven ecosystem a bit more.
We would have done an extension but there is no USB HID support. Obviously a web app would be a bad idea. Anyone know if there are plans to make the chrome.hid api available to extensions any time soon?
> - Full TCP/UDP socket support (AFAIK this is never coming to the web platform)
While it could never be allowed unconditionally (because it allows scanning internal networks), I don't see any reason it couldn't be allowed with a permission request.
Asking a end user if foo.com should be allowed to open a TCP connexion to host:port makes no sense. 99.999% of users can't make an informed decision, and they just want the damn to work so they choose "allow".
Never ask users questions that they can't reasonably answer, ie don't do what android did for a long time (looks like this has been improving since N).
Maybe the case of TCP/UDP could be improved by showing a human readable version of the prompt for some well known ports. So a browser would ask "Do you allow webmail.com to use a secure IMAP connexion to mydomain.com?" when webmail.com requests access to mydomain.com:993
> Maybe the case of TCP/UDP could be improved by showing a human readable version of the prompt for some well known ports. So a browser would ask "Do you allow webmail.com to use a secure IMAP connexion to mydomain.com?" when webmail.com requests access to mydomain.com:993
Such prompts are going to be super confusing to the majority of users. What is IMAP? What does secure mean? What's a port?
I don't have a solution; I think it's really difficult and interesting problem. For example, you might think a game shouldn't require any permissions, but then it might need internet access to upload scores, access to your address book to invite your friends to play etc. I can't see any easy solutions how you can check the app isn't using these permissions in a malicious way.
You can't reasonably limit access to a specific host anyway, because DNS allows you to point a hostname to any IP; once you have permission to access a hostname that you control DNS for, you can connect to any arbitrary IP address, including LAN addresses. (You could slightly mitigate that by blocking RFC1918 private addresses and localhost, but then you couldn't build clients to talk to such servers.)
As another alternative, which would allow applications like mail clients, SSH clients, VNC clients, and similar, you could treat Internet connections like the web treats file-pickers today: ask the browser to prompt the user for one, and get handed a connection, without the ability for the site to set the target. Combine that with persistence ("allow the site to connect to this host again in the future without prompting?"), and you could easily connect to the handful of servers a user wanted to connect to. That wouldn't let you build a web-based BitTorrent client or similar, but it'd solve many of the problems people want arbitrary connections for.
Yes, but the "solution" is that you can't convince the browser to talk anything but HTTP. So unless the device is HTTP it will probably ignore your "malformed" request.
It is awful that we can't rely on devices to do proper authentication but that is the state of security today.
Actually, Chrome Apps are different because they are offline by default (you need to ask permission to get anything online), have access to system APIs, and have certain rules to keep users safe from cross script attacks, etc.
There are "hosted" chrome apps, which are indeed glorified bookmarks. The "packaged" chrome apps are actually offline by default. Two separate things, with the same name...
I think next year's Android tablets will be more like the Play Store with Chrome OS under the hood, the apps they are obsoleting today will be a universally inferior experience on tablets because they were only ever supported on desktops.
I think Google are betting on the Play Store for Windows and macOS breaking the Windows/Mac desktop paradigm too ... between Chrome the browser and Android apps Google occupies a lot of user attention already, they're already close to all the apps most people need, especially when they're co-installed on your desktop/laptop.
In terms of functionality they're on the brink of parity with Windows wherever the dependency is really just x86. A commercial Android version of WINE has already installed the Windows version of Steam and playable games, just as sophisticated GPUs start moving to the same USB every cheap tablet will have next year.
A lot of people will end up completely weaned off Windows/Mac app dependency... those are platforms on which both native app stores are orders of magnitude less popular than the Play Store and unpopular with developers.
Maybe Play Store for Windows and Play Store for OS X will launch real soon... as Play Store for Chrome.
In Chrome OS they're currently adding the Play Store to select hardware including x86 laptops using ... "container" technology.
In Chrome OS these apps will start to stop being available in about a year.
In Chrome on Windows and Mac they are losing access to these apps, the vast vast vast majority of users, they start losing access almost immediately and completely lose access before this year ends.
So I guess Android will be a small device OS.
Chrome-as-Android will be the tablet/desktop/laptop OS.
And if Google's bet pays off Windows and OS X will be an MS-D...OS.
Yes. The browser is already like second OS. So if Google provides the Android API through Chrome. And if Chrome comes with PlayStore, then a lot of people will be able to run Android apps on Windows 7+, macOS and Linux. And as a next step, people will ask themself why not just buy a notebook with Android and run 1-2 legacy apps via Wine or whatever. And the new announced (on Github) Fuchsia OS that may replace some rusty parts may happen like Win98 to WinNT. And MS can do little to prevent it, their Phones and tablets have a 1% global market share, their store is a joke, their UWP platform failed (Win10 exclusive games like Quantum Break already backported to Win7 and Steam), and they still do their best to scare of their long time users with their aggressive style, that was unheard of during Balmer era. So Google has a very good chance to win the desktop market share big time. Just don't forget about enterprise customers!
Back then to get any kind of power you had to use a packaged app. Extensions either didn't have permissions needed to build a real offline first experience.
Nowadays service workers help with the offline role. I wonder how much permissions have been expanded to allow the same types of apps to be extensions.
Postman founder here. We saw this coming a while back. Chrome apps have had several issues related to window switching and menu control. We have been waiting for a fix for these for ages but they never came. We decided to build a cross platform app based on Electron last year and now have apps on OS X and Windows [1] with Linux coming soon.
This is not the first time Google has deprecated things or made a drastic change in the Chrome platform. Postman had to shift from the legacy style apps to the packaged style apps in 2014 while it still had hundreds of thousands of users on the legacy platform. Google's solution for the transition is pretty bad. You upload a new zip file and everyone sees the new app running outside the browser and without the ability to do certain things. This transition system was not available when the Chrome app platform launched and we had to create a new listing. Other apps that transitioned their users to the new platform on the existing listing got hammered in ratings as people were pretty obviously pissed.
Developers can continue to build Chrome apps and eventually Android apps for Chrome OS, when Google Play store is brought to Chrome OS. However, I agree there is the problem of losing incentive to maintain a native Chrome app from the developer POV.
Yep, ChromeOS developers can feel pretty screwed over. Previously a packaged app could run in any of the hundreds of millions of Chrome (desktop) installations, as well as ChromeOS machines. For example, Windows corporate desktops and Chromebooks.
There is no clear way to port your app to run on whatever conglomeration of features might meet your needs.
With Chrome OS now supporting Android apps, this obviously means Chrome Apps will get dropped there as well even if they deny it now. A real shame since since those had a chance to become an excellent modern platform for internet-first desktop-grade apps. As all things Google, they had a great solid technical start, but at some point the clueless managers had to pull the plug.
For K-12 schools, losing Internet access is a frequent occurrence and when they do have access it's often slowed down by the other 1000+ students using it. Chrome Apps totally on the web also mean times when there will be no app at all.
Four months notice to be told there's no point releasing a Chrome packaged app you might have been working on (which may not work as an extension) isn't very much notice.
But if you want to maintain a presence on ChromeOS, you can keep updating your app indefinitely, but it'll only run on ChromeOS starting sometime in 2018. Or you can redevelop everything for the Google Play Store (ie. the Android store) if your ChromeOS customers are on new-enough ChromeOS devices to get access to the Android store, leaving old ChromeOS devices stuck on the old Chrome App version. Or you can redevelop everything as an entirely HTML5 single-page-app with all the lovely ever-evolving, impossible-to-keep-up-with features or lack thereof [1] of the web platform. Or you can redevelop everything and go full-native on every single OS. Or you can put all your JS into Electron and hope people don't mind a 60+ MB download. The choice of awful choices is yours.
According to the link, in short, it says to notify your users (assuming you've been keeping track of them via a mailing list) and then posting an uninstall button.
As far as I can tell, there will be no way to programmatically transition users and their IAP outside of your chromeapp. Meaning, we will have to figure out a way to get users to register their purchases to a database.
> According to the link, in short, it says to notify your users (assuming you've been keeping track of them via a mailing list) and then posting an uninstall button.
> As far as I can tell, there will be no way to programmatically transition users and their IAP outside of your chromeapp. Meaning, we will have to figure out a way to get users to register their purchases to a database.
It will be very disappointing if Google doesn't help make this migration easy.
I don't think that will be very likely as you'd be surprise how little information you're given about users who make any purchases.
Currently, it's up to you to create hooks upon successful payment to ask for information (which is extremely weird to the users because they're under the impression that they paid you directly and already possess that information).
Every In-App-Purchase (or app purchase) is not linked between platforms. It sort of makes sense that any IAP you buy in iOS will not (automatically) make it over to Android, but it makes less sense between Android and Chrome (considering it's the same Google user).
ServiceWorkers allows installing apps on Chrome or on the desktop so hangouts and drive could use it. Not so sure about ssh and what's going to happen to NaCl.
The moment it was announced that Android Apps/Play store was coming to Chrome OS, I always wondered about the fate of Chrome Apps.
I built a Photobooth App called Photomatico[1] (for use in events/wedding/parties). While there is an endless supply of photo/camera apps in Android and iOS, there were only a few photo/camera apps on the Chrome Store, and even less that didn't rely on using Flash. I wrote Photomatico originally as a web app for one of my friend's wedding (super happy with the use of only HTML/CSS/Javascript).
It was a relatively small effort to package the code into a web app (because packaged web apps have the added functionality of running offline/disconnected, kind of like Cordova/PhoneGap) and adding to the fact that Google handled all the payments - so no need to do extra work and sign up for credit card processing/Stripe/Recurly/paypal, etc. So all you had to do was add a few lines of code, zip it up and people would pay you for it!
I think people value the simplicity of an "app" versus a website even though in my case the functionality is equivalent. From the last 3 years, I find that non-tech people (i.e. people who celebrate retirement parties, DIY party organizers, etc.) are pretty comfortable with the concept of packaged apps (icons, distinct install process) but are even more comfortable with the safety of an App store. As crowded as it is, users definitely were more comfortable with a store than navigating and bookmarking a website.
I have built other apps that use the bookmarking feature to launch separate self-contained windows and my own anecdotal observations show that this workflow is really hard for them to grasp. Even the "new" way in Chrome is being dismissed by users because it looks too much like an ad or popup.
A few years ago, I put my Photobooth app on the Chrome Store and slapped a price (currently:free for selfies, $40 for the "Events" edition). I learned a lot about pricing/offering (I was surprised when I discovered I had more people paying $40 for the Events Edition than $5), building an email list (incentivizing signups), etc.
Just the other day, I was reviewing my revenue figures, and for relatively low amounts of work/support it's currently bringing in around $150 CDN / month, with over 40 daily installs, a couple thousand pictures taken weekly.
As sad as it is to see the chrome store go all I can say (in 2018 when they will shut it down) is: "So Long! Thanks for all the fish!"
I was working on a Chrome app so this is interesting to read, thanks! Are you planning to convert your app to an extension now? Is that possible? Did you consider monetising this as a web app somehow?
I think Google is working toward the consolidation of all their platforms, like Microsoft did with UWP on Windows 10.
You can run Android apps on some Chromebooks but it doesn't feel optimal. I wouldn't be surprised if both Android and ChromeOS were replaced by "Fuchsia" eventually. You could have a single platform for mobile phones (including VR/AR), desktop, IoT (replacing Brillo), server, etc...
1% of Chrome users using Chrome packaged apps is an extraordinary large number! This is an absolutely stupid decision. Chrome apps gave a clean convenient way of packaging offline apps without bundling a huge runtime like the electron framework.
I suspect many people will migrate to electron instead of web apps. APIs for USB and Bluetooth and the isolation offered by Chrome apps have no equivalent in extensions / web apps
It is possible to make some money on there. If you own a Chromebook with Chrome OS, it's the only place to get software. There is a torrent app for sale on the Chrome store for £1.89 and has over 50k installs: https://chrome.google.com/webstore/detail/jstorrent/anhdpjpo...
I don't know but there is no free version at the moment. Looking at the updates in the description it mentions that they will refund any unsatisfied customers, that was in 2013 so it was for sale back then too.
Thanks! I thought about porting, but honestly this was a "big fish in a little pond" scenario. With fewer apps (and also fewer users) you don't have to do a lot to stand out. I'd have to weigh cost/benefits of doing an iOS port.
As a developer, I was pretty concerned on what to chose between Chrome Apps and packaged apps with Electron. Chrome apps didn't make sense.
I chose Electron for obvious reasons, but still wish there was a some simpler way to package and distribute Electron apps. And a way to restrict app-permissions on Electron desktop apps - similar to what we do on mobile .
https://wicg.github.io/webusb/ is implemented on Chrome today behind experimental flags. It's not an answer for legacy USB devices, but for new devices that take into account the web's same-origin policy, it's quite powerful.
In a multi-stage, two year effort, the Chrome App Store is being deprecated on Windows, Mac, Linux, but not ChromeOS. They're asking people to migrate to websites/webapps instead. Extensions and themes are unaffected. By 2018, only ChromeOS will be able to run apps in the Chrome App Store.