It really depends how much mileage you get out of multithreading a system. if you look at games, there was a time when games were all single-threaded, then they moved to hardcoding specific tasks to certain threads. The first step you traditionally do when moving a codebase onto multiple threads is to move the rendering engine onto a seperate thread. This kind of approach gives you some rough parallelism, but it’s hard to scale when moving to 4 threads or 8 threads.
These days, most large games have switched architecture to a job-based approach, where you split the work the engine is doing into many small jobs, which are then farmed out to a pool of threads. This is a lot more scaleable, and it really depends on how many jobs you’ve got whether you can keep your thread pool at 100% utilization.
With more typical Mac software, utilities and creative programs and so on, there are generally fewer tasks than in game software. It will take some time for developers to get used to the new way of working.