backward compatibility – Techdirt (original) (raw)

Apple's Failure To Ensure Backwards Compatibility In Big Sur Leaves Developers Quite Sour

from the doesn't-anyone-check-these-things dept

When there’s a major OS upgrade, like Apple’s recent Big Sur MacOS release, you would hope that an effort was made to ensure backwards compatibility with key apps and services. However, it’s now become clear that Apple failed to do so, and a variety of different developers across a variety of different applications have had to scramble over the last few weeks to update their apps just to keep working on the latest version of MacOS. It’s always understandable that a few apps may fall through the cracks, but with Big Sur, it’s notable just how widespread the reports are of compatibility problems, and just how much scrambling app developers had to do just to make sure their apps continued working. Here are just a few reports of such problems from across the internet.

Starcraft 2

There are plenty of gripes from users about Starcraft 2 problems on Big Sur found on MacRumors and elsewhere.

The issues range from crashes on start to display issues to being “unable to quit the game” (a feature?). A user comments “In general macOS is a train wreck when it comes to gaming,” but the blame is quickly assigned to the Big Sur update.

“Actually before the update, SC2 worked perfectly on my macbook. All the problems only started with Big Sur. I’m still having the issues unfortunately, but I have a workaround that works (with my eGPU)”.

Apache’s Netbeans IDE

This is one case where developers moved quickly. By November 21 the second voting candidate for Netbeans 12.2 was announced with Java programmer Glenn Holmer praising the inclusion of the “Big Sur fix.” The previous release had startup issues.

Other Java IDEs

Many other Java IDEs had issues: “Well, yesterday I impatiently upgraded to MacOs Big Sur and since then I can’t use any of my IDEs (Eclipse, Netbeans, IntelliJ). They don’t recognize the JDK” wrote Pablo Herreo.

It turns out Apple broke the “Java_home” environment variable in Big Sur.

Other programmers suggest using the SDKman package manager “I use sdkman to manage my JDKs and other Java-related stuff. It works pretty good even on MacOS Big Sur” wrote Gleb Remniov.

In the middle of this brouhaha, Azul Systems gets a nod for giving Big Sur users some hope: two weeks ago, the firm had released builds of its Zulu OpenJDK port both for x64 and Apple Silicon which at least made the Netbeans team happy.

Apache’s OpenOffice

“After upgrading from Catalina to Big Sur, users on our French forum report that docx and xlsx cannot be opened. Whatever the opening process, OpenOffice crashes” reads the bug report on the project’s public bugtracker.

This was confirmed by other users on the web forum: “have the same problem. Safe Mode doesn’t fix it.”

Other user comments show that the OpenOffice fork LibreOffice also had issues: “the big problem with LibreOffice at the moment is that, with Big Sur on a Retina-screened Mac, the text is blurry. The devs at LibreOffice are looking to fix this”

Virtualbox

MacOS Catalina and beyond changed the way the OS handles kernel extensions, some of them requiring a system reboot. This raised some developer worries last year. What started as worries has turned into actual problems with Big Sur during the beta cycle for some developers. One example is with Virtualbox, Oracle’s open source virtualization solution.

