What do Photoshop, Matlab, Panic Transmit, and Eclipse have in common? They are among the 299 apps for which macOS applies compatibility fixes.
Here’s the full list of bundle IDs, along with the functions that checks for them, and the first caller to those functions. It’s also available in CSV format.
Note that this is just a list of apps Apple has developed compatibility tweaks to make them run on newer macOS versions. As the list demonstrates, even the best apps often needs some tweaks on newer macOS. In addition, most of these patches are only applied to older versions of apps.
Here’s how I extracted the list, and some interesting things I found in it.
This is absolutely fascinating, and provides some amazing insight into which applications Apple considers crucial to the macOS user experience and platform. We all know Windows performs various tricks to maintain backwards compatibility, but I had no idea Apple went to decent lengths too for the same reasons.
It’s a great article, but the title is writing checks the article can’t cash. It could be rewritten as
The point being the nature of these patches isn’t fully known, other than Apple is doing these patches. A great look behind the scenes, but we didn’t need the hyperbole for it to be interesting.
It would also be interesting to know if Apple ever contacts these developers to let them know so they can fix their software themselves.
Based on what’s in the article, this seems to apply to apps that haven’t been updated, or older versions of apps.
So for example, this may be why Photoshop CS5/6 keep working for people who don’t want to subscribe to Creative Cloud and so are stuck on an older version — and Adobe’s not going to fix their old software. And for an older version of MS Office — it will still keep working even if you don’t buy the latest version of the software.
Also some of the changes are where Apple may have improved the code and made if faster/more secure, and all updated software get the advantages. Also the code may work for older software as well who are using it in the documented way, but some software may be using the API in unofficial/undocumented ways — so compatibility breaks when the APIs are updated.
Right sure, but it would be lovely to know if Apple actually communicated with any of these companies/groups to let them know.
It is awesome they are doing this, but one of the downsides of fixing other people’s mistakes is it can perpetuate that kind code use and prevent people from knowing it needs to be fixed.
Also think of the scenario where someone copies the technique and one set of code fails and the other succeeds. That is a nightmare of a debugging scenario right there
True. Based on that article & responses on Twitter, it looks like several of the developers were surprised to be on that list.
Agreed 100%. The title forces the blame on the application code. What’s missing is any exploration of whether or not that code worked correctly on the version of the Mac OS for which it was written.
Isn’t this practice, issuing “compatibility fixes”, something existing in Windows for ages?
The question you are asking is addressed right there in Thom’s opinion in the article summary.
I still don’t understand why the fuss. Of course course it would be embarrassing for Apple if things like the Adobe apps won’t work properly. And of course it would be extra-embarrassing if Apple’s own apps would not work properly… have you noticed a bunch of those apps are made by Apple themselves?
It is kinda embarrassing and an honor for the app devs, and its kinda nice for apple.
It’s kinda bad to have your bugs called out in os code, but as the article says its also kind of an honor that Apple cares enough about you and your combined users to fix your bugs for you.
As mentioned elsewhere, Microsoft also does this extensively. I’m pretty sure my niche lob windows apps have not met this qualification.
They may not be bugs at all.
I write Awesome App 2.0 and specifically target MacOS X 10.5
When MacOS X 10.7 comes out I release Awesome App 3.0, to which there is an upgrade path, but $ is expected by me for my hard work.
A certain % of Awesome App users stay at 2.0 but upgrade to Mac OS X 10.7 Unbeknownst to them 10.7 changed NSRandomFunction() to deprecated and instead expects programmers to use NSRandomFunctionUnicodeSafe().
Now, the Awesome App 2.0 users *know* Awesome App 2.0 works great and is bug free because they’ve been using it for years. Clearly the problems they’re now seeing aren’t caused by Awesome App 2.0. Something else is amiss. It won’t take them long to realize that it’s the upgrade to OS X 10.7 that is the culprit. Now Apple could just live with the bad press and customer ill-will (and history has shown they’re quite comfortable doing that), but what if a ten line patch that maps Awesome App 2.0’s calls to NSRandomFunction() instead to NSRandomFunctionUnicodeSafe() and then takes the result and decodes it from UTF-8 back to ASCII would fix the entire thing? It’s negligible engineering effort and saves Apple from all sorts of non-great PR.
None of that makes what is wrong a bug in Awesome App 2.0. It was correctly built to the API available at the time it was created. Just because the API changed in a later OS release doesn’t mean that retroactively Awesome App 2.0 was created incorrectly.
Edited 2018-05-22 00:59 UTC
…I read that “Eclipse” is concerned about “compatibility tweaks”. Seriously? The thing never worked right from the beginning, it’s not about “compatibility”, it’s about “maturity” and “stability’.
The same is true in Windows. When the Win2k(ish) source code was leaked, many fixes specific to certain programs (as well as general fixes for certain compilers and toolkits) were found.
Additionally, it’s known that basically all major games ship broken, and the GPU drivers have to make up for them performing invalid operations.
Turns out everything was always broken.
I used to write video drivers for Win9X (then 2K et al). The unbelievable crap in the OS /and/ drivers to support “Magic School Bus”. Quicktime and a thousand other apps was staggering.
D3D used to be the same. It improved massively in the end but, holy mick mack, each driver would come with a database of module names to change behaviour based on apps. Mostly covering up bugs, sometimes platform behaviour.
Torture!
Meanwhile Android has API levels which allow newer versions of the OS to emulate the broken behavior for old apps targeting an old API levels while providing a clean behavior for newer apps targeting new API levels.
Autodesk Maya is on that list not because “it’s buggy” but because it needs OS support to disable Vertical retrace and get faster playback performance, something that Apple doesn’t want to allow generally for all application that aren’t full screen games.
Since Apple are maya customers themselves, they care.