I wonder if this policy, or the general mentality that produced it, is why webkit is so underdeveloped and widely reviled by devs compared to alternatives.
Sounds like one can push in a security bug or performance increase that is fast because it is frankly completely broken, but wouldn’t be allowed to reverse the decision at least not without finding some alternative unrelated performance increase. Features or fixes that may obviously be worth an associated dip in performance can generally not be implemented.
Under these conditions if I knew of ways to improve performance without adverse effect, as a developer I would sit on them instead of applying them because I would need a stockpile of reserves to apply in case of emergency to account for unrelated performance degrading changes that absolutely need to be made. I would also work to make sure the benchmarks were lousy and irrelevant.
Policies like this can’t be written by people with any semblance of sense. Singular mindedness on one metric and extreme policies like this can kill development and subvert goals just as lack of discipline can. Everything is a balance. Weigh performance metrics heavily by all
means, but absolutism leads to the absurd.
I guess as long as Apple holds its monopoly on keeping iOS device browsers exclusively on Webkit, it will stick around though.
Sadly having had years of an inside perspective on the competence level or lack thereof of decision makers in the non-revenue generating parts of their software business, can’t say this policy surprises me.
1: https://webkit.org/performance/