A long bug report (ticket#19795) on the project’s public bugtracker documents the hurdles faced by users who had VBox working fine on earlier releases but failing on Big Sur, with “security pop-ups” that developers expected to appear, but users didn’t get.

In the end, some manual command line magic and rebooting often led to a working configuration. The good news is that there is now a Virtualbox release available that manages to work fine for most if not all Big Sur users (version 6.1.17 (r141370)).

But the bug squashing didn’t end without sweat and tears. In the flaming bug report, a project contributor was facing end user criticism and chastised Apple for changing a command line tool during the beta cycle, “Apple completely re-did their KEXT handling and there were issues throughout the different Betas with it blocking us from getting everything tested extensively, they even changed the kmutil command line tool completey[sic] in the last Beta.” That same user notes that people saying that “ample time” was given to developers to adjust “is a joke.”

ZFS also affected

In the same Virtualbox bug report, a user reports compatibility problems with the ZFS file system port to the fruity OS: “Nevermind! Further research indicated that the problem was my ZFS installation which hasn’t been made compatible with Big Sur yet”

ZFS developer Jörgen Lundman is still battling the compatibility bugs and API changes, with a test release for x64 available. But things aren’t so easy on ARM64: “So many kernel functions that are missing – so it is hard to say. Still working on it though” he said two weeks ago.

One of the ZFS users has cleverly nicknamed the OS “Bug Sur.” Some sour Apples, indeed.

The more you look, the more problems you find. Native Instruments is noting that a bunch of its software is somehow causing CPU spikes on Big Sur, and it’s working with Apple to find a solution:

Using a MASCHINE MK2 or MIKRO MK2 on macOS 11 (Big Sur) can produce high CPU spikes on your computer, which could cause it to freeze. We are working together with Apple to find a solution to this problem.

Using a KOMPLETE AUDIO 1, KOMPLETE AUDIO 2 or KOMPLETE AUDIO 6 MK2 on macOS 11 (Big Sur) can cause CPU spikes and distortion with sample rates above 172kHz. This can be avoided by selecting large buffer sizes (2000ms). We are working together with Apple to find a solution to this problem.

It’s not surprising that there might be some compatibility problems and updates necessary to deal with a new OS, but it’s striking to see just how many apps seem to have been caught totally off-guard by these changes.

Filed Under: backward compatibility, big sur, developers, macos
Companies: apple

United Airlines Made Its App Stop Working On My Phone, And What This Says About How Broken The Mobile Tech Space Is

from the garbage-in-garbage-out? dept

This post isn’t really about United Airlines, but let’s start there because it’s still due plenty of criticism.

One day my phone updated the United App. I forget if I had trusted it to auto-update, or if I’d manually accepted the update (which I usually do only after reviewing what’s been changed in the new version), but in any case, suddenly I found that it wasn’t working. I waited a few days to see if it was a transient problem, but it still wouldn’t work. So I decided to uninstall and reinstall, and that’s where I ran into a wall: it wouldn’t download, because Google Play said the new version wasn’t compatible with my phone.

Wait, what? It used to run just fine. So I tweeted at United, which first responded in a surprisingly condescending and unhelpful way.

Hi, Cathy. We try to keep up to date with the latest technology and apologize if this has caused you any inconvenience. ^BK

— United Airlines (@united) July 28, 2018

Sometime later I tweeted again, and this time the rep at least took the inquiry seriously. Apparently United had made the affirmative choice to stop supporting my Android version. And apparently it made this decision without actually telling anyone (like, any of their customers still running that version, who might not have updated if they knew they would have to BUY A NEW PHONE if they wanted to keep running it).

Ranting about this on Twitter then led to an interesting argument about what is actually wrong with this situation.

But let’s not let United off the hook too soon. First, even if United were justified in ceasing to support an Android 4.x capable app, it should have clearly communicated this to the customers with 4.x phones. Perhaps we could have refused the update, but even if not, at least we would have known what happened and not wasted time troubleshooting. Plus we would have had some idea of how much United valued our business…

Second, one of the points raised in United’s defense is that it is expensive to have to support older versions of software. True, but if United wants to pursue the business strategy of driving its customers to its app as a way of managing that relationship, then it will need to figure out how to budget for maintaining that relationship with all of its customers, or at least those whose business it wants to keep. If providing support for older phones is too expensive, then it should reconsider the business decision of driving everyone to the app in the first place. It shouldn’t make customers subsidize this business decision by forcing them to invest in new equipment.

And then there was the third and most troubling point raised in United’s defense, which is that Android 4.x is a ticking time bomb of hackable horror, and that any device still running it should be cast out of our lives as soon as possible. According to this argument, for United to continue to allow people to use their app on a 4.x Android device would be akin to malpractice, and possibly not even be allowed per their payment provider agreements.

At this point we’ll stop talking to United, because the problem is no longer about them. Let’s assume that the security researchers making this argument are right about the vulnerability of 4.x and its lack of support.

The reality is, THE PHONES STILL WORK. They dial calls. They surf the web. They show movies. Display ebooks. Give directions. Hold information. Sure, at some point the hardware will fail. But for those wrapped in good cases that have managed to avoid plunging into the bath, there’s no reason they couldn’t continue to chug on for years. Maybe even decades. In fact, the first thing to go may be the battery ? although, thanks to them often not being removable, this failure would doom the rest of the device to becoming e-waste. But why should it be doomed to becoming e-waste a moment before it actually becomes an unusable thing? Today these phones are still usable, and people use them, because it is simply not viable for most people to spend several hundred dollars every few years to get a new one.

And yet, in this mobile ecosystem, they’ll need to. Not only to keep running the software they depend on, but to be able to use the devices safely. The mere ability to function no longer is enough to delineate a working device from a non-working one. The difference between a working device and a piece of trash is what the OS manufacturer deems it. Because when it says it’s done maintaining the OS, then the only proper place for a phone that runs it is a landfill.

It is neither economically nor environmentally sustainable for mobile phones to have such artificially short lifespans. “Your phone was released in 2013!” someone told me, as if I’d somehow excavated it from some ancient ruin and turned it on. It’s a perfectly modern device (in fact, this particular phone in my possession came into use far more recently than 2013), still holds a reasonable charge, and is perfectly usable for all the things I use it for (well, except the United app…). So what do you mean that I can’t use it? Or that any of the other millions if not billions of people in the world running Android 4.x phones can’t use them?

There are lots of fingers to point in this unacceptable state of affairs. At app makers who refuse to support older OSes. At app makers who make us use apps at all, instead of mobile web applications, since one of the whole points of the Web in the first place was to make sure that information sharing would not be device- or OS-dependent. At carriers who bake the OS into their phones in such a way that we become dependent on them to allow us OS updates. At the OS manufacturers who release these systems into the wild with no intention of supporting them beyond just a few years. And to various legal regimes (I’m looking at you, copyright law?) that prevent third parties from stepping in to provide the support the OEM providers refuse to anymore. Obviously there are some tricky issues with having a maintenance aftermarket given concerns with authentication, etc., but we aren’t even trying to solve them. We aren’t doing anything at all, except damning the public to either throw good money after bad for new devices that will suffer the same premature fate, or to continue to walk around with insecure garbage in their pockets. And neither is ok.

Filed Under: backward compatibility, mobile apps, transparency
Companies: united