App 上架後的維護指南：系統年度更新、商店政策與 SDK 升級怎麼應對

很多業主在 App 上架那天鬆了一口氣，以為接下來只要偶爾加個功能就好。結果一年後，客服開始收到「新手機打不開」「登入一直轉圈」的抱怨，或是收到商店寄來的通知信，說 App 不符合新政策、限期修正否則下架。這時才發現，App 上架後的維護其實比上架前想像的重要得多。

App 跟網站最大的不同在於：它跑在別人的平台上。蘋果與 Google 每年都會推出新版作業系統、調整審核規則、淘汰舊的開發工具，而你的 App 必須跟著動。沒有人顧的 App 不會停在原地，它會一點一點地壞掉。

以下說明 App 維護到底在維護什麼、系統更新與商店政策怎麼應對、SDK 與套件為什麼要升級、強制更新機制怎麼設計、停止維護會發生什麼事，以及維護合約該約定哪些內容。

App 維護跟網站維護有什麼不同

網站維護多半是在處理主機、內容管理系統與外掛的更新，這部分可以參考網站維護費用與合約指南。App 的維護邏輯有幾個本質上的差異：

• 使用者自己決定要不要更新。網站改了，所有人重新整理就看到新版；App 改了，總有一部分使用者停在舊版本，所以後端必須同時支援多個版本。
• 每次發版都要過審核。修一個小錯也要重新送審，等待時間不一定，緊急修正無法像網站一樣即時上線。
• 平台方握有生殺大權。商店政策調整時，不符合的 App 會被限制更新或下架，業主沒有協商空間。
• 硬體與系統版本極度分散。尤其 Android，不同品牌、不同螢幕尺寸、不同系統版本的組合非常多，問題常常只在特定機型出現。

所以 App 維護的重點不是「有沒有壞」，而是持續讓 App 跟上一個一直在移動的環境。

作業系統每年更新：相容性怎麼顧

iOS 與 Android 都有固定的年度大版本節奏，正式版推出前會先釋出開發者測試版。這段空窗期就是維護方該做功課的時間。

每年大版本前後要做的事

1. 測試版階段先跑一輪：在測試版系統上安裝現行 App，走過登入、主要功能、付款、推播等核心流程，記錄異常。
2. 檢查權限與隱私規則變動：新系統常會收緊定位、相機、相簿、通知、追蹤等權限的取得方式，原本的寫法可能被系統擋下或改變跳出提示的時機。
3. 檢查介面顯示：新的螢幕尺寸、系統字型、深色模式、手勢操作區域，都可能讓按鈕被遮住或文字被截斷。
4. 正式版推出後追蹤當機回報：使用者升級是逐步發生的，正式版上線後的前幾週要特別盯錯誤回報。
5. 決定最低支援版本：太舊的系統版本使用者少、測試成本高，每年都該重新檢視一次要不要調高最低支援版本，並事先告知使用者。

開發工具也會被要求升級

除了手機系統本身，商店也會定期要求新送審的 App 必須以較新的開發工具與目標系統版本建置。這代表即使你一行功能都沒改，只要想發新版，就可能被迫先升級整個專案的建置環境。專案若好幾年沒動，這一步常常會卡住，因為舊的套件與新的工具不相容，必須連帶升級一串東西。

商店政策變動：最容易被忽略的下架風險

蘋果與 Google 的商店政策會不定期更新，常見的調整方向包括：

• 隱私揭露的要求變得更細，例如要求申報 App 蒐集哪些資料、用途為何。
• 帳號相關規定，例如提供註冊功能的 App 需要讓使用者能在 App 內申請刪除帳號。
• 對訂閱、應用程式內購買、外部付款連結的規範調整。
• 對兒童類、健康類、金融類 App 的額外審查要求。
• 開發者帳號本身的身分驗證與聯絡資訊更新要求。

這些變動通常會透過寄給開發者帳號的通知信告知，並給一段修正期限。最常見的悲劇是：帳號掛在離職同仁或前廠商的信箱，通知信根本沒有人看到，等到 App 被限制更新才知道。

實務建議：開發者帳號一律用公司共用信箱註冊、至少兩位管理者，並指定一位負責每月檢查商店後台的訊息中心。上架前的完整準備可以回頭對照App 上架檢查清單，裡面的政策與資料申報項目，在維護期也要定期回頭確認。

套件與 SDK 升級：看不見的依賴鏈

現代 App 幾乎不會從零寫起，而是組合大量第三方元件：登入、推播、地圖、金流、數據分析、廣告、當機回報。每一個都是一份外部依賴，而這些依賴會：

• 停止支援舊版本：提供者宣布舊版 SDK 在某個時間點後失效，舊版 App 的該功能就直接不能用。
• 跟著系統規則改版：系統收緊權限後，SDK 需要更新才能正常運作。
• 出現資安漏洞：舊版套件被發現漏洞時，唯一的解法就是升級。
• 服務本身被收掉或改名：提供者合併、轉型或停止服務，App 必須換另一個方案。

升級 SDK 不像換個零件那麼單純，新版常常改了用法，需要調整程式並重新測試。如果長期不升級，等到被迫升級時，往往要一次跨越好幾個大版本，工程量會明顯膨脹。這種「拖越久越貴」的累積現象，本質上就是技術債。

