This is absolutely correct. Instead of maintaining any sort of ABI and API stability, Apple offloads a constant burden of maintenance updates across thousands of developers, just to keep existing apps from breaking every year with a new iOS version. This takes time which could be spent in more productive ways such as fixing bugs, adding features, or developing new apps. It seems like the wrong trade-off, since stability would offer huge, multiplicative benefits across the whole ecosystem. Apple does seem to want apps to die to mitigate the glut of shovelware in the app store, but there has to be a better way (human curation still seems like the only reliable approach for app surfacing and discovery.)
Most iOS apps are games, but in contrast to developing for other game platforms, iOS developers have to continuously update each game yearly simply to keep it working. (Not to mention Apple was happy to kill off 32-bit games on both iOS and macOS, and many games were never converted to 64-bit.) Compare to other handheld game platforms such as the Nintendo DS/DSi/3DS where games mostly kept working across major and minor hardware revisions along with dozens of firmware revisions from 2004-2020, or the Switch where games have generally worked from across Switch 1 and 2 from 2017 onward.
Maybe it’s worse for games, but I’ve been maintaining non-game apps on both iOS and Android for many years and keeping the iOS halves functional has generally been pretty chill. Updates aren’t required all that often and it’s rare that APIs break entirely on me, especially if targeting older SDKs. Usually the worst post-WWDC fallout is needing to recompile the app in question with minimal changes.
By comparison, Android is much worse. The Play Store kicks you off for not submitting updates much more quickly and the whole ecosystem is in a permanent state of simultaneous flux and obsolescence. Whatever deity help you if you let an Android project collect dust for a year or two… you’re gonna be fighting battles on multiple fronts getting everything up to date. Gradle conflicts, APIs getting deprecated without fully baked replacements, divergence in behavior between OS versions… it’s a real hoot.
>Usually the worst post-WWDC fallout is needing to recompile the app in question with minimal changes.
But that still means that any app that is not actively maintains dies very quickly. I've got software I wrote for Windows 7 that still runs fine on Windows 11.
> This is absolutely correct. Instead of maintaining any sort of ABI and API stability, Apple offloads a constant burden of maintenance updates across thousands of developers, just to keep existing apps from breaking every year with a new iOS version. This takes time which could be spent in more productive ways such as fixing bugs, adding features, or developing new apps. It seems like the wrong trade-off, since stability would offer huge, multiplicative benefits across the whole ecosystem. Apple does seem to want apps to die to mitigate the glut of shovelware in the app store, but there has to be a better way (human curation still seems like the only reliable approach for app surfacing and discovery.)
I keep trying to explain this to people but it's hard enough to describe the issue, even harder to get people to care, and an impossible battle to change Apple. I don't actually think they're doing this to kill old apps. I think it's a very cynical and calculated plan to require developers to actively maintain their applications, *thereby requiring the use of subscriptions as the only viable business model for developers.* That is Apple's primary revenue stream by far, and they're making far more money now that we have to subscribe to workout apps instead of buying them once and using them for years.
Apple has been dropping older subsystems and backwards compatibility layers long before app subscriptions were the default way people got paid for software. The 68k -> PPC transition happened in the mid 90's and 68k support was dropped entirely somewhere around OS 8 and the start of the iMac era. The Carbon framework might have been the most long running one, going from about 2000 to 2012 for deprecation and basically ending once the 64 bit transition happened around 2018. The PPC -> Intel transition, including the original Rosetta emulator was ~2005-2011. The app store itself only debuted in 2011.
I do agree that Apple does this in part to force developers to either stay active and maintain their apps or stop shipping for the platform, but I personally posit that the move of more and more apps to subscription models is simply due to how many more apps are connected and user expectations for update timeliness (and the devaluing of updates both by increased popularity of "free as in beer" open source apps and also the distribution of no-cost OS updates by Apple. People expect more for free and expect it as soon as someone notices a problem. I think the idea of not only waiting a year or more to have new features or some bugs fixed and then on top of that having to shell out more money for that is just not something people are as wiling to do. So subscription models become necessary to fund the continuous work that goes into keeping up with all the new trends. Apple's dropping of old libraries and frameworks is part of that churn, but it's only one part in a sea of other pressures driving the subscription model.
>thereby requiring the use of subscriptions as the only viable business model for developers. That is Apple's primary revenue stream by far, and they're making far more money now that we have to subscribe to workout apps instead of buying them once and using them for years.
Apple earns almost twice as much revenue from selling iPhones ($210B per year) than it does from "Services" ($109B), and "Services" includes far more than just App store commissions.
Thanks for the correction. I should have said profit, and I should clarify further: gross profit for the App Store and global iPhone production is similar ($84B and $88B), but the App Store and other services have nearly double the profit margin and is growing much faster than physical products.
Unfortunately well-written native macOS desktop software (Apple's own apps are sometimes exceptions, if we ignore monstrosities like the Music app) seems to be dying (new "desktop" software often being a wrapper for a clunky web app), while half of my Steam library that used to run on macOS no longer does. (And removing Rosetta2 might kill the other half.)
Ios actually is far better than macos for old apps. I have a few ancient maybe 8-10 year old ios apps on my iphone that have not received updates and still work fine. Can’t say the same for macos because they decided to drop 32bit support.
Contempt.
use any apple device 2 updates back or more. you're screwed.
You would accept this in no other place in life, except that apple gives it for free, and puts a 'security' sticker on the box.
It's a racket. Planned obsolescence 2.0 - Users forced to update, update removes features, breaks working apps, breaks paid for ip ( literally removed from phones), apple blames the devs. bullshit.
Switch OLED is still great, as the Switch 2 display is something of a downgrade.
But the Switch 2 shines for Nintendo gaming on a 4K display and for actually being able to play PS4-era games well on a handheld.
I am not completely sold on Mario Kart World's open-world driving (vs. Mario Kart 8's track-only approach), but it's still a lot of fun, plays well, looks fantastic, and scales up to 24 players for LAN games and tournaments.
> The only reason to buy Nintendo hardware is so that you can play Nintendo's exclusive games
Nintendo also pushes gaming innovation in different directions, enabling interesting experiences. It's not always successful, but is rarely boring: virtual boy (proto-VR), dual screen gaming (DS, 3DS, Wii U), asymmetric multiplayer (Wii U), split controller with motion controls (Wii, Switch), advanced haptics (Switch), screen-free gaming (1-2 Switch), glasses-free lenticular 3D (3DS), hybrid cardboard gaming (Labo/Switch), slab handheld (2DS), hybrid handheld/TV gaming (Wii U, Switch), asynchronous network interaction and game data sharing (3DS street pass), moderated social networking (Warawara Plaza and MiiVerse on Wii U and 3DS), etc.
The consoles are carefully designed. Game Boy had a non-backlit, reflective display that enabled it to be used in broad daylight and helped it achieve a 50-hour battery life. GBA SL and Nintendo DS/3DS were attractive and functional clamshell designs. GameCube (a compact and rather charming purple cube design) had a handle to encourage people to move the system to different TVs or bring it to friends' houses. Switch has a kickstand and a dock system to enable quick switching between handheld, tabletop, and TV-attached gaming, all without restarting the game.
It's also the best game in its category (which Nintendo basically invented), offers terrific local multiplayer on a single console, and is something you can enjoy for years with friends and family.
> Nintendo hardware and games were already obscenely overpriced imo
Nothing against those $1 game sales on Steam or gog.com (or "free to play"/live service games – for those who can tolerate their monetization schemes), but fun/benefit per dollar for {Mario Kart, Super Smash Bros., Animal Crossing, Ring Fit Adventure, etc.} has been huge for me, even accounting for the cost of the console and additional controllers.
Being able to pop in a physical game card and play the game immediately (even if you are offline) is another thing I appreciated about the Switch (though unfortunately some Switch 2 games are not available as real game cards.)
> Does Nintendo intentionally make its hardware really underpowered and cheap in terms of chips to juice profits? In the past this was more the case, but with the Switch 2 the hardware bill of materials is actually more costly relative to previous products like the Switch 1.
Underpowered and cheap, yes, but not really "to juice profits". See "lateral thinking with withered technology":
"his strategy demonstrated Nintendo's belief that graphical advancement is not the only way to make progress in gaming technology; indeed, after the Wii's overwhelming success, Sony and Microsoft released their own motion control peripherals."
I find with-style code so convenient that I recreate it in other languages (auto _=&foo; ...)
reply