> "Tinder has been updated. Deal with it".
is an interesting choice of example. The anger at updates only really makes sense for apps that are entirely local to your hardware. As soon as you have an app where part of it runs on a server that you don't control, that logic goes out the window. They can stop your non-updated app from working with no effort, just by making the server API incompatible. As long as you are depending on someone else's server to be up and responding and not changing, you give up your rights to be in control of local updates.
It sucks, but that's the reality of SaaS. I'm a fan of using local apps whenever possible. For instance, Google Docs is just too damn useful not to use sometimes. But I still, majority of the time, will choose to use a local word processor whenever I can get away with it. And when I'm done working on a Google Docs project, I download it in several formats and put it in the drawer.
In the meantime I'd really like to see more take-up of open source, federated hosted solutions based on open document standards and open protocols. But so far the big corporations are winning that game.
This may be the current sucky reality of SaaS, but it could be fixed if the market demanded it.
I'm not so much angry about server-based apps changing things, although I see your point, but I am angry about too many server-based apps in the first place. At least when it's not necessary. Hard to argue when it's literally for a social network.
* Although in practice this only works for so long as it gets more and more painful as time passes.. there are still users of Windows XP! But I'm sure it's far from a pleasant experience these days.
Meaning, effectively, that it will not be fixed.
I understand the frustration. I work on a mobile application that, like Uber, relies on a lot of server-side communication and deliberately stops working if the client is out of date. And I do know that this sucks.
But the reality is, our API is non-public, and so there is no pressure from anyone to maintain backward compatibility. And I have a thousand features that need to ship, with not enough time as it is, or I will start getting heat from management. Abandoning the cadence of "constant breaking changes bundled with client updates" would slow development considerably, for no gain except the one-hundredth-of-one-percent of HN weirdos who care about this stuff. It's just not going to happen.
Ignoring the lame slur, it's not just people that care about computing freedom. It's also people with terrible connections and extremely limited data plans. Being forced to download a 40MB app update just to look at a few KB of data is a deal-breaker for many people.
The market (my mom for example) is unaware there is a fix.
> there is no pressure from anyone to maintain backward compatibility.
You and your manager are both part of the problem. And the phone makers, because they invented a market place for shit companies that wants to ship unfinished software and push daily updates to their users to eventually reach a point where their API is stable.
There used to exist software developers who took great pride in (API) backwards compatibility. These days, where are they? My guess is they have been overrun by the a huge crowd of new people who have never maintained a backwards compatible API and who don't know how to. Management love fast-moving people who say "yes sir" and "not a problem sir".
1. Software that would work, un-modified, for decades.
2. Software that worked without access to some back-end.
3. Software that didn't require permission from a third party to run.
4. Software that didn't collect personal data from users.
5. Having root/admin access to your own computer/devices.
We can still prevent this from coming true, but it's going to happen if nobody pushes back on these practices.
This is an admirable sentiment. Thank you for making HN a better place.
> But everything comes at a cost that has to be weighted against the corresponding benefit, and the apparent benefit (to management) in this case is near-zero
Software can have virtues that do not present short-term benefits, but instead contribute to a wholesome UX, even to captive users. It is the responsibility of the software developer to make these hard calls and stick to their guns in the face of management pressure.
Now, you often buy only a license to use something until the company that made it decides not to let you use it anymore.
In some sense, we live at the mercy of people we've never met.
People providing services can argue a lot about the limitations for them of this situation and the advantages of having more control:
https://signal.org/blog/the-ecosystem-is-moving/
http://paulgraham.com/road.html
(Analemma_'s comment elsewhere in this thread also expresses this.)
But it also comes at a cost to users' power and autonomy:
https://www.gnu.org/philosophy/who-does-that-server-really-s...
Out of curiosity, would you pay for a standalone Google Docs that worked locally and pushed data to a server (say, a daemon you can also purchase and run in your home computer or droplet) only when you wanted to sync? If you are willing to pay, Microsoft offers much of this through Sharepoint + Office.
But anyway, my workplace brought some version with a clear requirement of getting an eternal license on it. Yet, it breaks all the time because it can't get licenses on the cloud. I am still not sure how MS isn't evading the requirements, but well, it's not my job to check it.
Hard for companies to give up that juicy user monitoring, though.
Even if you turn off auto-updates, some things still auto update silently. A long time ago, I wrote a small utility which listened to the PACKAGE_ADDED and PACKAGE_REMOVED events (I don't know if it's still possible to listen to these events on recent Android versions). IIRC, there were two packages that always updated silently (wihout a notification icon) and automatically, even with automatic updates disabled: com.android.vending (Android Market/Google Play Store), and com.google.android.gms (Google Play Services).
Now, I do still care of being in control of my own hardware, but I do so on my server. I don't know of a cell phone that delivers what I want without being sold as a service rather than a standalone product. Best I can do is back up all my data to my own box and keep buying new phones when the batteries die.
On the individual scale, the sensor data was noisy, but in a dense environment with lots of sensors, the noise is identifiable and filterable to get solid pressure trends (actual pressure values is considerably harder).
They insist on updating to newer versions of the Play Store on very old hardware that doesn't actually have the hardware power to run it.
It's a huge problem if I tell a computer to do something and it doesn't do it, it does it half way, or it usually does it but sometimes doesn't. We engineers need to have a Hippocratic Oath that starts with: 1. Never put the company's need over the user's intent.
And, yes, I understand disk caches and why we have a graceful shutdown process. What irks me is that the computer might be in the middle of doing something despite my not having told it to be doing anything.
It could easily and even possibly be fairly argued that there's a massive difference between updating 3rd party apps and updating the operating system itself.
The Play services were originally an immutable part of the core OS, but it meant that security updates relied on the manufacturer to push updates, which were useless useless at doing.
I am minded that everyone would laugh at me if I took an un-patched Windows XP system on the internet, yet using ancient Android 4 is still common place. A PC can function offline where as most people can't isolate a phone (from multiple networks) without loosing the core functionality. The PC can be blank; phones usually contain all sorts of personal and private information.
Personally I want OS's to leave me the hell alone, but actually, I can't really blame them for trying to protect their users.
Updates to the OS come as OTA notifications that I can choose how and when to apply (download+install separately, for example). I don't monitor my Play Services version, but I assume that it's silently updating in the background, unlike either my apps or the OS itself.
You’ll notice that apps that target stable protocols—POP3/IMAP mail clients, RSS newsreaders, vCard calendar apps—never force you to update. They don’t need to. The app will keep working as long as the server they are configured to talk to keeps speaking the same protocol (and it will, because public, RFCed protocols evolve really slowly.)
The fault here lies mostly, I think, with backend developers who have spent their entire careers working on web projects—where, if they want to make a breaking change, they can just ask the web frontend developers to make a matching change on the website that conforms it to the new wire-protocol, and at most the only problem users will have is that their webpage might spontaneously refresh itself if it was relying on a websocket connection. You can’t do that when you have a native frontend pointed at your backend service, but these backend engineers just don’t seem to put much weight on the needs of native frontends. It's web-frontend chauvinism, basically. (Either that or it’s their management forcing them to act as if they don’t.)
/edit: spelling
The issue isn't really one of backward compatibility but software design and function. As far as I know, Android maintains API compatibility all the way back to API v1. A simple app, like the calculator, written in API v1 should run on the latest Oreo device.
An app requires a remote service to function must maintain compatibility with that service to function. The trouble is compatibility updates and feature updates aren't delivered separately. So you can't avoid new features if a service compatibility prevents your old version of the app from functioning.
I've had my phone die well before the Uber arrived and it wasn't a problem, it showed up at the place I requested.
Once the ride is initiated the drivers phone becomes the primary client. It seems quite flexible with devices going offline (as it should, mobile networks are unreliable).
> use some of the apps nowadays that wouldn't work when you haven't updated them for a month.
This is a worrying trend but I don't think it's really that bad yet. My primary phone died recently (famous Nexus 6p bootloop) and I used my old Samsung S3 with stock Android circa 2014 and I was surprised how many of the apps still functioned properly without updates (including the ancient built-in pre-Chrome webview Browser app).
... basically my expectation these days was that they wouldn't work. But in practice 99% of my phone use is SMS/Messengers + Maps + Browsers, and they all worked perfectly fine, web standards don't advance that quickly at all, and the messengers are all using simple protocols where they had no problem.
So it's typically the edge case 1-5% 3rd-party apps like Uber that are of concern.
It's really not hard to develop APIs that are versioned. This is becoming a standard best practice among mobile/web app developers (via SemVer standard). And there's no excuse for a big company like Uber to not support ~1-2yr old apps.
All of those things shouldn't be a problem in the first place.
But otherwise it's not a massive problem, yet. But one we in the software community should promote as best practice and provide social pressure/ridicule when not done.
When do you think it starts becoming ridiculous to demand the rights to not update to the user? Do you think that a juicer that stops working because its firmware hasn't been updated recently, and they just changed their expiration date API, is reasonable? After all, yeah, I'm using their health-friendly juicer as a service, just as I'm using a TV to decode the airwaves as a service.
If it can't do its job at all without an internet connection then denying functionality if you don't update is entirely reasonable in my book. If it can do its primary job without an internet connection then no it's not.
I think an one-month-old app that refuses to work is a bit too much.
You didn't update your apps for a month, it shouldn't be that big of a deal but security fixes, bugs, and new features are several reasons why they need you to keep it up to date.
For example they introduced a new feature allowing drivers to see you on the map so they can find you more easily (you can disable it) most user will add extra pressure on the support by contacting them telling them they don't have that feature while it's 100% their fault for not updating, now if they force updates that's will reduce their costs.
Your view of it is simplistic and you only see your own benefit and not the full picture.
Yes the things you use everyday could stay the same for you and just work but that won't bring any income to the companies, if you buy a juicer that needs to be connected to the internet to work that's your own stupid decision.
Your device, workflow, and lifestyle are generally pretty integral to your devices, work, and life, so it's natural to want to exercise control over them?
I'd argue that the real problem is that software is eating the world, and companies are becoming less relevant to everyday life, but trying to force ways to stay relevant.
As an end-user, I'd like things the way they are. If I'm used to the app and it works, why should I be forced to update the damn thing so that it keeps working?
It's not really Windows' fault that the applications are being bad actors, though, so I don't see how that suddenly invalidates the backwards compatibility of the OS. Also, I'm sure if you use a 30-year old app, it's not going to prompt you to update before using it.
God forbid other technology communities tolerate frank, accurate, and warranted cynicism.
Last night I was in a discussion about the whole shift in market power that a central role playing app like WeChat could enable: the premise of debate was that Alexa and competitors are potentially a step towards a new interest in text interfaces. Only our own generation has had our vision occluded by growing up in the command line interface, which is too involving and too complicated for widespread use. The word involving, we chose to describe the experience of working with a CLI, which, having stripped away every attribute we could, we concluded that you had to be involved in a continuous thought process to gain any utility from a CLI. Whereas we figured casual users wish to receive answers to questions, or refine queries without any parsing or precise expressions. So if we had a text interface that was more, so to speak, open ended, then also voice might be workable, and the interface become a widely used interaction. This then could really create the foundation for individual customisation, as local processing power can be applied to learning from the user's total interaction with many different types of connected application, as well as from existing phone voice command systems. We imagined further, that the opportunity might exist for a newcomer to enter this space, as the need for a independent and unaffiliated party for brokering online interaction is potentially a strongly perceived need, whilst we figured it remains one that is subject to the same negative perception of big internet names in a era when I more than my colleagues think that saturation reporting of privacies dying by the thousand cuts has engendered public apathy. We all agreed that public apathy or cynicism, even straight up hostility towards any attempt at selling a "do no evil" message, is a significant hurdle. The question we retired to consider, is how you can organically grow the required trust, in a market where giant capital can leave you alone with outmoded paradigms and entirely whole technologies behind the willing big spenders. As we have seen, there's no marketing to generational segments, when it comes to a web where the generations would not willingly be separated by communications islands - at least presently you couldn't sell a safebook social network to seniors and expect them to get their grandchildren on the platform.
Once gone our ways to home, a few hopeful texts were thrown around, wondering if there was some way to get sufficient a body of technology figureheads to be part of a board approving technologies for some kind of do no harm branding evaluation. This died the moment one of our more cynical lot linked a sheet of the quick results of his rough and ready search for directorships held by the first ten names we'd bandied about. He signed off, "you already know each advertising budget for those."
Step 2: ask someone for a charger and meanwhile use the wifi to update the app, also buy something from the cafe
Step 3: enjoy the thing you bought for a bit while your phone charges and you now have a place to wait your Uber without freezing in the rain
At least I don't have that problem with my Linux computer and I love it. It works exactly when I expect it to, and it updates exactly when I expect it to.
I turned off auto-updates on my phone.
So this happened. Last year or so I traveled to SF and tried to call an Uber home after a long day of walking around. My phone had 5% battery left. I opened the app and there it was... The maps and everything showed up, but then it blocked the UI with the message: "You haven't updated the app in a month. Uber won't work if you don't update it right now." It really rustled my jimmies. In the next 15 minutes, 3 of us (2 are foreigners with no cell connection) had to stand in the freezing rain when the damn thing was updating with my 2.5G connection. When the Uber arrived, I had 1% left and not long after I got in the car, my phone shut down. I was so worried the phone would die before the car arrived.
The other day I talked about how backward-compatible Google Maps is and unfortunately it made the news on Slashdot. Some people were like, oh yeah, Windows is backward compatible with 30 years old apps. Are you a millennial/a shill for praising them for supporting their API for 10 years? Yeah, keep talking about Windows, until you fucking use some of the apps nowadays that wouldn't work when you haven't updated them in a month.