4 ms·

As a dev myself, I agree. You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. Software is an ongoing

As a dev myself, I agree. You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. Software is an ongoing commitment and periodic recompiles and fixes should factor into architecture and planning. Some decisions early on can save you a lot of pain. For instance, building your app with stock UI widgets to the greatest extent possible and limiting custom widgets and third party stuff to a minimum goes a LONG way for making your apps weather new OS versions better. These days my UIKit apps only need a handful of minor changes when a new OS version is released, making them trivial to maintain. Choosing Unity was a big part of the problem in this case because Unity is terrible about maintaining particular versions of their engines over time. Devs need to start dumping Unity over this, because it’s the only way that Unity is ever going to fix it.

howinteresting 5y ago
This is simply false. Some software is an ongoing commitment. Other software can just be done and never need to be updated. An indie game with no online component falls squarely in the latter bucket.
MattRix 5y ago
Worth noting that Unity now has a system of maintaining LTS versions of each of their major yearly releases. They’re doing a LOT of stuff wrong these days but at least they’ve improved on that front.
hedora 5y ago
I build my software to last. Almost no one else seems to care, but I am too stubborn and lazy to do it any other way.
ryandrake 5y ago
> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. Auugghh! This is the wrongest thing I’ve read on HN since 2021 COVID threads. Sorry you get the distinction! Software absolutely should keep working as it did the first day it was released. The binary is the same, no cosmic rays have flipped any bits, so why should it stop executing exactly the same, but for a deliberate choice made by the platform to break backwards compatibility? This idea that software should have to get recompiled over and over with the latest SDK simply to keep doing the same thing is maybe the worst idea ever thought of in software: and Apple leads the charge.
- xlii 5y ago
  Software doesn’t work in isolation. It’s like you’d expect to take a tape with binary recorded on it and then expect it to use it on Mars. And Apple ecosystem is rapidly changing. OSes are changing every year. Phones get reiterated every year. 2 years of no updates mean 2 cycles behind. And Apple is very good with pushing updates on the users. And to be technically correct - both software on the tape brought to Mars and removed games will work in the same hardware and running context exactly the same. But for Mars context made it not runnable anymore and for Apple we’re talking about taking it down from storefront (but all existing customers can still get it). I’d recommend checking Emacs - Elisp is very stable and some code is working well for decades and yet with all the carefulness of the developers some thing breaks due to API changes.
  - 8note 5y ago
    Can people with older phones still buy a new copy of it though?
- abnercoimbre 5y ago
  I've quoted you in the past [0] and usually align with your takes. Consider attending our conference sometime :) [0] https://media.handmade-seattle.com/self-hosted-conference/ https://media.handmade-seattle.com/self-hosted-conference/
- kitsunesoba 5y ago
  Much of the time decisions to break backwards compatibility are made to remove roadblocks in the OS development process. Keeping old software for the platform running forever has a high cost, and so I think that OS vendors wanting to limit how far back that compatibility goes is entirely reasonable. If the argument is that OS vendors should include virtualized old OS environments for compatibility with old binaries to make sure OS development remains unencumbered, I could get behind that, but in that situation App Store listings of seldom updated apps should include a highly visible indicator that it’s been many years since the last update and as such expectations of significant bug fixes and support should be tempered.
wtallis 5y ago
> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. You can on Windows. Microsoft has shown us what a three decades of maintaining an OS to that standard will do to a platform and its software ecosystem. There are definitely pros and cons to taking that approach. These days, as a user I'd much rather have decent emulators of older platforms and operating systems, rather than rely on the current OS to be completely and forever backwards compatible. But that doesn't seem like a good solution for mobile platforms or their app stores.
- kitsunesoba 5y ago
  Windows really is the exception and not the rule, though. In fact in the free and open world of Linux, backwards compatibility is even worse… a binary compiled a year ago has a good chance of no longer working. Stuff like Flatpak is improving that situation a bit, but it’s still nowhere as backwards compatible as Windows.
  - wila 5y ago
    > In fact in the free and open world of Linux, backwards compatibility is even worse… I have linux binaries from 2001 that still work fine on recent Linux kernels.
    - berkut 5y ago
      If they're CLI C ones, or statically link all deps: sure.... If they link against libstdc++, Qt or Python, good luck...
      - seba_dos1 5y ago
        Games usually bundle or statically link their dependencies (just like most software on Windows).
      - kitsunesoba 5y ago
        Those three you listed have definitely been the most problematic by far when trying to run things on Linux.

