MacInTouch Amazon link...

macOS 10.15 Catalina

Channels
Apple, News
Like others, I have some legacy software (like QuickTime 7 Pro) that I occasionally need. I long ago set up a VM for Snow Leopard to handle some old Adobe (and other) programs that I still need for supporting clients who can't upgrade. I plan on setting up a VM for Mojave to take care of whatever 32-bit programs I can't do without. It's a minor inconvenience [for me].
 


Ric Ford

MacInTouch
Yup, Apple gives their macOS away for free, so there's no money to pay the costs to keep on developing and supporting the legacy 32-bit APIs (but a tricked out Mac Mini with that "free" OS costs $3,599.00). I mean, the company is so hard up, they have to deliberately stop supporting hardware, too, after just ~5 years, 'cos that's soooo expensive (yet, your high-end iMac "Pro" that will still be forced into obsolescence in around 5 years can cost $15,848.00)...
You hit the nail on the head, and, in fact, Apple's customers are paying a great deal of money for software updates, it's just that Apple hides that with accounting tricks that make software expenses appear to be "free" when they are actually incorporated in Apple's exhorbitant hardware prices and counted as subscription revenue!
 




I suspect very few today would be willing to pay even the $130 per computer (or $200 per 5-computer family pack) that Apple used to charge for major upgrades.​
If it no longer sucked, and the "updates" and "maintenance" being done were actually relevant, purposeful (for the good of the user), and resulted in a more robust tool, I would. But I suspect I am among a small demographic, perhaps disproportionately represented here on MacInTouch.
 


Given that I would have to pay thousands of dollars to replace my 32-bit software, I, for one, would be willing to pay $200 for continued 32-bit support...
I work in academia, and I have many 32-bit applications I rely upon to help me analyse data, map DNA constructs and visualise molecules. Most of these are freeware, released by fellow researchers, and some will be updated by their authors, but many will not. These are often gnarly, awkward little programs, but profoundly useful in their niche.

There are often commercially available programs that can replicate some of these utilities, but here's the kicker, the licenses often run into thousands of dollars annually (even 'academic' licenses), and we don't have that sort of money to spend on software. One solution is to get my hands dirty with Python and write my own data analysis programs. But I'm getting on in life, and these things don't come as easily as they used to. There's also the significant time investment required. So, in the meantime, I'll avoid 10.15 as long as reasonably possible, make the leap into Windows, or look at virtualisation options. Change isn't always good.
 


As long as Apple updates their applications to supply what was previously afforded to their clients, then I have no problem, even if they want to update to 128-bit! However, to abandon the base just to somehow relieve their responsibilities to what is still relevant technology, seems like a pretty heinous abuse of power.
 


I agree with most of the other complaints about this. Computers and computer users (yes, computers = Macs) are no longer even close to top priority for Apple - they're now almost demotivating. I’m getting the ugly feeling that Apple is either going to spin off the Mac division or possibly even stop making them altogether.
 


Unfortunately, Apple's current designers do seem shamefully oblivious to the brilliance, essence and integrity of the original Macintosh Human Interface Guidelines...
That to me is far more important than 32-bit vs 64-bit. These guidelines are what made Apple what they are today.

I realize so many iOS users are blissfully unaware of the existence of these guidlines and how important they are. They are the basis for Apple's continued existence - without them, Apple would not have survived long enough to create the iPhone. And, does any iOS device conform to them? Not often in my experience.

Does it matter to Apple's survival? Maybe not, because there are no high expectations for any touch interface that I have seen, so maybe it's not a problem.

But it does play a critical part of whether I stay with Mac or not. Even though they don't necessarily need to follow those guidlines, the good third-party Mac app developers do for one reason: the Macintosh Human Interface Guidelines work! Like the alphabet and the multiplication tables work. Good luck going without them.
 


As the system architecture grows and evolves, all the 32-bit libraries and frameworks need to be updated to remain compatible. This means architecture, engineering, testing and support. That can cost as much as it does for the 64-bit APIs, possibly doubling Apple's R&D costs for the product.
Yup, Apple gives their macOS away for free, so there's no money to pay the costs to keep on developing and supporting the legacy 32-bit APIs
But why must there be two sets of APIs?

