Live data from Hacker News

Apple developer boycott of Feedback Assistant

lapcatsoftware.com

101–110 of 130 posts

Re: Apple developer boycott of Feedback Assistant

#102
post #8

I sympathize: even filing radars internally at Apple gets much of the same treatment, albeit with the ability to see the state of the radar.

Which basically mean they’re understaffed with people who enjoy fixing bugs. Fixing bugs, fine tuning, just gardening the code base

I think a lot of Apple engineers would love to have more time to be able to fix bugs but for the most part they're all stretched pretty thin.

Prioritizing fixing old bugs over developing new features isn't a call an IC can really make so I'd kinda argue that the issue is either "overstaffed with designers+execs who spend engineer time on UI changes" or "understaffed with engineers in general" and not an issue with the mindset of the current engineers.

Re: Apple developer boycott of Feedback Assistant

#103

I estimate that around 10% of my Feedback Assistant reports ever receive a reply or acknowledgement. These are for reproducible bugs in iOS, for which I've provided an isolated sample project with a 100% reproduction rate. It takes time to create a thoughtful and detailed bug report and the lack of replies are beyond frustrating. I'm glad to see this post and couldn't agree more.

Respectfully, why file them at all if that's the case? The cynic in me can't help but see that as free high-quality engineering labor for what's already the world's most valuable company. They don't need more help :)

I see a similar response rate as the poster you’re replying to, but I am going to keep filing bugs. If Apple fixes a bug I file, that’s not just to Apple’s benefit, it’s to my benefit and to the benefit of people who use my software as well. Even if they only fix 10% of what I file, it’s a better outcome than if I didn’t file any bugs at all.

I also notice that response and fix rates have large variance across components / teams within Apple. Some of them are quite responsive and others are just /dev/null. I do tend to focus my energy on those components where I’ve had success in the past.

Re: Apple developer boycott of Feedback Assistant

#105

I estimate that around 10% of my Feedback Assistant reports ever receive a reply or acknowledgement. These are for reproducible bugs in iOS, for which I've provided an isolated sample project with a 100% reproduction rate. It takes time to create a thoughtful and detailed bug report and the lack of replies are beyond frustrating. I'm glad to see this post and couldn't agree more.

Respectfully, why file them at all if that's the case? The cynic in me can't help but see that as free high-quality engineering labor for what's already the world's most valuable company. They don't need more help :)

This is also the stance I take on customer support of Apple products. It got hyped so much about "just working" that I take it as a bit of an insult that they want me to stand in for their CS team. I do make exceptions for close family.

Re: Apple developer boycott of Feedback Assistant

#107

Earlier quoted context omitted.

What would the ideal structure look like in your opinion?

Ideally, daily BRBs (kept to an hour) with engineers attending. If it turns out there are too many Radars to keep the BRBs to an hour then there are issues elsewhere. At the same time, I didn't mention it above, engineers need to be allowed time in the product schedule to fix these bugs. As probably everyone knows, when a bug is kicked down the road once (because of scheduling constraints: hey, we gotta ship the soft…

When I was there on the BRBs I often dreamed of actually commissioning a neon *NMOS* sign that I would flash by pressing a button for nearly every bug that came up for discussion.

Re: Apple developer boycott of Feedback Assistant

#108

Earlier quoted context omitted.

Ideally, daily BRBs (kept to an hour) with engineers attending. If it turns out there are too many Radars to keep the BRBs to an hour then there are issues elsewhere. At the same time, I didn't mention it above, engineers need to be allowed time in the product schedule to fix these bugs. As probably everyone knows, when a bug is kicked down the road once (because of scheduling constraints: hey, we gotta ship the soft…

I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful Snow Leopard was simply because it was a bug-fix only (mostly?) release. Apple's dot zero OSX releases have always been pretty bad, so yes Snow Leopard and the last iteration of Tiger look great by comparison. As an outsider I don't have fond memories of filing bugs with Apple in that er…

I was on the team that owned CalDAV and CardDAV in approximately that era, as a bug screener and with zero decision making power.

