前言
眾所周知，App 在上架至 App Store 前，必須通過蘋果神秘的審核團隊的審核。能否在短時間內順利通過審核，對 App 推廣節奏和策略、以及迭代等影響是非常大的！
1.提交審核的流程
目前應用提審的整個流程大體分為五個階段，這個登錄過 App Store Connect 后臺或操作過 App 上架的小伙伴應該都知道：Prepare For Upload（準備上傳）、Waiting For Review（等待審核）、 In Review（審核）、Pending Developer Release（等待開發者發布）、Ready For Sale（準備銷售）。
其中 Waiting For Review（等待審核）和 In Review（審核）這兩個階段是不受開發者控制的，也就是說，這兩個階段由審核人員操控。
2.機審和人工審核
蘋果審核大體分為三部分，預審、機審和人工審核。包上傳后首先進入的是預審，會被掃描 API 等，沒問題的話才會在 App Store Connect 里出現 然后才可以提交至 Waiting。
在審核前期，也就是 Waiting For Review（等待審核）階段一般是機審，去年鬧得沸沸揚揚的 4.3 就是通過機器掃描掃代碼；
機審不通過則直接被拒，通過后會進入人工審核，即 In Review（審核）階段，這個階段主要看的是 App 的元數據，例如標題、描述、截圖等，以及檢測 App 的功能使用情況，常遇到的 IPV6 也在此處檢測。
判斷是進入了機審狀況還是人工審核狀態，除了看時間外，還有一個方式，就是去看后臺，如果有美國 IP 登錄，應該就是人審了；如果只有 App 啟動但沒有深度訪問，說明在機審呢，正在掃代碼。
當然，利用上述兩種方式也可以來判斷 App 是機審被拒，還是人工審核被拒，然后確定解決側重點。
目前機審機制越來越完善了，而且也越來越受重視，這個從 2.1 和 4.3 出現的頻率就可以看出來！其實蘋果重視機審也是可以理解，減少人工成本并增加審核嚴格度，也更傾向于人工智能這個大方向！不過如果機審機制太完美，對我們可能不是好事，過審也許會越來越不容易。
3.審核時間逐漸縮短，但延期審核現象增多
雖然大家一直在吐槽蘋果的審核時間，但相比于之前，例如 7~8 天階段、3~4 天階段，現在已經很不錯了。而且通過近三個月的審核數據對比，App審核的周期又有了進一步縮短的趨勢。
蘋果曾在 2017 年 6 月 WWDC 大會上表示，接下來會進一步縮短審核時間。從目前趨勢來看，確實是在進一步縮短。不過現在又出現了一個現象或者說處罰方式——延期審核。
延期審核一般針對的是大量同種類的 App，比如游戲（斗地主等），還有涉及敏感題材的 App，比如金融、彩票、VPN 等。特別是對于游戲，蘋果已經摸清了此類 App 開發者的套路（馬甲包、隱藏支付等），但由于一些開發者隱藏工作做得好，蘋果又無法拿到確鑿證據，所以只能故意拖延。如果被延期輕則需要十幾天，重則拖延 1 個月甚至幾個月。
有小伙伴可能想了解延期審核后怎么辦？在此說幾點，如果沒有明顯違規，除了打電話，在 App Store Connect 后臺點【聯系我們】這些方式外，還有一些稍微冒險的方式，申訴或加速審核。如果這兩個方式還不行，又不想等，果斷換賬號重新提包吧！還有個方法是將免費 App 設置為付費，但也只是可以縮短等待時間，審核的時間也可能會很久，這個不是很好管控。
4.蘋果審核側重點不斷調整，且新的被拒理由層出不窮
蘋果審核側重點不斷調整，且新的被拒理由層出不窮。當然這里所說的“新的被拒理由”有些是一直存在的，只是沒有側重這方面審核或者說審核沒有升級到這一步而已。
5.問題匯總
今日有空，把以往所遇到的問題匯總一下：
Guideline 1.2 - Safety - User Generated Content
Your app enables the display of user-generated content but still does not have the proper precautions in place.
Next Steps
To resolve this issue, please revise your app to implement all of the following precautions:
- Require that users agree to terms (EULA) and these terms must make it clear that there is no tolerance for objectionable content or abusive users
- A method for filtering objectionable content
- A mechanism for users to flag objectionable content
- A mechanism for users to block abusive users
- The developer must act on objectionable content reports within 24 hours by removing the content and ejecting the user who provided the offending content
這里談到了關于用戶發布內容（類似朋友圈、 QQ空間、微博），需要涉及到的安全機制，包括：
- 要求用戶同意條款（EULA），并且這些條款必須明確表示，不允許有令人反感的內容或濫用的用戶。
- 一種過濾有害內容的方法
- 一種用戶標記不良內容的機制
- 用戶阻止濫用用戶的機制
- 開發人員必須在24小時內通過刪除內容并彈出提供有問題內容的用戶來處理令人不快的內容報告。
根據這些反饋，以及網絡收集到的信息，為了防止非法濫用用戶生成的內容，從而給用戶提供虛假信息、盜取用戶的知識產權，社交應用以及應用當中包含用戶生成的信息的應用必須包括下述功能：
- 用戶使用協議。
對敏感信息進行說明，在登錄頁面加用戶使用協議，部分 APP 在發布頁面，有的 APP，在制作頁面也會有； - 過濾不良內容（色情、裸露、褻瀆等內容）
后臺對用戶發布的內容進行審核、過濾； - 提供舉報機制
對用戶發布的內容進行舉報，讓后臺處理。 - 屏蔽/拉黑。
之前網上有文章講，說要這個功能，有的沒有提到這個。因為這個需要加新接口，并且大部分的查詢接口都需要做對應的判斷，所以一直希望這個不是必要的，只是在改其他的接口。 - 聯系方式。
提供官方聯系方式，讓用戶可以快速聯系到開發商
另外，被拒后不要去猜測被拒原因，而是最快的方式就是上訴然后他們會打電話過來詳細說明原因，這樣能夠盡快的解決問題。
Guideline 2.1 - Performance - App Completeness
Your app crashed on iPhone running iOS 13.2 on WiFi when we:
- Tapped on the recharge button.
We have attached detailed crash logs to help troubleshoot this issue.
Next Steps
To resolve this issue, please revise your app and test it on a device to ensure that it runs as expected.
Resources
For information on how to symbolicate and read a crash log, please review Tech Note TN2151 Understanding and Analyzing Application Crash Reports.
Please see attached screenshot for details.
蘋果支付，充值按鈕事件崩潰。
一開始一直沒搞明白 "recharge button" 什么意思，充電按鈕？后來才知道是“充值按鈕”，英語很重要。在 iOS 13 下點擊【充值】按鈕崩潰了，iOS 12 之前都正常提示，排查原因，是蘋果《付費應用程序協議》到期，需要續簽。App Store Connect 提示如下：
點擊【續簽】即可
注意：以后要及時更新蘋果協議！！
Guideline 2.3 - Performance - Accurate Metadata
【2.3 系列 - 準確的元數據】
客戶應該知道他們在下載或購買您的 App 時會得到什么，所以請確保 App 的描述、屏幕快照和預覽能夠準確反映 App 的核心體驗，并記得不斷更新，以便保持與新版本相應的最新狀態。
被拒原因：
- 應用中包含隱藏功能，試圖隱藏應用程序中的功能，功能或內容被認為是令人震驚的行為；
- 上架時的 App 預覽和截屏沒有適配 6.5 英寸 和 5.5 英寸。
- 應用截圖等級不符，圖片過于暴露、血腥等……
- 應用標題、描述、截圖等與應用功能嚴重不符。如果是使用了安卓手機的截圖或瀏覽器也會引起拒審；
解決方法：
- 修改或刪除應用中隱藏的功能（去除隱藏功能模塊代碼或將需要隱藏功能的代碼及定向跳轉鏈接網址做混淆處理，適當增加邏輯復雜度）；
- 重新更換 App 預覽和截屏，適配 6.5 英寸 和 5.5 英寸；
- 調整應用截圖內容，或者修正應用的上架年齡等級
- 應用標題、功能描述等要與 App 預覽和截屏相符合，保證整個 App 功能、流程看起來是一致的；
提交審核：您的 App 正在使用廣告標識符 (IDFA)。您必須先提供關于 IDFA 的使用信息或將其從 App 中移除，然后再上傳您的二進制文件。
IDFA(identifier for advertising) 主要被用于廣告中區分設備的作用。從 2014 年 2 月初開始，App Store 禁止沒有使用廣告而采集 IDFA 的 App 上架，所以如果 App 本身沒有廣告的話，使用第三方 SDK 要注意檢查是否含有 IDFA 廣告模塊。
解決方案：
- 如果應用本身有集成廣告的話，只需要在提交審核的時候勾選正確的廣告標識符選項即可。
- 如果應用本身未集成廣告，卻包含 IDFA 的話。這種情況一般都是集成的第三方 SDK 中包含 IDFA 導致的。
如何查看自己的項目是否采集了 IDFA 呢？
很簡單，打開終端，cd 到工程目錄，執行如下命令(注意：后面包含個點)看下運行結果
grep -r advertisingIdentifier .
看下運行結果
Binary file ./Pods/MOBFoundation_IDFA/MOBFoundation.framework/MOBFoundation matches
Binary file ./Pods/ShareSDK3/ShareSDK/Support/PlatformSDK/SinaWeiboSDK/libWeiboSDK.a matches
看最后一個單詞，matches(匹配)到了。 罪魁禍首原來是 SinaWeiboSDK/libWeiboSDK.a
具體原因：iOS 9 之后新浪微博分享可使用的前提是加入 ADSupport.framework，打包提交后一直報您的 App 正在使用廣告標識符 (IDFA)。
找到原因就好解決了。
具體解決方法呢？
很簡單，承認使用 IDFA，然后勾選相應的選項。 如圖所示：
當然，你也可以根據命令行做出調整。例如，上方命令行顯示SinaWeiboSDK/libWeiboSDK.a，你可以將其移除，移除完后也是可以分享成功的。（此時你可重新執行命令行，看是否還存在 IDFA，如果沒 match 到了，直接提交即可。）
另一種途徑: 下載官方最新x-code，重新打包提交審核。(沒試過，據說有人成功過)。
總結一下 ShareSDK 的解決方法：
1、 如果你的應用里只是集成了廣告，不追蹤廣告帶來的激活行為，那么選擇 1 和 4；
2、如果您的應用沒有廣告，而又獲取了 IDFA。我們建議開發者朋友選擇 2 和 4。這種做法蘋果官方沒有明確說明，但目前為止還沒有收到開發者選擇 2 和 4 被拒的反饋。
歡迎大家批評指正！O(∩_∩)O~