Back to z/OS: it doesn't have different APIs and services for 24-bit, 31-bit, and 64-bit programs. There's just one set of APIs and services for applications to use.

Now, if you're talking about dropping the Carbon framework, that could save on development effort. But that's not what they're doing here. Apple is also dropping support for 32-bit Cocoa applications. In fact, as far as we know, Apple is changing macOS so it won't even execute 32-bit code, even if it uses no frameworks or APIs.

Are there really separate 32-bit and 64-bit Cocoa frameworks? Why was that necessary?
 


I won't be leaving the 32-bit world behind. I have numerous 32-bit apps that I like and use which won't be updated in the future (such as the standalone version of "Picasa").

Nor will I be leaving the world of HFS+. Again, my utility apps are designed to maintain it.

I've just bought a 2018 Mac Mini, which will be my "main computing platform" into 2025, 2026, perhaps even 2027.

I've set it up with Mojave running under HFS+ on the internal drive.
T2 functions are disabled (insofar as they can be, using the Startup Security utility).
It boots and runs just fine with HFS+.

If I need to update the OS, I keep a "mule drive" formatted to APFS with a copy of Mojave on it, and Software Update can be used on that drive. But other than for updates, it is never booted or used.

Once Mojave becomes "mature" (with the release of macOS 10.15), the internal drive will no longer be updated and will remain at macOS 10.14 - for the life of the Mini.

Thus, I'll have a relatively late-model Mac, still capable of running 32-bit, for the foreseeable future.

I will probably also keep at least one "later version" of the macOS on an external SSD, to boot and run externally when needed. But again, my "main OS" is going to be macOS 10.14.x for the next 6-8 years.

Before anyone jumps in and says "you'll be running an outdated version of the OS that is no longer supported", I care not at all about such things. My old 2010 MacBook Pro still boots its original OS (Mac OS X 10.6.8) and runs fine. Others may worry about such things... I don't.
 


You hit the nail on the head, and, in fact, Apple's customers are paying a great deal of money for software updates, it's just that Apple hides that with accounting tricks that make software expenses appear to be "free" when they are actually incorporated in Apple's exhorbitant hardware prices and, critically, counted as subscription revenue!
If I recall correctly, it was just such “accounting tricks” that prompted the federal anti-trust action against IBM in the late ‘60s or ‘70s, which eventually led to IBM “unbundling” hardware and software pricing. Hmm...

Unfortunately, the federal government has pretty much abandoned anti-trust enforcement in this century.
 


Ric Ford

MacInTouch
I've set it up with Mojave running under HFS+ on the internal drive.
T2 functions are disabled (insofar as they can be, using the Startup Security utility).
It boots and runs just fine with HFS+.
If I need to update the OS, I keep a "mule drive" formatted to APFS with a copy of Mojave on it, and Software Update can be used on that drive. But other than for updates, it is never booted or used.
That's an interesting approach, but how exactly do you coordinate updates with your main system? That is, how do you migrate and merge updates from the "mule" drive into your main HFS+ system without causing problems, such as wiping out user preferences or breaking compatibility with something due to update changes?
 


I have grumbled here before about my main 32-bit concern. I have an absurdly expensive Hasselblad Flextight X1 film scanner that looks like becoming a giant paperweight when my last Mac running High Sierra dies. It requires proprietary software from Hasselblad, and they refuse to say what their plans are. I know they approached a large scanning software company but couldn't make a deal (LaserSoft, I believe). Ed Hamrick has said he can adapt VueScan but they won't give him any engineering details to permit this.

I fear Hasselblad will abandon these rather special scanners. I did make a VM in Parallels that will run the software fine, but Parallels can't see FireWire ports.

Amazingly, High Sierra can see and communicate with the scanner using a FireWire 400-to-FireWire 800 cable, a FireWire 800-to-Thunderbolt dongle, and a Thunderbolt to USB-C dongle, all daisy-chained. I guess if a VM environment is made that will utilise the USB-C ports on current Macs, it might be worth trying again.
 


