工作至今，由我上架和更新的 App 大概有二十多個(gè)吧，有為客戶做的項(xiàng)目，也有自己公司的產(chǎn)品?？梢哉f(shuō)，由我檢查確認(rèn)過(guò)的應(yīng)用，上架一次性通過(guò)率還是相當(dāng)高的。
這里把我遇到的一些特別的注意點(diǎn)和遭拒記錄下來(lái)。
注意點(diǎn)
提交審核大大小小注意事項(xiàng)還是有不少，這里就記錄幾點(diǎn)
- 確定打包項(xiàng)目中有無(wú)廣告標(biāo)識(shí)符（IDFA）
在上架的每個(gè)版本提交時(shí)，都需要確認(rèn) App 有無(wú)使用，如果選擇結(jié)果與 App Store 實(shí)際檢測(cè)結(jié)構(gòu)不符，此打包文件將遭拒絕。
檢測(cè)方法是 CD 到項(xiàng)目根目錄（或者打包文件所在目錄）,使用 grep 命令
grep -r advertisingIdentifier .
此命令可以搜索項(xiàng)目中有無(wú) advertisingIdentifier 符號(hào)，advertisingIdentifier 是AdSupport 框架中的一個(gè)成員變量，它的值代表了投放廣告時(shí)用于識(shí)別設(shè)備的唯一標(biāo)志。如果存在，則說(shuō)明很大可能是啟用了廣告標(biāo)志符。雖然自己的項(xiàng)目中沒(méi)有直接使用廣告標(biāo)識(shí)符，但很多第三方 SDK 中會(huì)使用，所以上架前進(jìn)行檢測(cè)一下也是必要的。
- 檢查項(xiàng)目的 Push Notifications 開(kāi)關(guān)是否處于 ON 的狀態(tài)
Xcode 7 以前，不開(kāi)啟 Push Notifications 開(kāi)關(guān)也沒(méi)什么問(wèn)題，從 Xcode 8 開(kāi)始，啟用推送的項(xiàng)目必須打開(kāi)這個(gè)開(kāi)關(guān)才能開(kāi)啟推送功能開(kāi)關(guān)，否則無(wú)法接收到手機(jī)的 deviceToken，另外上傳 App Store 后還會(huì)收到一封郵件，提示 “Missing Push Notification Entitlement”。
類似的，項(xiàng)目中用到其他的服務(wù)也必須開(kāi)啟相應(yīng)的開(kāi)關(guān)。開(kāi)啟后會(huì)在項(xiàng)目中生成一個(gè) entitlements 文件，用于統(tǒng)計(jì)此項(xiàng)目啟用的所有服務(wù)。
- 如果項(xiàng)目中有動(dòng)態(tài)庫(kù)，在上傳之前必須把動(dòng)態(tài)庫(kù)中的 i386 或 x86_64 架構(gòu)剔除，否則直接導(dǎo)致上傳失敗
以環(huán)信 SDK 為例
如果不剔除 x86_64 架構(gòu)，上傳時(shí)可看到如下界面。
使用 lipo 命令
lipo Hyphenate.framework/Hyphenate -thin armv7 -output Hyphenate_armv7
lipo Hyphenate.framework/Hyphenate -thin arm64 -output Hyphenate_arm64
lipo -create Hyphenate_armv7 Hyphenate_arm64 -output Hyphenate
mv Hyphenate Hyphenate.framework/
這個(gè)操作其實(shí)是通過(guò) Xcode 提供的 lipo 命令把環(huán)信動(dòng)態(tài)庫(kù) Hyphenate 中的 armv7 和 arm64 架構(gòu)取出合成一個(gè)新的文件。
如果要查看動(dòng)態(tài)庫(kù)的架構(gòu)組成可以使用
lipo Hyphenate.framework/Hyphenate -info
或者
file Hyphenate.framework/Hyphenate
剔除 x86_64 架構(gòu)后的界面
另外扯一句題外話，使用使用環(huán)信動(dòng)態(tài)庫(kù)后會(huì)讓?xiě)?yīng)用安裝后大小增加 20+M ，因?yàn)?Xcode 會(huì)把編譯后的 動(dòng)態(tài)庫(kù)文件直接打包進(jìn) App 的 Frameworks 文件夾，而使用靜態(tài)庫(kù)則不然，靜態(tài)庫(kù)只會(huì)把用到的部分鏈接到 App 二進(jìn)制文件中。
其他還有很多零碎的注意事項(xiàng)這里就不一一展開(kāi)了。
被拒案例
常在河邊走，哪能不濕鞋。上架過(guò)程中偶爾還是會(huì)遇到一些拒絕的情況，提2個(gè)印象比較深刻的
- PLA 1.2 & Guideline 5.2.1
這是我遇到最多的被拒理由。PLA 1.2 是去年收到的過(guò)，Guideline 5.2.1 是最近收到的。
PLA 1.2
The seller and company names associated with your app do not reflect the name “XXXX” in the app or its metadata, as required by section 1.2 of the Apple Developer Program License Agreement.
Your app must be published under a seller name and company name that reflects the institution. If you have developed this app on behalf of a client, please advise your client to add you to the development team of their Apple Developer account
Guideline 5.2.1 - Legal - Intellectual Property
The seller and company names associated with your app do not reflect the institution in the app or its metadata, as required by Guideline 5.2.1 of the App Store Review Guidelines.
雖然條款變了，但都指向了一個(gè)問(wèn)題，應(yīng)用與開(kāi)發(fā)者賬戶沒(méi)有對(duì)應(yīng)關(guān)系，因?yàn)橐徊糠謶?yīng)用是我司替客戶開(kāi)發(fā)并上架的，應(yīng)用本身跟我司并無(wú)關(guān)聯(lián)。申訴過(guò)幾次，之前有一定概率通過(guò)，但最近越來(lái)越難，目前沒(méi)有好的解決辦法，實(shí)在不行只能讓客戶申請(qǐng)自己的開(kāi)發(fā)者賬戶了。
- UIRequiredDeviceCapabilities 問(wèn)題
這是我遇到的唯一一次也是最“坑”的拒絕，
App 的 Info.plist 不得包含 UIRequiredDeviceCapabilities 鍵的值，該鍵會(huì)阻止此 App 在之前版本支持的任何 iOS 設(shè)備上打開(kāi)。有關(guān)更多信息，請(qǐng)參閱了解 UIRequiredDeviceCapabilities 鍵。
事情是由于應(yīng)用之前的版本都不包含 HealthKit ,而新版本需要添加步數(shù)記錄功能，添加后在 Info.plist 中會(huì)出現(xiàn) Required device capabilities 一欄，要求運(yùn)行應(yīng)用的手機(jī)必須支持 HealthKit，而支持 HealthKit 又會(huì)導(dǎo)致在之前版本支持的設(shè)備上無(wú)法打開(kāi)，要消除這個(gè)錯(cuò)誤必須刪除 Info.plist 中的 Required device capabilities 一欄，而刪除后 HealthKit 功能又沒(méi)法使用了，于是陷入了死循環(huán)中...
咨詢蘋(píng)果客服并沒(méi)有任何幫助，只是得到了一些官方的無(wú)實(shí)際幫助的解答，而問(wèn)題最終是通過(guò)上架一個(gè)新應(yīng)用解決的。
以上只是對(duì)審核中幾個(gè)小點(diǎn)記錄下，如果想要順利通過(guò) Apple Store 審核，有時(shí)間時(shí)應(yīng)看看 Apple 官方文檔，遇到解決不了的問(wèn)題多搜索，不行還可以郵件咨詢咨詢 Apple 客服，一般不會(huì)遇太大問(wèn)題。
