I provided a little explanation for what we are doing here, in this post.
There is a more to it than that of course. Almost everyone that is making a tool of some sophistication is going to be using it in “non-standard ways”; that doesn’t mean a whole lot by itself. The stock text engine is extremely simple, and often does not support full RTF standards (it can’t even properly open a file with footnotes without flat-out deleting them). It does not support styles at all, and it takes considerable effort to make it do so. Thus, saying “no other applications… broke in this way” doesn’t mean much. I can count with two fingers the number of programs using the native text engine that support styles, and the other one is a dedicated word processor that naturally spends all of their coding time on the text engine, to the point that they have deeply modified (in non-standard ways!!) how the native text engine writes RTF.
What we are doing for styles is about as non-invasive as it gets. Styles are saved as a plain-text code just like the text you type in yourself. The only difference is you never see them in Scrivener because they are stripped out and turned into attributes in memory.
This is what a Scrivener RTF file looks like from Windows, opened in a word processor that doesn’t look for these markers and considers them normal text (LibreOffice):
And now here is how the Mac version saves this same exact file (after a trivial update elsewhere to force an auto-save):
This all by itself isn’t too useful to us though, because we can’t really see from this what Scrivener meant to do, or what has always worked before. All we can see is what the updated Apple RTF writer decided to do with that request. So here is a look at what the Mac version saves with a fake list. I typed in the bullets and tabs, and applied the same indent and tab stop settings Apple uses for its list formatting:
You might be wondering why this is different from the Windows save pattern. The difference is in whether the terminal newline on a paragraph that contains a style is included within that styled range.
In practice it doesn’t make a lot of difference, but it can lead to some minor behavioural differences between platforms—such as how Find by Format selects this line, and whether deleting it would also remove the line fully (advancing the list up) or leave an empty line behind. Neither is really right nor wrong, but in this case, including the newline is confusing the RTF writer.
Both are valid approaches, but may produce different programmed behaviours off of functions that work with this attribute. That said, the way Windows works is valid, but unconventional, and has been a point of contention all along, because it is a more standard practice to include the entire line within the styled range, not just up to the penultimate character.
So yes, given the conventional behaviour being followed on the Mac, it has always written lists the way you see them above, even with real lists instead of fake lists, and up until recently that has worked fine, because Apple’s writer was evidently aware of those conventions that they recently have come to no longer respect in all scenarios.
It’s easy to blame Apple.
That’s not how this works, and I don’t really understand that sentiment either, what does that matter? Around here we identify the sources of the problem and spread that information so that people can know what to expect, and potentially how to avoid problems.
In this case, a minor system update to macOS broke every version of Scrivener. That is useful information in two ways: (a) because it informs you that you cannot install an older version of Scrivener to get around it, and (b) if you have the means to do so, you can roll back your OS to an update that doesn’t break it.
(This is all, incidentally, why back when I used a Mac productively, I always stayed one year or more behind the curve. Avoids a lot of drama like this, and most everything tends to get fixed eventually—either by Apple or by hoards of developers having to patch around the bugs themselves. This kind of stuff happens all of the time, and has for years, it’s part of Apple’s culture. Either live with the occasional disruptions or hold back and use last year’s OS (i.e. I’d just be installing macOS 14.x right now, upgrading from 13. It’s done, solved, isn’t going to be changing monthly, and still is recent enough for everything to support it.)
So on to that…
I never said that. We very often have to fix Apple bugs, particularly with the text engine because they often never do fix what they break. This is an ugly and frustrating process, that often involves fragile code that you’d normally never want to use, but if that’s what it takes to fix it, we will, as we have many times in the past.