From Chrome Apps to the Web
blog.chromium.org
blog.chromium.org
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.
Presumably there will still be some centralized place to get extensions.
So in short, Google proves once again to _never_ take a bet on their technology.
Is there a reason that those are worse options than Chrome apps?
It's not all bad - there's more freedom with these.
Source: Have written many many Electron node modules
npm install --global node-gyp
npm install --global --production windows-build-toolsBrowsers 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.
Perfect is the enemy of good! It's better than the alternative and that's all that matters.
In terms of maturity, all of these techniques are probably more mature than any WebUSB/Browser hardware access thing/abysmal-of-the-day.
> 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.
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.
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.
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.
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.
- Full TCP/UDP socket support (AFAIK this is never coming to the web platform)
- Bluetooth support (Web platform is getting this, though)
- Filesystem support (e.g. get persistent read/write access to user selected directory. Web platform probably won't get this)
Notably the socket and filesystem permissions are not available to extensions. Most of the other permissions though are available in extensions.
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?
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.
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
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.
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.
It is awful that we can't rely on devices to do proper authentication but that is the state of security today.
And you can have a web extension that natively connects to a local program if you need more power. Not self contained but it's possible.
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.
We'll continue supporting it and Chrome App developers can redistribute their apps after packaging with NW.js
I built it about 4-5 years ago
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.
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.
1. Postman apps: www.getpostman.com/apps
So basically, we have an OS that will only run chrome apps, and they are removing the ability to create chrome apps.
I'd be more okay with this if they gave ChromeOS the ability to install and run an .apk.
Does no one see a problem with this?
The Google Play store is also coming to ChromeOS.
There is no clear way to port your app to run on whatever conglomeration of features might meet your needs.
"Starting in late 2016, newly-published Chrome apps will only be available to users on Chrome OS."
As someone who has been building a Chrome app this sudden change with a lack of notice has made me very nervous.
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.
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.
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).
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!"
[1]https://chrome.google.com/webstore/detail/photobooth/lcimple...
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...
Right now Brillo appears much more mature.
However Google being Google, who knows which variant ends up winning.
It's just not searchable in the store by default.
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 .
It's currently piggy-backing on the Chrome App Store (only for the listing/entry, they are otherwise different).