The attitude was basically, if it doesn't affect us personally working inside Apple, we don't care. If our personal workflow and servers doesn't use those features (which I guess is the case for GID), it doesn't matter.

We don't know what Exchange is or why anyone would use a Microsoft product. What are they, idiots? We don't really care about Gmail. Why is their server not responding according to RFC Whatever? Google must be idiots.

Etc.

There were a very few number of developers, most were wasting their time making fake leather stitching for the UI because Jobs demanded it. Unit testing was quite poor. Code review was nonexistent.

Re: Apple developer boycott of Feedback Assistant

#109

Earlier quoted context omitted.

I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful Snow Leopard was simply because it was a bug-fix only (mostly?) release. Apple's dot zero OSX releases have always been pretty bad, so yes Snow Leopard and the last iteration of Tiger look great by comparison. As an outsider I don't have fond memories of filing bugs with Apple in that er…

I was on the team that owned CalDAV and CardDAV in approximately that era, as a bug screener and with zero decision making power. The attitude was basically, if it doesn't affect us personally working inside Apple, we don't care. If our personal workflow and servers doesn't use those features (which I guess is the case for GID), it doesn't matter. We don't know what Exchange is or why anyone would use a Microsoft pro…

I should probably clarify: the DVD bug was related to playing DVDs on a Mac with Intel graphics and 4 GB of RAM. Certainly it's an odd edge case but it spoke volumes about the quality control with the drivers. Maxing out the RAM on one of those can't have been such a rare thing. Certainly I can wrap my head around why calendaring and enterprise features didn't get much love, but video drivers on the mass market product? Jesus.

With the calendaring stuff: I wrote a CardDAV server that's probably still lurking around on Github somewhere. The workarounds I had to implement for MacOS and iOS clients were beyond pale. For instance stuff would just get cached indefinitely and trailing slashes caused OSX to have a conniption fit. If you told me that the client implementations just hardcoded a bunch of stuff so it worked for Steve Jobs (and that nobody else used it) I'd believe you.

Eventually I did a brief stint at a consultant that was brought on to do some infra stuff for Apple, and that didn't do much to improve my impression. We got a bunch of servers from the basement with expired iLO licenses, and boy were we lucky to get that much.

  The attitude was basically, if it doesn't affect us personally working inside Apple,
  we don't care. If our personal workflow and servers doesn't use those features (which
  I guess is the case for GID), it doesn't matter.
Honestly I'm not sure how to respond to this. If memory serves there was no way to uncouple group mapping, so this was part and parcel of Apple's push into the enterprise space (and in this case AD was behaving as an OpenDirectory server would've). Which is to say, their failure in that space was entirely a self-fulfilling prophecy. The more frustrating part was that an obvious security flaw was treated with such disdain, which encouraged me to stop caring about filing bug report with Apple (and it's lead me to keep the bluetooth modem off almost exclusively on my iPhone).

That gig was actually mostly staffed with Apple alumni so there were 1st gen iPhones all around. Even the less esoteric stuff was simply not good. Obviously voice quality was shit (at least in San Francisco) compared to the CDMA feature phones of the day. One of the coworkers there worked on the mobile Mail.app before bailing for startup life. Autocomplete was a mess. Honestly, I rather enjoyed rubbing some salt into that wound.

What amazes me is that fifteen years on and Microsoft is still somehow worse (what with Windows being adware and all).

Re: Apple developer boycott of Feedback Assistant

#110

I estimate that around 10% of my Feedback Assistant reports ever receive a reply or acknowledgement. These are for reproducible bugs in iOS, for which I've provided an isolated sample project with a 100% reproduction rate. It takes time to create a thoughtful and detailed bug report and the lack of replies are beyond frustrating. I'm glad to see this post and couldn't agree more.

Fully agree. I work in security and sent Apple a bypass for child restriction policies on iOS, they told me to send it to feedback. Testing, reproducing, writing it up all takes time and effort. I didn’t want anything from them other than for it to be fixed, I have kids with iPhones. It’s no different than other companies though, I sent a remote code execution to Cisco and they just replied that they already knew abo…

To be fair, remote code execution and "I got around the child lock on this device" are somewhat different in severity.
Post reply on HN