Apple developer boycott of Feedback Assistant
31–40 of 130 posts
Re: Apple developer boycott of Feedback Assistant
#32Are there companies that do this well, at a scale approaching Apple’s?
I can think of lots of reasons why this is a “hard problem”, and how it’d be hard to staff. I also think they’re getting paid to solve this problem, and aren’t.
Re: Apple developer boycott of Feedback Assistant
#33Actions speak louder than words - Apple is letting it's developers know what it thinks of them. You're going to have to raise quite the ruckus to get them to change their behavior. There's really no impetus for them to change when they're sitting on a mountain of cash.
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.
Re: Apple developer boycott of Feedback Assistant
#34I'm not sure I understand this. Wouldn't developers who need code-level assistance (i.e. have more than simple "feedback") submit a Technical Support Incident ( https://developer.apple.com/support/technical/ )?
Here's an excerpt from the reply that I get from filing a TSI for functionality that is ultimately a bug with iOS. ------------ Hello, Thank you for contacting Apple Developer Technical Support (DTS). We believe this issue is a bug. Please file a bug report via Feedback Assistant ( https://feedbackassistant.apple.com ). For more information on Feedback Assistant, visit https://developer.apple.com/bug-reporting . ----…
Re: Apple developer boycott of Feedback Assistant
#35Re: Apple developer boycott of Feedback Assistant
#36Someone please set up a website that can compose an email to Craig Federighi with these issues and let developers email him directly. Apple may not act on or respond to this collective Feedback Assistant feedbacks, since the system may probably be broken to the extent that Apple’s teams don’t even see or get these feedback reports.
We do not need a website for that.
Simply send an email to Craig Federighi or even Tim Cook.
You can find their email addresses here → https://news.ycombinator.com/item?id=27320383
Re: Apple developer boycott of Feedback Assistant
#37Reporting 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…
Re: Apple developer boycott of Feedback Assistant
#38Re: Apple developer boycott of Feedback Assistant
#39Earlier quoted context omitted.
Reading the post is how I learned the developer didn't file Technical Support Incidents (TSIs).
Almost every time, developer technical support will look at the internal bug and if there is no known workaround will say “sorry that’s our bug and engineering is investigating, we don’t have anything to tell you, please keep an eye on the feedback and we will update you if anything changes - in the meantime here’s your TSI refunded”.
Two things that simply filing a feedback issue doesn’t seem to reliably do.
I’m suspect a concerted effort to get developers using their TSIs for bug reporting would backfire (stop refunding them? remove the program?), but I think it’s an interesting idea given how cheap the TSIs are for developers.
Re: Apple developer boycott of Feedback Assistant
#40Earlier quoted context omitted.
Here's an excerpt from the reply that I get from filing a TSI for functionality that is ultimately a bug with iOS. ------------ Hello, Thank you for contacting Apple Developer Technical Support (DTS). We believe this issue is a bug. Please file a bug report via Feedback Assistant ( https://feedbackassistant.apple.com ). For more information on Feedback Assistant, visit https://developer.apple.com/bug-reporting . ----…
> 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?
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, it is not possible to have more than one MTAudioProcessingTap running at the same time.
3. AVPlayer's `addPeriodicTimeObserverForInterval` function will randomly stop calling back to its observer, and never recover, when connected to an Apple TV via AirPlay on iOS 17.
Issue 1 makes debugging more arduous. Issue 2 stops my app from being able to crossfade audio together or play more than one audio stream at once. Issue 3 requires me to build my own time observer which is further technical debt, versus being able to rely on Apple's API.
I've spent hours debugging each of these and trying to find a workaround before resigning myself that it's a platform issue and relegating myself to abandoning that specific API or feature.