If they got depreciated once, it's gonna happen again. Apple should invest in Microsoft-tier backwards compatibility if they want to avoid publishers abandoning their software.
As an end user it’s already annoying how, mainly big devs, are extremely slow in adopting the latest APIs, this would only motivate them more to just sit on their laurels.
As a dev for Apple platforms it would become a buggy mess and would lead to less bumping of target OS versions, which in turn leads to needing to reinvent wheels and coming up with time consuming workarounds.
Just one look at the gazillion ways Windows 11 has implemented configuration apps, from as far back as the XP era, has me shudder. You start out with Win 11 stuff but oh, you want to use that one thing? Now you’re lopped into Windows 7 stuff oh you want this other thing, enjoy this XP app, etc, etc.
All in the name of backwards compatibility, no thank you.
Hell, the fact that they had to skip Windows 9 because of so many devs checking for a 9 to detect 95/98 is another such messy nonsense.
If I had to choose between that experience or Apple forcing me every year to learn an entirely new programming language + UI framework + persistent storage framework I’ll happily become a polyglot because the MS way of doing things is ridiculous.
What I really dont get is why in some cases, when it looks obvious to me that the XP UI is just some Microsoft GUI for the drivers, why Microsoft didn't consolidate those APIs into the modern UI. They own the entire run-time, I don't understand why they cannot add a translation layer.
XP? They still have the NT 3.5 UI if you dig deep enough. Translating these is just asking for trouble when an important checkbox moves out of the frame because the original dev, in 1993, placed it with absolute coordinates. And there's no way in hell MS has access to all of these vintage drivers.
The driver has to talk to the OS somehow, and they have insane amount of telemetry, might as well use it to some actual usefulness. Always allow a way to "use the old UI" with this approach, but at least then, you can have more uniformity.
Most software is written for ten year business cycles. Maybe the Apple approach makes sense for most consumers and the few little apps they use, but there's reasons why Microsoft is so strong in the enterprise, and backwards compatibility is a huge part of that.
I’d say that more and more are moving to SaaS and/or platform-agnostic web-based stuff (even if it just runs on an on-prem server).
But you’re right in that a lot of enterprise software is/was written with ten years or more in mind.
Having seen it in action, I wonder if that’s the right course of action just in terms of security and what passed as acceptable UI alone, but I suppose that’s a topic for another time. For most enterprises, it’s a cost consideration where there’s a high tolerance for crap as long as it means that it saves money.
While Apple is nowhere near as uncommon in the enterprise world as it used to be, it’s no secret that enterprise is far down Apple’s priority list. Backward compatibility (or rather lack of motivation to facilitate that) might very well be a factor in that, but it seems to be more a matter of not needing to tap into that market.
I suspect Apple considers developers ignoring a five(?) year notice period that 32 bit compatibility will be dropped a sign that the publisher has already abandoned their software.
Expecting old software to be backwards compatible forever is unrealistic. Even modern 64-bit Windows doesn't support 16 bit applications, and the only reason this isn't a problem is because of how long ago they were of any importance.
Old software still lives on in emulation and old hardware. If a developer doesn't feel the need to keep it updated for new hardware, it can join the outdated hardware it was made for in the archive.
Not sure if you linked the wrong video, but the one you linked to barely supports your comment.
Setting aside that abandoning OpenDoc turned out to be the right call, I see a dude trying to get a rise out of Jobs and Jobs handling it in a very respectful way, going as far as admitting they make mistakes and that he is flawed, but that ultimately the decisions are made with the end user (and sales) in mind and less with what kind of nifty technology is behind it.
Specifically on the matter of 32-bit support, not dropping it would’ve meant not being able to make the leaps forward that they were able to make, which led to a better user experience.
From the developer side of things, as a developer for Apple platforms, it’s a silly discussion to begin with because in 99% of the cases it just meant recompiling it against the latest SDK.
So I have no lost love for devs that couldn’t be arsed, even ignoring the fact that the entire ecosystem is known for rapid improvements and continuous maintenance. In fact that’s what most indie devs love about it.
> So I have no lost love for devs that couldn’t be arsed,
How are teams that no longer exist supposed to recompile anything? Plenty of source is laying around where the last person who knew how to compile it left the company years ago and no one even knows how to check the software out from the source repo anymore.
(Pre Git, it wasn't always obvious how to even pull software down from repos, tools like perforce allow for fancy remapping of folders so you cannot necessarily just pull source down, also I've worked in repos where you needed specially modified scripts that weren't in the repo so you could actually build things!)
Microsoft's MO has been that once the end user has acquired an executable, that program will keep working damn nearly forever.
16bit support was the only time they ever dropped anything, and people are still upset about that.
As I stated in a reply[0] to a similar comment below, the way you’re framing it doesn’t reflect the reality of this specific 64-bit transition.
> How are teams that no longer exist supposed to recompile anything? Plenty of source is laying around where the last person who knew how to compile it left the company years ago and no one even knows how to check the software out from the source repo anymore.
This transition started five years after the birth of the App Store. Most of the abandoned apps and games were created in the two years between the start of the transition and the deadline, not to mention that many of those developers happily published other apps and games after the transition was complete.
So, the notion that there were no people around or that the source code was inaccessible is not believable.
> (Pre Git, it wasn't always obvious how to even pull software down from repos, tools like perforce allow for fancy remapping of folders so you cannot necessarily just pull source down, also I've worked in repos where you needed specially modified scripts that weren't in the repo so you could actually build things!)
This was well after the birth of Git. At the start of the transition, more than half of the developers were using Git, and another 40% were using SVN. So, we weren’t exactly in the stone ages of software development.
> Microsoft's MO has been that once the end user has acquired an executable, that program will keep working damn nearly forever.
This is becoming less and less the case. I must install dependencies like older .NET frameworks, track down obscure dlls, or generally run into compatibility issues.
While annoying, I can’t fault them for it. It’s simply not feasible to ensure compatibility in perpetuity and deliver a smooth, innovative experience.
You see them attempting this with their abomination, that is, the control panel and its underlying systems. It’s grafted together from all kinds of components that originate from pretty much every Windows in existence.
This assumes you have all the source code for everything available, the person to do it ready, and that no compiler errors anywhere have crept in through the many revisions of the SDK. None of these assumptions hold for iOS ports that sold poorly (as most did), that were done by some team (likely defunct) as a one-off, that probably used a bunch of middleware they didn't own. It's just not worth it, otherwise it would've happened.
You’re acting like this is about decades-old software with obscure source code that’s nowhere to be found.
The transition to 64-bit started in 2013 with iOS 7, 5 years after the App Store launched and included a 64-bit compiler in Xcode 5 that year.
Not long after, 64-bit was set to default for new projects in Xcode.
That was the point developers should have made the transition.
Instead, we saw that most developers didn’t bother, and by the time 2015 rolled around, and 64-bit became mandatory, many had still published 32-bit apps in the two preceding years.
In other words, most of the abandonware was made in the two years leading up to the 64-bit requirement despite ample warnings.
Now, you have me believe that they didn’t have their source code lying around somewhere? I’m sorry, but that’s just not believable.
So, the source code was available. How about the people who could do it?
Many makers of abandoned apps and games happily continued publishing new 64-bit apps and games after the transition (e.g., Capcom), so I think it’s safe to say that the people were available.
Now, what about the difficulty of porting it to 64-bit? I can’t find an authoritative source that describes it objectively, so I’ll just have to throw in my own anecdotes.
I’ve done about 15 ports for various people with apps varying from your garden variety app to some games.
As I stated above, in most cases, it was as easy as recompiling it. In a few instances, Xcode would throw up some warnings and errors, but those were all of the “you need to do this” variety, and working through them didn’t take me (a solo dev) more than a day.
Games were a little more involved in some cases because I needed to audit pointer usage and optimize memory usage, but even so, in all cases, I had a build up and running within a week.
Would all of this been harder had this been abandonware from two decades ago that nobody had touched since? Probably.
But specifically, in the case of the iOS transition to 64-bit, it mostly boiled down to “just recompile it, bro,” as you so aptly stated in part because they were, by definition, relatively recent projects.
So to me, the ones that didn’t do it didn’t bother because it wasn’t opportune to them, rather than out of a lack of ability to do it.