如何给苹果提交Bug或功能需求？

jopen 10年前

如何给苹果提交Bug或功能需求？

自从 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 吧！~

参考链接：

来自: idlelife.org