Live data from Hacker News

From Chrome Apps to the Web

blog.chromium.org

41–50 of 111 posts

Re: From Chrome Apps to the Web

#41

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.

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.

Re: From Chrome Apps to the Web

#42

Earlier quoted context omitted.

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.

Re: From Chrome Apps to the Web

#43
post #22

Earlier quoted context omitted.

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…

> - 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

Re: From Chrome Apps to the Web

#44

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 ori…

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?

Re: From Chrome Apps to the Web

#45
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...

Re: From Chrome Apps to the Web

#46

Earlier quoted context omitted.

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…

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).

Re: From Chrome Apps to the Web

#47
post #45

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...

> IoT (replacing Brillo)

Right now Brillo appears much more mature.

However Google being Google, who knows which variant ends up winning.

Re: From Chrome Apps to the Web

#48
post #35

Earlier quoted context omitted.

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.

Is this your app?

Re: From Chrome Apps to the Web

#49
post #23

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 obli…

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?

Re: From Chrome Apps to the Web

#50
post #22
post #3

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.

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…

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.

Post reply on HN