Let’s see if there will be Bug as a Service. Pay for bug fix in addition of $99/year
Apple developer boycott of Feedback Assistant
61–70 of 130 posts
Re: Apple developer boycott of Feedback Assistant
#62Reporting bugs via feedback assistant is sometimes required when you've successfully found a developer inside Apple who has agreed to fix your bug and they just need the feedback number for internal work reporting purposes. Submitting unsolicited bug reports are just a pointless waste of time. I wouldn't say I'm specifically "boycotting" Feedback Assistant; I just stopped using it because it wasn't doing anything use…
How are you supposed to find a developer inside Apple to fix your issue?
It is possible to backchannel to them like any other company. It's just much less... publicly evident, if that makes sense?
Also (IIRC) if you post on their dev forums and deal with e.g Quinn, they might ask you to file and provide a radar - but it's been a minute since I've interacted over there.
Re: Apple developer boycott of Feedback Assistant
#63Previously: https://news.ycombinator.com/item?id=3947903
(I feel incredibly old right now.)
Edited to add: Finally found the full form letter [1]. (I filed a copy back then and it still shows up languishing in Feedback Assistant even now!)
Re: Apple developer boycott of Feedback Assistant
#64I hope something changes with the way apple manages bugs. It’s incredibly demoralizing to spend my time reproducing a bug, writing up the bug report I’d want to receive (including a minimal test case), and hearing nothing for years until it’s either closed or receiving a message asking me to do more work to determine if it’s still an issue. Are there companies that do this well, at a scale approaching Apple’s? I can…
There's a fundamental problem that the first step is you doing all that work. That means there's no way to tell you the work is wasted; you already did it. I generally think people should do /less/ work when reporting bugs because of this, but you should be careful and clear about what you do put in there.
Some of that work does benefit me: better understanding of the bug, verification that it’s not something I’m doing wrong, maybe some ideas of a workaround.
I’ve stopped doing the second phase: packaging it up and submitting it to apple, because that’s shown itself to be an entirely negative experience.
If apple’s not going to spend the $$ on internal QA, and they’re not going to spend the $$ on developer relations, I’m not especially interested in donating my time to help them. I know I’ve seen a similar sentiment from other developers for years.
I think low quality / low content bug reports are usually worse than none, because they decrease the signal to noise ratio of bugs. Maybe if there was a better channel of communication, and I knew it’d be more interactive it’d be different.
Re: Apple developer boycott of Feedback Assistant
#65Earlier quoted context omitted.
> I would happily pay Apple a developer rate to fix these bugs. Some of them are massive showstoppers in a large scale production application. Wow that's pretty intense. Any examples of such show-stopping bugs?
Here's a few recent ones: 1. Xcode 15's "Replace Container" feature replaces the app container with incorrect permissions that results in the app not being able to write to its container (ex. the documents directory). This is an important feature for debugging and flat out doesn't work. 2. Apple's AVPlayer has an API called MTAudioProcessingTap which allows you to get access to low level audio data. Since iOS 17.1, i…
> Issue 3 requires me to build my own time observer which is further technical debt, versus being able to rely on Apple's API.
IMHO, it's the same amount of technical debt, regardless of who built it. In this case, the overall situation is worse: because you didn't build it, you can't fix it. If you have a dependency built by a benevolent provider, that may mean less work for you in the future, but it's still technical debt.
Re: Apple developer boycott of Feedback Assistant
#66Earlier quoted context omitted.
I never thought I'd wistfully look back on Steve Ballmer yelling DEVELOPERS! DEVELOPERS! DEVELOPERS!!! Apple seem to view external developers as a kind of infestation. The systems and processes they subject them to seem designed to actively discourage them.
Stockholm syndrome with a hint of masochism. App developers seem to stick with apple regardless of what they are being subjected to.
> App developers seem to stick with apple regardless of what they are being subjected to.
Because the alternatives aren’t preferable. The indies who have been exclusively using and developing for Apple platforms for years know that Windows and Linux aren’t better¹, just a different set of annoying trade offs. Apple platforms aren’t perfect, but they are the least bad option in that context. They also used to be better in many regards, which makes the situation frustrating due to the wasted potential.
¹ At a personal preference level. There’s no judgement either way, you do you and use whatever you like best.
Re: Apple developer boycott of Feedback Assistant
#67I 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 about it but the product was approaching end of life so they wouldn’t fix it.
I’ve stumbled across so many vulnerabilities over the years and I tend to just ignore them unless I’m being paid to find them. It’s not worth the frustration.
Re: Apple developer boycott of Feedback Assistant
#68The recent macOS dialog "Allow app to access folder [OK] [Cancel]" supports button cycling by Shift+Tab (previous), but not Tab (next). The Wi-Fi signal strength indication changes when clicking it. So yeah, at least they need to admit things are very bad over there.
Whenever I see or hear about keyboard shortcuts being weird or not working, for some reason I can only think of Catalyst or Electron, both bringing frustratingly poor user experiences. Apple’s own Catalyst based apps (Reminders, as an example) have been terrible over the last few years. I can’t imagine a macOS dialog being either one of these abominations though, which makes me wonder how the issue you describe was i…
Apple's solution for missing Catalyst functionality has been to create analogous features or port existing API to iPad.
That said - the long-term strategy doesn't appear to be Catalyst, but Swift UI.
Re: Apple developer boycott of Feedback Assistant
#69Earlier 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…
Incentivize screening Radars (and fixing them). There's no engineering glory in keeping your unscreened count at zero... nobody gets promoted for it.
Re: Apple developer boycott of Feedback Assistant
#70Boycotts/strikes* only work if most or nearly all people participate, because you'll only participate if you're pretty sure nearly everyone else is too. While if this blogpost merely gets 0.1% of developers to strike... Apple couldn't care less.
I think this developer strike is a great idea, but launching it as a single person's call to action (Jeff Johnson's) is not generally going to be effective in changing behavior.
What an organizer needs to do is to first personally contact somewhere between 50-200 other major, known, respected developers and get them to co-sign a joint letter which then gets published, so everyone can see this is a serious strike by people who know what they're doing -- not just one person's wish. It needs to get covered in all the major tech publications, so both Apple and all developers see it as well.
And then the letter needes to not lay out a list of all of the complaints, but rather the specific, verifiable actions Apple needs to take in order to end the strike, so this isn't some open-ended thing. And they need to be realistic actions as well, not wishful thinking -- signs of progress with dates and milestones, not fix-all-the-things-immediately.
If you're going to do a strike, you need to actually organize it. Writing a blog post that merely "encourage[s] all Apple developers to join me" is not the same as organizing. And generally speaking, writing a blog post claiming that you're striking isn't going to get anybody else to magically organize it for you.
* As the author indicates lower in the article, it's more of a strike than a boycott since it's stopping providing free labor rather than stopping purchases, so I'll refer to it as a strike