Please check developer. apple. com / design / human-interface-guidelines / macos / visual-design / color down to the part how you : Don’t hard code system color values in your app
I’m quite sure the graphic designer went through all of those guidelines several times, and if I had to guess I would say Apple means don’t hard code them, in the actual technical sense, where you have software that is always System Blue in its buttons, or whatever, no matter the user’s preferences. I wouldn’t myself describe using a dynamic colour setting that comes from the system as hard-coding. It’s rather the opposite if something is dynamic.
To relay his thinking on the matter, he felt that the system accent colour should be used to indicate elements that are “active” within the software window. There are other examples that use that approach, such as the Forklift dual-pane file manager.
I don’t actually disagree with you to be clear, it’s a change that never made any sense to me, on something that wasn’t broken. How Scrivener used to use colour to communicate the various split states had very little to do with the concept of “active focus” in the interface—where you’d have a good argument for using the system colour. It is now using a binary colour system (inactive vs active) to express four different states, so it is obviously going to be less effective at communicating some of them than it used to be.
But again, it was considered that Apple so strongly wants software to look “accented”, that this was worth having less effective communication overall. Maybe they are right. I don’t claim to understand Apple design decisions much, these days, so I could be out of touch.
No fix. a workaround: try switching your system to …grey? while using Scrivener
You might not want to use that one either. I used to use system grey, but found it impossible to use Scrivener efficiently with it, because the difference between an inactive split, active split and locked split is inscrutable at all times.
And so I am afraid we found out that the system accent Red, which looks very nice as a system accent, in Scrivener translates into error-message-pink, which somehow was not tested before hardcoded.
Well, that is all at once culturally contextual (where I’m from, yellow is generally used for strong warnings and errors more often than red), quite a presumption, and lastly, not very charitable. One can make a decision you don’t care for or agree with, without them being incompetent. I tested every facet, window, dialogue box and corner of the cosmetic update across multiple macOS versions. Missed a few pixels here and there, but we got most of them sorted out.