I fear Hasselblad will abandon these rather special scanners. I did make a VM in Parallels that will run the software fine, but Parallels can't see FireWire ports. Amazingly, High Sierra can see and communicate with the scanner using a FireWire 400-to-FireWire 800 cable, a FireWire 800-to-Thunderbolt dongle, and a Thunderbolt to USB-C dongle, all daisy-chained. I guess if a VM environment is made that will utilise the USB-C ports on current Macs, it might be worth trying again.
It should be able to be passed to the VM environment by Parallels as a USB (or Thunderbolt) attached device. Some combination of these settings should do it:
 


Given that I would have to pay thousands of dollars to replace my 32-bit software, I, for one, would be willing to pay $200 for continued 32-bit support...
No need to pay; just keep using what you have. When Apple releases 10.15, just don't upgrade to it. Save your money for any repairs needed by your existing equipment. It may mean having to abandon some of the subscription software from vendors who are transitioning over to 64-bit but that's the other vendors, not Apple. With a little imagination and effort, one may keep using the 32-bit versions for many more years.

Alternatively, there's Windows (or Linux, if you don't mind the sort of applications that pass for professional level there). I am not being facetious here. I used to say that Windows wasn't that bad but Apple's laughable UI and file system changes have made macOS and Apple hardware much less desirable.
 


You hit the nail on the head, and, in fact, Apple's customers are paying a great deal of money for software updates, it's just that Apple hides that with accounting tricks that make software expenses appear to be "free" when they are actually incorporated in Apple's exhorbitant hardware prices and counted as subscription revenue!
The two go hand in hand. If Apple would unbundle the software pricing (e.g. charge money for upgrades), then they would have a clear indication, on their balance sheet, of how many people want the new software and how many do not (because the sales figures will indicate how many people are actually willing to pay).

By bundling it all together as "free" upgrades, they have no clue. Their revenue is completely unaffected, whether everybody upgrades or if nobody does. And they get lots of people who upgrade simply because it exists, without giving it any thought - people who would consider that decision if it cost them $130 a pop.

So, Apple has no (financial) feedback about whether anybody likes or wants their new software, and we can all see the result.