howinteresting 5y ago

This is simply false. Some software is an ongoing commitment. Other software can just be done and never need to be updated. An indie game with no online component falls squarely in the latter bucket.

MattRix 5y ago

Worth noting that Unity now has a system of maintaining LTS versions of each of their major yearly releases. They’re doing a LOT of stuff wrong these days but at least they’ve improved on that front.

hedora 5y ago

I build my software to last. Almost no one else seems to care, but I am too stubborn and lazy to do it any other way.

ryandrake 5y ago

> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. Auugghh! This is the wrongest thing I’ve read on HN since 2021 COVID threads. Sorry you get the distinction! Software absolutely should keep working as it did the first day it was released. The binary is the same, no cosmic rays have flipped any bits, so why should it stop executing exactly the same, but for a deliberate choice made by the platform to break backwards compatibility? This idea that software should have to get recompiled over and over with the latest SDK simply to keep doing the same thing is maybe the worst idea ever thought of in software: and Apple leads the charge.

xlii 5y ago
Software doesn’t work in isolation. It’s like you’d expect to take a tape with binary recorded on it and then expect it to use it on Mars. And Apple ecosystem is rapidly changing. OSes are changing every year. Phones get reiterated every year. 2 years of no updates mean 2 cycles behind. And Apple is very good with pushing updates on the users. And to be technically correct - both software on the tape brought to Mars and removed games will work in the same hardware and running context exactly the same. But for Mars context made it not runnable anymore and for Apple we’re talking about taking it down from storefront (but all existing customers can still get it). I’d recommend checking Emacs - Elisp is very stable and some code is working well for decades and yet with all the carefulness of the developers some thing breaks due to API changes.
- 8note 5y ago
  Can people with older phones still buy a new copy of it though?
abnercoimbre 5y ago
I've quoted you in the past [0] and usually align with your takes. Consider attending our conference sometime :) [0] https://media.handmade-seattle.com/self-hosted-conference/ https://media.handmade-seattle.com/self-hosted-conference/
kitsunesoba 5y ago
Much of the time decisions to break backwards compatibility are made to remove roadblocks in the OS development process. Keeping old software for the platform running forever has a high cost, and so I think that OS vendors wanting to limit how far back that compatibility goes is entirely reasonable. If the argument is that OS vendors should include virtualized old OS environments for compatibility with old binaries to make sure OS development remains unencumbered, I could get behind that, but in that situation App Store listings of seldom updated apps should include a highly visible indicator that it’s been many years since the last update and as such expectations of significant bug fixes and support should be tempered.

wtallis 5y ago

> You can’t really expect to just toss a binary over the wall and forget about the project for the next decade. You can on Windows. Microsoft has shown us what a three decades of maintaining an OS to that standard will do to a platform and its software ecosystem. There are definitely pros and cons to taking that approach. These days, as a user I'd much rather have decent emulators of older platforms and operating systems, rather than rely on the current OS to be completely and forever backwards compatible. But that doesn't seem like a good solution for mobile platforms or their app stores.

kitsunesoba 5y ago
Windows really is the exception and not the rule, though. In fact in the free and open world of Linux, backwards compatibility is even worse… a binary compiled a year ago has a good chance of no longer working. Stuff like Flatpak is improving that situation a bit, but it’s still nowhere as backwards compatible as Windows.
- wila 5y ago
  > In fact in the free and open world of Linux, backwards compatibility is even worse… I have linux binaries from 2001 that still work fine on recent Linux kernels.
  - berkut 5y ago
    If they're CLI C ones, or statically link all deps: sure.... If they link against libstdc++, Qt or Python, good luck...
    - seba_dos1 5y ago
      Games usually bundle or statically link their dependencies (just like most software on Windows).
    - kitsunesoba 5y ago
      Those three you listed have definitely been the most problematic by far when trying to run things on Linux.