This is another case where Apple fundamentally doesn't "get" games. They had a plan for clearing out crap from their store which probably sounded reasonable, but nobody even thought about an entire class of programs.
Lots of stumbles and missed opportunities - like, what if they had actually been serious about making the Apple TV a Wii-style games console? They have the hardware expertise to do that at a reasonable cost, but they just have no idea about the market, and apparently no desire to learn.
I understand that Apple is trying to deal with the sort of shovelware/accumulation problem that the Wii had, but the blanket approach of culling games based on release date seems wrongheaded.
If Nintendo took that approach then they'd end up throwing away Super Mario Odyssey and Zelda: Breath of the Wild.
Apple products very much have a time and a place. Their plan is recurring revenue. Something that happened 3 years ago is almost entirely irrelevant to them. It's true with both hardware and software.
Wii-style games on AppleTV would not be a win for them. They don't want to sell a few million copies of Wii Sports once every 3-5 years. They want you buying a new 99¢ game at least once a month. They want you spending $5-10 in micro-transactions a month. They want you subscribed to AppleOne for $15-30 a month. They want you to buy a whole new iPhone every 2-3 years and start the process all over again with some new AirPods, cases and bands in between.
Apple doesn't want to sell you a new game for $59 every 2 years. They want to sell you what amount to an average of $59 worth of goods and services a month… forever. And while that sounds like a lot, that's a low target. If you have your TV subscriptions through Apple and Apple Care you can easily be contributing $100/mo or more to Apple's bottom line.
Apple is starting to remind me of auditors, but instead of trying to keep people honest/push trendy practices, they're pushing whatever's trendy in Apple's management class this month.
When do we get to the point of companies hiring "review specialists" who used to work for Apple?
Anyone who could afford a "review specialist" is probably already getting the white glove treatment this post describes, and wouldn't actually need one.
I am convinced the world doesn't understand the concept of something being "complete." It's like part of their brain can't comprehend that something is functionally whole, and any changes would actually detract from what is there.
Related: open source devs fret if a library hasn't been updated in the last month, even if it is feature complete with no bugs.
For open source code, I think the concern is practical: bit rot is real, and libraries with no recent updates are more likely to have suffered bit rot. It's not that a library can't be finished, but that the world in which it lives never stops moving. It can be a bigger or smaller problem depending on the ecosystem. Old C89 libraries have a good chance of still working, because the ecosystem isn't moving so much any more. Old C# libraries almost definitely don't, because the ecosystem is moving quickly.
maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works
quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.
Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.
I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.
I would assume a noop is automated, and the library is no longer maintained.
If, however, I saw a statement at the top of the README that said:
"Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed"
Bits don't rot--vendors break things. If my code built with yesterday's SDK and ran on yesterday's OS, and it doesn't for today's, that's not some supernatural phenomenon where digital media rots away--let's clearly blame who's causing it: SDK and OS vendors making changes that break backward compatibility and dump the maintenance burden on developers. The term "bit rot" is an attempt to shift the blame away from those who are causing the rot in the first place.
Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."
If a library is not updated in some capacity "recently" (coming from the Java land, "recent" is a different timescale than Javascript), then I have little confidence that a security issue can be resolved if discovered. Even if a library is complete, it may depend on libraries downstream that do have security issues that are no longer supported, which means it needs to swap to newer versions, etc.
The thing is, even if the lib is "feature complete", it's pretty rare to not have to update anything, since the ecosystem in which this lib evolves will undoubtely have changed. Programming language, hardware, OS, etc. everything evolves all the time.
I use an ancient library to perform some math. It's been working just fine for more than 10 years without any need for update. Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation.
I think what you are saying is simply FUD when taken as a blanket statement.
Are you passing user input into it? Does it interact with anything on the system? Poorly sanitized inputs present a very serious risk for RCE vulnerabilities.
As already said it is pure computational lib. It does not interact with anything and I use it from my code. There are tons of libraries like this. They work just fine, do not pose a security risk and have no need for update.
Anyone can cherry-pick examples to try to disprove a security principle. A pure, functional math library isn't representative of the vast, vast majority of libraries that are imported every day.
The most-used libraries across languages are for things like database access, logging, package management, HTTP, and (de)serialization. All of those things need to be kept updated for security.
> Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation.
You didn't specify the language or library.
Most libraries that people import are going to be JS, just because of the number of JS users and the minimal standard library in that language. Many are also going to operate on user input, which means they can have vulnerabilities.
The mathjs package in NPM, for example, has had tons of vulnerabilities[1].
NPM system is security abomination I agree. But I am not using it. I look at things from my own perspective. If 90% of the world programmers are bound to NPM ecosystem (doubt it) it is their problem. Not mine. I do not "import" half of the Internet for my "hello worlds".
This is only true if the ecosystem doesn’t care about compatibility, so this is just a symptom of a deeper issue. Say what you will about Wintel, but the long-term compatibility of x86 and Windows still lets me run a lot of win32 applications written two decades ago without issues.
I bet that if I moved back to Windows, KatMouse would work just as well as ever—and it was already nearly a decade out-of-date when I stopped being a daily Windows user.
I mean a heartbeat is needed sometimes to make sure something is still alive and can address critical issues if they do happen. But I do agree that libraries and apps don't need to "update" to show that.
Maybe some other way like "Hey, we're still here just the thing we're working on doesn't need an update" would suffice for most things.
By "the world" I think you mean a specific subset of people: investors/execs/the business side. I don't particularly believe that average end users or competent engineers feel that way...
I'm not sure I follow your logic. If you find a bug, wouldn't that provide a reason for updating your code? What is the utility of issuing superfluous updates when you don't have any new known bugs to fix? How does doing that shift your likelihood of fixing bugs when they are found, in any direction?
Other game platforms (game consoles, Windows) seem to have drastically better backward compatibility and API stability.
If you look at the Nintendo DS/3DS (for example), the platform had many hardware revisions (about every other year) and dozens of firmware revisions, yet games from 2004 still worked on a brand new 3DS in 2020.
On the Sony side, PS4 games from 2013 still work fine on a PS5 in 2022 (and probably through 2029.)
Steam has tons of old games that work great on Windows (but the Mac side took a major hit with macOS Catalina's 32-bit apocalypse.)
The 3DS physically included most parts of a DS, that often went unused in "normal" operations.
In my experience old games often work better in proton/wine than in Win 11.
My understanding is that the Steam Runtime also provides a stable base, that (or something close to it) unfortunately wasn't adopted in other ecosystems. Flatpak is great, but not used widely used for binaries yet.
And Playstation is way behind Xbox when it comes to backwards compatibility. Xbox backwards compatibility goes all the way back to the original Xbox released in 2001.
A PHP library I use and used to help maintain had a bit of a fight break out in the Issues on GitHub a couple weeks ago.
They were dropping support for older versions of PHP despite getting nothing from it and using none of the newer features. Just needlessly limiting the audience, and churn for churns sake.
I hear you and I get what you're saying. However, to argue the other side, maybe it's a decision based on the possibility of long maintenance going forward. Keeping track of, in your example, PHP and all of its various versions is mentally daunting. What's wrong with a project just saying, "Hey look, we're not saying it won't work for you, but if you're running these older versions, we just don't give you any guarantees that it does. YMMV."
e.g. say a bug comes up in the library, and say that it only affects older versions of PHP. Why can't the project just shrug its shoulders and be truthful that it doesn't have interest in maintenance/support against those old versions? It's better that the project declares this intention now, before the bug comes up, then later having to part ways with the old versions more abruptly.
This is why OSS is great, as you can decide if, at the time said bug is found, that you want to provide legacy support for older PHP versions, maybe through a fork or other means. Have at it, it's your software too.
Removing support for old versions is a simplification of what needs to be considered. It is a reduction of complexity. If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library - even if new features that weren't available in the EOL'ed version haven't been added yet.
> If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library
Its not. Large Linux distributions support those PHP versions for a long time in their LTS releases, and majority of web hosts and infra providers use those distros in their infra.
That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying "I'm not going to deal with something that had its last release nearly 4 years ago."
7.4 is supported on focal until 2025 for example. Centos has its own LTS and supported versions and so on.
> That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying
Yes it should. Its not 'some' provider. Its providerS. A gigantic part of the web lives on such large hosts. AWS and similar ecosystems constitute a small part of the web. This is not saying that the former is low traffic but large in size compared to AWS et al. There is similar traffic and user activity going on in both ecosystems.
You can easily 'deprecate' something and spend millions of dollars man-hours in upgrading your stack as a larger startup which uses AWS. But millions of small businesses, individuals who rely on Open Source software and such hosting providers won't have the money or time to jump through such upgrade hoops 'just because'. It is 'just because' for the simple fact that a lot of such version hops we do in Open Source software development do not bring much to the end users. And they will not appreciate their businesses getting hampered trying to go through upgrade hoops which they have never asked for.
An alternate approach to this is saying 'f*k you' to those people and doing Open Source for the sake of software development itself, without caring about end users. That would also work - but only for those who develop Open Source and who have the time to keep it updated. The general public would just move on from Open Source and start using reliable private service providers that don't break their businesses every other year.
How much effort should a library maintainer expend to keep 5.x code in place?
Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?
If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?
> How much effort should a library maintainer expend to keep 5.x code in place?
Based on the usage of the version and the support for it in large hosting/infra providers.
> Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?
Breaking backwards compatibility is practically always bad. You do it once. You do it twice. By the third time it does not matter because a large part of your users would have moved on to some other stack by the second time.
> If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?
These must be seen as ecosystems. The ecosystem would slowly move to a higher version over the span of 2-3 years starting from the point when a version starts nearing its EOL. And the users upgrade slowly on their end.
Using the same language in the article: The users would say one single F word to such a project, without the project maintainers ever hearing about it, and silently move on to some project that is not so self-indulgent and so irreverent towards its users. Nobody has the time to jump through hoops to keep their business running on Open SOurce, less suffer such arrogant sh*t.
Such an attidude is only workable if the project is a hobby one, does not aim to gather ANY kind of community/userbase, does not aim to do any impact.
> I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.
I would recommend that you prioritize your users and backwards compatibility in that order. The moment your users start trusting your project that it will not break their software, they will start upgrading easily and adoption and retention will get boosted.
JSON API spec's 'only add, never deprecate' approach is the holy grail to chase:
> New versions of JSON:API will always be backwards compatible using a never remove, only add strategy. Additions can be proposed in our discussion forum.
The Elixir ecosystem is quite good for this. I've found smaller libraries that haven't been update in a long time but still work just fine since Elixir itself hardly ever changes in a breaking way (the recurring phrase in the community being: "There will probably never be a version 2"). It's weird to get used to at first but it's actually quite refreshing.
I used an Erlang library in my Elixir project a while back that hadn't had an update in a decade. If a language's semantics don't change (and they really, really shouldn't change without either A) a very good reason or B) a really, really good backwards compatibility story) then there's really no reason for a library that does a job well to ever update.
I suppose for simple libraries this might be possible (e.g. left-pad) but how would you know in general that something is bug-free? `units` was introduced in 1979 and is still one of the canonical examples used in automated program repair research to show that new bugs can be found even in extremely well-studied codebases.
I think people might be:
1. Implicitly assuming that all nontrivial code has bugs, and
2. Using recent commits as a signal that means, "If I ran into a bug, there is someone who might fix it (or at least accept a fix PR) to take away my immediate pain.
I like that so many unix command tools (like cat, ls...) is rarely updated. Often comes with a man page written in 30 years ago. Same with a lot of C libraries.
Everything you use continuously improves. What do you use that has seen improved versions since you bought it?
Our knowledge, our abilities, our raw materials continuously improve, and everything is expected to advantage of this. Things that don't improve, are soon outdated and fall behind.
We reached the peak of software usability a long time ago, probably around the turn of the century. Now it's all about trendchasing, change for the sake of change, dark patterns to squeeze the $$$ out of you, etc.
I think there's still room for real improvement: once we have afforable displays that cover your entire wall, imagine what something like miro could bring you. Visual collaboration, pen drawings that turn into organizated information, architecture diagrams that can be turned into low-code models and running software, all whilst collaborating with others all over the world in front of their digital display walls.
Last 2 years, the thing i miss most about working in the office, is the ability to collaborate with co-workers in front of a huge whiteboard. The brainstorming, ideation. Miro is nice, but it deserves a huge screen, it needs more interaction with your co-workers, and it needs to help you take your drawings into real value (running software, designs that can be fed into 3d printers, cnc machines, etc).
From the Tex Tuneup of 2021: "The TEX family of programs seems to be nice
and healthy as it continues to approach perfection. Chances are nil that any documents produced by previous versions of TEX or METAFONT will be
affected by the changes in the new versions"
I don't think culling games/apps based on age is the right approach to improving discoverability.
I don't see Nintendo removing old Switch games from the eShop.
I don't see Apple Music removing the Beatles because they haven't updated recently.
My recommendation, which Apple's (obnoxious) ad business would never accept, would be to
1. Remove the obnoxious and generally useless ads which eat up the top half of the first page of app search on the iPhone.
2. Improve app search with more options and a fast, responsive UI. Also they might consider allowing you to consider ratings from other sources such as critical reviews vs. user reviews (a la metacritic.)
3. Better human curation with more categories. This is the same approach that Apple Music takes and it seems to work well. Games should have Artist/Studio/Developer pages as well as Essentials lists to facilitate discovery. Same with genre/category essentials, which have a rotating list that can be saved/bookmarked.
The missing point is that they are culling apps based upon age and downloads. I think this is a reasonable criteria if Apple is trying to make space for popular and potentially upcoming apps. Yes, space is an issue if you think of it in terms of the customer's attention span.
The real problem is that developers have no choice except to offer their app through Apple's store. There is no room for the developer to offer their labour of love or niche product in a storefront that better serves their needs, or even from their own website.
> The real problem is that developers have no choice except to offer their app through Apple's store
How is this different from other walled garden game systems/game stores like Nintendo's eShop?
Yet they seem to keep older games and apps, even niche titles for a limited audience (such as music production apps or BASIC programming apps) which I greatly appreciate.
I would agree that discoverability isn't great on the eShop, but there are dozens of enthusiast web sites which are pretty good for game discovery (also aggregators like metacritic.)
And, as I noted, I think Apple already has a good approach which they're using with Apple Music - better human curation including category/genre/time period/artist/etc. playlists. Podcasts/radio shows also help.
Many games (at least ones that aren't in the "live service" category) are more akin to movies, music, or books than to some sort of perishable produce, so a curation approach that balances older content with new content makes sense.
Consoles are different because they have a limited shelf life. For example, I dug out my PS3 the other day and took a peek at their eshop. The most recent title was three years old. It also sounds like they're going to shut down the PS3 eshop, effectively ending the sale of old games anyhow. Something similar appears to be true for Nintendo. I pulled up their eshop on my 3DS and they have a message saying that it will be impossible to add funds to an account after March 20223. Presumably that means sales will end.
As for other media, brick and mortar retailers were always selective about what they offered. I suspect that we will see something similar happen with their digital variants in the coming years. I also suspect that it will be sales numbers, not human curation, that will be the basis of their decisions.
So do you want to sift through a bunch of apps that don't work on the current version of the operating system or are otherwise significantly dated?
Even in a less wall gardened environment, I'm mostly not interested in running 10 year old applications unless they're something fairly simple that really does do everything required for the purpose and still runs reliably.
In any case, as a user, I probably figure that if an app hasn't been updated in five years, it may or may not work and I'll probably at least subconsciously resent the store's owner a bit for clogging up the store with old stuff.
>I'm mostly not interested in running 10 year old applications unless they're something fairly simple that really does do everything required for the purpose and still runs reliably.
The 10 year old version of AutoCAD still runs, and you can use it today to do a ton of high-value CAD work. Thanks to Microsoft for not arbitrarily blocking it from running.
Yes. But that’s a case of having an old version of a program that you know still runs on a given platform. That’s rather different from looking for a CAD program and deciding to take one that hasn’t been updated for ten years for a spin.
Backwards compatibility benefits current, and future users. I agree that "hasn't been updated" is a concern, but you can also look for "hasn't needed to be updated". If you can obtain a legal copy of 10 year old software, you can use it for the fraction of the cost of the new version.
When I do a search in English, Google absolutely returns mostly web pages written in English. And, yes, it would be very annoying to the point of being useless if it did otherwise. Presumably if you query it in French, I assume it returns mostly French pages.
Virtual space only makes sense in terms of floorspace. If you want to access a backroom special-order item (virtually unlimited space here), you should be able to get it by searching for a specific item (or URL).
Removing apps based on downloads or lack of updates is troubling.
> Yes, space is an issue if you think of it in terms of the customer's attention span.
I don't hear independent developers griping that Apple is failing to advertise their apps and bring those apps to the attention of iPhone users. Instead, I hear independent developers griping that Apple is preventing their apps from being run on iPhones.
Therefore, I completely disagree. This is purely a matter of data storage space (cheap and nigh infinite), not a matter of limited attention.
Rectangle with capacitive screen is just that. Well designed apps should be robust to improved screen resolution, faster processors or network connectivity.
Sorry, I think you’re misunderstanding. Android vendors built compatibility layers that allowed 16:9 apps to run on 18:9 and up screens. The apps weren’t built to run on 18:9 screens but the vendors found a way regardless.
Part of what makes iPhones great is that you aren’t running apps sitting on a pile of compatibility hacks. It was all designed to work correct on the exact device you use.
In the case of Apple removing 32 bit support from the OS first and then the actual processors:
- they care about their apps not being evicted from memory as quickly when they switch apps because memory isn’t taken up by 32 bit and 64 bit versions of shared libraries.
- increased battery life by not having as much RAM - yes RAM takes energy.
- using the die space saved by not having 32 bit instruction decoding means you can use that die space for enhancements that users care about, and decrease the die size to make the phone more battery efficient
- for Mac computers, you have computers that are faster, have more than twice the battery life, are more memory efficient (meaning less swap), and can be fanless without getting hot.
> running apps sitting on a pile of compatibility hacks
You do realise the only reason iphone retina screens became a thing was to enable double pixel scaling because iphone apps at the time were coded to a fixed resolution.
That's the definition of a compatibility hack.
Of course apple being apple they managed to sell it as a feature and made every person who was happy with a 1366x768 laptop suddenly desire a retina display.
That's not all that a smartphone is, but it is most of what a smartphone is.
Most applications basically just need:
- a canvas to paint some bitmaps on
- some way to tell what part of the screen the user tapped on
- a way to get TCP/IP or HTTPS traffic in and out
- some sound output
- some persistence
- some way to show notifications
- a few other odds and ends like GPS, sometimes
Almost the entire list been supported on every major platform since the late 2000s. Yes, rich multimedia apps that make good use of additional APIs and hardware features do exist. But it's inappropriate to nuke most old "normal" applications just because old rich multimedia apps stopped working over time.
Back in the iPhone 4/iPad era, there was no facility within iOS to have responsive screens.
Apple introduced size classes and then you needed to adjust for different views for iPads once they supported more than one app being displayed on the screen.
Apple rightfully got rid of 3/ bit app support on the actual die. It introduced new permission models, design aesthetics change, new accessibility options are added, better APIS are written, etc.
Apple should just have fewer apps. I don't see why developers should cater to their customers. They buy less and require more support. They are the worst segment to support.
> A lot of Android users spend $0/yr on paid apps.
As do a lot of iOS users. I think the stat you are looking for is that, on average, iPhone users purchase more apps.
Don't forget to consider Android's massive installed user base in the calculation. Even if Droid users convert to paid at 1/4 the rate of iOS, you can make it up in sheer bulk.
They would ask the Beatles copyright owners to update their format if they posted an old 8 track or vinyl in to the music store though, right? Audio formats change, just at a more glacial pace than software dependencies. There is remastering and all that too.
> I don't see Nintendo removing old Switch games from the eShop.
The difference is that Nintendo shops have a limited shelf life, while App Store is forever(-ish). Nintendo will be shutting down the Wii U and 3DS eShops in 2023.
2023 is 6 years after Wii U was discontinued. Since the platform was frozen in time in 2017, there's no point to game updates.
Eh, this is Apple you’re talking about. They don’t know what backwards compatibility means, and your app might randomly break on the newest version of iOS. Or it might be slightly ugly around the Dynamic Island™ and Apple users would hate that.
I've personally witnessed several unnecessary and costly refactorings in my job that were done due to this weird perception the blog is talking about. All those weeks and months that were spent removing a perfectly fine tool that was working without issues.
I’m not sure the ls command has to do much if anything to support new file systems since the file system driver should present a standard interface for them.
"Planned obsolesence" as a matter of official policy. Any cultural expression older than a few years is not worth the bits encoding it. Meanwhile, GTA V from 2013 is still one of the top selling games on Steam.
The Windows port being sold at Steam is from 2015. But of course you have a point; there have been updates in the meantime. It's conceivable that those updates are what's keeping the game marketable.
Still, I don't think Steam would confess to deleting a game just because it is old. They carry a lot of games which haven't been updated in years and which still sell.
That’s not a reason, unless the platform is changing in incompatible ways, which is exactly the problem, and a largely avoidable one, as other platforms demonstrate.
There are ways to still maintain API compatibility in that case (Windows does it all the time), and it’s also not a reason to require projects not affected by those changes to recompile with the newest Xcode version each year. I’m maintaining a Swift library/framework that doesn’t use any iOS APIs at all, only basic Swift standard library calls, and I still have to produce a new build each year from unchanged source code so that the library can be consumed with the new Xcode version. That’s just insane.
Testing with a new OS version shouldn’t (and usually doesn’t) require rebuilding the project. The need to rebuild is imposed primarily by the Xcode releases here, not by the OS. And that seems entirely unnecessary. Note that breaking compatibility and having to rebuild for new Xcode versions are two independent and orthogonal issues here.
I won't continue this discussion about maintaining compatibility. This is fundamentally a philosophical issue. I agree with the sibling comment that it is the job of an OS to provide stable APIs across versions. It requires some effort (as a long-term library maintainer, I'm very well aware of this), but it is not an impossibility at all.
New features in the API indirectly benefit the end users (once apps start using them). But those new features don't have to be breaking, and that part doesn't help the users at all. It does help Apple spend less resources on maintenance, though.
If I'm aware of an issue (be it tracking, or power consumption, or ...) with the older version of the app and want to run it despite that, that should be my prerogative as a user.
The most basic, first step of maintenance is: does it still compile? Not in this case.
So another way to look at it is Apple requires developers to once every 3 years do the absolute minimum amount of maintenance, and they get a 90 day window to do it in.
Developers needing to demonstrate once every 3 years that they still have the source code and it compiles should not be an obstacle at all.
> Developers needing to demonstrate once every 3 years
You say "Developers" without qualification, missing the crucial exemption: for some bizarre reason, developers of apps that are above a certain download threshold do not have to demonstrate that their code still compiles. Does that make sense?
What Apple actually stated is the policy is for "discoverability of apps" for "the majority of users". Clearly the intention stated is to remove old, unpopular, outdated, crappy apps from the App store.
So when you ask but why are popular apps exempt? - well, they already told you exactly why, because they're popular. People still want the app.
I feel like the actual reason you're against this policy is left unstated.
> Clearly the intention stated is to remove old, unpopular, outdated, crappy apps from the App store.
1) The criteria do not include "crappy". Apple didn't claim that the article author's app is crappy.
2) What's the difference between "old" and "outdated"? The article author's app was recompiled but otherwise not changed.
3) The app is now back in the App Store. So if Apple's goal was to remove the app from the App Store, then Apple failed.
> People still want the app.
Alternatively, they could be scams that are getting downloads from keyword stuffing, fake reviews, search ads, and other well-known methods.
> I feel like the actual reason you're against this policy is left unstated.
Not at all. The same reason as the article author:
"The decision to remove outdated apps places a disproportional burden on indie developers and hobbyists"
Apple has said, in response to anti-trust claims that "developers, from first-time engineers to larger companies, can rest assured that everyone is playing by the same set of rules." But that's clearly a lie, is it not?
I said that was part of their intention, indicated by "follow current review guidelines". Go ahead now and try to put Apple's intention into your own words. What do you feel is Apple's intention behind this policy?
> "... everyone is playing by the same set of rules." But that's clearly a lie, is it not?
Large developers also have to resubmit their very unpopular, obscure apps every three years. Small developers with popular apps also do not. Everyone is playing by the same rule. You made the claim, what developers are not subject to this same policy?
> "The decision to remove outdated apps places a disproportional burden on indie developers and hobbyists"
Explain why you feel a few minutes every three years is a burden. Literally the only thing Apple is requiring you do is recompile your unpopular app and submit it as an update once every three years.
It's not disproportional on indie developers and hobbyists unless you feel they have more unpopular apps that they also almost never update. Hobbyists can make popular apps, such as that Japanese guy's side-by-side calculator app that was on the HN front page the other day and they often put more love and effort into updating their apps, even the old ones. Frankly this view that hobbyists are oppressed by needing to recompile once every three years reads like an insult.
> Go ahead now and try to put Apple's intention into your own words. What do you feel is Apple's intention behind this policy?
I can't read Apple's mind. You can't either.
> Large developers also have to resubmit their very unpopular, obscure apps every three years.
Oh give me a break. I'm done here, this is not a good faith argument.
> Explain why you feel a few minutes every three years is a burden.
A few minutes. Again, this is not a good faith argument. Your reply is not serious.
> Literally the only thing Apple is requiring you do is recompile your unpopular app and submit it as an update once every three years.
Your reply is contradicting itself, because you claim Apple's intention is to get rid of apps, but you also claim that it's incredibly easy to not get removed.
> Frankly this view that hobbyists are oppressed by needing to recompile once every three years reads like an insult.
Do you think the original article author was insulting herself?
> I can't read Apple's mind. You can't either. ... Do you think the original article author was insulting herself?
I asked what your understanding was, not what Apple actually was thinking, and you absolutely can say what you believe about Apple and their intentions; this goes to Theory of Mind that is a cornerstone of being a functional person.
> give me a break ... not a good faith ... reply is not serious .. bad faith, insulting reply
It's now clear to me that you have unstated reasons because when calmly asked to explain your reasons you went off crazy like this rather than simply state those beliefs. You feel it's a burden, but why is effort so minimal a burden? You won't say.
Your expression of concern over the blog author's character, your inability to explain your views, and those views being irrational leads me to conclude that you are simply white-knighting.
Hate away, but in this case I'm on Apple's side here. The author may be the exception where no updates are actually needed, but that does seem to be the exception. In my experience, most iOS apps I've tried downloading that were last updated 2-3 years ago simply don't work.
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.
> In my experience, most iOS apps I've tried downloading that were last updated 2-3 years ago simply don't work.
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.
I also had many games killed off by the 64-bit switch (on both iOS and macOS), but even after that a number of games that still worked were removed from the app store.
Games are definitely “complete” after a while., sometimes on first release. If they continue to work on the OS, the only reason Apple is dropping them is because they want the developer to give them another $99. The busywork this creates is a headache for everyone except Apple.
$99 from a few developers is meaningless to both Apple and the developer of a game. It's like 40 minutes of wages for an average engineer. Apple doesn't want to have to support old bugs and poor API choices in perpetuity.
What makes you think it's only a few and not large scale? And why would forcing a developer to update their feature-complete game result in stopping support of "old bugs and poor API choices"? There is no requirement to update the API level. Read the article.
Simply rebuilding and resubmitting the app with a new version of Xcode will yield a significantly different binary artifact today than a few years ago.
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.
In your grandparent comment, you said it costs everyone but Apple. Apple has manual reviewers. It would be much cheaper if all those apps didn’t have to go through the app review process. You think Apple changes their APIs willy nilly just to collect $99 a year?
>Apple tells me I could have avoided all this pain if my app was being downloaded above a “minimum download threshold”. The policy is completely silent on what this download number needs to be to avoid getting flagged as outdated–is it hundreds or thousands or hundreds of thousands of downloads a month?
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.
It also makes sense because it might not be a good idea to apply the same criteria everywhere. In an app category with 10,000,000 downloads per month, an app pulling 500 downloads a month might be a drop-worthy also-ran that's mostly just directing a few people away from better options & cluttering results. In a category with 1,000 downloads a month, the app with 500 dl/m is likely the best and most-popular app in that category and dropping it would be tantamount to dropping the whole category.
In theory if you follow Apple's guidelines then you should maximize your app longevity; in practice Apple is going to break you eventually, and quite possibly in the next OS release.
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.)
The tradeoff with killing 32 bit apps was that Apple could remove support for 32 bit code in ARM processors. Apple knew they were moving to 64 bit ARM processors.
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?
> 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. ;-)
Windows 7 had a better backwards compatibility story than Vista, and it's arguably the best version of Windows to date, ever. So whatever the problem was with Vista, it sure wasn't back-compat.
I agree. Unfortunately they've abdicated their responsibility and dumped the maintenance/compatibility burden upon developers.
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.
> It seems like a multiplicative trade-off: Apple saves a small number of hours but offloads a support burden onto thousands of developers.
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.
Android to me is better regarding of backward compatibility. Of course everything is easier since it has a much more flexible architecture, being based on bytecode and a JVM (contrary to iOS where applications are actual native binaries). The problem is that iOS is not all that well designed in that regards.
> 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.
Hard disagree. Letting your platform stagnate by ossifying bugs and poor API choices is not what I want to see from any platform provider, and I for one am happy Apple is aggressively pruning the old to make room for the new and not allowing themselves to be beholden to past mistakes.
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.
I don't understand this comment, do YOU actually ship breaking changes to your users and expect them to continue using your code or programs? Just because Apple does it doesn't mean it's actually a good idea.
Can you not? I understand sometimes you absolutely need to change a signature or deprecate a feature, but that should absolutely be the exception and not the norm.
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.
I know this isn’t an issue for the author. But for Apple to keep backward compatibility for ever, they would still be using die space for 32 bit support and have duplicate versions of every shared library both in memory and on disk.
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?
Nope, cull it all. I don't need zombie apps in store because one guy in Australia really likes it and I really don't need 10 years backward compatibility in OSes. This whole debate let ie6 go on for over 21 years... 21 years because businesses couldn't be asked to update their apps. Sorry if you need old shit emulate it.
I'm advocating for me, and users like me, not for the interests of a greedy corporation. I just want the things that I paid for to continue working. I don't want to re-buy things just so Apple can line their own pockets. I don't want to chase developers to provide updates, or if they have gone out of business, be stuck. I use technology as a tool to get stuff done. I don't need Apple to come and disable my investment in software.
If you bought the apps they will still be available to download… You can use them at least for another 2 years with a ios16 device and probably later on. You just can’t buy them anymore if you really need spacebar heating it’s on you.
This is just wrong. Some older APIs are simply insecure or inefficient for example, and of course there are things that apps must now ask permission for where they didn’t in the past.
Apple can’t make these things compatible, nor should they try.
I learned of this working at Apple that they don’t really strive for backwards compatibility. I think I upgraded some internal tool and discovered this MO. This was in such a contrast to Microsoft where I heard crazy stories of incredibly old software still being able to run. What exactly is the overhead to achieving such astonishing backwards compatibility as Microsoft has?
Mh, changing the "ecosystem" so much means the ecosystem is not stable, witch means is a crappy mass of bugs/a working prototype not a commercial product.
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.
Quite a few changes over the past few years have been reducing access to data that can be used for fingerprinting, and requiring apps to ask permission for access to user data.
This is squarely the fault of developers abusing the users trust.
Unless you did one of the gazillion things that was permissible in 2001 but is now considered insecure and was patched out of all the major browsers. Not saying that making browsers more secure is a bad thing but it's definitely not true that every 20 year old web app will work flawlessly on a modern web browser in 2022.
> In my experience, most iOS apps I've tried downloading that were last updated 2-3 years ago simply don't work.
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 tracks
> 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.
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.
I couldn't really accept this blog post because the author doesn't even realize they benefit from Apple's walled garden:
> Most people are trying to build well-designed, useful mobile apps
and then proceeds to say how the review process is not helpful because they don't weed out many malicious apps. First, confirmation bias. Second, do they have any idea how things are in Android land? It's a constant struggle against nefarious app devs trying to abuse new technologies or means of getting ad/install revenue. It's one of the things I like the least about the ecosystem I use.
In an ecosystem like npm, having such thing is next to impossible. The useful libraries that don’t depend on anything else from npm are rare, and those that are need to review their lockfiles and run npm audit and whatnot every once in a while, even if their own code doesn’t change. Otherwise it’s quite a pain to integrate them with newer codebases.
In any ecosystem at all: if it speaks HTTPS, it’s either never complete, or it ceases to function past some date.
I get the sentiment very much, but there are cases when you can’t have nice things.
I would advocate for Apple and other app marketplaces to adopt the carrot and not the stick.
Incentive App developers who make good and substantial updates, whether its new features or updating to newer system APIs, with a positive % modifier to their search results in the App store.
This way well-maintained Apps should show up higher in search rankings and there's a natural incentive for developers to keep their programs maintained. But at the same time, this would allow developers to call a program "finished" and leave it on the store without being scared of having their hard-work destroyed. Their hard-work might not be as visible, but that would be on them.
Hey, Apple, people still play Super Mario, they didn't change a single bit since it was released, 37 years ago.
But there is one reason I somehow understand Apple stance. First is security, almost all apps are online now, and new vulnerabilities are found regularly. Super Mario has bugs, be no one cares, in fact, speedrunners have fun with them, because a NES is not online and there is nothing sensitive in there to begin with. Second is Apple's own fault: they break their own system and want you to make sure you keep up.
I don't think the Super Mario comparison is entirely fair here.
Super Mario Bros runs on a single piece of unchanging hardware. Even when you play it on any other platform, you're playing it through an emulator designed to mimic the original hardware.
And that's the case with all video game consoles. Even when the physical hardware changes, you're given the guarantee that it won't be breaking to the software. The few times that has not been the case has been notable.
iOS devices don't have that guarantee. The hardware can have breaking changes. You software now has to contend with the fact that there is no guarantee that certain features may or may not be present. Things that were previously not customizable, now are. If you want your software to run on the latest iOS, it is at least partly your responsibility to ensure that it does.
Looking at the metrics Apple tracks in the App Store, it seems to me that "engagement" is all that really matters. You could have some huge number of happy users, but if they open the app only occasionally, you get numbers in red. Or you could have an app that solves an important issue but only for a small number of users, and you get numbers in red. If you're not releasing hits that people use all the time, you sink. If tons of people don't spend tons of time in your app, you sink.
Author complains about the time required to update libraries, and that's an aggravating process, but that's just an unfortunate part of maintaining an app. The real issue, again it seems to me, isn't that you have to do a lot of work just to increment the version string; it's that, ultimately, modern content ecosystems are designed according to engagement-driven revenue models. And solid, simple, quiet, long-lived, useful or fun little apps simply can't thrive when all the sunlight is blocked by towering marketing-tech giants.
> Looking at the metrics Apple tracks in the App Store, it seems to me that "engagement" is all that really matters.
This has been the name of the game in ad tech like fb, Google and social media in general. I think two worlds are clashing with each other, where consumer tech is somewhat aware of the problems around mindless scrolling and addiction, but the growth & engagement mindset of the 2010s is cemented in the culture. Apple has little reason to follow this model because they primarily make money from selling hardware. Having a software platform that protects the user from this crap is a competitive advantage against Google, who depends on ad-based revenue. Apple seems to have an identity crisis, fearing they lose out on sweet subscription fees and ad revenue, now that most apps are free. This in turn is creating conflicts of interest, where they end up fighting their own customers.
If regulators would bark and bite harder around anti-competitive behavior, it might actually force corporations to focus on what they're good at instead of everyone building their own mediocre walled gardens that grow like a cancer and eats the company from within. At least, that's my wishful thinking..
Additionally, updating libraries periodically is inescapable for any app involving network connections or handling arbitrary user content, because doing otherwise means exposing your users to vulnerabilities.
Fully offline, totally self-contained apps are a different matter, but those represent an increasingly small percentage of apps.
You're completely right. And I wouldn't single out just Apple here, they're falling into the same trap as others. And this is going to be a recurring theme across all domains. We're attempting to model things like 'usefullness', 'credibility', 'importance' etc into measurable metrics because of the pressure to scale and monopolize the market. Its scary to think that for all the talk of hiring the 'best and brightest', its these metrics that supposedly the smartest engineers in the world come up with. Its pure hubris on our part.
There is a dystopian arc, but I prefer to be more optimistic. I would think a legal mandate that champions interoperability, open data standards, and platform openness will put a dent in this march towards convert the human experience into numbers.
> So I had to spend four hours on Saturday upgrading all my platform libraries simply so that I could compile the damn app.
I sort of assume this is the actual point? Apple presumably wants to drop support for older versions of the SDKs, and that requires that app developers update to the newer versions. I think you can make a reasonable argument that dumping work on third-party developers to simplify things for themselves is bad, but the author's belief that it was simply pointless busywork is probably incorrect from Apple's perspective.
I suspect the minimum download threshold to be exempt from this is _very_ high. Maintaining backwards compatibility for a small fixed set of apps doing things an old way is a categorically different problem from maintaining backwards compatibility for every app out there.
This is a great point, but if true, Apple should do a better job of communicating the reason, including specifics, not just say "your app is rejected because it is outdated".
If they have specific libraries or APIs that they wanted to deprecate, I think developers would understand that. But the current implementation of "anything 2 years old is too old" is arbitrary.
If this was really about deprecation, they wouldn't have a "minimum monthly downloads" exemption either. This policy is just a way to clear out old, unpopular apps from the store
> This policy is just a way to clear out old, unpopular apps from the store
Except popularity doesn't correlate with utility when it comes to apps. Probably only addictive games and social network apps will pass whatever arbitrary threshold has been set.
This will harm any one off apps built to satisfy a niche purpose downloaded by a small set of users. Which Apple probably think are not important, like all of the little high street shops, except cumulatively they might affect a majority of users. Also if it's measured by "downloads" rather than "installed", then it could take out larger more widely used apps that are considered complete by both authors and users, but don't have enough daily new users to pop up on their radar as important enough... this is similar to the "maintenance" fallacy of NPM, where frequent patches = better, even though if your package is small and well written you should be making no patches as a sign of quality.
Traditionally, this is a significant philosophical difference between Apple and Microsoft that goes quite a ways towards explaining how Microsoft gained and held dominance for so long in the business sector.
Businesses don't want to be told that their working software needs to be updated to make a vendor's bottom-line cheaper. They recognize cost-shifting when they see it and respond by backing towards the exits. Microsoft maintained a philosophy for decades that it was their responsibility to, if at all possible, maintain backwards compatibility with older Windows software as a market differentiator. The primary times I remember them breaking this policy were security related.
(That having been said, I got out of active development of Windows software around Windows 8, so this may have changed).
it seems like that on a long enough timeline however, promising that legacy cruft will always keep crufting as it did before seems like a huge burden that leaks into your ability to deliver quality in your current offerings.
Sure there are old things that are good and "complete" but far more old stuff is just old and could well be burnt to the ground, except for the fact that you have some customer somewhere relying on its oddities and unintended behaviors as an essential feature of their integrations.
I feel you are arguing for real harm now, versus potential harm in the future.
There's no sign that being very-backward-compatible is holding Windows back that I can see.
In the other hand I have collected a set of utilities into my work-flow that are easily 20+ years old, and they all work fine.
The last major cull from Microsoft was that 16bit programs ceased to work on 64 bit platforms. Other than that I've never had an app fail.
Most of those utility supplies have long since disappeared, retired, or died. But I can still keep transferring those apps to the next machine and they keep running.
None of this impacts the quality of my current offerings. Ultimately all this costs me is some cheap disk space.
I have a couple camera apps from the mid 'aughts that were written for Windows XP that still function fine under Windows 10. Same thing with an old photo scanner, that just only recently failed. My last SCSI dependent peripheral. Ran fine on Windows 10, on ancient software, using ancient TWAIN SCSI drivers, until the scanner itself failed. As I moved from XP -> 7 -> 8.1 -> 10, the first thing I did was load up all my old photo software to be sure it would work.
My father has an ancient scanner from the XP era and the only thing that still works with it is a Windows XP VM he happens to have (I assume later windows could work too, but the XP exists for other reasons and so we continue to connect the scanner to it).
Maybe Linux could be beaten to work with it, but this works well enough.
Again, I don't think people would have as much of an issue if it was clearly about deprecation.
Something like Google's minimum sdk version is annoying, but understandable. It's technical and concrete - you must link against version X because version X-1 is going to disappear.
This is not that. It's culling apps that are arbitrarily too old and arbitrarily not popular enough. They must be keeping around old sdk versions if those old but popular apps are allowed to continue on.
> The primary times I remember them breaking this policy were security related.
And they also went above and beyond to make it happen too. That time when they byte-patched a binary which they didn't have the source code anymore comes to mind.
This is the single biggest reason why Microsoft continues to be dominant in the market of practicality. Microsoft will bend backwards 420 degrees and land a headshot to make sure something from 30 years ago will run (within reason) on the latest version of Windows.
That's the reputation, but it's far from true at the moment. For example, there are numerous games from the 2000s that don't work anymore (I mean crash at startup or soon after, not some soft "not working like before") in any compatibility mode on modern Windows. I'm more familiar with games, but I'm sure the same is true of various other kinds of software (though graphics drivers may well be an important part of the problem, so games may well be over-represented).
Games depend on more volatile elements like graphics drivers and APIs, like you said, so they aren't exactly representative of Microsoft's backwards compatibility efforts. That said, there are still quite a lot of games which owe their continued operation in modern Windows to Microsoft's veneration of old programs.
A better example is productivity software, like Photoshop and Illustrator or Paint Shop Pro. I can get Paint Shop Pro 5, a raster graphics editor from 1998, to run on Windows 11 just fine, for example. Another is Microsoft Office, in which Microsoft goes out of its way to make sure documents created long ago will load and work fine in modern Office, and ancient versions of Office itself will happily run mostly fine on modern Windows too (eg: I run Office XP on my Windows 7 machines).
Only things I've ever noticed that had issues in modern versions of Windows with is software reliant on old, specialized hardware (for example, dental imaging software) and games. Wouldn't really put the blame in these areas on Microsoft, as they don't provide the drivers nor the custom graphic API's (notice that most old DirectX software has no issues working) - and hell, you can still run your 40-or-so-year-old apps on a 32-bit version of Windows...
Games were among the worst offender in terms of writing on the disk outside of user space (including Program Files and the registry).
Old games were also quite often doing direct access to graphic cards outside of official APIs
And games are not business software. An old game that stops working is "too bad, move long", accounting software that stops working has real life consequences.
That's not the market they care about. What they care about is that the stupid labelmaking application my employer uses for its annual conference whose vendor went out of business in 2005 still runs today even though it was compiled for Windows 2000.
Games, especially in the 90s (and some early 2000s) did a ton of API abuse so they are among the harder types of software to keep running. Still, most do work out of the box and with 3rd party compatibility shims like dgVoodoo (for the older ones) and DXVK (for the more recent ones) stuff tend to work since the breakage is still very minimal.
More regular applications tend to be much easier to get working though. E.g. something like Delphi 2 or C++ Builder 1 work out of the box just fine. The biggest issue with older software is that they sometimes had 16bit installers who do not work with 64bit Windows. Windows comes with some updated stubs for some popular installers and it is possible to manually fiddle with some of the unsupported ones to run the 32bit engine directly, though something like odtvdm/winevdm that emulates 16bit code on 64bit would also work.
But in general you can get things working, depending on how well the application was written. In some cases (games, 16bit installers) you do need workarounds as they wont work out of the box, but even those workarounds are based on the 99.9% of the rest of the system preserving backwards compatibility.
I remember the old trick on MacOS of calling `getNextEvent()` instead of `waitNextEvent()` to make sure no other processes got CPU cycles.
Worked generally okay until the era of the Internet came along and after you quit the game, all manner of programs would crash when the network stack suddenly found itself teleported an hour or two into the future and couldn't cope.
> The most impressive things to read on Raymond’s weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility ...
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
> ... Raymond Chen writes, “I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.”
> A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work. For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple’s official Bible of Macintosh programming, there was a tech note saying “you can’t do this,” they did it, and it worked, and their programs ran faster… until the next version of the OS came out and they didn’t run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.
---
This really gets into a philosophical difference of how software should work and who should be maintaining it. As a user, I love Raymond Chen's approach. As a developer, trying to maintain bug for bug compatibility with older versions of the code is something that scales poorly and continues to consume more and more resources as more and more bugs need that bug for bug compatibility across versions.
Not anymore. That may once have been true but circa Windows 8.1/10 that changed substantially IME. It really came to a head when Windows 7 support was dropped but I spent several years consulting and helping people migrate really really old software (which should have been replaced) that was Win 3.11/DOS based from Win7 to either Dosbox or Wine on Linux systems because Windows 10 specifically couldn't actually support running them anymore. Compatibility was broken in a rough way with 10 for very old applications which were otherwise working.
It's fine to argue typical desktop applications need to be updated but purpose-built applications cost money, so when you have things like a POS terminal installed in thousands of fast-oil-change locations and it's from the Win3.11 era working perfectly fine for years but suddenly stops working after moving to 10, that's a sudden cost on a business (especially with no warning). Yes, you can argue that companies should be updating that kind of software, if only for reasons of security (I often did). The bottom line tends to be king, especially in smaller businesses, in my experience.
Which is the reason that Apple is never going to conquer "traditional" gaming. Traditional games (ones that are NOT perpetually updated live services) and rock-solid-stable development targets have always been very close -- game consoles would always be guaranteed to run any game that's ever been officially released for it, even if it's an unpatched launch-day game running on the final hardware revision of console 8 years after release.
Even if Mac hardware manages to vastly outrun the top end gaming PCs on raw performance, they'll never be seen as serious mainstream targets for this reason alone.
> But the current implementation of "anything 2 years old is too old" is arbitrary.
To an extent, but the reality is that an unacceptably-large percentage of apps that are 2+ years old are not correctly handling current screen sizes and reserved sensor areas.
> This policy is just a way to clear out old, unpopular apps from the store.
Great. This is the kind of active culling/editing an app store requires to remain vibrant.
Yes, I agree. All users should be forced to re-evaluate all the apps they are using everytime they get a new device.
It doesn't matter if that tool you currently use is perfect, or the game you play is just fun as-it-is, it is clearly harmful to you (and makes the app store "less vibrant".
Everything older than 2 years must go. Crumbs, everything older than 1 year should go... Nay make that 1 month...
Who cares if users like an old app, "vibrancy" matters most.
It's a way to clear out old apps that don't make money. A freeware app can be quite popular but won’t get updated if the developer as moved on to other jobs and can't continue to devote unpaid labor toward their passion project. In order to afford to keep maintaining it, they may have to move a happily free app toward a subscription or ad-supported model. And Apple's forced updates are nudging people in that direction.
It reminds me of a class I once took where the professor stated that some colonial governments would go into tribal areas, claim land ownership, and start taxing the indigenous people. And because these people now owed taxes, they had to give up their lifestyle, enter the workforce, and participate in the money economy whether they wanted to or not. I don't know if that scenario is historically accurate but it certainly is analogous to Apple's policy. Developers who might not even want to make money are being compelled to do so or see their apps get pulled, because forced updates amount to a tax that must be paid.
> forced updates amount to a tax that must be paid.
It's not a tax that must be paid. The developer can simply discontinue the older app, and not have to pay anything. So your analogy doesn't apply.
Switching an app from free to paid is a lot more work than recompiling and updating the app. There's a ton of coding and infrastructure you have to do. So it's not really saving you anything. The work of switching is a large upfront cost, which might not pay off, because apps don't magically sell themselves, you have to market them (which costs money!). This is especially a problem if you already have an app with low download numbers and low consumer awareness.
> I suspect the minimum download threshold to be exempt from this is _very_ high.
You can suspect based on no evidence, but nobody knows, and Apple refuses to say.
The crazy thing is, if Apple truly wants to drop support for older version of the SDKs, then how in the world does it make sense to exempt the most used apps???
My guess is the income from a reduced subset of apps offsets special maintenance for only those parts of the old SDKs which that subset uses. Likely as a cost saving measure. Apple may even ask for support contracts beyond some point, to motivate those apps to update too.
> My guess is the income from a reduced subset of apps offsets special maintenance for only those parts of the old SDKs which that subset uses.
Again, a guess based on zero empirical evidence. Also, Apple's "rule" here makes no distinction between paid and free apps. Indeed, free apps tend to have more downloads than paid apps, which means that Apple would be targeting the wrong apps if they were looking to offset costs.
It's much easier to support only a handful of apps on an old SDK than millions. Those a few probably only utilize 30% APIs the SDK exposes, meaning you can safely assume the rest 70% can be removed from maintenance list. They can also one-on-one work with those few companies on deprecation and migration.
They don't need to work 1 on 1. Any uploaded app is automatically analyzed for API usage. At least I've been getting warnings about deprecated or unsupported APIs in my apps once in a while and other developers too - even if it sometimes seems like crude string matching rather than checking for actual usage of the API
I've had a few apps on the Google Play Store automatically removed because I didn't update them for some new policy or some such.
If they paid me maybe I would have. Otherwise I don't have time to keep dealing with their requests every 6 months. Is it such a hard thing to ask that if shit works, just leave it be?
I agree that this may be the point. Software changes, and being able to compile with latest libraries is somewhat of a minimum requirement.
To Apple's defense, are they supposed to wait until the app breaks, starts receiving many complaints from customers, before it triggers the review process for them (which they would be forced to look at as somewhat high priority) before they then take action to remove the offending app? That hurts the customer experience from their perspective.
Better for them to institute a policy preemptively addressing these issues (arbitrary as the timeframe may be).
And four hours is a good chunk of time, but what percent of time is it compared to the amount of time for the app to be designed and implemented in the first place?
> To Apple's defense, are they supposed to wait until the app breaks, starts receiving many complaints from customers
Except that Apple is exempting apps with more downloads, and only punishing apps with fewer downloads, which is the opposite of worrying about "many complaints".
> For an app with more downloads, they can dedicate more labor/resources to it.
What resources? For older apps with more downloads, Apple is doing exactly what you said they shouldn't do: wait until the app breaks, and start receiving many complaints from customers.
> The intention behind Apple and Google’s policies is to force developers to make sure their apps run successfully on the latest devices and operating systems.
The intention is to not support old iOS APIs with new versions of XCode and iOS anymore.
Apple isn't Microsoft or the Web - very old Windows programs and very old websites still run pretty fine.
Apple would rather shift the burden to update and App according to the latest API to the Devs than to provide API support forever.
I hate to see a piece of open-source software abandoned and broken. But I love to see a piece of software “abandoned” and still working because it has been designed for long-term use and simply doesn’t need updating.
That is how open-source grows. Because you can’t grow a codebase if you have to keep updating and fixing what you’ve already done. As you have to keep updating and fixing stuff, new progress slows and eventually stops. It’s the same for “codebases” like ecosystems/package repos and open-source in general
The use of recency as a proxy for quality or usefulness is one of the more perverse trends of recent years, but it's understandable. There is just so much of everything that a strong demand is created for any method of filtering.
Of course I have to add that it does matter a lot for certain types of software. Anything that interacts with ever-changing APIs, hardware specs, and protocols needs to be kept up at least frequently enough to stay useful.
Frankly, isn't that just what you signed up for as a mobile developer? The WorldAnimals app would probably have worked perfectly fine as a web app, but then the author would have had to figure out payments and discoverability himself. That's what the App Store offers, and in exchange Apple gets tremendous power to tweak every nook and cranny to maximise their profit. I'm sure Apple has good commercial reasons for the process that the author has experienced.
I think the real answer here isn't to try and beg Apple to be nicer to the small fish, but to instead use the "old", non-walled version of the web.
Well, no, a native app and a web app aren’t one-for-one interchangeable.
Apple acts as a gatekeeper by only allowing native apps to be distributed through the App Store, so it is not unreasonable to ask that they refrain from making the process too onerous.
It doesn't apply here, but there are a few app ideas I have where I don't really care about payments or discoverability; I would need use native just because the features are not supported in iOS Safari. For example, here's a list of standards that the Webkit team has said that they have no plans to implement: https://webkit.org/tracking-prevention/#anti-fingerprinting (for me, WebBluetooth and Web NFC are the big blockers).
Until those gaps are fixed, native apps are your only option.
On a related note, I feel that some websites at are a point where they're complete, and adding new features makes the experience worse.
Take Github: to me it feels that it's now at an optimum where adding new features that make it more social or more "fun" would simply make it worse.
Similarly Youtube: tons of good material, user interface is fine. Then they introduced shorts, and to me it feels like these type of video's are simply not part of youtube's identity, adding them only makes it worse.
At some point it might be best to stop adding new features and just agree that things are fine now as they are.
Surely it's possible for GitHub to add features that aren't related to making it more social or "fun," though? For example, they could improve their support for stacked PRs in a number of ways; that's an area that is far from fine at the moment IMO.
> The impact of the App Store Improvement policy is nonexistent for VC-funded companies.
Not true. More often than not, our iOS releases get delayed hours if not days, while our long-suffering iOS lead patiently walks yet another green reviewer through the policies and our previous interactions with reviewers to convince them that our app is in compliance. Among other things, our app repeatedly gets flagged for failing to comply with rules that don't apply to it. This is usually resolved with a simple message to the reviewer, but depending on the turnaround, that can effectively add a day to the time it takes to get a bug fix out.
Dealing with these bogus issues probably accounts for 5% of the productive time of our iOS lead. And this is despite keeping our release cadence slow (every two weeks except for the most critical bugs) and after we've made many reasonable low-to-medium effort changes in our app to stop triggering false positives in their tools.
God help us if Apple ever went the Google route. Apple reviewers might be inexperienced and undertrained, but at least they're human and capable of talking through issues.
>I think the asymmetry of App Review is still lost on Apple. For indie developers our hopes and dreams (and sometimes our finances) hang in the balance, for the App Review team it’s just another app rejection among tens of thousands. I know they think they get it, they just don’t.
I really don't think it's lost on Apple or the app review team. They simply have no incentive to change and a captive audience in both developers & app users/buyers. Better customer service (to devs) on the app review process when there are issues, and continuing support for older SDK's, cost time and money and Apple does not see the value in that investment.
Absent competition there's also no pressure to change this. There's effectively a duopoly in mobile software between Apple & Google. They don't even need to explicitly communicate with each other to act as a cartel, they just need to silently follow each other's lead.
Android is at least marginally better for allowing-- through a few scare-tactics hoops to jump through-- sideloading of apps, but I don't consider that sufficient competition to overcome the duopoly label. Neither is Android's allowance of alternative app stores, no more than MS allowing users to install alternate browsers was sufficient to overcome their uncompetitive practices when it came to IE. The primacy of the Play store on initial setup & its extremely deep integration in the OS is difficult to overcome.
Alternatively, I am slightly conflicted on this due to the security aspects of app installation. Mobile certainly isn't perfect, but the prevalence of malware seems significantly reduced from what is seen in PC's. (well, windows. MacOS is not as bad as Windows, but I've always considered that to be a produce of it's lower market share & therefore lower cost/benefit ratio for attackers.)
506 comments
[ 5.5 ms ] story [ 371 ms ] threadLots of stumbles and missed opportunities - like, what if they had actually been serious about making the Apple TV a Wii-style games console? They have the hardware expertise to do that at a reasonable cost, but they just have no idea about the market, and apparently no desire to learn.
If Nintendo took that approach then they'd end up throwing away Super Mario Odyssey and Zelda: Breath of the Wild.
Apple products very much have a time and a place. Their plan is recurring revenue. Something that happened 3 years ago is almost entirely irrelevant to them. It's true with both hardware and software.
Wii-style games on AppleTV would not be a win for them. They don't want to sell a few million copies of Wii Sports once every 3-5 years. They want you buying a new 99¢ game at least once a month. They want you spending $5-10 in micro-transactions a month. They want you subscribed to AppleOne for $15-30 a month. They want you to buy a whole new iPhone every 2-3 years and start the process all over again with some new AirPods, cases and bands in between.
Apple doesn't want to sell you a new game for $59 every 2 years. They want to sell you what amount to an average of $59 worth of goods and services a month… forever. And while that sounds like a lot, that's a low target. If you have your TV subscriptions through Apple and Apple Care you can easily be contributing $100/mo or more to Apple's bottom line.
When do we get to the point of companies hiring "review specialists" who used to work for Apple?
Related: open source devs fret if a library hasn't been updated in the last month, even if it is feature complete with no bugs.
I personally support every version of my projects.
My goal is not to minimize the effort to myself but to facilitate the use of my software.
If, however, I saw a statement at the top of the README that said:
"Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed"
then I would feel very confident.
Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."
The thing is, even if the lib is "feature complete", it's pretty rare to not have to update anything, since the ecosystem in which this lib evolves will undoubtely have changed. Programming language, hardware, OS, etc. everything evolves all the time.
I think what you are saying is simply FUD when taken as a blanket statement.
But thanks for trying anyways.
Anyone can cherry-pick examples to try to disprove a security principle. A pure, functional math library isn't representative of the vast, vast majority of libraries that are imported every day.
The most-used libraries across languages are for things like database access, logging, package management, HTTP, and (de)serialization. All of those things need to be kept updated for security.
> Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation.
You didn't specify the language or library.
Most libraries that people import are going to be JS, just because of the number of JS users and the minimal standard library in that language. Many are also going to operate on user input, which means they can have vulnerabilities.
The mathjs package in NPM, for example, has had tons of vulnerabilities[1].
1. https://security.snyk.io/package/npm/mathjs
NPM system is security abomination I agree. But I am not using it. I look at things from my own perspective. If 90% of the world programmers are bound to NPM ecosystem (doubt it) it is their problem. Not mine. I do not "import" half of the Internet for my "hello worlds".
Maybe some other way like "Hey, we're still here just the thing we're working on doesn't need an update" would suffice for most things.
Thing is, even if there are no known bugs, having rare updates means if I do find a new bug it’s less likely to get addressed quickly.
If you look at the Nintendo DS/3DS (for example), the platform had many hardware revisions (about every other year) and dozens of firmware revisions, yet games from 2004 still worked on a brand new 3DS in 2020.
On the Sony side, PS4 games from 2013 still work fine on a PS5 in 2022 (and probably through 2029.)
Steam has tons of old games that work great on Windows (but the Mac side took a major hit with macOS Catalina's 32-bit apocalypse.)
In my experience old games often work better in proton/wine than in Win 11.
My understanding is that the Steam Runtime also provides a stable base, that (or something close to it) unfortunately wasn't adopted in other ecosystems. Flatpak is great, but not used widely used for binaries yet.
They were dropping support for older versions of PHP despite getting nothing from it and using none of the newer features. Just needlessly limiting the audience, and churn for churns sake.
e.g. say a bug comes up in the library, and say that it only affects older versions of PHP. Why can't the project just shrug its shoulders and be truthful that it doesn't have interest in maintenance/support against those old versions? It's better that the project declares this intention now, before the bug comes up, then later having to part ways with the old versions more abruptly.
This is why OSS is great, as you can decide if, at the time said bug is found, that you want to provide legacy support for older PHP versions, maybe through a fork or other means. Have at it, it's your software too.
Removing support for old versions is a simplification of what needs to be considered. It is a reduction of complexity. If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library - even if new features that weren't available in the EOL'ed version haven't been added yet.
Its not. Large Linux distributions support those PHP versions for a long time in their LTS releases, and majority of web hosts and infra providers use those distros in their infra.
That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying "I'm not going to deal with something that had its last release nearly 4 years ago."
> That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying
Yes it should. Its not 'some' provider. Its providerS. A gigantic part of the web lives on such large hosts. AWS and similar ecosystems constitute a small part of the web. This is not saying that the former is low traffic but large in size compared to AWS et al. There is similar traffic and user activity going on in both ecosystems.
You can easily 'deprecate' something and spend millions of dollars man-hours in upgrading your stack as a larger startup which uses AWS. But millions of small businesses, individuals who rely on Open Source software and such hosting providers won't have the money or time to jump through such upgrade hoops 'just because'. It is 'just because' for the simple fact that a lot of such version hops we do in Open Source software development do not bring much to the end users. And they will not appreciate their businesses getting hampered trying to go through upgrade hoops which they have never asked for.
An alternate approach to this is saying 'f*k you' to those people and doing Open Source for the sake of software development itself, without caring about end users. That would also work - but only for those who develop Open Source and who have the time to keep it updated. The general public would just move on from Open Source and start using reliable private service providers that don't break their businesses every other year.
Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?
If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?
Note that the FOSS approach to "but it doesn't support the old version that I'm running" has been "don't upgrade or fork it and maintain it yourself." It's the flip side of https://boyter.org/posts/the-three-f-s-of-open-source/ ( https://news.ycombinator.com/item?id=32591265 ).
I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.
Based on the usage of the version and the support for it in large hosting/infra providers.
> Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?
Breaking backwards compatibility is practically always bad. You do it once. You do it twice. By the third time it does not matter because a large part of your users would have moved on to some other stack by the second time.
> If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?
These must be seen as ecosystems. The ecosystem would slowly move to a higher version over the span of 2-3 years starting from the point when a version starts nearing its EOL. And the users upgrade slowly on their end.
> https://boyter.org/posts/the-three-f-s-of-open-source/
Using the same language in the article: The users would say one single F word to such a project, without the project maintainers ever hearing about it, and silently move on to some project that is not so self-indulgent and so irreverent towards its users. Nobody has the time to jump through hoops to keep their business running on Open SOurce, less suffer such arrogant sh*t.
Such an attidude is only workable if the project is a hobby one, does not aim to gather ANY kind of community/userbase, does not aim to do any impact.
> I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.
I would recommend that you prioritize your users and backwards compatibility in that order. The moment your users start trusting your project that it will not break their software, they will start upgrading easily and adoption and retention will get boosted.
JSON API spec's 'only add, never deprecate' approach is the holy grail to chase:
https://jsonapi.org/format/
> New versions of JSON:API will always be backwards compatible using a never remove, only add strategy. Additions can be proposed in our discussion forum.
I suppose for simple libraries this might be possible (e.g. left-pad) but how would you know in general that something is bug-free? `units` was introduced in 1979 and is still one of the canonical examples used in automated program repair research to show that new bugs can be found even in extremely well-studied codebases.
I think people might be:
1. Implicitly assuming that all nontrivial code has bugs, and 2. Using recent commits as a signal that means, "If I ran into a bug, there is someone who might fix it (or at least accept a fix PR) to take away my immediate pain.
Our knowledge, our abilities, our raw materials continuously improve, and everything is expected to advantage of this. Things that don't improve, are soon outdated and fall behind.
Everything continuously improves: cars, bicycles, windows, houses, refridgerators, tv, etc, etc.
We reached the peak of software usability a long time ago, probably around the turn of the century. Now it's all about trendchasing, change for the sake of change, dark patterns to squeeze the $$$ out of you, etc.
Last 2 years, the thing i miss most about working in the office, is the ability to collaborate with co-workers in front of a huge whiteboard. The brainstorming, ideation. Miro is nice, but it deserves a huge screen, it needs more interaction with your co-workers, and it needs to help you take your drawings into real value (running software, designs that can be fed into 3d printers, cnc machines, etc).
This is how the Gods do programming :)
I don't see Nintendo removing old Switch games from the eShop.
I don't see Apple Music removing the Beatles because they haven't updated recently.
My recommendation, which Apple's (obnoxious) ad business would never accept, would be to
1. Remove the obnoxious and generally useless ads which eat up the top half of the first page of app search on the iPhone.
2. Improve app search with more options and a fast, responsive UI. Also they might consider allowing you to consider ratings from other sources such as critical reviews vs. user reviews (a la metacritic.)
3. Better human curation with more categories. This is the same approach that Apple Music takes and it seems to work well. Games should have Artist/Studio/Developer pages as well as Essentials lists to facilitate discovery. Same with genre/category essentials, which have a rotating list that can be saved/bookmarked.
The real problem is that developers have no choice except to offer their app through Apple's store. There is no room for the developer to offer their labour of love or niche product in a storefront that better serves their needs, or even from their own website.
How is this different from other walled garden game systems/game stores like Nintendo's eShop?
Yet they seem to keep older games and apps, even niche titles for a limited audience (such as music production apps or BASIC programming apps) which I greatly appreciate.
I would agree that discoverability isn't great on the eShop, but there are dozens of enthusiast web sites which are pretty good for game discovery (also aggregators like metacritic.)
And, as I noted, I think Apple already has a good approach which they're using with Apple Music - better human curation including category/genre/time period/artist/etc. playlists. Podcasts/radio shows also help.
Many games (at least ones that aren't in the "live service" category) are more akin to movies, music, or books than to some sort of perishable produce, so a curation approach that balances older content with new content makes sense.
0: https://support.xbox.com/en-US/help/hardware-network/console...
As for other media, brick and mortar retailers were always selective about what they offered. I suspect that we will see something similar happen with their digital variants in the coming years. I also suspect that it will be sales numbers, not human curation, that will be the basis of their decisions.
“Make space”? This isn’t a shelf. There’s always enough space for digital items.
Even in a less wall gardened environment, I'm mostly not interested in running 10 year old applications unless they're something fairly simple that really does do everything required for the purpose and still runs reliably.
In any case, as a user, I probably figure that if an app hasn't been updated in five years, it may or may not work and I'll probably at least subconsciously resent the store's owner a bit for clogging up the store with old stuff.
The 10 year old version of AutoCAD still runs, and you can use it today to do a ton of high-value CAD work. Thanks to Microsoft for not arbitrarily blocking it from running.
This is precisely why Google only indexes webpages written in English and are focused on the American market.
Also - there's a cultural preservation issue here as well. That bothers me.
Removing apps based on downloads or lack of updates is troubling.
I don't hear independent developers griping that Apple is failing to advertise their apps and bring those apps to the attention of iPhone users. Instead, I hear independent developers griping that Apple is preventing their apps from being run on iPhones.
Therefore, I completely disagree. This is purely a matter of data storage space (cheap and nigh infinite), not a matter of limited attention.
There are huge numbers of good apps on the store that don’t get visibility.
By that argument they should also get rid of most old music, old books, old movies.
I do not. Do you think shovelware author x has any issues pushing a new garbage update?
I want the app store to be full of high quality stuff, not recent.
Besides, isn’t this the company that allowed you to install iPhone apps on iPads and blow the UI up to 2x size?
You could run iPhone 4 apps on iPhone 5 and beyond. But they looked horrible.
- they care about their apps not being evicted from memory as quickly when they switch apps because memory isn’t taken up by 32 bit and 64 bit versions of shared libraries.
- increased battery life by not having as much RAM - yes RAM takes energy.
- using the die space saved by not having 32 bit instruction decoding means you can use that die space for enhancements that users care about, and decrease the die size to make the phone more battery efficient
- for Mac computers, you have computers that are faster, have more than twice the battery life, are more memory efficient (meaning less swap), and can be fanless without getting hot.
You do realise the only reason iphone retina screens became a thing was to enable double pixel scaling because iphone apps at the time were coded to a fixed resolution.
That's the definition of a compatibility hack.
Of course apple being apple they managed to sell it as a feature and made every person who was happy with a 1366x768 laptop suddenly desire a retina display.
Let the user make the damn choice.
If you think that’s all a smartphone is, then it’s natural to come to the conclusion that the only thing that has changed is speed and resolution.
It also happens to be simply wrong.
Most applications basically just need:
- a canvas to paint some bitmaps on
- some way to tell what part of the screen the user tapped on
- a way to get TCP/IP or HTTPS traffic in and out - some sound output
- some persistence
- some way to show notifications
- a few other odds and ends like GPS, sometimes
Almost the entire list been supported on every major platform since the late 2000s. Yes, rich multimedia apps that make good use of additional APIs and hardware features do exist. But it's inappropriate to nuke most old "normal" applications just because old rich multimedia apps stopped working over time.
Apple introduced size classes and then you needed to adjust for different views for iPads once they supported more than one app being displayed on the screen.
Apple rightfully got rid of 3/ bit app support on the actual die. It introduced new permission models, design aesthetics change, new accessibility options are added, better APIS are written, etc.
https://youtu.be/KB07oxJkd2g
As do a lot of iOS users. I think the stat you are looking for is that, on average, iPhone users purchase more apps.
Don't forget to consider Android's massive installed user base in the calculation. Even if Droid users convert to paid at 1/4 the rate of iOS, you can make it up in sheer bulk.
I wish I could upvote you for that multiple times!
The difference is that Nintendo shops have a limited shelf life, while App Store is forever(-ish). Nintendo will be shutting down the Wii U and 3DS eShops in 2023.
2023 is 6 years after Wii U was discontinued. Since the platform was frozen in time in 2017, there's no point to game updates.
Platforms are supposed to absorb developer pain, but Apple offloads a continuous and multiplicative update burden onto all of their developers.
Like this https://www.exploit-db.com/exploits/33508
coreutils ls: https://git.savannah.gnu.org/cgit/coreutils.git/log/src/ls.c
freebsd ls: https://github.com/freebsd/freebsd-src/commits/927f8d8bbbed7...
busybox ls: https://git.busybox.net/busybox/log/coreutils/ls.c
openbsd ls: https://github.com/openbsd/src/commits/master/bin/ls/ls.c
The latter seems to be the most stable, yet has been updated two years ago, many years after its first introduction.
Security concerns are very clustered around limited attack surface, that many apps just don't have.
Still, I don't think Steam would confess to deleting a game just because it is old. They carry a lot of games which haven't been updated in years and which still sell.
In other words if there was some actual reason to do an update, like a security flaw or serious bug, she wouldn't have been able to readily do so.
This seems to support Apple's policy to make developers update the app every once in a while.
Closing off APIs that facilitate fingerprinting is just one of many incompatible changes Apple has been making.
Some other reasons are deprecating power hungry technologies and asking for more permissions to access private data.
These are changes that benefit users on a massive scale. Why shouldn’t a developer be expected to respect users needs?
Also - “windows does it” is obviously irrelevant when we are talking about a mobile OS.
I won't continue this discussion about maintaining compatibility. This is fundamentally a philosophical issue. I agree with the sibling comment that it is the job of an OS to provide stable APIs across versions. It requires some effort (as a long-term library maintainer, I'm very well aware of this), but it is not an impossibility at all.
The job of the computer is to serve the end user. The job of the OS is to manage the computer’s resources on the users behalf.
API stability can contribute to that goal, but this is not an absolute.
Apple balances their view of what is good for users over what is good for developers and themselves.
Your preference is to prioritize developer comfort over both end users and Apple.
If you think there are no insecure or inefficient APIs in older versions of operating systems, then you are simply wrong.
API stability sometimes serves the end user, and sometimes does not. When it does not, it should not be maintained.
Isn't this supposed to be why the App Store has a manual approval process? So Apple can actually check if developers are doing malicious things?
By all means, apply extra scrutiny if an old API is in use. Maybe allow the API only in updates to old apps, and not new ones.
> By all means, apply extra scrutiny if an old API is in use. Maybe allow the API only in updates to old apps, and not new ones.
If the developer is updating the app, there is no reason they shouldn’t adopt a more user friendly api.
(1) There wasn't.
(2) "After 4 hours of work to re-compile my app and 44 hours waiting in the review queue"
The biggest obstacle here isn't the developer, it's Apple.
So another way to look at it is Apple requires developers to once every 3 years do the absolute minimum amount of maintenance, and they get a 90 day window to do it in.
Developers needing to demonstrate once every 3 years that they still have the source code and it compiles should not be an obstacle at all.
You say "Developers" without qualification, missing the crucial exemption: for some bizarre reason, developers of apps that are above a certain download threshold do not have to demonstrate that their code still compiles. Does that make sense?
So when you ask but why are popular apps exempt? - well, they already told you exactly why, because they're popular. People still want the app.
I feel like the actual reason you're against this policy is left unstated.
1) The criteria do not include "crappy". Apple didn't claim that the article author's app is crappy.
2) What's the difference between "old" and "outdated"? The article author's app was recompiled but otherwise not changed.
3) The app is now back in the App Store. So if Apple's goal was to remove the app from the App Store, then Apple failed.
> People still want the app.
Alternatively, they could be scams that are getting downloads from keyword stuffing, fake reviews, search ads, and other well-known methods.
> I feel like the actual reason you're against this policy is left unstated.
Not at all. The same reason as the article author:
"The decision to remove outdated apps places a disproportional burden on indie developers and hobbyists"
Apple has said, in response to anti-trust claims that "developers, from first-time engineers to larger companies, can rest assured that everyone is playing by the same set of rules." But that's clearly a lie, is it not?
I said that was part of their intention, indicated by "follow current review guidelines". Go ahead now and try to put Apple's intention into your own words. What do you feel is Apple's intention behind this policy?
> "... everyone is playing by the same set of rules." But that's clearly a lie, is it not?
Large developers also have to resubmit their very unpopular, obscure apps every three years. Small developers with popular apps also do not. Everyone is playing by the same rule. You made the claim, what developers are not subject to this same policy?
> "The decision to remove outdated apps places a disproportional burden on indie developers and hobbyists"
Explain why you feel a few minutes every three years is a burden. Literally the only thing Apple is requiring you do is recompile your unpopular app and submit it as an update once every three years.
It's not disproportional on indie developers and hobbyists unless you feel they have more unpopular apps that they also almost never update. Hobbyists can make popular apps, such as that Japanese guy's side-by-side calculator app that was on the HN front page the other day and they often put more love and effort into updating their apps, even the old ones. Frankly this view that hobbyists are oppressed by needing to recompile once every three years reads like an insult.
I can't read Apple's mind. You can't either.
> Large developers also have to resubmit their very unpopular, obscure apps every three years.
Oh give me a break. I'm done here, this is not a good faith argument.
> Explain why you feel a few minutes every three years is a burden.
A few minutes. Again, this is not a good faith argument. Your reply is not serious.
> Literally the only thing Apple is requiring you do is recompile your unpopular app and submit it as an update once every three years.
Your reply is contradicting itself, because you claim Apple's intention is to get rid of apps, but you also claim that it's incredibly easy to not get removed.
> Frankly this view that hobbyists are oppressed by needing to recompile once every three years reads like an insult.
Do you think the original article author was insulting herself?
What a bad faith, insulting reply.
I asked what your understanding was, not what Apple actually was thinking, and you absolutely can say what you believe about Apple and their intentions; this goes to Theory of Mind that is a cornerstone of being a functional person.
> give me a break ... not a good faith ... reply is not serious .. bad faith, insulting reply
It's now clear to me that you have unstated reasons because when calmly asked to explain your reasons you went off crazy like this rather than simply state those beliefs. You feel it's a burden, but why is effort so minimal a burden? You won't say.
Your expression of concern over the blog author's character, your inability to explain your views, and those views being irrational leads me to conclude that you are simply white-knighting.
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.
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.
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.
More importantly for better than or worse it’s just not how game lifecycles and financing go.
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.
(This debate is as old as computers, but I'm strongly in Raymond Chen's camp.)
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. ;-)
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.
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.
[1] https://en.wikipedia.org/wiki/Carbon_(API)
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?
https://lkml.org/lkml/2012/3/8/495
https://discussions.apple.com/thread/252735331
Apple can’t make these things compatible, nor should they try.
That's generally a good practice as buffer overflows and all kinds of entropy accumulates on an OS.
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.
The linked article already answered this:
First 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.
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.
It's a real thing especially when you're building something under the unix philosophy of "do one thing only, really well".
> Most people are trying to build well-designed, useful mobile apps
and then proceeds to say how the review process is not helpful because they don't weed out many malicious apps. First, confirmation bias. Second, do they have any idea how things are in Android land? It's a constant struggle against nefarious app devs trying to abuse new technologies or means of getting ad/install revenue. It's one of the things I like the least about the ecosystem I use.
In any ecosystem at all: if it speaks HTTPS, it’s either never complete, or it ceases to function past some date.
I get the sentiment very much, but there are cases when you can’t have nice things.
Incentive App developers who make good and substantial updates, whether its new features or updating to newer system APIs, with a positive % modifier to their search results in the App store.
This way well-maintained Apps should show up higher in search rankings and there's a natural incentive for developers to keep their programs maintained. But at the same time, this would allow developers to call a program "finished" and leave it on the store without being scared of having their hard-work destroyed. Their hard-work might not be as visible, but that would be on them.
But there is one reason I somehow understand Apple stance. First is security, almost all apps are online now, and new vulnerabilities are found regularly. Super Mario has bugs, be no one cares, in fact, speedrunners have fun with them, because a NES is not online and there is nothing sensitive in there to begin with. Second is Apple's own fault: they break their own system and want you to make sure you keep up.
Super Mario Bros runs on a single piece of unchanging hardware. Even when you play it on any other platform, you're playing it through an emulator designed to mimic the original hardware.
And that's the case with all video game consoles. Even when the physical hardware changes, you're given the guarantee that it won't be breaking to the software. The few times that has not been the case has been notable.
iOS devices don't have that guarantee. The hardware can have breaking changes. You software now has to contend with the fact that there is no guarantee that certain features may or may not be present. Things that were previously not customizable, now are. If you want your software to run on the latest iOS, it is at least partly your responsibility to ensure that it does.
You also need an emulator to run 31 year old PC games like Civilization on modern OS/hardware.
Author complains about the time required to update libraries, and that's an aggravating process, but that's just an unfortunate part of maintaining an app. The real issue, again it seems to me, isn't that you have to do a lot of work just to increment the version string; it's that, ultimately, modern content ecosystems are designed according to engagement-driven revenue models. And solid, simple, quiet, long-lived, useful or fun little apps simply can't thrive when all the sunlight is blocked by towering marketing-tech giants.
IMHO.
This has been the name of the game in ad tech like fb, Google and social media in general. I think two worlds are clashing with each other, where consumer tech is somewhat aware of the problems around mindless scrolling and addiction, but the growth & engagement mindset of the 2010s is cemented in the culture. Apple has little reason to follow this model because they primarily make money from selling hardware. Having a software platform that protects the user from this crap is a competitive advantage against Google, who depends on ad-based revenue. Apple seems to have an identity crisis, fearing they lose out on sweet subscription fees and ad revenue, now that most apps are free. This in turn is creating conflicts of interest, where they end up fighting their own customers.
If regulators would bark and bite harder around anti-competitive behavior, it might actually force corporations to focus on what they're good at instead of everyone building their own mediocre walled gardens that grow like a cancer and eats the company from within. At least, that's my wishful thinking..
Fully offline, totally self-contained apps are a different matter, but those represent an increasingly small percentage of apps.
There is a dystopian arc, but I prefer to be more optimistic. I would think a legal mandate that champions interoperability, open data standards, and platform openness will put a dent in this march towards convert the human experience into numbers.
I sort of assume this is the actual point? Apple presumably wants to drop support for older versions of the SDKs, and that requires that app developers update to the newer versions. I think you can make a reasonable argument that dumping work on third-party developers to simplify things for themselves is bad, but the author's belief that it was simply pointless busywork is probably incorrect from Apple's perspective.
I suspect the minimum download threshold to be exempt from this is _very_ high. Maintaining backwards compatibility for a small fixed set of apps doing things an old way is a categorically different problem from maintaining backwards compatibility for every app out there.
If this was really about deprecation, they wouldn't have a "minimum monthly downloads" exemption either. This policy is just a way to clear out old, unpopular apps from the store
Except popularity doesn't correlate with utility when it comes to apps. Probably only addictive games and social network apps will pass whatever arbitrary threshold has been set.
This will harm any one off apps built to satisfy a niche purpose downloaded by a small set of users. Which Apple probably think are not important, like all of the little high street shops, except cumulatively they might affect a majority of users. Also if it's measured by "downloads" rather than "installed", then it could take out larger more widely used apps that are considered complete by both authors and users, but don't have enough daily new users to pop up on their radar as important enough... this is similar to the "maintenance" fallacy of NPM, where frequent patches = better, even though if your package is small and well written you should be making no patches as a sign of quality.
Businesses don't want to be told that their working software needs to be updated to make a vendor's bottom-line cheaper. They recognize cost-shifting when they see it and respond by backing towards the exits. Microsoft maintained a philosophy for decades that it was their responsibility to, if at all possible, maintain backwards compatibility with older Windows software as a market differentiator. The primary times I remember them breaking this policy were security related.
(That having been said, I got out of active development of Windows software around Windows 8, so this may have changed).
Sure there are old things that are good and "complete" but far more old stuff is just old and could well be burnt to the ground, except for the fact that you have some customer somewhere relying on its oddities and unintended behaviors as an essential feature of their integrations.
There's no sign that being very-backward-compatible is holding Windows back that I can see.
In the other hand I have collected a set of utilities into my work-flow that are easily 20+ years old, and they all work fine.
The last major cull from Microsoft was that 16bit programs ceased to work on 64 bit platforms. Other than that I've never had an app fail.
Most of those utility supplies have long since disappeared, retired, or died. But I can still keep transferring those apps to the next machine and they keep running.
None of this impacts the quality of my current offerings. Ultimately all this costs me is some cheap disk space.
Maybe Linux could be beaten to work with it, but this works well enough.
Backwards compatibility is very much holding MS back
Something like Google's minimum sdk version is annoying, but understandable. It's technical and concrete - you must link against version X because version X-1 is going to disappear.
This is not that. It's culling apps that are arbitrarily too old and arbitrarily not popular enough. They must be keeping around old sdk versions if those old but popular apps are allowed to continue on.
And they also went above and beyond to make it happen too. That time when they byte-patched a binary which they didn't have the source code anymore comes to mind.
A better example is productivity software, like Photoshop and Illustrator or Paint Shop Pro. I can get Paint Shop Pro 5, a raster graphics editor from 1998, to run on Windows 11 just fine, for example. Another is Microsoft Office, in which Microsoft goes out of its way to make sure documents created long ago will load and work fine in modern Office, and ancient versions of Office itself will happily run mostly fine on modern Windows too (eg: I run Office XP on my Windows 7 machines).
Old games were also quite often doing direct access to graphic cards outside of official APIs
And games are not business software. An old game that stops working is "too bad, move long", accounting software that stops working has real life consequences.
More regular applications tend to be much easier to get working though. E.g. something like Delphi 2 or C++ Builder 1 work out of the box just fine. The biggest issue with older software is that they sometimes had 16bit installers who do not work with 64bit Windows. Windows comes with some updated stubs for some popular installers and it is possible to manually fiddle with some of the unsupported ones to run the 32bit engine directly, though something like odtvdm/winevdm that emulates 16bit code on 64bit would also work.
But in general you can get things working, depending on how well the application was written. In some cases (games, 16bit installers) you do need workarounds as they wont work out of the box, but even those workarounds are based on the 99.9% of the rest of the system preserving backwards compatibility.
Worked generally okay until the era of the Internet came along and after you quit the game, all manner of programs would crash when the network stack suddenly found itself teleported an hour or two into the future and couldn't cope.
> The most impressive things to read on Raymond’s weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility ...
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
> ... Raymond Chen writes, “I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.”
> A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work. For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple’s official Bible of Macintosh programming, there was a tech note saying “you can’t do this,” they did it, and it worked, and their programs ran faster… until the next version of the OS came out and they didn’t run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.
---
This really gets into a philosophical difference of how software should work and who should be maintaining it. As a user, I love Raymond Chen's approach. As a developer, trying to maintain bug for bug compatibility with older versions of the code is something that scales poorly and continues to consume more and more resources as more and more bugs need that bug for bug compatibility across versions.
It's fine to argue typical desktop applications need to be updated but purpose-built applications cost money, so when you have things like a POS terminal installed in thousands of fast-oil-change locations and it's from the Win3.11 era working perfectly fine for years but suddenly stops working after moving to 10, that's a sudden cost on a business (especially with no warning). Yes, you can argue that companies should be updating that kind of software, if only for reasons of security (I often did). The bottom line tends to be king, especially in smaller businesses, in my experience.
Even if Mac hardware manages to vastly outrun the top end gaming PCs on raw performance, they'll never be seen as serious mainstream targets for this reason alone.
To an extent, but the reality is that an unacceptably-large percentage of apps that are 2+ years old are not correctly handling current screen sizes and reserved sensor areas.
> This policy is just a way to clear out old, unpopular apps from the store.
Great. This is the kind of active culling/editing an app store requires to remain vibrant.
It doesn't matter if that tool you currently use is perfect, or the game you play is just fun as-it-is, it is clearly harmful to you (and makes the app store "less vibrant".
Everything older than 2 years must go. Crumbs, everything older than 1 year should go... Nay make that 1 month...
Who cares if users like an old app, "vibrancy" matters most.
/s
It reminds me of a class I once took where the professor stated that some colonial governments would go into tribal areas, claim land ownership, and start taxing the indigenous people. And because these people now owed taxes, they had to give up their lifestyle, enter the workforce, and participate in the money economy whether they wanted to or not. I don't know if that scenario is historically accurate but it certainly is analogous to Apple's policy. Developers who might not even want to make money are being compelled to do so or see their apps get pulled, because forced updates amount to a tax that must be paid.
It's not a tax that must be paid. The developer can simply discontinue the older app, and not have to pay anything. So your analogy doesn't apply.
Switching an app from free to paid is a lot more work than recompiling and updating the app. There's a ton of coding and infrastructure you have to do. So it's not really saving you anything. The work of switching is a large upfront cost, which might not pay off, because apps don't magically sell themselves, you have to market them (which costs money!). This is especially a problem if you already have an app with low download numbers and low consumer awareness.
You can suspect based on no evidence, but nobody knows, and Apple refuses to say.
The crazy thing is, if Apple truly wants to drop support for older version of the SDKs, then how in the world does it make sense to exempt the most used apps???
Again, a guess based on zero empirical evidence. Also, Apple's "rule" here makes no distinction between paid and free apps. Indeed, free apps tend to have more downloads than paid apps, which means that Apple would be targeting the wrong apps if they were looking to offset costs.
Basically a cost saving move.
> Basically a cost saving move.
Working 1-on-1 with companies to determine what to keep and what not is anything but cost saving, by my estimate.
If they paid me maybe I would have. Otherwise I don't have time to keep dealing with their requests every 6 months. Is it such a hard thing to ask that if shit works, just leave it be?
To Apple's defense, are they supposed to wait until the app breaks, starts receiving many complaints from customers, before it triggers the review process for them (which they would be forced to look at as somewhat high priority) before they then take action to remove the offending app? That hurts the customer experience from their perspective.
Better for them to institute a policy preemptively addressing these issues (arbitrary as the timeframe may be).
And four hours is a good chunk of time, but what percent of time is it compared to the amount of time for the app to be designed and implemented in the first place?
Except that Apple is exempting apps with more downloads, and only punishing apps with fewer downloads, which is the opposite of worrying about "many complaints".
For an app with more downloads, they can dedicate more labor/resources to it.
What resources? For older apps with more downloads, Apple is doing exactly what you said they shouldn't do: wait until the app breaks, and start receiving many complaints from customers.
The intention is to not support old iOS APIs with new versions of XCode and iOS anymore.
Apple isn't Microsoft or the Web - very old Windows programs and very old websites still run pretty fine.
Apple would rather shift the burden to update and App according to the latest API to the Devs than to provide API support forever.
That is how open-source grows. Because you can’t grow a codebase if you have to keep updating and fixing what you’ve already done. As you have to keep updating and fixing stuff, new progress slows and eventually stops. It’s the same for “codebases” like ecosystems/package repos and open-source in general
Of course I have to add that it does matter a lot for certain types of software. Anything that interacts with ever-changing APIs, hardware specs, and protocols needs to be kept up at least frequently enough to stay useful.
I think the real answer here isn't to try and beg Apple to be nicer to the small fish, but to instead use the "old", non-walled version of the web.
Apple acts as a gatekeeper by only allowing native apps to be distributed through the App Store, so it is not unreasonable to ask that they refrain from making the process too onerous.
Until those gaps are fixed, native apps are your only option.
Take Github: to me it feels that it's now at an optimum where adding new features that make it more social or more "fun" would simply make it worse.
Similarly Youtube: tons of good material, user interface is fine. Then they introduced shorts, and to me it feels like these type of video's are simply not part of youtube's identity, adding them only makes it worse.
At some point it might be best to stop adding new features and just agree that things are fine now as they are.
They know you wont leave, they know you'll put up with it.
Not true. More often than not, our iOS releases get delayed hours if not days, while our long-suffering iOS lead patiently walks yet another green reviewer through the policies and our previous interactions with reviewers to convince them that our app is in compliance. Among other things, our app repeatedly gets flagged for failing to comply with rules that don't apply to it. This is usually resolved with a simple message to the reviewer, but depending on the turnaround, that can effectively add a day to the time it takes to get a bug fix out.
Dealing with these bogus issues probably accounts for 5% of the productive time of our iOS lead. And this is despite keeping our release cadence slow (every two weeks except for the most critical bugs) and after we've made many reasonable low-to-medium effort changes in our app to stop triggering false positives in their tools.
God help us if Apple ever went the Google route. Apple reviewers might be inexperienced and undertrained, but at least they're human and capable of talking through issues.
Besides, users aren’t going to be updating their app multiple times per day as they would a website that is continuously updated.
I really don't think it's lost on Apple or the app review team. They simply have no incentive to change and a captive audience in both developers & app users/buyers. Better customer service (to devs) on the app review process when there are issues, and continuing support for older SDK's, cost time and money and Apple does not see the value in that investment.
Absent competition there's also no pressure to change this. There's effectively a duopoly in mobile software between Apple & Google. They don't even need to explicitly communicate with each other to act as a cartel, they just need to silently follow each other's lead.
Android is at least marginally better for allowing-- through a few scare-tactics hoops to jump through-- sideloading of apps, but I don't consider that sufficient competition to overcome the duopoly label. Neither is Android's allowance of alternative app stores, no more than MS allowing users to install alternate browsers was sufficient to overcome their uncompetitive practices when it came to IE. The primacy of the Play store on initial setup & its extremely deep integration in the OS is difficult to overcome.
Alternatively, I am slightly conflicted on this due to the security aspects of app installation. Mobile certainly isn't perfect, but the prevalence of malware seems significantly reduced from what is seen in PC's. (well, windows. MacOS is not as bad as Windows, but I've always considered that to be a produce of it's lower market share & therefore lower cost/benefit ratio for attackers.)