It is my professional mission to build a web that works for everyone.
I was on the Safari/WebKit team from 2012-2015, and I can say with absolute certainty that the author has no clue what he's talking about with respect to how bug tracking, feature/bug prioritization, or headcount works at Apple.
I could elaborate on all of that for an hour or more, but what I will say is this:
The _number one_ problem with the speed of Safari/WebKit releases has always been that they have traditionally been tied to the release of major OS versions. A few of us on the team referred to this as the “fundamental tension,” i.e. the tug-of-war between yearly OS releases and the much-faster pace of innovation of the web platform.
Everyone on the team was aware of this. Many of us lobbied to change this. The holdup was _absolutely not_ due to any kind of willingness to keep Safari behind in order to push people toward native apps, it was due to the seemingly-immovable internal culture of everything being tied to a yearly OS release.
The culture finally started to change with the advent of the Safari Technology Preview builds, which were explicitly meant to offer insight into the progress of new WebKit features. It seems like my former colleagues have done a great job in pushing for greater transparency and more frequent release cycles since then, and I applaud them for doing so.