In some cases badly designed themes (like dark gray labels on black backgrounds) are the culprit, but most often it’s a result of the app developers hard coding colors in their UI elements assuming all users will be using a similar theme.
That’s not only bad for custom theme users, it’s bad for accessibility since there’s no way for increased contrast modes to modify the hard coded colors. Apps really just shouldn’t hard code colors.
KDE (or rather Qt) goes even further and still let's you completely change the way interface elements are rendered, which is great because it means you can use the same look across versions if you want to and are not beholden to the latest design fad.
I build bespoke UI elements for iOS apps all the time and building them in such a way that they look and function correctly not only across light/dark and accessibility modes but also future OS versions is not that difficult, and with how they’re built I don’t see them breaking even if iOS took on a radically different appearance. They might not match perfectly but usability will not be impacted.
If this is not reasonably possible with GTK, then it seems pretty clearly like a weakness of how GTK handles themes. Personally, I believe that CSS is ill-suited for the task and is responsible for many of the issues depicted in that blog post.
> not only across light/dark and accessibility modes but also future OS versions
When Apple makes a future OS versions they are expected to avoid breaking apps.
The comparison here would be not to future iOS versions, but to arbitrary jailbreak tweaks that overhaul the look system-wide. You're not ensuring that will look good with your app ;)
That’s not only bad for custom theme users, it’s bad for accessibility since there’s no way for increased contrast modes to modify the hard coded colors. Apps really just shouldn’t hard code colors.