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