自從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吧!~