Submitting Radar may encounter a situation where someone has submitted this question before, so it will be labeled "duplicate" and don't panic. In fact, there is a technique for submitting Radar.
As I said earlier, the only way to give Apple feedback on bugs is Bug Reporter, which is useless in other places. Apple does not recommend doing so. If you go too far, you may be punished by Apple. So how do you get Apple to take your questions seriously?
Daniel Pasco, an experienced Apple developer, teaches us this lesson in his article:
Engineer teams are always faced with too many problems to be solved. Engineers meet regularly with their supervisors to sort out the problems so as to decide which problems to solve next. The more a problem is reported, the more attention it needs, and the easier it will be for engineers to make judgments.
This is true for all software companies. When you release a product, people are likely to report a problem under one or two edge cases. Of course, you want to fix it when time permits, but if hundreds of people report the same problem, it shows that the problem is serious and needs to be solved urgently. Apple is no different from other companies in this respect.
In a sense, asking duplicate questions is a vote, or a support for existing problems. The more repetitions a problem obtains, the higher its priority.
So if you find a problem, you can post Radar's original text on your blog or forum after you mention Radar, and call on other developers to propose the same Radar, so that Apple engineers can pay attention to it. Nevertheless, we should exercise restraint and be careful not to abuse it.
In addition to submitting duplicate questions, another technique that may not be commonly used is that you can go with Apple engineers, and if your Radar submission has not been active for several days, you can contact Apple engineers for feedback. Of course, how to collude and collude here needs to be considered by everyone.
Do you want to submit a few bugs on Bug Reporter? But foreign Apple developers don't pay much for the Radar system. Why?
Fix Radar or GTFO
The biggest problem with Apple's Bug Reporter system is that developers can't get effective feedback quickly after submitting questions. The general scenario is that you submit a question, then it's marked duplicate and closed, and then it's gone. Other developers can't see your submitted adar, you can't see Apple engineers'response to this question, and you can't know when your submitted problem will be fixed. (If your Bug submission is very urgent or has some other problems, Apple may also contact you directly, but this is rarely the case.)
Mattt once mentioned that a Radar was not repaired until seven years after it was proposed. In addition to submitting Radar's skills, the lack of effective communication means was also responsible for this result.
In addition, the Bug Reporter system also has the drawback of an ugly UI, completely unlike Apple's, which is not friendly enough for developers.
In 2012, some Apple developers could no longer tolerate the black hole-like Bug Reporter system, launching the "Fix Radar or GTFO" campaign, calling on developers to submit repetitive Radar in order to make Apple improve the Bug collection system and make it more open. Others have made an open radar, where developers can submit their Radar to the official Bug Reporter as well as their Radar. Developers can see and discuss other people's Radar.
Developers'efforts have paid off. In September 2013, Apple redesigned the Bug Reporter system to improve its UI and usage experience. However, the requirement for developers to open Radar has not been met. You still don't know what happened after you submitted the problem.
However, some developers disagree with the Fix Radar or GTFO movement, as this article says:
In fact, developers do not need a Radar, Radar is Apple, if Radar works well for Apple, then there is no problem. For example, on whether to open Radar or not, if open Radar will cause some bad consequences, such as Bug being maliciously exploited, Radar priority being interfered with by active users and so on, then it is better not to open Radar. What developers need to do is "file and forget" (submit and forget). Submitting Bug has fulfilled the developer's responsibility, and then leave it to Apple.
Yes, maybe we've gone too far. If we know that the submitted Radar will be taken seriously, there's no need to ask for more. After all, the most urgent thing to improve the product is Apple, not the developer.
So asymmetric information is the root of all evil, so let's see how Apple handles a Radar submission.
How does Radar work inside Apple?
A developer who visited Apple described that there was a special Mac app inside Apple that handled submitted Bugs. In this app, Apple engineers could mark and classify problems. Different engineers could discuss the same problem and finally evaluate priorities, such as "Show-Stopper" status. Solve, otherwise it will not be released