如果你還沒有看過「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)，以下為我在上架前就先查過網路上前輩們比較常發生的拒絕原因。
- Crash
簡言之就是不能在運行中有程序崩潰的狀況發生，我認為這是開發者本來就應該要有的最低責任。 - OAuth
第三方登入，也就是常看到的google / facebook等等的登入，用以快速登入取代重新申請帳號。APPLE表示：「我也有支援第三方登入，只要APP有開放其他登入方式，我就要分一杯羹被支援」(設計對白)。所以啦，如果有支援OAuth功能的話，要記得也要加入APPLE 登入功能。 - 相容性
這一個項目是表示各種版本和尺寸的支援性都要足夠，最好是連iPad的尺寸都一併支援，這樣就一定沒問題啦。 - In-App-Purchase (IAP)
這項目是APPLE的金庫來源，除了審核非常嚴謹之外，會一併檢視APP內是否有任何引導〈外部購買〉的機制或舉動；例如販賣一個產品但卻引導到第三方的信用卡金流系統去付費，這肯定會讓蘋果氣得直跳腳，畢竟你居然膽敢不付蘋果萬萬稅。所以只要有販賣虛擬商品或功能的，就必須得乖乖使用IAP，並且繳納30% / 15%的蘋果奢侈稅。 - 隱私權政策
APP中必須提供相關隱私權政策及使用者協議的資料內容。 - 使用者生成內容 (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
這個部份就是Android內很深很深的坑了，因為Android在使用到第三方的時候會需要提供對應的APP signing KEY (非對稱加密的公鑰)，用來確保使用端的設備。一般在編譯時會區分Debug和Release Key，這些都要加入到第三方的簽署中，如果在開發者平台上有開啟PlayStore APP Signing，在上傳到PlayStore後會幫你自動重新簽署(參考)。
問題就出在這裡！！！
平常在開發的時候第三方 (例如Firebase) 一切都非常正常，功能也完整，但真的上架到商店內下載後卻發現一切都變了，就是因為這個KEY。但這很容易被忽略，因為平常自行發佈測試的APK使用的是自己簽署的APP KEY，所以不會出事，只有真的從PlayStore下載的才會使用被重新簽署過的APP KEY，在發生問題的當下也很難察覺出問題。所以要記得將PlayStore上自動簽暑的APP Signing KEY發佈到各相關第三方平台去，才不會造成瞬間掉入地獄的錯愕。
第三種：第三方平台
第三方的狀況和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卻不自知，一直到實際上線後才被發現。
以上這4種問題就是我們在「上線期」實際遇到且深深影響我們的問題，希望對於即將上架的你有所幫助囉！
