Chrome Apps are dead, as Google shuts down the Chrome Web Store section
arstechnica.com
arstechnica.com
PWAs have replaced a few native apps on my phone and I couldn't be happier about it. I can use Twitter, Telegram, YouTube and even read HN (via the Premii webapp [1]) through a fullscreen interface that behaves like a native application (no address bar, tinted notifications bar, push notifications for Twitter and Telegram), but that nonetheless is still a browser.
Support for PWAs on Firefox for Android is around the corner. I'm a Firefox Nightly user and the support is there: websites that have a webapp manifest display an icon on the address bar to let you quickly "install" the application as an icon to the homescreen. It is supposed to reach stable channel on Firefox 58 [2].
[1]: http://hn.premii.com/ [2]: http://www.androidpolice.com/2017/10/24/firefox-58-will-let-...
On Android it's possible for example to run Facebook as a web app, because Chrome on Android can deliver notifications, keeping that connection persistent, so even after the page has been closed.
And this is pretty cool because the browser is a much better sandbox than the OS. Now I use an iPhone and I'm very uncomfortable giving access to my photos to Facebook just for uploading a file.
Every time browsers get new features people (ESPECIALLY ad networks) abuse it for tracking and other nefarious purposes.
Battery level, light level, probably even gyroscope stuff. Hell they fingerprint canvas which isn’t even an iOS thing.
I don’t want these issues. I LIKE these restrictions so random sites I visit (and even worse random code injected in them) can’t watch me as easy.
Apps have issues but I control what apps I download and can delete them. At least I have a _chance_ there.
That's not an argument. Desktop browsers have features and add-ons for the privacy conscious right now. You can block trackers, third party cookies, JavaScript execution and anything you need. Personally I feel much, much safer loading a website than when executing a binary on my computer or phone.
You can block any elements on any website from loading, but you can't inspect application binaries and block specific elements from it — only requests to certain IPs or domains, if you had root access that is.
Can you block Facebook's in-app advertising on your iPhone? You can't and even more so, the app insists on opening all URLs in its own dumbed down view instead of Safari, which means they track those visits and their duration as well, probably without content blocking active, because AFAIK it doesn't work in web views.
Well I can block Facebook's ads and tracking in my Firefox for Android, since it supports extensions and it probably works using iOS Safari's content blockers as well.
(I avoid the vast majority of ad laden apps anyway, partlybfor tracking reasons).
The website operator/publisher is the one choosing to track you (or not). Not some magic third party.
If you don't trust example.com from tracking you, you certainly cannot trust example.App from tracking you.
For web, the technology is at least transparant and you can detect being tracked. With native apps, there is nothing you can do, other than reverse engineering the binaries, monitoring internet-traffic and hoping that example.App was built with privacy in mind.
If I download the example.com app then any tracking is limited to what they included either themselves or through an SDK. I know that $random_advertiser doesn’t get to execute their own code.
You either trust them, or you don't. If you don't trust the ad-networks they embed in their site then you don't trust them.
> If I download the example.com app then any tracking is limited to what they included either themselves or through an SDK.
You either trust them, or you don't. If you decide you trust the ad-networks they embed in their site then you can trust them.
Both are no different. Other than that you can evaluate the first quite easily but not the latter.
My point is that it is silly to trust someone from including advertising and tracking on one platform (binary-app) but not when they do the exact same on another (html-app).
You can add a website to your homescreen in safari, but when you do it uses a different rendering engine, with different levels of support.
Take WebRTC which was recently (partially) added to iOS. It will work great in safari, but if you add the site to your homescreen, it is no longer supported.
The job of telling users to remove homescreen shortcuts to use a new feature is a nightmare.
It doesn't make any sense to them, so they distrust it. Especially because we had been encouraging the act of bookmarking our web app on the homescreen for years (since it works great for our use case! Offline access is possible, loads quickly, no worries of apple shutting us down, and it's as cross platform as it gets). Also the wording is difficult. Telling users to open this same page, but in safari is confusing, and they need to login again, and navigate to that page again.
Imagine if a website told you that if you had previously "bookmarked" their page in your desktop browser, that you had to remove the bookmark to use a feature. You'd be skeptical at the very least right? It's a strange request...
Not to mention that even detecting it is kind of broken. The feature looks like it's available (opposed to pre ios 11 where the functions didn't exist), but when you go to use them they throw a generic exception (which can mean anything from they are in the "added to homescreen" browser on ios, the camera randomly crashed on android, another app is currently using the camera, or it just didn't work for some unknown reason).
So we have to check for the nonstandard `navigator.standalone` property, then just assume it won't work for the user. If iOS 12 adds support for this, we will need to update our app again and remove this block, but only if they are on iOS 12...
It's just a giant fucking mess.
Anybody knows why Apple is doing that?
The cynical part of me wants to think that it's because by hurting it in WebViews and in a desktop-shortcut they can "support" these technologies without fear of them cutting into their app store sales/numbers.
But I have heard that there are some shitty technical problems with it.
Safari is not the same as a WebView when it comes to the code, and apparently a desktop-shortcut app runs in a WkWebView. So while they were able to add these features to Safari, the process of adding them to a WebView is much harder since it's intertwined with the OS so heavily.
According to someone I talked to a while back, WebViews and Safari in iOS are different enough that sharing code isn't exactly easy or straightforward.
But then the cynical part of me kicks back in and thinks that they shouldn't be following into the footsteps of Internet Explorer which hit the same traps and potholes (the integration with the OS meant new feature were extremely difficult to add, and the browser lagged behind because of it).
I think the difference might just be in the rendering engine. So Safari uses "safari", and WkWebView uses straight WebKit? But even that isn't true since there are things that WkWebViews support that WebKit doesn't...
But there are many differences between them. The WebRTC stuff above as one, but also things like appcache manifest stuff didn't work in WkWebView in iOS 9 (even though it worked in Safari). And that violation was especially egregious because it could be enabled by calling a single private Objective-C method like this
[_wkWebView.configuration.preferences _setOfflineApplicationCacheIsEnabled:YES];
So I genuinely don't know what to think.
Oh, and SFSafariViewController won't even save you, as that doesn't support WebRTC either...
I forgot to actually test that a proof-of-concept of a new feature using WebRTC in a WebView until it was already like 70% done. I heard it worked in iOS 11, I tried it in safari and developed it like that, then once I started more in depth testing and integration I saw the problem.
So now I make sure I test everything in a WebView (if needed), as an "added to homescreen" web app, and as a safari tab ASAP.
Now we instead have to pay Google for ads to get visibility for our PWA. Now we're probably going to turn to Facebook and try to get some traction there.. From one evil walled garden into the next!
And that is why the web is dying.
I wonder if Rails support could be added for PWAs? I found a guide here: https://rossta.net/blog/make-your-rails-app-a-progressive-we... but I'm only midway through testing it. Getting Puma (Rails dev web server) to speak SSL without throwing errors is a stumbling block :/
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Di...
It gives JavaScript access to its very own, empty, sand-boxed VFS. However, you can give the page access to directories manually with drag-n-drop or a directory selecting input tag. So if the app needs access to just one parent directory then you're good to go. If you need the app to have indiscriminate access to the entire filesystem then you might be able to give it C:/ (or whatever other root dir) but I have never actually tried it.
Just another case of Chrome running in like a bull and doing one thing then breaking it later. :(
Anyone who needs the low level functionality will end up with a native app that use native messaging to talk to Chrome. Or just stands alone.
All please note. Electron is not a native app. It is a horrible hack that everybody use because it is easy.
Hybrid apps will always suck! ~ <3 hobbyist hybrid gamedev with client side js crypto mining on his mind }:‑)
Electron is an extremely heavyweight native app frsmework, not a native app, but Electron apps are (bloated, sure) native apps.
I mean I really like PWAs. But while they are around since a while now (about 2 years?), the pain points have not been addressed so far.
- Privacy: There are multiple issues related to privacy here (transparent updates, Serviceworker running in the background without the user knowing about it), and when I see it how many serviceworkers my browser runs already I am happy that they don't have an even deeper access to my system.
- Ownership: Installing a PWA works like visiting a website twice. After that you have no idea what you have (version? offline capabilities? storage?). And if you decide to use an App for a while you are living in the constant danger of the web service quitting.
- Storage: While many people do not care where their data is stored (proprietary service XYZ, AWS, Google Drive, DropBox). I would like to be able select my storage location myself. Furthermore, I think the storage topic is also one of the main reasons why people build electron apps, as the browser has no robust and user friendly way of accessing the filesystem.
So here are a few suggestions which I think would help to make PWAs more accessible.
- Archive Format: make it possible to easily download, save and install an PWA at any time. That way I should also be able to see a version and the required permissions.
- Storage interface: In my opinion the browsers should offer some storage solution. For my last PWA I wrote a lib which could use different storage locations like a REST API or a WebDAV. It works really well, but it is a pain to enter your credentials every time you want to use a new app. Therefore, your browser should offer something similar to a webdav service to save data locally and let you configure a WebDAV service location if you want to store you data somewhere else (e.g. Nextcloud, DropBox, etc.).
- Improve native integration. Yes that is no easy part. I mean we already have a bunch of native integrations, like e.g. the Notifcation API, but to be honest I think they could be better. One thing many Apps probably would like to have, are systemtray icons. Actually, I never used electron so far (only cordova), but I expect them to have a bunch of plugins which could be a great ressource for the browser devs to find out what we need here.
As permissions are already built into the browsers I haven't mentioned them here, but with the rise of the Serviceworkers they are more important than ever. Users should be aware of the permissions they grant a software from some brief encounter in the web.
You can upload files to the PWA using drag-n-drop or file input. You can also send files from the PWA to the device file system.
I think it's important that Web browsers can't automatically control the device hard drives, imagine if all web sites you visited would be able to do rm / -rf or scan all files on your hard drive.
That way it can't do much damage and when you trust it, you can give it more access.
I use the localStorage as a cache for some of the offline capabilites but as a persistent storage it sucks as you can't easily open the stored "files" with other programms or PWAs.
We've been pestering Google for a way to have a redirect or link on that page that says "get the app for windows and mac in its new home over here" but they haven't been very responsive. It's such a shitty way to treat developers who chose your ecosystem and who you did a certain amount of convincing. They have done this to us once before, with their wallet for digital goods, where they shut that down and developers lost any recurring subscriptions they had on the platform.
Basically, google is brutal if you develop on a platform for them that they decide to axe, they really don't think of the people and companies and how they will be affected and we now think twice before choosing to use anything they maintain.
That seems like a permanent fix in case you decided to change platforms as well.
I wouldn't build much on GAE either...
Even Youtube is not safe, have a look at the Adpocalypse a few months ago or all the wrong/incorrect demonetization of innocent videos.
What a surprise. It was deserved and a long time coming.
People need to learn that whatever horrible thing you put online doesn’t automatically get you paid. Advertisers don’t want to sponsor “anything” because it reflects poorly on them.
I don’t understand how YouTubers expected to never have advertisers try to scrutinize what they’re supporting or putting their name next to.
And yes, good people are getting dragged down by association because there are other things on YT that are toxic to advertisers like the weird copyright infringing kids content or the seemingly abusive kids content.
But if YT is going to host that stuff (they are), and you’re going to use their site too, then you’re going to get lumped in.
It’s the same problem as the dark web. Yes, there are a handful of legal sites that may be useful. But when a huge chunk of what it’s actualky used for is horribly illegal things you’re going to to get lumped in.
I’m kind of surprised YTers weren’t pushing YT to clean up a lot of this stuff earlier so this wouldn’t have happened.
For one, because they shouldn't have a say. They should pay for views, and that's it. If they don't like a specific program, they can not sponsor it -- but not try to affect regular ad rotation through all kinds of videos a users sees through their ad money.
Because with the latter way, advertisers also get censorship power over content providers. Which is something only the public should have (view or not view).
But they’ve always had that over ad-sponsored content. That’s what makes it ad-sponsored, that they choose who to pay and thus can pull funds for any reason.
Again, why should YT be different than other mediums with ad sponsored content?
No, it means they've started promoting crap for monetizing and penalizing things that people actually want to see.
>Advertisers don’t want to sponsor “anything” because it reflects poorly on them.
Given the human scum that are advertisers, I doubt anything could reflect poorly on them.
At best it would reflect badly on their clients -- who themselves would be totally fine to advertise on KKK websites and snuff films if it didn't cause a backslash.
They still think it's TV advertising when it's not.
Someone always says ‘but the internet is different’ but I’ve never seen a good explanation for why. Just things along the lines of ‘that’s how it’s been’ or ‘TV and radio are wrong’.
How is paying money to support something not an endorsement?
This is a good question. TV, radio, and newspapers all need to cater to the lowest common denominator(LCD) in order to obtain the greatest amount of viewership as possible, because distribution is expensive. A focus on the LCD combined with data analytics is why channels like The Learning Channel(TLC) and History Channel only show reality TV nowadays: They don't want to offend, they just want to maximize revenue on their single channel.
YouTube uses a different model. Every individual can subscribe to specific media niches that wouldn't otherwise be able to survive on TV, because the cost of distribution is brought to zero. The only costs that need to be considered are the costs of media development.
In real life, most people use vulgar language. Most people don't care about diversity or gender stereotypes. They don't care about the focus on the LCD. All they want is media that they can relate to and enjoy, and almost everyone enjoys stuff a bit different from the LCD. The fact that advertisers are trying to shift focus from individualized content to LCD content just so they can control the platform leaves many people bitter, and removes the competitive edge that YouTube has over typical media.
> How is paying money to support something not an endorsement?
Companies nowadays are trying to make it an endorsement, but it doesn't have to be. All YouTube needs to do is to make it widely known that while companies can push for certain demographics, they have no control over the advertising. Companies want more control over the platform than they really need.
I don’t see why that means advertisers aren’t, in some way, endorsing the content. If anything the fact there are so many channels and the content is more specific seems like a stronger endorsement than mass media.
Could you explain this part? I thought the whole issue was YT was being more selective about the videos they monetized with ads.
> Given the human scum that are advertisers, I doubt anything could reflect poorly on them.
If that was true boycotting brands wouldn’t be effective. But it is VERY effective. Ask Sean Hamburg or Dr. Laura (among many others).
I think you mean "any service that's not Search or Ads". Ads pay the bills, so every service is only useful as long as it increases ad revenue. Search may be special since Google cannot afford the damage to its brand if it shuts down search because it's not bringing in enough ad revenue.
Ads still make more, but at this point Google is not entirely just an advertising company.
Thus far, Google's major platforms have had roughly the same longevity as a typical series C startup. I will keep this in mind the next time Google announces a promising platform technology.
Google routinely kills off products. Because this is a standard Google platform life cycle, it doesn't look like evidence of anything in particular.
There is a huge graveyard of good products that were or could have been . https://www.lifewire.com/google-graveyard-products-1616198
Presumably, anyone who was going to be convinced of that by this move was convinced when it was announced 16 months ago.
https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
> I wouldn't build much on GAE either...
AppEngine has just about hit 10 years, and it's still growing and deeply integrated with the rest of the (even more actively developed) Google Cloud Platform, so it's probably nearly as secure as the other core itemss you mention.
Disclaimer: It's interesting to see that our app (Polarr) is in the screenshot (link: https://chrome.google.com/webstore/detail/polarr-photo-edito...)
Although ChromeOS is the smallest platform we currently support, we spent a lot of energy on it and it is so far, still the highest rated photo chrome app.
To put things in perspective. Between September to December, our Chrome App user breakdown are
Windows: 48.05% ChromeOS: 43.38% macOS: 7.11% Amount of users who used the app during this time frame: 326,459 (28.92% new).
Between Jun and September, our user breakdown are
Windows: 56.34% ChromeOS: 34.84% macOS: 7.25% Amount of users who used the app during this time frame: 280,013 (28.52% new).
Personal side note: I will miss Postmann Interceptor because I can catch cookies from a web login with the pwa app without any copy&pasting data and continue using our REST api with this cookes. <- not possible with Electron Postman.
And what a step backward on a 2GB RAM notebook that would otherwise be fine for office and browsing tasks.
That's 10 million active users who can't install apps that they use on their next machine?
Then why do the chrome website auditing tools promote progressive web apps as the first analytic for the performance of a page. Surely only a small subset of webpages are going to be 'app-like'.
Chrome Apps could do more than progressive web apps could do but less than Electron apps. For some uses, now your only option is to implement an Electron app.
Electron is much heavier, requires more trust because its a native app, makes cross platform support harder and you're missing out on the update, payment and discoverability features of the Chrome Web Store.
I'd prefer progressive web apps over Electron and Chrome Apps but they're not powerful enough to replace all use cases yet. I agree Chrome Apps weren't being widely used but I like the idea behind web apps replacing native apps (including Electron) where suitable.
No, there are plenty of options when doing native development.
I was mostly meaning if you have an existing Chrome App or wanted to rely on existing JavaScript libraries.
Electron gets a huge amount of hate on HN but I personally see the native route as very unappealing. With less developer resources (and perhaps a slightly worse UI; I think people really over exaggerate here), you get fairly simple cross platform support, an update system, access to a huge JavaScript ecosystem and your code can be shared between desktop, mobile, web and server-side.
As a developer, I don't see the appeal of e.g. QT, Java or OS specific implementations at all compared to the above. In my opinion, you're trading a small increase in UX and improved system resource usage (which most users won't notice) for a massive increase in developer resources. This is an order of magnitude worse if you're going to do a separate implementation for each platform as well as now you're going to need platform specific libraries, testing frameworks, development workflows etc. for each OS.
Unless you have lots of money, it's not practical to support multiple platforms with a 100% native experience using the minimal amount of CPU and memory possible. If you have an existing web app, moving to Electron isn't a big leap but that isn't the case if you want to have multiple native apps.
Another alternative would be React-Native, now that react-native-web exists...
I often see comments mentioning QT and Java as alternatives to Electron for cross platform apps but my impression is an order of magnitude more developers/companies side with and see the advantages of Electron instead.
I work in IT and I see it as a small increase in UX for an order of magnitude increase in cost. I don't see how e.g. making Spotify or Slack into native apps would dramatically improve their UX.
In contrast, I think many coders are overly sensitive to CPU and memory usage to such an extent that they lose sight of business sense.
Slack for iOS is pretty terrible in terms of stability and quality.
Writing an actual native app in Swift isn’t that hard and they’re Slack — one would think they could afford to hire the proper developers.
It’s hoghly irritating when I’m a paying customer of a fairly big tech company and they think saving money on pseudo-native for iOS is ok. They think it’s ok to provide a shitty “near native” experience in the name of crosss platform. iOS and Android are different systems. They have different devices; it’s ridiculous to ship the same app.
Well then that is something you might want to do something about if you're an app developer. There's no reason arguing if you are unable to discern the big difference between the UX of a (both properly built) native app and an Electron app. I think this might be one of the reasons Electron is actually successful; a lot of developers do not have a good sense for UX so they think what they've built is a proper alternative to a native app. Same goes for those who think PWA's are going to be great and up to par with native apps (hint: nope, not even close).
I'm able to tell the difference thanks. I'm saying that with native apps the UX can be better but for a large cost and a lot of the time that cost is not worth it. I'd also argue that most coders fixate on bad examples of non-native apps because when non-native apps are done well they don't notice. For example, Visual Studio Code is based on Electron and there's always lots of comments from people being surprised how performant it is. People also use lots of web apps day-to-day that they're happy with.
I must've interpreted that the wrong way then. We'll have to agree to disagree then because I do think there is a big difference in UX.
I really think the limits of providing a nice UX with web tech is the elephant in the room here and everyone is ignoring it because it is simply cheaper and easier to work with and/or because of idealistic reasons. Which I think is a shame because it's responsible for a trend where we're moving towards good-enough software on all platforms, instead of nice software for specific platforms.
Turning Slack and Spotify into native apps can upgrade them from just being functional, to actually being a pleasure to use, something of which I'm convinced is not possible with web tech no matter how hard you try. There is a huge amount of platform specific UX details (much appreciated by Apple users especially) which you will not be able to emulate.
GTK+, too. There was a big uproar several years ago when GNOME tried to anoint JS as the "official" language for GNOME app development. They eventually backpedaled, and overall their story for JS today seems to be technically decent but thoroughly undocumented.
Keep in mind, this was all before GitHub announced Atom and (what was not-yet-then called) Electron. Imagine if the GNOME folks had used that head start to commit themselves to the original decision, instead of reversing. They might have managed to capture the mindshare that eventually poured in Electron, there'd be a straightforward migration path for DOM-based UIs to go "native", and GTK+ and GNOME apps might've been successful outside the increasingly niche space it occupies on the Linux desktop.
https://wiki.gnome.org/Projects/Gjs
https://2017.guadec.org/talks-and-events/index.html#abstract...
Electron apps across GNU/Linux users are the final nail of the desktop Linux aspirations.
When the world is a Web VM, the kernel and everything UNIX related is irrelevant.
I'm speaking only of my own frustration.
There are ripple effects that impact Google's other businesses. I wasn't willing to switch to Google Plus for that same reason. I'm certain that I'm not the only one.
Wish we have system level support for Electron apps, so not every single one has to bundle Electron libraries separately.
Edit: There is already project that is targeting that. https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w...
https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
They will however now reduce the amount of platforms it can run on to a fraction of what it was... But for what reason? (Since it's clearly an OK technology in the eyes of ChromeOS)
This only shows yet again to never rely on a Google-based platform for your application or service.
The plan, of course, is that everyone will be on ChromeOS.
For instance my old Acer Chromebook 13 never got Android app support, it was too old despite being based on the same Nvidia Tegra K1 ARM CPU that has been used in a number of Android devices.
Well, if you delegate discovery of said apps to a small icon no one can see on screen, then no surprise.
Anyone have any suggestions for a replacement for Authy?
It's a 2FA Chrome App that syncs your 2FA tokens across devices.
They have a 'desktop app' now available for Mac and Windows, but of course nothing for Linux (surprise surprise).
So any equivalent that will work cross platform and sync too?
I don't have a good solution to this problem - I am mugged while traveling and I lose my phone and wallet. If anyone could share how they tackle this problem I'd be grateful.
'Something you have' relies on physical security, so if you have the same physical security for both your laptop and phone, there's no reduction by having a 2FA token on each device.
The concern is that Authy changes the second factor from physical security back to something cloud-based and hackable.
I don't know if that's legit because I don't know how Authy works.
I experimented with migrating from Chrome to Firefox 57 when that launched. It's a very capable browser and I could easily use it as my main browser, but Authy was the main thing which stopped me dropping Chrome for work use. There were other things (like Netflix Chromecast support) which were stumbling blocks for home use, but I can always keep Chrome around for those.
For standard OTP, I use 1Password. It integrates well, syncs with my devices, and is still locked behind a secured central password (or fingerprint, in the case of my mobile device). It's secure enough for my needs while still being performant and encouraging of good habits, such as randomized, unique passwords.
There is also a companion extension, but I am unsure what purpose it serves.
https://productforums.google.com/forum/#!topic/chrome/uVCvle...
I'm currently trying Poki [1] but I find it's offline reading features too limited for my tastes.
Pocket hints they may produce a Windows 10 app but that's a vague promise at the moment.
1% of Chrome’s users are millions of users.