(This debate is as old as computers, but I'm strongly in Raymond Chen's camp.)
It seems like a multiplicative trade-off: Apple saves a small number of hours but offloads a support burden onto thousands of developers.
I think you have to be careful about this. Apple benefits from lower costs and having more time to improve the platform; but developer time/focus/creativity is also being taxed by a constant support burden.
Backwards compatibility is not a trivial effort, and can severely constrain the future evolution of a product. Keep in mind you’re asking for a completely backwards compatible embedded device OS. Being willing to make breaking changes is part of why Apple’s software is the quality that it is.
If you want a counter example, Windows is notorious for strange undocumented behaviors and special case handling. These are consequences of Microsofts choice to fully embrace backwards compatibility. This leads to a complicated platform that is continually more and more expensive to maintain, polish, and secure.
That expensive polishing cost is what tips the scales here for Apple. Backward compatibility can get in the way to get the level of polish that they call acceptable.
> If you want a counter example, Windows is notorious for strange undocumented behaviors and special case handling. These are consequences of Microsofts choice to fully embrace backwards compatibility. This leads to a complicated platform that is continually more and more expensive to maintain, polish, and secure.
Yes, and macOS (and iOS) a POSIX operating systems that maintains backward compatibility with something from the 80s. In that regards Windows is much more modern.
Apple can’t make these things compatible, nor should they try.
I'm sorry this developer spent a couple hours hitting "build" until their app started working. If they'd done it earlier it would have been far less painful. Their sacrifice improves the community.
I say this as an iOS engineer since like 2012 and a macOS developer since ... 2004?
Carbon [1] should never be allowed to happen again. If you really want an old system, you should be allowed to virtualize it, but the world must move forward.
Going back to the original post, I find it ridiculous that Apple regularly ships breaking changes (to their APIs) and developers just put up with it. In my minds, it's like being in an abusive relationship where you think if you try a little harder and stay up to date with the latest API version maybe Apple will treat you better (they won't). Apple can get away with it because they own the whole iOS/macOS tower top-to-bottom, but if you want to build trust with your users breaking changes should be the absolute last choice.
Last time I checked, because MS worships at the alter of backwards compatibility, there are nine ways to represent a string in Windows in C and you constantly have to convert between them depending on which API you’re calling.
Every piece of code in your operating system is another vector for security vulnerabilities and something else to maintain and in Apple’s case port to a new processor. How slow has Microsoft been entering new markets because of the albatross of legacy code?
1) Compatibility wise it wasn't worse than macOS Catalina or iOS 11, which both killed off 32-bit apps; actually a typical iOS release is probably worse than Vista in terms of backward compatibility
2) Vista's security improvements (such as sandboxing device drivers, requiring app permissions, etc.) were beneficial and persist to today – and were arguably the predecessor to modern app permissions systems in macOS and iOS (and Windows 10/11)
2a) Microsoft eventually largely addressed compatibility by providing an XP compatibility mode (really an XP VM); they could have/should have managed this better
3) Vista got the UI for app permissions wrong, and users hated it; I think Apple did it better but Apple is generally better at UI and also had the chance to learn from Microsoft's mistakes.
At the end of the day, Vista's woes were largely from not paying enough attention to backward compatibility, combined with poor UI design. It was a rough transition, but Microsoft seems to have learned somewhat from the experience (although Windows 8 also had some UI issues.)
But should Apple have kept support for PPC support forever? 68K? Why not keep a 65C02 emulator around so I can run Oregon Trail from the 80s?
Sounds good to me! Pretty sure Apple 2 system software and an emulator would only be a few megabytes, and it would be awesome as something you could install for free like GarageBand etc.. Apple might also be able to acquire the rights to a bunch of classic Apple 2 apps and games...
Maybe we can convince Apple to do it for their 50th birthday. Or maybe a Mac emulator for the 40th anniversary of the Macintosh in 2024. ;-)
That's generally a good practice as buffer overflows and all kinds of entropy accumulates on an OS.
Not sure what category of software that was but e.g. for games it’s usually not an issue. I used to have a bunch of games and game-adjacent software from the first AppStore year, we’re talking the time when you’d pay a buck for a virtual rain stick which’s use the accelerometer.
They kept working until the 64b switch killed them. Rebuilding them would undoubtedly have been difficult for the author even if they’d not moved away from them, but because those’d use only minimal is features (raw-ish inputs, and setting up opengl) there’s basically nothing to break which would not be flagrant.
More importantly for better than or worse it’s just not how game lifecycles and financing go.
It isn't necessarily about API level, it could be (from time to time) about going from arm32 to arm64, to adding better-optimized builds for new microarchitectures, getting bitcode that's recompiled by Apple to support app thinning. Apple may deprecate or remove APIs from time to time that should also be addressed.
That there wasn't necessarily, specifically, a change this time doesn't mean that this program isn't about supporting that over time. It's much easier to make such changes if developers are in the habit of periodically making updates vs. being told to make a breaking update out of the blue.
And before you quote the number of “registered developers”, all of those aren’t paying developers.
The linked article already answered this:
For instance, the App Store could factor in:
- App Store ratings and reviews
- Active developer membership
- Historical behavior of the developer (ie. updating other apps)
- Number of crashes
- Number of active sessions, especially for the latest devices and platform versions
These are all metrics that the Apple already automatically tracksFirst they deprecate APIs and then remove support entirely. She said herself that she had to make changes to update her code to the latest SDK.
I think this is a fair policy as well. From Apple's POV how can they ensure many apps in the app store still work on the latest phones? If the developer has been updating the app, they can be relatively sure. If the developer hasn't, but the app continues to be downloaded with success they can also be sure the app works. But for an app the developer has (seemingly) abandoned and and nobody downloads? It's most likely broken. You could argue that that Apple should test the app before sending such a message but I think it's probably likely that (1) the majority of apps that are abandoned are broken and (2) the developers don't actually respond. It's easier to tell all the devs to get up to speed and those that actually care will submit the app for review (even if all you have to do is change a version number).
What actually sucks is if you have to rewrite parts of your app because even though the iPhone 22 Pro Max Plus w/ Turbo & Knuckles supports the same SDKs as the iPhone 4, Apple won't let you resubmit your app as is.
Oh, I like of course innovation but if we talk about mobile stuff, so something tied by choice to hw, their real update rates behind security related patches, should be very calm.
Anything must evolve to be alive, but also anything must NOT be stressed to change just some crap to prove that something have changed. That's not evolution.
Beside that, I fail to see any tangible improvement in ALL modern software to a point that I almost quit using mobile crapware of any vendor and kind, for real. I can't avoid it completely, unfortunately, but that's is.
This is squarely the fault of developers abusing the users trust.
You think App Store ratings and reviews are accurate?
They're incredibly easy to fake and buy. Scam artists are doing it all the time.
Apple requires an update in the past 3 years or else a minimum threshold of downloads. Presumably the latter is required so there are simply enough newer reviews to indicate whether it's broken (lots of 1-star) or not. These seem like pretty reasonable indicators that it's still working.
> My old code simply did not work anymore with the latest versions of Xcode. So I had to spend four hours on Saturday upgrading all my platform libraries simply so that I could compile the damn app.
Honestly that's just good hygiene. Because if they waited another 2 years, it might have taken 4 days to get the thing working. New versions of libraries come with all sorts of improvements, whether it's for accessibility or security or a hundred other things.
It doesn't seem unreasonable to me that if you're maintaining software in a public app store, you should be able to compile it semi-regularly with new versions of packages.