You could argue that hardware sales will reflect this, but that's a much more tenuous connection, and it is probably impossible to link those figures with what customers think of the software.
But why must there be two sets of APIs? Back to z/OS: it doesn't have different APIs and services for 24-bit, 31-bit, and 64-bit programs. There's just one set of APIs and services for applications to use.
There are separate sets of APIs. The fact that you might type in the same function calls in your C program (or whatever language you're using) doesn't mean there aren't three different libraries containing three different implementations of those calls, all of which need to be maintained, tested and supported, and which IBM's customers pay quite a lot (in ongoing maintenance fees) in order to have.

The only way you could truly have only one set of calls would be for every single system call to result in sending a packet of data to a completely independent API server process (some kind of remote procedure call). Doing that for literally every system call would completely cripple performance, so it's unlikely anybody would do it outside of a research project.

(This is, of course, one of the fundamental design points for microkernels and is also why microkernel-based operating systems don't perform well and are not used commercially without hacks that violate this design for many timing-critical parts of the OS.)
Now, if you're talking about dropping the Carbon framework, that could save on development effort. But that's not what they're doing here. Apple is also dropping support for 32-bit Cocoa applications. In fact, as far as we know, Apple is changing macOS so it won't even execute 32-bit code, even if it uses no frameworks or APIs. Are there really separate 32-bit and 64-bit Cocoa frameworks? Why was that necessary?
There are most certainly separate 32-bit and 64-bit Cocoa frameworks, as there are 32- and 64-bit versions of the underlying BSD/Unix functions, the C library, and all of the other library code that an application requires.

There also needs to be code in the OS kernel to correctly execute both 32- and 64-bit code at the same time. It doesn't "just happen". The scheduler (that makes multitasking happen) needs to switch the CPU between the two operating modes, which include two representations for process/thread state and lots of other critical functions.

All of this is software that needs to be maintained, upgraded and supported. You and I can argue about whether it is wise for Apple to spend money on this maintenance and support, but you can't argue that the work doesn't have to be done.
 


There are separate sets of APIs. The fact that you might type in the same function calls in your C program (or whatever language you're using) doesn't mean there aren't three different libraries containing three different implementations of those calls, all of which need to be maintained, tested and supported, and which IBM's customers pay quite a lot (in ongoing maintenance fees) in order to have.
This may be what Apple did, but I still don't see why they had to do it this way.

What IBM did for z/OS is to just make the API's compatible at the higher address mode. To go from 24-bit to 31-bit, they made the APIs and services 31-bit compatible, but they can still be called by 24-bit programs. In some cases, to get full 31-bit capability, a 31-bit program needs to change their call slightly; otherwise it still works the same as it did for 24-bit.

Behind the scenes, increasingly large parts of the run-time systems operate in 64-bit mode, even if the caller is 31-bit. It isn't like, if you're 31-bit, you don't get to use the 64-bit implementations of the function calls.

I think you're saying that to have one run-time would require an RPC-type call, in order to switch from a 32-bit process to a 64-bit process. That's not how it works on z/OS. Any process can switch modes at any time, even in application code. It takes a single instruction.* So, if you're in 24-bit mode but need to be in 31-bit mode, you just switch the mode. So, in the system code, if it is called by a 31-bit program, it can switch to 64-bit mode and then back again.

On z/OS the scheduler switches the mode while multitasking, but the mode is just a single bit on the hardware's Program Status Word, so this is not a performance impact. There are not different process states or anything like that.

Maybe really what's at issue here is the z/Architecture Instruction Set architecture. It doesn't have different instructions for 24-bit vs. 31-bit vs. 64-bit mode. Any program can use any of the instructions. All the address mode does it tell it how to interpret addresses; for example, in 24-bit mode it ignores the first byte of an address, in 31-bit it doesn't. A 31-bit program can use instructions that use all 64-bits of a register.

(I suspect one of the drivers of Apple's moratorium on 32-bit code is there could be two different Objective-C run-times, with different formats for the Objective-C compiled objects. But I still don't see why there had to be two different run-times, instead of one run-time that handles both object formats.)


* It actually takes less than a single instruction, because you switch modes and branch at the same time. So if you're already branching to somewhere, you get the mode change as a bonus. And, the system automatically changes modes when needed, such as when one program calls another via a "link".
 


<lots of good comments>
Of course, the driver for these changes may not be anything yet discussed...

Consider the cost for conversion of code to another instruction set processor, for example, Intel to ARM.

Or, even, code memory and storage footprint. The fewer applications and library variants that exist, the less testing and support costs.

Along with this, fitting high-function code into wearable devices becomes more feasible. For iDevices (iPad, iPhone, Apple TV, ...), less storage for code means less memory and bandwidth occupancy and more room for all those downloads.

This is most likely part of the general trend from Apple Computer to Apple, the media and life { style | support } company.
 


I would rather pay for a solid major upgrade every two years or so than deal with Apple’s yearly releases—especially if Apple were also releasing compelling hardware on a reasonable schedule.
Absolutely! I think the prospect of potential lost sales motivated Apple to do a better job [in the past]. It was an incentive to release quality software and to quickly fix any serious bugs that did slip through. I had no problem paying $129. The way I see it, the time it took me to save up the money gave them time to fix the initial bugs.
 


Absolutely! I think the prospect of potential lost sales motivated Apple to do a better job [in the past]. It was an incentive to release quality software and to quickly fix any serious bugs that did slip through. I had no problem paying $129. The way I see it, the time it took me to save up the money gave them time to fix the initial bugs.
Absolutely. I'd rather pay for quality software and privacy than have neither for free.
 


I think you're saying that to have one run-time would require an RPC-type call, in order to switch from a 32-bit process to a 64-bit process. That's not how it works on z/OS. Any process can switch modes at any time, even in application code. It takes a single instruction.* So, if you're in 24-bit mode but need to be in 31-bit mode, you just switch the mode. So, in the system code, if it is called by a 31-bit program, it can switch to 64-bit mode and then back again. On z/OS the scheduler switches the mode while multitasking, but the mode is just a single bit on the hardware's Program Status Word, so this is not a performance impact. There are not different process states or anything like that.
Interesting. I've never seen anything like this in the Unix world. Multi-architecture systems, including Linux, Solaris and others require each process to be a single architecture, 32- or 64-bit. Standard shared libraries (like the C library and other system services) require both 32- and 64-bit versions in order to dynamically link against processes of the matching architecture.

Switching modes on an x86 processor is definitely not cheap. Note that 64-bit mode adds additional registers that don't exist in 32-bit mode, and all the registers change size. Trying to change modes while preserving the memory organization (page tables, pointers, caches, etc.) is going to be a non-trivial operation - definitely a lot more than a single lightweight instruction.

An RPC mechanism might not technically be necessary, but it would still require an expensive mode switch when entering and leaving system library code if you want to keep a single set of system libraries for both modes.

If mode switching is so lightweight on Z-series computers that this can be done without a significant performance penalty, then that's great, but it's not going to port over to x86.

Would this also be the case on ARM (or PowerPC)? I don't know those architectures well enough to know, but it would almost certainly require a significant change to the portable BSD kernel that Apple uses in macOS.
 


.textclipping files are apparently resource files.
Very interesting. I wonder what is going to happen in macOS 10.15, when the 32-bit APIs (including all of Carbon, where the Resource Manager lives) get deleted. They're going to need to do something about text clippings.

I can imagine a few possibilities:
  • Make a Cocoa port of the Resource Manager (or at least a basic subset of it), so the necessary APIs will remain available in the 64-bit world. This would be my preference, but it also seems unlikely. I can only see them doing this if there are a lot of different standard file types that all depend on resources.
  • Migrate the parts of the resource manager needed for text clippings into the text clipping code itself, so the text clipping library will open the resource fork as an opaque block of data and manually read/write the resources contained within - a hack, but an acceptable one if there aren't any other standard file types that require resources.
  • Change the format of text clipping files to something that doesn't use resources, converting all existing clippings as a part of the OS upgrade - probably the best for most users but will really tick off people who run multiple macOS versions and share clipping files among the systems. (Side question: does anyone actually do this?)
  • Change the format of text clipping files and don't auto-convert existing clippings, but keep an importer module that can read the old format for the next few OS releases, dropping support in the future. Maybe offer to upgrade clippings as they are used as well.
  • Change the format of text clipping files, don't convert anything, and let old clipping files break (the fastest, easiest and cheapest option, even though it is the most user-unfriendly).
I wonder if there will be a third-party (open source?) project to create a resource manager for 64-bit code. I assume the resource fork organization is well documented and it's not likely to change, so there's no technical reason why it couldn't be done. If the developers consist entirely of people who have never seen Apple's source code, working only from public information, there shouldn't be a copyright problem.
 


New Apple Tech Note confirms Aperture will not run on any macOS beyond Mojave.
Apple said:
Migrate your Aperture libraries to Photos or Adobe Lightroom Classic
In June 2014, Apple announced the discontinuation of development of Aperture. Since that time, Apple has released five major macOS updates. For technical reasons, Aperture will not run in future versions of macOS after macOS Mojave. To continue working with your Aperture photo libraries, you must migrate them to the Photos app included with macOS, or migrate them to Adobe Lightroom Classic.
 


I just ran across this article about the IINA media player.
TidBITS said:
IINA is based on the open source mpv video player application (which is, in turn, based on FFMPEG) but is designed as a proper Mac application, so (unlike VLC, which is also based on FFMPEG) it should be easier for Mac users to learn and use.

I don't think it can convert formats (the way VLC and Handbrake do), but it may still be an important tool, given the soon-to-be-abandoned QuickTime 7.
 


I just ran across this article about the IINA media player.
IINA is based on the open source mpv video player application (which is, in turn, based on FFMPEG) but is designed as a proper Mac application, so (unlike VLC, which is also based on FFMPEG) it should be easier for Mac users to learn and use.
I don't think it can convert formats (the way VLC and Handbrake do), but it may still be an important tool, given the soon-to-be-abandoned QuickTime 7.
It also has the ability to find and download subtitles which is also useful.
 


Ric Ford

MacInTouch
It will be interesting to see how compatible Apple's FileMaker products are with macOS 10.15.
FileMaker An Apple Subsidiary said:
FileMaker Pro 17 Advanced release notes
As FileMaker Pro Advanced evolves, the list of supported technologies, APIs, and features will change. As part of this evolution, certain operating systems versions, hardware, and features may be deprecated in favor of newer ones. Although deprecation does not mean the immediate deletion of an item, you should migrate your solution away from deprecated technologies, because these technologies may be removed in a future version of the product.
 


I'm still running macOS 10.12.6 Sierra happily on my two main Macs, and I've been very hesitant to upgrade to either High Sierra or Mojave.

I have a spare Mac in the office, so, after hearing so much about the demise of iTunes and other changes, I went ahead and installed the WWDC build of the macOS 10.15 Catalina beta (19A471t) on it. The spare machine is a 13" mid-2012 MacBook Pro (non-Retina) with 8 GB RAM and a Core i7 CPU. The hard drive is the machine's factory-original 5400 RPM 750 GB spinning disk.

Upgrading this machine directly from Sierra to Catalina took almost exactly an hour from launching the installer to landing in the Catalina Finder, including the conversion of the hard drive from HFS+ to APFS.

So far, I'm very pleasantly surprised by Catalina's performance on this older MacBook Pro. Even with only a 5400 RPM drive, the machine feels very snappy and responsive. I may be imagining it, but it almost feels like opening windows and other basic Finder tasks are faster than they were on this machine under Sierra. Web browsing with Safari also feels quite brisk for a seven year old machine. On the negative side, booting and logging in both feel noticeably slower than under Sierra, but not objectionably so.

Some minor notes:

Apple has switched from BASH to ZSH as the default shell in Terminal.app for new user accounts, but it does not appear to force the switch for existing accounts. Instead, if a user is not using ZSH, a banner message appears at the top of new Terminal sessions explaining how to switch to ZSH manually. This is much better than the last time Apple switched default shells. When Apple moved from Jaguar to Panther, it switched all users from TCSH to BASH without warning users. Maybe Apple is recognizing that there are a lot more developers using the macOS command line today than in the past.

The new Music, Podcasts, and Apple TV apps do not appear to be complete rewrites of those functions but seem to be based on existing iTunes code. For example, the Preferences windows for each of the apps are just slightly modified revisions of the old iTunes preferences, with the same look and feel as the old iTunes preferences. In contrast, the main windows of the new apps have refreshed interfaces. My guess is that the preferences windows will be refreshed to the new look in future betas.

I was expecting that these new iTunes-based apps would continue Apple's recent pattern of poor interface decisions, but, at first glance, they're not bad at all. I actually think the switch to the new apps feels much less jarring than when Apple dropped support for multiple playlist windows in iTunes 11.

That said, I am disappointed that the browsable list of "Internet Radio" stations seems to have been dropped, but at least you can open third party music streams manually using the "Open Stream" command. I had feared that Apple would drop the ability to listen to non-Apple radio streams altogether. If you like having a browsable list of Internet Radio stations handy, I strongly recommend creating custom playlists of stations from the Internet Radio browser before upgrading to Catalina, as it will be much less convenient to create Internet Radio playlists after the upgrade removes the browser. (Note: additions/modifications are no longer being accepted to the iTunes Internet Radio browser, so it looks like that feature probably will just degrade over time if you keep running iTunes on older versions of macOS.)

Unfortunately, installing the Catalina beta removed the old version of iTunes from the Mac, and attempting to run the standalone iTunes 12.8 installer fails with the message that "macOS version 10.13.99 or earlier" is required.

I haven't loaded any third party tools on the test Mac yet, but, bottom line, my initial impression is that Catalina looks very promising, including on older supported hardware.
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts