3 ms·

This guy's about page says: It is my professional mission to build a web that works for everyone. Judging by this article, it's also his “professional mis

by cjk 4y ago

This guy's about page says: It is my professional mission to build a web that works for everyone. Judging by this article, it's also his “professional mission” to present opinion as fact with no connection to reality. 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.

h0l0cube 4y ago
I'm swayed by your internal accounting that internal politics and bureaucracy could have been the main cause behind the lagging feature set of Safari, but do you think that it could also be a downstream consequence of browser functionality being in tension with App Store dominance? i.e. why prioritize something that could eat into your bottom line?
- cjk 4y ago
  To this day, I don't have any reason to believe that anyone in my management chain (at closest, I was two managers down from Craig Federighi) ever considered profit when prioritizing features or bugs.
  - h0l0cube 4y ago
    Thanks for your insight
mtomweb 4y ago
ckj: The number one issue with Safari has always been lack of investment by Apple. It has always been plagued with serious application breaking bugs for the past decade. In comparison with both Firefox and the Chromium browsers bugs would just not get fixed. Most developers I knew gave up in lodging bugs.webkit tickets. This is not the Safari/Webkit's teams fault, just far too small a team for such a complex project and Apple, without any competition on iOS and an adverse incentive to make the web a compelling platform was not going to fund it. This is in addition to the fact that Google was paying Apple not only for Safari search engine traffic but Chrome traffic as well. Outside of the stability issues, the gaps in functionality especially for Web Apps became vast and it was not practical to build a viable Web App on iOS. No Install Prompts, no push, no orientation lock in addition to severe issues with scrolll (which haven't yet been fixed) meant the only way to build a working app was to go native. The only thing that has changed, is that Apple realizes that competition is coming and they need to build a competitive browser. This is why they are investing now. Headcount and the development of Push Notifications was almost certainly related to this regulatory pressure. This is a great outcome, and just with what's happened in the last year I'm really hopeful for the future. That said, still quite a number of critical missing features and fixed are needed before Safari can truly be used as an application platform.
- cjk 4y ago
  Given my experience on the team, I genuinely don't believe that lack of investment, or even team size, has ever been the issue. I think that all of the recent changes and increased transparency are great, but I disagree that the motivation behind those changes was any form of perceived or actual increased competition. From my perspective, this is the result of years--years!--of internal lobbying to improve transparency and increase release cadence. Apple, on the whole, has never been interested in competing with other companies that operate in shared spaces on a feature-by-feature basis, even if it came at the expense of market share. The one and only guiding star has always been the user experience, and if there was no obvious user experience-based justification for prioritizing a feature or a bug fix, then it did not get prioritized, period. This is, in part, why Apple engineers have always been adamant about third-party developers and users filing bugs--a higher quantity of reports makes it easier to justify addressing a particular issue to management during a given development cycle.

by cjk 4y ago

h0l0cube 4y ago

I'm swayed by your internal accounting that internal politics and bureaucracy could have been the main cause behind the lagging feature set of Safari, but do you think that it could also be a downstream consequence of browser functionality being in tension with App Store dominance? i.e. why prioritize something that could eat into your bottom line?

cjk 4y ago
To this day, I don't have any reason to believe that anyone in my management chain (at closest, I was two managers down from Craig Federighi) ever considered profit when prioritizing features or bugs.
- h0l0cube 4y ago
  Thanks for your insight

mtomweb 4y ago

ckj: The number one issue with Safari has always been lack of investment by Apple. It has always been plagued with serious application breaking bugs for the past decade. In comparison with both Firefox and the Chromium browsers bugs would just not get fixed. Most developers I knew gave up in lodging bugs.webkit tickets. This is not the Safari/Webkit's teams fault, just far too small a team for such a complex project and Apple, without any competition on iOS and an adverse incentive to make the web a compelling platform was not going to fund it. This is in addition to the fact that Google was paying Apple not only for Safari search engine traffic but Chrome traffic as well. Outside of the stability issues, the gaps in functionality especially for Web Apps became vast and it was not practical to build a viable Web App on iOS. No Install Prompts, no push, no orientation lock in addition to severe issues with scrolll (which haven't yet been fixed) meant the only way to build a working app was to go native. The only thing that has changed, is that Apple realizes that competition is coming and they need to build a competitive browser. This is why they are investing now. Headcount and the development of Push Notifications was almost certainly related to this regulatory pressure. This is a great outcome, and just with what's happened in the last year I'm really hopeful for the future. That said, still quite a number of critical missing features and fixed are needed before Safari can truly be used as an application platform.

cjk 4y ago
Given my experience on the team, I genuinely don't believe that lack of investment, or even team size, has ever been the issue. I think that all of the recent changes and increased transparency are great, but I disagree that the motivation behind those changes was any form of perceived or actual increased competition. From my perspective, this is the result of years--years!--of internal lobbying to improve transparency and increase release cadence. Apple, on the whole, has never been interested in competing with other companies that operate in shared spaces on a feature-by-feature basis, even if it came at the expense of market share. The one and only guiding star has always been the user experience, and if there was no obvious user experience-based justification for prioritizing a feature or a bug fix, then it did not get prioritized, period. This is, in part, why Apple engineers have always been adamant about third-party developers and users filing bugs--a higher quantity of reports makes it easier to justify addressing a particular issue to management during a given development cycle.