爱华网自从Swift推出以来，很多开发者已经第一时间尝鲜并且尝试用它进行开发了。不过，由于Swift还是个演进中的语言，Xcode对它的支持并不完善，偶尔会出这样那样的小问题。有些开发者在发现问题后，顶多发个博客记录一下然后就不管了，我们是否有更好的办法，比如给苹果提交这个bug，让它快速修复呢?
答案是有的，并且仅对苹果的开发者开放，即苹果的Bug Reporter系统。
Radar or GTFO
在苹果的Bug Reporter里，你可以提交你发现的问题或者功能需求，你也可以查看你提交的问题的处理情况。问题会被分配一个ID，并带上rdar://10993759这样的URI链接，因此给苹果提Bug被称为“file a Radar”，意味着你的问题出现在了苹果工程师的雷达上面，十分形象。
在国外苹果开发者中间有一句广为流传的话叫做“Radar or GTFO(Get The f*ck Out)”，意思是除非你发布了一个Radar，否则苹果不会处理你的问题。无论你在个人博客或者苹果的开发者论坛上面提交Bug，即使苹果工程师看到也会被忽略掉的，这个Bug Reporter几乎是开发者和苹果之间关于系统和软件故障的唯一反馈渠道(如果是和App审核、苹果设备相关的问题，你可以寻找对应的客服)。
如何写一个Radar?
使用苹果开发者账号登录到Bug Reporter后，你可以提交问题。苹果的这个系统和其它的Bug追踪系统并没有太大的差别，你需要先选择发生问题的产品、问题类型、复现频率，然后用标题和文字来尽可能清晰的描述你的问题细节。
编写问题细节并没有固定的格式，你需要提供出问题的系统或软件版本，如果有截图或者其他文件证据可以作为附件添加。需要注意的是，你需要用英文编写问题。
不过，虽然没有格式，作为完美主义者的苹果还是对问题细节的描述做出了诸多规定和建议。比如，标题部分：
Safari is slow.(坏的)
Safari is slow allocating JavaScript arrays. (Include JavaScript sample with your bug report.)(好的)
问题细节也需要包含以下几个部分：
复现问题的步骤
预期结果
实际结果
变通方案
回归测试和条件隔离情况(Regression/Isolation)
具体内容可以看苹果关于Bug Reporting的文档。
提交Radar的技巧
提交Radar可能会遇到一个情况，那就是这个问题之前已经有人提交过，那么它会被标注为“duplicate”，不要惊慌，其实这里包含着一个提交Radar的技巧。
前面说过，向苹果反馈bug的唯一途径是Bug Reporter，在其它地方闹得满城风雨也没有用，苹果也不建议这么做，如果你做得太过分了，还可能受到苹果的惩罚。那么，如何让苹果重视你提交的问题呢?
Daniel Pasco，一位有经验的苹果开发者在他的文章里这样向我们传授经验：
工程师团队总是面对太多需要解决的问题，工程师们定期的和它们的上级主管开会，对问题进行分类，以决定接下来需要解决哪个问题。一个问题被报告得越多，说明它越需要关注，工程师在下判断时也会更容易。
对于所有软件公司来说都是这样，当你发布了一个产品，人们很有可能会报告一两个边缘用例(edge case)下的问题，你当然会想在时间允许的情况下修复它，但如果有数百人报告相同的问题，说明问题很严重，并亟待解决。苹果在这方面和其它公司并无不同。
从某种意义上来说，提出重复的问题是一种投票，或是对已存在问题的一个支持。一个问题获得的重复次数越多，说明它的优先级越高。
因此，如果你发现了一个问题，在提出Radar之后，可以将Radar原文发布到自己的博客或者论坛上，号召其它开发者提出相同的Radar，促使苹果工程师重视这个问题。不过也要有所克制，注意不要滥用。
除了提交重复问题，还有一个可能不太常用的技巧是，你可以去勾搭苹果工程师，如果你提交的Radar好几天了都没动静，你可以联系苹果工程师，以求获得一个反馈。当然，这里如何勾搭和勾搭的技巧就需要大家自己琢磨了。
看到这里你是不是蠢蠢欲动，想去Bug Reporter上提交几个bug?但国外的苹果开发者对这个Radar系统却并不怎么买账，为什么呢?
Fix Radar or GTFO
苹果的这个Bug Reporter系统最大的问题是，开发者提交问题之后，无法快速收到有效的反馈。一般的场景是这样，你提交了一个问题，然后它被标为duplicate并关闭，然后就没有然后了。别的开发者无法看到你的提交的Radar，你无法看到苹果的工程师对于此问题的回复，你也无法得知你提交的问题何时能得到修复。(如果你提交的Bug非常紧急或有一些其它问题，苹果也可能会直接联系你，不过这种情况很少)
Mattt大神曾经提到，一个Radar在提出足足7年之后才被修复，除了提交Radar的技巧之外，缺乏有效的沟通手段也是造成这一结果的原因。
另外，这个Bug Reporter系统还有UI不美观，完全不像苹果出品，对于开发者不够友好的缺陷。
在2012年，一些苹果开发者再也无法忍受如同黑洞一般的Bug Reporter系统，发起了“Fix Radar or GTFO”活动，呼吁开发者提交重复性的Radar，想让苹果改进这个Bug收集系统，让它变得更加开放。另外一些人则做了一个openradar，开发者在提交到官方的Bug Reporter之余，也可以将他们的Radar提交到这里，开发者可以看到别人的Radar并进行讨论。
开发者的这些努力收到了一定的效果，2013年9月，苹果对Bug Reporter系统进行重新设计，改进了它的UI和使用体验，但是，对于开发者们开放Radar的要求则未予满足，你仍然不知道你提交问题之后究竟发生了什么。
不过，也有开发者对“Fix Radar or GTFO”运动并不以为然，像这篇文章所说的：
其实开发者并不需要一个Radar，需要Radar的是苹果，如果Radar对于苹果来说工作得很好，那么就没什么问题。比如在是否开放Radar上面，如果开放Radar会造成一些不好的后果，比如Bug被恶意利用、Radar优先级被活跃用户干扰等等，那么还不如不开放。开发者需要做的是“file and forget(提交并遗忘)”，提交Bug已经尽到了开发者的责任，接下来的就留给苹果吧。
是的，也许我们走过头了，如果我们知道，提交的Radar会被认真对待，那么其实没有必要要求更多，毕竟对于改进产品最迫切的是苹果，而不是开发者。
所以，信息不对称是万恶之源，那么就让我们来看看，一个Radar被提交后，苹果是怎么处理的吧。
苹果内部是如何处理Radar的?
一个曾参观过苹果内部的开发者描述道：苹果内部有一个专门的Mac app用于处理提交的Bug，在这个app里面，苹果工程师能够对问题进行标记和分类，不同的工程师能对同一个问题进行讨论，最终进行优先级的评定，比如评定为“Show-Stopper”状态的问题是必须第一时间解决的，否则不会发布下一个更新。
事实上，苹果非常重视提交到Bug Reporter的问题，一位曾在苹果工作过的开发者写道：所有的问题都会被很快的分类并进行讨论，只是问题是，讨论多涉及到苹果内部的技术，而由于苹果的保密措施，所以即使是讨论也是难以对外分享的。
所以，你可以放心的提交Bug而无需担心它受到冷落，而另一方面，也不要太期待从苹果得到反馈，如果苹果修复了这个问题，那么你是幸运的;如果苹果没有修复，说明这个问题的优先级还不够高，工程师们有其它要做的事情。
如果你认为你发现的问题很重要，你可以尝试一下上面提到的技巧。重要的是态度，其实你和苹果的目标是一致的，都想解决你提出的问题，所以没有必要闹得不愉快。
据苹果最新的财报显示，中国已经是iPhone最大的发售地了，中国的iOS开发者数量也居世界前列，苹果本身也越来越重视中国。但相比之下，苹果软件在中国的本地化仍然存在一些问题，有不少问题值得报告;中国的iOS开发者也显得太低调，无论是开发者之间的交流，还是和苹果之间的交流都很少。我想，向苹果提交bug和功能需求是一种沟通和表达自己的手段，无论是对于开发者自己，还是对提高中国在苹果软件开发生态的地位都是有帮助的。
所以还等什么呢?快去提交Radar吧!~
