Catalina suffers from downward compatibility problems. As a result a large number of audio developers have warned their users from upgrading to Catalina.
Now Apple is trying to do damage control and they sent out an email to the freelance developers what marketing language they should use to communicate Apple's shortcomings towards their customers.
This thread should create some public pressure on Apple to improve things in the future, because we devs want to be able to support Apple also in the future.
Please note: This is not an Apple vs PC thread. Please stick to the facts and keep the discussion as objective as possible. We all know that Microsoft's OS also has problems and shortcomings. But Windows will not be discussed here, because it is not the topic of this thread.
The listing below is a summary of aspects that have been posted by various kvr-users. If you got additional points that should be added feel free to submit them.
Technical facts about Catalina (updated on Friday evening and Saturday):
Problems for end-users:
1) Apple did drop 32 bit support. All 32 bit plugins and every other 32 bit software has stopped working. It is also not longer possible to use a bit-bridge.
2) Lots of old software does not longer work
3) Old song projects can not longer be loaded, because there are no 64-bit versions available for many old plugins.
4) Audiounit validation is still not working properly. The computer has to be rebooted before an Audiounit is detected.
5) Many Freeware products will disappear, because it requires that the devs pay a fee of $99 per year. Furthermore the software has be be passed through a very complicated validation process which is a critical barrier for many hobby-developers
Advantages that end-users experience with Catalina
1) They can use Ipad-Apps
2) Enhanced security
3) Display Zoom
4) Sidecar
Problems that end-users will face in the future:
1) Nearly all plugins that use a re-sizeable GUI use a technology called OpenGL. Apple announced that it will not longer be supported in the future. So far it has not been communicated by Apple when support will completely dropped. If this should happen all plugins that use it will stop to operate. Most likely only a small part of devs will provide updates, because they would have to rewrite large parts of the software to swap OpenGL with Metal. This is not economic for many products.
Furthermore all computer Games that use OpenGL will not longer work.
Security problems:
1) With Catalina Apple introduced 'software notarisation'. Apple advertises that this technology should enhance security, however it can be bypassed by hackers with a shell script (which will not be published here).
Problems for developers:
1) They receive a massive amount of email from customers because the installation of AUs is not working properly (auval, a part of macOS the is broken since 2 years now). They have to explain to the customer that he must reboot the Mac or include a dirty hack-script to the installers which forces a restart of auval.
2) By default it is now not longer possible to install older software which is not notarized or signed. Lots of packages have to be notarized and redistributed to the customers
3) Existing software, especially plugins which are not code-signed and are currently still working because of a 'grace period' might soon stop working. It is currently unknown when this grace period will end.
4) OpenGL is deprecated. They have to rewrite large parts of their software or their products will stop to operate as soon as Apple decides to drop it. It is unknown when this will happen
5) The notarisation process is complicated and the tools are not always working flawlessly. The notarisation process itself is slow and problematic if large packages have to be signed, especially with a slower internet connection.
6) With software notarisation in Catalina macOS is not longer an open platform. Apple now got full control about what software is allowed to run on their system and which is not - at least for legit commercial software. Apple now has full control about the developers and their products. In the future Apple can force devs to sell though their own App-store only and take additional fees. Apple also can raise the annual $99 fee for developers to a higher price. From the technical side all developers are completely dependand on Apple. Apple gained full control over the distribution of software on macOS.
7) If you can control what software is running on your OS you can also control the market on this system. This is what Apple does on the IPhone, it is what Sony does with the Playstation, it is what Nintendo does, Google does, the XBOX does, ... : They all take a %xx percentage fee from the sale of every software that is sold from the developer. It is currently not the case for macOS but the door for this scenario has been opened for the future
Advantages for developers
1) Code-signing and Notarisation makes it more difficult to crack their software
2) They do not longer have to compile and test 32-bit binaries
-------------------------------------------------------------------------------
Further info added by the kvr-user 'stratology', quotes and links from the Arstechnica review.
Full review:
https://arstechnica.com/gadgets/2019/10 ... ca-review/
32bit transition
https://arstechnica.com/gadgets/2019/10 ... view/3/#h1
OpenGLApple was careful not to surprise anyone with Catalina's removal of 32-bit support, and the company has been projecting its plans for over two years now. Most developers took the hint, and even software like Audacity and Zoom that was still 32-bit as I wrote the Mojave review last year is 64-bit now—though larger, more complicated apps might still be hung up on old 32-bit dependencies that need to be either updated or replaced. 32-bit apps will remain installed on your Mac, but their icons will be crossed out.
..
The impact of the 32-bit decision will be felt disproportionately. Regular users are unlikely to notice or care—or, at least, it will be reasonably easy to find replacement or updated versions of older apps that support 64-bit. Creative professionals, on the other hand—people who work with images, video, or audio, or folks who rely on expensive (and not always new) external equipment may run into problems with apps, or plugins, or drivers. Community-maintained open-source software is likely to lag behind software maintained by large companies. If you're holding on to older versions of these pro software packages before the whole professional software industry shifted to yearly subscriptions with rolling updates, those apps may not have 64-bit compatibility and certainly won't have it added in an update. And while I don't think macOS is the gaming platform of choice for many people, tons of older games (and, as of this writing, the regular Steam client) are 32-bit only and are extremely unlikely to be updated.
https://arstechnica.com/gadgets/2019/10 ... view/3/#h2
System Extensions and DriverKitOpenGL and OpenCL were officially deprecated in Mojave last year, though that's a little misleading since it implies that Apple had been actively maintaining and updating its support for those standards. In Catalina, as in every macOS version going all the way back to Mavericks, the macOS OpenGL implementation is stuck at version 4.1 (2010), and the OpenCL version is stuck at 1.2 (2011). This means that apps that still rely on those APIs on macOS will continue to run, provided they've been updated to meet the 64-bit-only requirement. But you shouldn't be developing new Mac apps that rely on OpenGL or CL for anything important.
Apple also isn't directly supporting newer replacement standards like Vulkan. Instead, the company is opting to direct developers toward its own proprietary Metal API for both graphics and GPU computing. But that doesn't mean there's no hope for cross-platform developers—the MoltenVK translation layer, which maps Vulkan API calls to Metal ones, is actively being used in several prominent apps, and the results are promising. In both Dota 2 and the Dolphin GameCube and Wii emulator, MoltenVK often performs significantly better than OpenGL while saving developers the trouble of adding and maintaining Metal support. It's not totally without bugs (and as those Dota 2 benchmarks from Phoronix show, still not quite as fast as Vulkan running on Linux or Windows 10), but MoltenVK is still a big improvement over OpenGL.
https://arstechnica.com/gadgets/2019/10 ... iew/10/#h1
..the whole section is worth reading...
..
But because the kernel is such important software, kexts can cause big problems. A bad kext can cause a kernel panic, bringing your whole system crashing down. The kernel has relatively unfettered access to your hardware and to other software running on your system, so a malicious or buggy one can open you up to security vulnerabilities. And from a development perspective, writing kexts can be difficult and time-consuming, since the whole system needs to be rebooted when you have a problem and there’s not much room for error.
Apple’s goal with both System Extensions and DriverKit is to retain the ability to extend macOS’ capabilities—a key point of differentiation between macOS and iOS—while bringing that software out of the kernel and into user space where it can cause fewer problems. A bug can crash the extension but not the whole system; the System Extensions will be subject to the same security policies as other applications; and System Extensions don’t have the same level of unprotected access to the kernel, your hardware, and your apps as kernel extensions do.
..
Apple has defined three different kinds of System Extensions for Catalina: Network Extensions, Endpoint Security Extensions, and Driver Extensions
..
DriverKit: Fairly limited, for now
Apple eventually wants DriverKit to be the only way anyone writes device drivers for the Mac, totally replacing the venerable I/O Kit. Apple describes DriverKit as an “updated and modernized” version of I/O Kit, but at least in Catalina, it’s considerably more limited.
..
Kexts will continue to work as-is for now, but Apple ultimately wants all macOS drivers to make the jump to DriverKit.
..
The future of kexts
Catalina will begin the process of deprecating kexts entirely, but as it did when it dropped support for 32-bit software, Apple is trying to give developers an off-ramp, and the deprecation timeline may look different for different kinds of kexts.
Catalina’s read-only system volume
https://arstechnica.com/gadgets/2019/10 ... iew/11/#h1
System Integrity Protection (SIP), a feature added in macOS 10.11 El Capitan that disables write access for the /System, /bin, /usr/ and /sbin system folders by default. Catalina takes this a step further, creating a separate read-only APFS volume exclusively for system files—including not just the SIP-protected folders, but all system files and most of the preinstalled apps. A new Catalina install with a single user account has around 10GB of data on its system volume and another 4 or 5GB in the user data volume.
If you’re the kind of person who prefers or needs to disable SIP to work with system files and folders, you can still do that, but Catalina throws up another barrier. While SIP’s protections could be disabled permanently from your Mac’s recovery partition, disabling read-only access to the Catalina system partition is reset every time you reboot. SIP and the read-only system volume are related features, but they’re not the same—to access system files, you need to disable SIP from the recovery partition, and then you can mount the system volume as read/write from within Catalina.
..
..your current system volume is marked as a data volume, and system files are deleted, leaving your data intact. From there, a new system volume is created in your APFS container, and the majority of the Catalina system files are written there instead. That new volume is marked as read-only as soon as the installation is complete.
..
To the typical Catalina user who doesn’t notice or care about filesystems or partition maps, they won’t notice a difference.
..
And many of Apple’s changes to APFS in Catalina are done in service of hiding this volume split. Your Catalina system and data volumes aren’t quite the same as two typical APFS volumes—they’re part of something new called a Volume Group, which helps the operating system treat the two volumes in some of the same ways that Mojave and previous versions of macOS treat the unified system and data volume. Not only do the two volumes appear as one in the Finder, but they share things like FileVault encryption keys—the two volumes are encrypted (or decrypted) simultaneously and the same key unlocks them both.
APFS in Catalina supports something called “firmlinks,” as a way to maintain macOS’ existing directory structure despite everything now being spread across two volumes. Think of an alias in macOS or a shortcut in Windows—these are forms of symbolic links (or symlinks), small files that can be stored anywhere and which point you toward another file on another volume, partition, or disk. But where symlinks only go one way, firmlinks are bidirectional. Folders can appear in multiple places, but from the Finder’s perspective and the user’s perspective, neither directory is the “real” one and neither is the “shortcut.”
..
This is where firmlinks come in. Look at the contents of either /Applications or /System/Volumes/Data/Applications, and you’ll see that the only applications actually stored in that folder are the ones you’ve installed yourself, plus Safari (presumably to make the browser easier to update on its own without a major system update). But the Finder still shows the user their installed applications plus all of the regular macOS system apps in the same folder.
According to Apple, firmlinks only exist for directories, not individual files, and they only work within established volume groups like the one Catalina creates when you install it on your system.
Notarisations
https://arstechnica.com/gadgets/2019/10 ... iew/11/#h4
..
This feature was introduced as an optional extra step in Mojave.
..
The notarization process is a bit more involved. It requires developers who want to distribute outside the Mac App Store to submit apps to Apple for review by its Notary Service—this isn’t the same as the actual content review process used to allow apps into the Mac App Store but a shorter and more automated process that should only take a few minutes. The Notary Service checks to see whether the app contains malware; whether it uses the enhanced System Integrity Protection runtime from Mojave that protects running apps from being tampered with; and whether the apps and all their components are properly signed in the first place.
Notarization, like Developer ID, isn’t strictly necessary—non-notarized apps will still run on macOS, one crucial point on which macOS continues to differ from iOS and iPadOS. But to run (at least the first time) without triggering Gatekeeper and scary security warnings, all apps running on Catalina must be notarized. And starting in January of 2020, apps will need to meet new Catalina-specific notarization requirements (these were originally supposed to go into effect when the operating system was released, but Apple relaxed them just a bit to give devs more time).
..
notification fatigue is real
From another source (targeted at sysadmins, but with some useful background):
Notarization on macOS Catalina and IT auditing
https://derflounder.wordpress.com/2019/ ... -auditing/
Unfortunately they don't really care but all they try to do is a bit of damage control.