判斷原則：維護期應該有一份依賴清單，列出每個第三方元件的用途、目前版本、提供者是誰、帳號掛在誰名下。每次系統大版本前後順手檢查一次哪些需要升級，比一年後一次大搬家安全得多。

強制更新機制：上架前就該埋好

因為使用者可以不更新，總有一天你會遇到「舊版本一定要淘汰」的時刻：後端 API 改了、舊版有嚴重錯誤、舊版的金流 SDK 失效。這時如果 App 裡沒有任何機制，你只能眼睜睜看著舊版使用者壞掉。

兩種常見的更新提示

• 建議更新：跳出提示告訴使用者有新版，可以選擇稍後再說。適合一般功能改版。
• 強制更新：偵測到版本低於門檻時，畫面只顯示「請更新以繼續使用」並導向商店。適合安全性修正或後端不再相容的情況。

設計時要注意的事

1. 門檻放在後端設定：最低版本號應該由伺服器回傳，而不是寫死在 App 裡，這樣才能隨時調整而不用重新送審。
2. 第一個版本就要內建：強制更新機制只對「已經有這段程式的版本」有效。上架初版沒埋，就永遠管不到那批最早的使用者。
3. 不要濫用：每次小改版都強制更新會讓使用者反感，評價也會變差。強制更新應該只保留給真的必要的情況。
4. 提示文案要說清楚原因：「為了保護您的帳號安全，請更新至最新版本」比單純一句「請更新」更容易讓人照做。
5. 後端保留一段相容期：即使要淘汰舊版，也盡量讓後端同時支援新舊 API 一段時間，給使用者緩衝。

停止維護的實際風險

有些業主會想：「App 現在能用就好，先不要維護。」短期內也許看不出差別，但風險是逐步累積的：

• 新手機或新系統開始出現異常，客服收到抱怨，卻沒有人能修。
• 第三方服務失效，例如登入或付款突然不能用，而且通常是在最不方便的時候。
• 被商店限制或下架，已安裝的使用者也許還能用，但新使用者再也下載不到。
• 資安漏洞無人處理，若 App 涉及個人資料或交易，後果不只是技術問題。
• 重新啟動的成本變高，停太久的專案要先花時間把建置環境救回來，才能開始修第一個錯。

更隱性的代價是品牌：商店評論區會留下大量「打不開」「垃圾 App」的評價，即使後來修好了，這些評價也會長期影響新使用者的第一印象。

維護合約該約定什麼：業主自查清單

App 維護合約如果只寫「提供維護服務」，幾乎等於沒寫。以下這份清單可以直接拿去對照現有合約，或用來跟廠商討論：

• 範圍：是否包含系統大版本的相容性檢查與修正？是否包含商店政策變動的配合調整？
• SDK 與套件：第三方元件的版本升級算在維護內，還是另案處理？
• 回應時間：一般問題與緊急問題（例如無法登入、無法付款）分別多久內回應、多久內提出處理方案？
• 發版流程：送審由誰操作？審核被退件時由誰負責修正與重送？
• 帳號歸屬：開發者帳號、簽署憑證、推播與分析服務的帳號是否在公司名下？
• 原始碼交付：每次發版後，原始碼是否同步交付或存放在公司可存取的版本庫？
• 監控與回報：是否有當機回報工具？誰負責定期查看並主動通報？
• 不在範圍內的事：新功能開發、介面改版如何計價與排程？
• 終止條款：合約結束時，交接內容包含哪些文件與帳號？

最後一點特別重要。維護廠商也可能換人，屆時能不能順利交接，取決於這份清單裡的帳號與原始碼項目有沒有落實。新功能該怎麼規劃與排優先順序，則可以另外參考上線後的產品路線圖。

把維護變成固定節奏，而不是救火

好的 App 維護應該是一份有節奏的行事曆，而不是出事才找人：

• 每月：查看當機回報與商店評論、檢查商店後台的訊息與政策通知。
• 每季：盤點第三方依賴是否有停止支援公告，評估要不要升級。
• 每年系統大版本前後：測試版相容性檢查、正式版上線後追蹤、重新評估最低支援版本。
• 每次發版：更新依賴清單、確認原始碼與建置說明同步更新。

這樣做的好處是，維護工作量變得可預期，業主也能提前編列資源，而不是每次都被突發狀況追著跑。

如果你的 App 已經上架一段時間、不確定現在的相容性狀況與依賴風險，NETVANA 可以先幫你做一次維護盤點：檢查系統相容性、第三方 SDK 版本、帳號歸屬與強制更新機制，再依結果建議維護範圍。軟體服務一律採詢問報價制，歡迎先和我們聊聊你的 App 現況；維護與開發的服務內容可在軟體服務介紹查看。

延伸閱讀：上架前要準備哪些資料與政策申報，看App 上架檢查清單；網站那一側的維護怎麼約定，看網站維護費用與合約指南；長期不升級為什麼越拖越貴，看技術債是什麼；上線後功能怎麼排優先順序，看上線後的產品路線圖；要換維護廠商時帳號與原始碼怎麼交接，看原始碼歸屬與專案交接；持續更新時商店頁面也要跟著調整，可以看App 商店優化 ASO 指南；SDK 升級也是資安的一環，可以看App 資安基本功。