41–50 of 130 posts
If you managed to create draft in old version (before random code change).
But it does not match with new version your feedback assistant crashes to blank screen. (JSON parse syntax error)
That means it is impossible to file new bugs...
1 second web page works but after that it is blank screen and nothing to do.
What would happen if some Apple developers moved their collective feedback to a Github repo where their bug reports were licensed as CC-BY-4.0, i.e. a license that would allow Apple to migrate content from the public repo to their internal radar? This would allow developers to have a public database of de-duped and triaged bugs, and it would allow Apple to either respond publicly (same as Webkit?) or maintain status…
Nothing would happen. Websites and GitHub repos for posting Apple bug reports publicly have existed for over a decade. https://openradar.appspot.com/
> Apple Feedback Assistant reports are not public. To help other developers discover existing reports, copy-paste your submitted Feedback Assistant report into a new issue. Make sure you include everything.
> This is similar to Open Radar, but it's easier to fill out the report and GitHub has better search. Also, Open Radar doesn't yet support Feedback Assistant.
> Instead of voting on issues opened here (which Apple won't see anyway), file a new Feedback Assistant report and copy-paste the contents of the report you found here and link to the original report. Apple encourages duplicates.
The 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…
Reporting 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?
I 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…
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.
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.
Yeah he's lamenting how poorly the external developers are being treated but seems like they are largely being treated the same as Apple treats its own employees
There were plenty of teams that were very good about jumping on bug reports and getting right back to me. In fact, a decade or so ago at Apple this was more or less the rule.
My sense though is that engineering became overwhelmed with bugs especially as Apple itself became as successful as it has become.
"In the old days" a smaller team would have one of the engineers on the team screen Radars — maybe rotating to a new engineer every week or so. Engineers could quickly mark a bug as a duplicate of another (recognizing a familiar backtrace or symptoms) or might be able to guess at a diagnosis and send it straight to the engineer in charge of the (likely) relevant code.
A few teams I worked on were very good about daily "BRB"s (bug review board meetings). With a number of engineers in attendance, again, bugs were quickly dispatched to the right component, assigned to right engineer.
Again though, as Apple grew, I saw bug screeners on many teams more or less automatically flipping Radars back to the Originator if there was not a litany of documentation attached to the Radar. What build of the OS, what hardware, a full sample, system diagnosis.... It was frustrating when it was an obvious bug — maybe even a UI bug — that would take someone all of 30 seconds to repro. I somewhat sympathize though as traffic no doubt began to become a firehose of bug reports.
It seemed backwards to me though to put such a burden on the person who is simply trying to report the bug, trying to help you improve the software. Often in screening Radars the description alone was enough for me to know exactly where in the code the problem was. I didn't mind my time being spent at least scanning the Radar title and description. If it was not clear to me at that point, sure, flip it back for more info. The seeming rise of "auto-reject" is what began to irk me.
I suppose Feedback Assistant is like Windows' Feedback Hub. Users fill it to the top with shit making it impossible for Apple or Microsoft to do anything useful with the feedback.
Actions 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.
Actions 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.
They used to (or still do?) have coding courses for kids at Apple stores, they have free learn to code resources (https://developer.apple.com/learn/), probably some more programs I'm not familiar with.