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