APP上線全記錄 - 4種APP上線會遇到的問題

第一種：審查

Android

自動審查+(人工？)，相對輕鬆簡單，只要把APP內相關資訊填對，並且自動驗證中沒有錯誤項目，基本上很快就過了。這裡建議最好將警告項目也一併修正。

要注意的是，version name 和 version code (build) 是不同的東西，PlayStore看的是build，而且不能覆蓋或是刪除，如果上傳到重複的build會在上傳完成後才顯示失敗，浪費整個上傳時間，所以建議上傳前檢查一下。

補充個小知識，大部分軟體版本制定會遵照Semantic Versioning (語意化版本號)。

<major> . <minor> . <patch> + <build>

major是主版號，進版表示版本內包含了不相容的 API 修改。

minor是次版號，進版表示版本內包含了向下相容的功能性新增。

patch是修訂號，進版表示版本內包含了向下相容的問題修正。

所以如果版本號如下

3.1.2+10

PlayStore看的就是10這個version code (build)

PlayStore商店頁面給使用者看到的是3.1.2這個version name

iOS

主要為人工審查，可以看這裡洋洋灑灑的一堆規範(Review Guidelines)，以下為我在上架前就先查過網路上前輩們比較常發生的拒絕原因。

1. Crash 簡言之就是不能在運行中有程序崩潰的狀況發生，我認為這是開發者本來就應該要有的最低責任。
2. OAuth 第三方登入，也就是常看到的google / facebook等等的登入，用以快速登入取代重新申請帳號。APPLE表示：「我也有支援第三方登入，只要APP有開放其他登入方式，我就要分一杯羹被支援」(設計對白)。所以啦，如果有支援OAuth功能的話，要記得也要加入APPLE 登入功能。
3. 相容性 這一個項目是表示各種版本和尺寸的支援性都要足夠，最好是連iPad的尺寸都一併支援，這樣就一定沒問題啦。
4. In-App-Purchase (IAP) 這項目是APPLE的金庫來源，除了審核非常嚴謹之外，會一併檢視APP內是否有任何引導〈外部購買〉的機制或舉動；例如販賣一個產品但卻引導到第三方的信用卡金流系統去付費，這肯定會讓蘋果氣得直跳腳，畢竟你居然膽敢不付蘋果萬萬稅。所以只要有販賣虛擬商品或功能的，就必須得乖乖使用IAP，並且繳納30% / 15%的蘋果奢侈稅。
5. 隱私權政策 APP中必須提供相關隱私權政策及使用者協議的資料內容。
6. 使用者生成內容 (UGC) 如果你今天開發的APP是讓使用者可以創造、分享、上傳內容，例如社群軟體、交友軟體，就必須要提供佐證你可以控管使用者發佈的內容，例如使用者可以舉報、刪除，管理者有權限可以處置等等。我個人覺得這也算是相當合理的一條規範啦，畢竟你提供了這個APP，本身就有義務去維護這個環境，避免成為犯罪者的溫床或垃圾場。

「聖經種子」當初在上架前已經完成上述的已知可能拒絕原因，但我們實際上還是被以下3種原因各拒絕了一次。 2.1 Performance - App Completeness 3.1.1 Business - Payments - In-App Purchase 3.2.2 Business - Payments - Subscriptions – A functional link to the Terms of Use (EULA) – A functional link to the privacy policy

第二種：APP Signing KEY

第三種：第三方平台

在這個例子中，我們上架後遇到了Facebook登入的異常，原因是因為Facebook登入的審查也很嚴謹，如果APP還沒上架，是不能開啟 "上線模式" 的，只能使用 "開發者模式"。在開發者模式中，只有限定的帳號可以登入，這導致我們開發時和測試期都很正常，但真的上線後就收到如雪片般飛來的問題回報 - Facebook無法登入。當下我們趕緊將功能開啟。 但當然沒有這麼簡單！ 過沒多久就收到Facebook的通知表示有部分驗證失效，違反了他們的政策，所以又立馬把我們關閉。這時後只好趕緊把已知的問題想辦法修復，第一次的問題是發現URL驗證沒過，找了找說明，似乎是要在隱私權政策的網域下放入app-ads.txt來驗證該網域是屬於我們的，但這起因是因為我們有開過Facebook Audience Network (FAN)，臉書的廣告放送平台，但後來沒用也不知道怎麼關掉該項目就是了(苦笑)。申訴回應後，第二個錯誤項目是隱私權政策沒寫清楚，根據Facebook的條文，原來要在隱私權政策裏面清楚告知如果使用者要刪除帳戶時要怎麼做。完成上面兩個問題後，權限終於恢復了(泣)，但也花了3-4天的回應和審閱時間。

另一個案例，我們在「聖經種子」中有設置獎勵廣告Admob。原本前幾天都好好的可以正常載入廣告，但某一天開始就突然失敗，一開始以為只是短暫的異常，後來幾天都一樣的狀況，才跑去Admob頁面中確認問題點，結果發現一個新的審核跑出來，並顯示我們的APP設定未完成。後來改了兩個地方才通過審查，第一個跟FAN一樣，要設定app-ads.txt；第二個是要設定iOS / Android的上架商店ID供驗證。這些審查在我們上線前應該是沒有的，但也沒收到Google通知說有重要審查變更，只能摸摸鼻子自己吞下去。

第四種：程式臭蟲

我們在這裡也吃了個大虧，雖然我們有執行了兩階段的封閉測試，但第二階段測試到最後上線為了搶快是併行的，所以對於第二階段測試所修正的內容只有開發者們內部自行測試，導致產生了Side Effect卻不自知，一直到實際上線後才被發現。