From Chrome Apps to the Web(blog.chromium.org)
blog.chromium.org
From Chrome Apps to the Web
http://blog.chromium.org/2016/08/from-chrome-apps-to-web.html
110 comments
Thanks! I could hardly understand the blog post.
Forgive my ignorance, but isn't the Chrome App Store also the place where you get extensions?
Presumably there will still be some centralized place to get extensions.
Presumably there will still be some centralized place to get extensions.
Yes, but extensions are unaffected. This is about 'apps' from that same store.
I thought "apps" was Chrome-speak for extensions.
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.
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.
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).
> > Websites with hardware access?
> 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.
> 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.
> Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be.
Perfect is the enemy of good! It's better than the alternative and that's all that matters.
Perfect is the enemy of good! It's better than the alternative and that's all that matters.
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.
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.
[1]: https://www.microbit.co.uk/create-code
[1]: https://www.microbit.co.uk/create-code
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.
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.
The article mentions using Electron or NW.js if you want to continue building apps on web technologies that need deeper platform access.
Is there a reason that those are worse options than Chrome apps?
Is there a reason that those are worse options than Chrome apps?
Each Electron/NW.js app will be packaged with a whole huge runtime.
It's not all bad - there's more freedom with these.
It's not all bad - there's more freedom with these.
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.
Nah, it's not that hard, not sure why you had so much trouble
Source: Have written many many Electron node modules
Source: Have written many many Electron node modules
It used to be hard, but when you have tried it last time? These days its as simple as hitting.
npm install --global node-gyp
npm install --global --production windows-build-toolsOnly Chrome apps work on Chrome OS and developing a Chrome app is way easier: Chrome takes care of the back-end and Google offers an app store.
To be fair, did many people actually place a significant 'bet' on Chrome Web Apps? Even from the beginning that wouldnt sound like a very wise bet.
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.
[0]: https://whispersystems.org/blog/signal-desktop/
[0]: https://whispersystems.org/blog/signal-desktop/
Did you place a bet on this technology? Tell us about it.
I didn't personally but there's stuff out there like chromeduino and Codebender that could be broken by this: https://chrome.google.com/webstore/detail/chromeduino/dmkinc... or https://chrome.google.com/webstore/detail/codebender-app/mag...
I did, I wanted a multi-platform GUI with USB access for my milling machine software.
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
Discloser, developer of Polarr for Chrome here https://chrome.google.com/webstore/detail/polarr-photo-edito...
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.
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.
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.
In terms of "Apps" that is comparable to a quality web app, I think Chrome Store is pretty dense. If you look at the photo apps here:
https://chrome.google.com/webstore/category/collection/pictu...
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.
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.
If I were in your shoes I'd look at going hybrid Android since recent chrome devices are getting Android apps.
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.
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.
Chrome apps can have extensive permissions that web platform does not provide.
- 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.
https://developer.chrome.com/apps/api_index
- 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.
https://developer.chrome.com/apps/api_index
I will add HID API support, that apps have and extensions don't.
https://developer.chrome.com/apps/hid
https://developer.chrome.com/apps/hid
We placed a bet on chrome apps because of the USB HID API - https://chrome.google.com/webstore/detail/onlykey-configurat...
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?
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.
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
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.
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.
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.
It is awful that we can't rely on devices to do proper authentication but that is the state of security today.
At least on Firefox there is a design decision in the works for that... https://bugzilla.mozilla.org/show_bug.cgi?id=1247628
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.
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.
AFAIK, A Chrome app is a glorified bookmark + offline support. An extension can add buttons to the toolbar, manipulate web pages, etc.
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.
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.
After thinking some more...
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.
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!
All the desktop OS vendors have to do is allow you to run native apps inside a tabbed, browser-like shell alongside websites.
NW.js supports running Chrome Apps directly: https://nwjs.io
We'll continue supporting it and Chrome App developers can redistribute their apps after packaging with NW.js
We'll continue supporting it and Chrome App developers can redistribute their apps after packaging with NW.js
I have a chrome packaged app
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.
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.
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.
1. Postman apps: www.getpostman.com/apps
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
Good to hear about electron based apps! Waiting for the Linux version.
Why does this feel like they are just giving the finger to ChromeOS users?
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?
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?
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.
There is no clear way to port your app to run on whatever conglomeration of features might meet your needs.
Chrome Web Store will continue to exist for ChromeOS.
The Google Play store is also coming to ChromeOS.
The Google Play store is also coming to ChromeOS.
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.
So what are developers of existing paid Chrome packaged apps suppose to do for existing users?
"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.
"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.
Why do you say "lack of notice?" This is the notice. Maybe it's surprising news, but nothing is actually changing today.
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.
Four months is plenty of time to repackage a chrome app into electron or something.
The lure of Chrome apps and extensions is they're easy and safe for users to install which is not true of alternatives.
[deleted]
The post said existing apps will continue to stay in the store for the next few years at least. So you have at least a few years to adapt.
Two years, to be specific.
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.
[1] http://caniuse.com/
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.
[1] http://caniuse.com/
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.
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.
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).
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).
So does this mean Chrome Remote Desktop is going to be a Chrome OS exclusive by early 2017?
There's also the official SSH client that is a NaCl version of OpenSSH, I've been toying with it since it seems kind of superior to PuTTY on Windows.
You should try hyperterm, it's based on the chrome ssh NaCl version shell with support for plugins on top https://hyperterm.org/
[deleted]
They will probably port that, and Hangouts, Google Drive and others, to extensions, I think.
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.
[deleted]
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!"
[1]https://chrome.google.com/webstore/detail/photobooth/lcimple...
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...
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...
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...
> IoT (replacing Brillo)
Right now Brillo appears much more mature.
However Google being Google, who knows which variant ends up winning.
Right now Brillo appears much more mature.
However Google being Google, who knows which variant ends up winning.
Fwiw, UWP supports writing apps for the Windows Store using JS & HTML I'm going to try porting one of my Chrome Apps over to see how easy/hard it is.
Does this mean postman app is gone as webapp ?
Incidentally they just released a Windows native application earlier this month (posted on HN yesterday): https://news.ycombinator.com/item?id=12315371
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
Does this have any effect on the seemingly small pool of games in the Chrome Store? Has anybody actually made money from that market?
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...
That's 50k weekly active users.
do 50k installs of this app equal 50k sales?
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.
This is the free version: https://chrome.google.com/webstore/detail/jstorrent-lite/abm...
It's just not searchable in the store by default.
It's just not searchable in the store by default.
Though I didn't build a game, I have made money (see above) around $1k/year.
Hm that's not bad at all! Have you considered trying to port the app to iOS though? It seems like you would have a much bigger audience there.
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 .
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 .
Does anyone know what they'll do with Google Apps Marketplace[1]?
It's currently piggy-backing on the Chrome App Store (only for the listing/entry, they are otherwise different).
[1] https://apps.google.com/marketplace/?hl=en
It's currently piggy-backing on the Chrome App Store (only for the listing/entry, they are otherwise different).
[1] https://apps.google.com/marketplace/?hl=en
[deleted]
Hopefully this pushes Signal developers to transition from a Chrome app to building a desktop-native client.
Any alternatives for Javascript USB connectivity on Windows machines? Just a Node.js install?
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.
[deleted]
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.