5 ms·

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

by 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.

mtomweb 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. How would explain the enormous numbers of serious bugs, or the fact the Safari had slipped well behind Firefox, a non-profit with a fraction of the resources? I lost count of the number of times local storage or indexedDB was broken by updates. Not to mention countless, very obvious regressions. Web Apps that would randomly crash 60 times a day (with one time requiring us to wait 1-2 months for the patch to role out. Also even in the code base, you'd have (exceptionally talented) engineers juggling complete disparate and unrelated areas of code. One major issue with no competition, is Apple never responded to developer needs. There were literally many thousands of requests for Push API for years and since no other vendor could implement them (no other vendor could even install Web Apps), there was no competitive pressure. I don't buy the "user experience" argument. A browser full of bugs does not lead to a good user experience and the expense it imposes on developers is enormous. As a personal example, we had such serious issues with scroll, tap to focus and bounce that the only solution was to recode all scroll-logic including scroll-bars, momentum bounce in javascript while the same app could be built with only minor issues in both Firefox and Chrome despite the fact that iOS Safari was our primary target. As for the bugs, they just didn't get fixed. So many for, years and years. That all said, this is past history, and I'm very hopeful for the future. The fact Apple has hired a ton more staff (including significant numbers of QA/Testers staff), a ton of really excellent web OG's and are pumping through both the features and the bugs really bodes well for the future of browser competition.
- cjk 4y ago
  We can disagree on the user experience-based motivation. Given the lack of any kind of public data on how those decisions are made, I can't blame you for thinking that way. I do agree that developer experience is important, and that Apple should take developer experience more seriously than it does, and that applies across every org in the company. Case in point: the infuriatingly-opaque and mercurial nature of the App Store review process. The problem is that, percentage-wise, developers are a minuscule portion of Apple's overall userbase. That makes the justification for fixing concerns that are (perceived as) unique to developers difficult when the culture has traditionally leaned toward prioritizing issues with a more obvious impact on the majority of users. I'm not saying this is correct or desirable, just the way things have worked historically. Given all of that, I think “a browser full of bugs” is relative. I witnessed many instances of bugs being experienced by large numbers of users being fixed extremely quickly. It's always been a function of (obvious, measurable) impact. If a significant percentage of web apps were crashing 60 times a day, those bugs would have been fixed extraordinarily quickly.
  - mtomweb 4y ago
    These same issues would get fixed in Firefox and Chrome. Safari was the outlier. We couldn't ask our users to use another competitive browser, since they'd been banned (and we most certainly would have put up banners). The 60 times a day crash (more specifically the app just froze), took 1 to 2 months to fix and it affected every web app. Users would have to force kill the app and restart. I'd recommend reading through all the comments to get a really good idea on how severe all of the bugs were: https://open-web-advocacy.org/walled-gardens-report/#ios-safari-is-buggy https://open-web-advocacy.org/walled-gardens-report/#ios-saf... https://open-web-advocacy.org/walled-gardens-report/#safari-has-been-buggy-for-a-long-time https://open-web-advocacy.org/walled-gardens-report/#safari-... In 2021, after 10 years of these issues, no progress on important web app features (like push/install prompts), no response from Apple or the Safari/Webkit team, we decided the only method by which Apple would fund Safari properly was to goto governments and regulators to reverse their ban on third party browsers. Not long after we petitioned regulators Apple started working on push notifications, 12 years after they came out for native.
  - 4y ago

by cjk 4y ago

mtomweb 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. How would explain the enormous numbers of serious bugs, or the fact the Safari had slipped well behind Firefox, a non-profit with a fraction of the resources? I lost count of the number of times local storage or indexedDB was broken by updates. Not to mention countless, very obvious regressions. Web Apps that would randomly crash 60 times a day (with one time requiring us to wait 1-2 months for the patch to role out. Also even in the code base, you'd have (exceptionally talented) engineers juggling complete disparate and unrelated areas of code. One major issue with no competition, is Apple never responded to developer needs. There were literally many thousands of requests for Push API for years and since no other vendor could implement them (no other vendor could even install Web Apps), there was no competitive pressure. I don't buy the "user experience" argument. A browser full of bugs does not lead to a good user experience and the expense it imposes on developers is enormous. As a personal example, we had such serious issues with scroll, tap to focus and bounce that the only solution was to recode all scroll-logic including scroll-bars, momentum bounce in javascript while the same app could be built with only minor issues in both Firefox and Chrome despite the fact that iOS Safari was our primary target. As for the bugs, they just didn't get fixed. So many for, years and years. That all said, this is past history, and I'm very hopeful for the future. The fact Apple has hired a ton more staff (including significant numbers of QA/Testers staff), a ton of really excellent web OG's and are pumping through both the features and the bugs really bodes well for the future of browser competition.

cjk 4y ago
We can disagree on the user experience-based motivation. Given the lack of any kind of public data on how those decisions are made, I can't blame you for thinking that way. I do agree that developer experience is important, and that Apple should take developer experience more seriously than it does, and that applies across every org in the company. Case in point: the infuriatingly-opaque and mercurial nature of the App Store review process. The problem is that, percentage-wise, developers are a minuscule portion of Apple's overall userbase. That makes the justification for fixing concerns that are (perceived as) unique to developers difficult when the culture has traditionally leaned toward prioritizing issues with a more obvious impact on the majority of users. I'm not saying this is correct or desirable, just the way things have worked historically. Given all of that, I think “a browser full of bugs” is relative. I witnessed many instances of bugs being experienced by large numbers of users being fixed extremely quickly. It's always been a function of (obvious, measurable) impact. If a significant percentage of web apps were crashing 60 times a day, those bugs would have been fixed extraordinarily quickly.
- mtomweb 4y ago
  These same issues would get fixed in Firefox and Chrome. Safari was the outlier. We couldn't ask our users to use another competitive browser, since they'd been banned (and we most certainly would have put up banners). The 60 times a day crash (more specifically the app just froze), took 1 to 2 months to fix and it affected every web app. Users would have to force kill the app and restart. I'd recommend reading through all the comments to get a really good idea on how severe all of the bugs were: https://open-web-advocacy.org/walled-gardens-report/#ios-safari-is-buggy https://open-web-advocacy.org/walled-gardens-report/#ios-saf... https://open-web-advocacy.org/walled-gardens-report/#safari-has-been-buggy-for-a-long-time https://open-web-advocacy.org/walled-gardens-report/#safari-... In 2021, after 10 years of these issues, no progress on important web app features (like push/install prompts), no response from Apple or the Safari/Webkit team, we decided the only method by which Apple would fund Safari properly was to goto governments and regulators to reverse their ban on third party browsers. Not long after we petitioned regulators Apple started working on push notifications, 12 years after they came out for native.
- 4y ago