晚上十一點多郵箱彈出一封標題只有兩個詞的郵件Invalid Binary。發(fā)件人是 App Store Connect。你點進去正文可能帶著幾行錯誤碼也可能只有一句冷冰冰的 this bundle is invalid連個具體原因都不給。如果你這時候打開后臺看到 Activities 里剛從 Processing 翻紅的那條構(gòu)建還杵在那兒那恭喜你提審前最容易讓人失眠的坑被你趕上了。先說清楚一個認知無效二進制不是一個單一的技術(shù)錯誤它更像是蘋果后臺對上傳包做了一系列靜態(tài)檢查之后給出的“不合格”結(jié)論。你本地能編譯、能真機跑、能順利 Archive都跟這個結(jié)論沒有必然關(guān)系。本地工具鏈寬松后臺檢查嚴格這兩者之間的落差就是大家集體踩坑的地方。這篇文章適合所有跟 iOS 上架流程打過交道的人獨立開發(fā)者、App 負責人、維護 CI 打包腳本的工程師。只要你用的是正規(guī)的 Xcode Archive 產(chǎn)物下面這套排查方法基本能覆蓋 90% 的 Invalid Binary 場景。如果是非官方工具生成、脫離 Xcode 流程的包那不在本文討論范圍內(nèi)也建議你別拿去撞后臺規(guī)則。1. 無效二進制的完整現(xiàn)場郵件、紅狀態(tài)與后臺的檢查機制1.1 大部分人是這樣收到噩耗的方式通常有三種按“嚇人程度”排序。最典型的是郵件。App Store Connect 會在構(gòu)建狀態(tài)變化后給你發(fā)一封通知標題就寫 Invalid Binary發(fā)件人地址是 App Store Connect 系統(tǒng)郵箱。郵件正文不一定包含錯誤碼有時候只有一句“The bundle is invalid”有時候會帶上 ITMS 開頭的編號比如 ITMS-90022、ITMS-90087 這種這些編號在后面會講是定位問題的第一把鑰匙。第二種方式是打開 App Store Connect進入“App - 活動”頁面看到某條構(gòu)建記錄的狀態(tài)從 Processing 變成紅色旁邊標注 Invalid Binary。這種情況通常郵件還沒到或者郵件被扔進了垃圾箱。所以收到上傳成功的提示之后別急著關(guān)瀏覽器盯一眼 Activities 的狀態(tài)變化。第三種最隱蔽你是在提交審核的最后一刻才發(fā)現(xiàn)的。因為構(gòu)建被標記為無效但舊版本還能用列表里根本選不到新的那個于是你才注意到后臺已經(jīng)在某個時間點悄悄把狀態(tài)翻紅了。我見過不少團隊是在“馬上要提審、老板來催”的時候才發(fā)現(xiàn)包早就紅了所以這里先立一條規(guī)矩每次上傳完等處理結(jié)束看到狀態(tài)變?yōu)榫G色的 Available 或 Processing 完成后再做其他事。別讓后臺在你看不見的時候做決定。1.2 App Store Connect 后臺到底在看什么很多人不理解為什么 Xcode 上傳時不報錯后臺卻給你個無效二進制。原因是 Xcode 在上傳階段只做兩件事校驗基礎(chǔ)的簽名和包結(jié)構(gòu)然后把文件傳上去。蘋果接收之后后臺會執(zhí)行一套更深的靜態(tài)檢查包括但不限于Mach-O 可執(zhí)行文件的架構(gòu)是否合法有沒有混入模擬器架構(gòu)或未知架構(gòu)Info.plist 里的關(guān)鍵字段是否齊全、格式是否正確比如 CFBundleVersion、CFBundleShortVersionString、Bundle IDApp 圖標是否存在尺寸是否滿足是否帶透明通道是否訪問了需要權(quán)限聲明的隱私接口而對應(yīng)的 UsageDescription 缺失或為空是否引用了某些已廢棄的 API導(dǎo)出合規(guī)、加密聲明、擴展目標的配置是否合理。這些檢查全是靜態(tài)的它不會真去運行你的 App。也就是說你的 App 在真機上跑得再歡也不影響這些規(guī)則判定你“無效”。這也解釋了為什么很多問題在開發(fā)階段完全暴露不了——開發(fā)時你根本不會走這一套流程。我之前跟團隊小伙伴打過一個比方Xcode 上傳就是進停車場保安只攔明顯沒掛牌的車后臺的靜態(tài)檢查才是驗車線發(fā)動機號、車架號、燈光、剎車全部過一遍才算合格。你平時在小區(qū)里開得再順手上驗車線該亮紅燈還是亮紅燈。1.3 兩個容易誤判的細節(jié)Processing 時間與構(gòu)建號復(fù)用第一個細節(jié)是關(guān)于 Processing 的等待時間。上傳成功之后后臺處理通常需要幾分鐘到幾十分鐘高峰期甚至更久。很多人一看到 Processing 狀態(tài)超過十分鐘就慌反復(fù)重新上傳同一個包結(jié)果反而可能收到“構(gòu)建號重復(fù)”或“已有版本號”這類新錯誤。我的建議是只要不是超過兩小時還沒變化就不要動它。處理時間長短不代表成功或失敗等到狀態(tài)落定再說。第二個細節(jié)比時間更隱蔽一旦某個構(gòu)建被判定為 Invalid Binary它不會消失后臺會把它保留在活動列表里但它永遠無法被選中提交。你想修復(fù)問題不能重傳同一個構(gòu)建號必須重新歸檔、讓 Build 號遞增、再傳一個新包。換句話說你手上那個有問題的包已經(jīng)“死”了搶救的意義不大直接準備下一個。搞清楚這個底層邏輯之后再看具體的報錯就開始有方向感了。2. 先對號入座ITMS-90000 系列錯誤碼的真實含義與處理動作2.1 版本號/構(gòu)建號ITMS-90060、90061、90473這三個錯誤碼都跟版本信息相關(guān)含義非常接近很多人容易搞混我拆開說。ITMS-90060 說的是 CFBundleVersion也就是 Build 號必須高于之前上傳過的版本。蘋果后臺每收到一個上傳包都會記錄這個構(gòu)建號。你修改完代碼再次上傳時如果 Build 號沒變或者比之前傳過的低就會觸發(fā)這個錯誤。很多小團隊用日期做構(gòu)建號比如 2024.06.01如果同一天補傳多次且忘記更新很容易撞車。ITMS-90061 針對的是 CFBundleShortVersionString也就是展示給用戶的版本號。后臺要求它必須高于之前提交過的版本。這里有個特別容易翻車的地方版本號比較不是簡單的字符串比較也不是整數(shù)比較而是一段一段做數(shù)字比較。舉例來說2.10.0 大于 2.9.9因為第二段 10 大于 9。如果你發(fā)過 2.10.0下一次想發(fā) 2.9.1哪怕你覺得“9 比 10 小我是降級修復(fù)”后臺也會直接拒絕。ITMS-90473 說的是版本號格式。后臺要求短版本號必須符合 x.y 或 x.y.z 的格式每段只能包含數(shù)字和點號。如果你填了 1.0.0-beta、2.0.0 (fix) 這類帶字母或空格的字符串就會收到這個錯誤。順帶提醒提交前在 Xcode 的 General 標簽頁里看一下 Version 和 Build 兩個字段確保都是純數(shù)字加點的格式。處理這三個錯誤碼的動作很一致把版本號和構(gòu)建號改成滿足條件的值Clean 之后重新 Archive。改完之后在項目的 Info.plist 里確認這兩個鍵的值真的變了。有些時候你改了 UI 里的字段但歸檔用的 target 沒選對最后打出來的包還是舊值這種情況并不少見。2.2 圖標ITMS-90022 與 90023圖標類錯誤在 Invalid Binary 里占比極高因為很多人對圖標的要求理解只停留在“看起來是張圖”的層面。ITMS-90022 的意思是缺少必需的圖標文件最常見的是缺失 1024x1024 的 App Store 圖標。如果你用的還是老式的非 Asset Catalog 圖標準備方式或者 Assets.xcassets 里的 AppIcon 沒有把 1024 那一格拖進去上傳后大概率踩中這個錯。ITMS-90023 說明圖標里帶了 alpha 通道。蘋果在大多數(shù)平臺要求 App 圖標不允許包含透明通道但很多設(shè)計工具導(dǎo)出 PNG 時默認會保留透明信息。哪怕你看到的圖片是純白底只要文件的 alpha 通道有信息就會被判定為不合格。這里建議圖像處理不熟的朋友直接用命令驗證打開終端進入圖標所在目錄執(zhí)行sips -g hasAlpha icon.png如果輸出hasAlpha: yes就必須去掉透明通道再重新導(dǎo)出。處理方案分兩種最穩(wěn)妥的是讓設(shè)計從源文件重新導(dǎo)出導(dǎo)出時明確選擇“不包含透明度”臨時救急的話可以用腳本把透明區(qū)域鋪成白色底我后面會給一個可復(fù)用的 Python 寫法。資產(chǎn)文件不要手工猜用命令驗證完再放入 Asset Catalog能省掉來回上傳的折騰。2.3 架構(gòu)ITMS-90087 與 90125這兩個錯誤碼都指向同一個問題包里存在后臺不允許的架構(gòu)。正常情況下一個面向 iOS 真機的 Archive 包應(yīng)該只包含 arm 系列架構(gòu)現(xiàn)在主流是 arm64。但當你集成了一些預(yù)編譯的第三方靜態(tài)庫、framework或者 CI 機器上打包時沒有切對目標設(shè)備很容易把 i386 或 x86_64 這種模擬器架構(gòu)一起打進去。上傳之后后臺一解析 Mach-O 文件發(fā)現(xiàn)不該出現(xiàn)的架構(gòu)直接給你標成無效。排查方式很簡單把 Archive 導(dǎo)出成 ipa解壓出 App 里的主可執(zhí)行文件執(zhí)行l(wèi)ipo -info看一下支持的架構(gòu)列表。我用一個例子說明lipo -info /path/to/YourApp.app/YourApp輸出里如果出現(xiàn)x86_64或i386那就別急著傳第二次先把架構(gòu)問題解決掉。解決思路通常是確認 Archive 的時候目標設(shè)備選的是“Any iOS Device (arm64)”而不是模擬器檢查所有第三方 framework 的 Release 版本是否只包含真機架構(gòu)如果還不行可以在 Build Phase 里加一段腳本在打包時把模擬器架構(gòu)刪掉。具體腳本在后面案例部分會寫。2.4 權(quán)限聲明ITMS-90683iOS 10 之后系統(tǒng)對隱私數(shù)據(jù)的訪問要求必須在 Info.plist 里聲明用途描述。相冊、相機、定位、麥克風、通訊錄、日歷、藍牙、健康數(shù)據(jù)這些都有對應(yīng)的 NS*UsageDescription 鍵。如果你在代碼里調(diào)用了相關(guān)接口但 Info.plist 里沒有對應(yīng)的鍵或者鍵的值是空字符串后臺在靜態(tài)檢查階段就可能直接判定無效錯誤碼常見是 ITMS-90683。這個問題的隱蔽之處在于本地開發(fā)時模擬器或真機首次彈窗會顯示你聲明的描述如果你壓根沒聲明系統(tǒng)可能不會崩潰只是不彈窗或直接崩潰并沒有統(tǒng)一的前置報錯很多團隊因此一直沒發(fā)現(xiàn)。直到提審那一步才被后臺揪出來。處理方式是逐項核對 Info.plist 里的權(quán)限鍵。我習慣拉一個清單把 App 用到的隱私接口全部列出來對照 Info.plist 檢查鍵是否存在、值是否非空、拼寫是否精確正確。注意這些鍵名必須一字不差比如NSCameraUsageDescription少寫一個字母后臺認不出來等于沒寫。2.5 其他常見錯誤碼速查表除了上面幾類還有一批出現(xiàn)頻率不低的報錯我把它們整理成一張速查表方便你收到郵件后快速對號入座。錯誤提示真實含義最快處理ITMS-90022 Missing required icon fileApp 圖標缺失或尺寸不滿足檢查 AppIcon補全各尺寸重點確認 1024 圖標ITMS-90023 Invalid Icon ... alpha channel圖標帶透明通道去掉 alpha重新導(dǎo)出 PNGITMS-90060 CFBundleVersion must be higher構(gòu)建號沒有高于上一次增大 Build 號重新 ArchiveITMS-90061 CFBundleShortVersionString must be higher版本號低于已提交過的版本使用單調(diào)遞增的版本號ITMS-90087 / 90125 unsupported/invalid architecture包含模擬器架構(gòu)或非法架構(gòu)lipo 檢查并排除 i386/x86_64ITMS-90683 Missing Info.plist key隱私權(quán)限未聲明或聲明為空補全并核對 UsageDescriptionITMS-90809 Deprecated API usage使用了已廢棄的 UIWebView遷移到 WKWebView 后重新打包Invalid Bundle Structure包內(nèi)缺少可執(zhí)行文件或關(guān)鍵目錄結(jié)構(gòu)不對用 Xcode Archive 重新導(dǎo)出不要手動改包內(nèi)容還有一類郵件正文不帶錯誤碼只有一句 “This bundle is invalid.” 后面括號里可能寫著更詳細的描述。如果描述里提到 missing the bundle identifier 或 does not contain a bundle executable先別懷疑證書回 Xcode 里確認 Archive 導(dǎo)出的是“App Store Connect”分發(fā)方式而不是 Ad Hoc 或 Development。3. 沒有錯誤碼時按這份隱性原因清單逐項排查3.1 郵件只有一個 Invalid Binary 時先看 Activity 詳情如果郵件正文真的只有一個光禿禿的 Invalid Binary第一步不是去改代碼而是回到 App Store Connect 的“活動”頁面點開那條紅色構(gòu)建記錄看看有沒有補充信息。有些情況下后臺會把更詳細的錯誤寫在構(gòu)建詳情里只是沒進郵件。這個地方經(jīng)常被人忽略我見過有人翻遍郵箱沒找到原因結(jié)果詳情頁里清清楚楚寫著缺哪個圖標。另外可以看上傳工具。如果你用的是 Xcode Organizer 或 Transporter上傳日志里可能會留存一些驗證階段的警告這些警告雖然不會阻止上傳但往往是后臺判定無效的預(yù)兆。比如日志里出現(xiàn) “beta” 字樣、傳感器/輔助框架警告、某個文件路徑異常都值得多看一眼。3.2 隱性原因一大小寫敏感的資源引用很多 Invalid Binary 查到最后根因是資源文件引用的大小寫問題但這個原因特別隱蔽。macOS 的默認文件系統(tǒng)不區(qū)分大小寫所以你在本地開發(fā)時代碼里引用圖片資源寫成[UIImage imageNamed:LaunchLogo]而實際文件名是launchlogo.png真機上跑也大概率沒問題。但蘋果后臺在解析你的 App 包時文件系統(tǒng)是大小寫敏感的一旦它校驗資源引用與真實文件名不匹配就可能把整個包判定為無效。我遇到過一個第三方庫它的字體文件名在 bundle 里是小寫代碼里引用是大寫本地開發(fā)一直正常上傳后卻收到 Invalid Binary。排查了將近半天最后是解壓 ipa逐個列出資源文件再用腳本比對代碼中的引用才定位到。這里建議在工程里搜索所有圖片、字體、配置文件名的引用同時去解壓后的.app目錄里核對真實文件名確保完全一致。3.3 隱性原因二Archive 產(chǎn)物不是你以為的最新代碼這一類問題最氣人因為你的代碼確實沒改錯問題出在打包流程本身。我見過一個很典型的場景工程師修好了 bug更新了構(gòu)建號覺得萬事俱備打開 Xcode 直接 Archive上傳后被判定無效。一看郵件錯誤碼還是之前那個。于是他懷疑是不是蘋果后臺抽風又傳了一次依然無效。最后發(fā)現(xiàn)他的 Archive 雖然構(gòu)建號是新的但產(chǎn)物里的可執(zhí)行文件對應(yīng)的是舊代碼因為 Xcode 的增量編譯沒有正確處理某幾個 source 文件的變更。處理這類問題別急著重傳同一個包。先做一次徹底清理菜單欄 Product - Clean Build Folder按住 Option 鍵讓 Clean 變成深色把 DerivedData 里的緩存一并清掉然后重新 Archive。這里有個很實際的小技巧歸檔完成后在 Organizer 里右鍵剛剛產(chǎn)出的 Archive選 Show in Finder進入.xcarchive里的 Products/Applications 目錄把.app文件復(fù)制出來拖到模擬器或真機上跑一下核心流程確認產(chǎn)物里的內(nèi)容真的是最新代碼再考慮上傳。3.4 隱性原因三把自研檢查腳本前置別等蘋果來打臉既然后臺用的是靜態(tài)檢查同樣的檢查完全可以放到本地 CI 里提前做。我在團隊里維護了一個腳本Archive 完成后自動執(zhí)行三件事檢查架構(gòu)、檢查圖標 alpha、檢查 Info.plist 關(guān)鍵鍵值。任何一項不過CI 直接標紅連上傳的機會都不給。這套做法的價值不只是省去來回上傳的等待更重要的是把“經(jīng)驗”沉淀成了團隊流程。新人加入后不需要把每個坑都踩一遍跑一次 CI 就知道問題出在哪。腳本核心很簡單大概長這樣APP_PATHpath/to/YourApp.app EXECUTABLEYourApp # 1. 架構(gòu)檢查確認只有 arm64 / armv7 lipo -info $APP_PATH/$EXECUTABLE # 2. 圖標透明通道檢查路徑按實際 Assets 導(dǎo)出位置調(diào)整 sips -g hasAlpha $APP_PATH/AppIcon60x602x.png # 3. Info.plist 關(guān)鍵字段檢查 plutil -p $APP_PATH/Info.plist | grep -E \ CFBundleVersion|CFBundleShortVersionString|NSCameraUsageDescription|NSPhotoLibraryUsageDescription腳本只需要能在 CI 的 macOS 機器上跑起來就行不需要做得多優(yōu)雅。關(guān)鍵是形成一個習慣每次提審前先讓機器把蘋果可能做的檢查做一半把明顯問題攔在發(fā)出之前。3.5 不要把時間浪費在證書上這里必須提一個誤區(qū)。很多人一看到 Invalid Binary第一反應(yīng)是“會不會是我證書出問題了”。說實話證書或描述文件出問題通常在上傳階段就會被拒提示通常是簽名錯誤、權(quán)限不匹配之類而不是等你上傳成功后給你一個 Invalid Binary。二者發(fā)生的階段完全不同前者是傳輸前的驗票后者是收票后的驗貨。所以如果你收到的狀態(tài)明確寫著 Invalid Binary先把證書相關(guān)的事務(wù)放一邊集中精力排查代碼、資源和配置。退一萬步講即使你真覺得證書可疑也可以先用 Xcode 的 Validate 功能驗證一下而不是盲目重簽后反復(fù)上傳同一個包那樣只會讓構(gòu)建號沖突的坑疊加進來。4. 從收到郵件到重新提交可以直接照抄的排障 SOP4.1 記錄失敗包的關(guān)鍵信息收到 Invalid Binary 通知后不要立刻改代碼先花兩分鐘記錄失敗包的信息。打開 Organizer選中那個 Archive記下三個東西版本號 CFBundleShortVersionString、構(gòu)建號 CFBundleVersion、Bundle Identifier。為什么要記錄因為下一步你修改后重新上傳時構(gòu)建號必須是全新且高于之前的。如果你不記錄舊值隨手填了一個與上次相同的構(gòu)建號等傳到一半才被后臺拒絕白白浪費一次上傳機會。而版本號如果填低了又會撞上 90061。更好的做法是在項目里用一個結(jié)構(gòu)化的版本管理方案。比如構(gòu)建號用$(date %Y%m%d%H%M)這種可讀時間戳保證單調(diào)遞增版本號走 Release Train 規(guī)則主版本和次版本只增不減補丁版本在提交前手動確認。這樣至少在版本字段上不太會出低級錯誤。4.2 本地把蘋果的靜態(tài)檢查提前做一遍這一步相當于把上一節(jié)的檢查腳本手動跑一遍適合沒有 CI 的個人開發(fā)者。在重新打包之前先拿到上一次的 Archive 產(chǎn)物確認它真的有問題避免改錯方向。具體操作是在 Organizer 里右鍵失敗的那個 Archive選擇 Show in Finder然后進入.xcarchive/Products/Applications目錄對該目錄下的.app文件執(zhí)行架構(gòu)檢查和圖標檢查。如果你能在這一步復(fù)現(xiàn)出問題說明你已經(jīng)拿到了根因的一半。如果檢查結(jié)果全部正常那問題可能出在你沒看到的配置文件或依賴項上需要走更深一層的排查比如對比 Dashboard 里的報錯描述。我不建議跳過這一步直接重新打包因為你可能只是“猜測”問題出在版本號但實際原因是圖標結(jié)果改完版本號再傳一次依然被拒白白等一輪后臺處理時間。4.3 修改之后Clean、Build 號加一、重新 Archive確認問題之后進入修復(fù)階段。無論你改了版本號、圖標還是 Info.plist都建議按同一套節(jié)奏走這幾步。第一步Clean Build Folder。用快捷鍵 Shift Command K 只 Clean 當前工程如果覺得不放心按住 Option 再點 Product 菜單里的 Clean Build Folder徹底清掉中間產(chǎn)物。這一步能避免增量編譯把舊的二進制殘留帶進新包。第二步在 Xcode 的 General 標簽頁里把 Build 號加一。注意如果你剛才給版本號改了值也要確認短版本號沒有被誤改小。第三步重新 Archive。歸檔時目的地選擇 Any iOS Device不要選模擬器。歸檔完成后在 Organizer 里確認新 Archive 的版本號和構(gòu)建號確實比你記錄到的舊值大再進入下一步。4.4 用 Transporter 上傳比 Xcode 更直觀上傳環(huán)節(jié)我強烈建議優(yōu)先用 Transporter而不是直接在 Xcode 里點 Distribute App。原因不是 Xcode 不能傳而是 Transporter 在狀態(tài)提示和錯誤信息上更清晰尤其是在網(wǎng)絡(luò)不穩(wěn)、包比較大時它能給你更明確的反饋。而且 Transporter 支持斷點續(xù)傳上傳大包時比 Xcode 穩(wěn)得多。操作流程在 Organizer 里選中新的 Archive點擊 Distribute App選擇 App Store Connect最后得到導(dǎo)出的 ipa 文件。然后打開 Transporter把 ipa 拖進窗口點驗證驗證通過后再點交付。如果驗證階段就報了錯誤說明包在本地就已經(jīng)不滿足基本要求這時候停下來排查比硬傳更有價值。有個小細節(jié)要提一下交付完成后Transporter 會顯示“已成功交付”之類的狀態(tài)但這只代表文件上傳完畢后臺檢查還沒開始。你需要回到 App Store Connect 的“活動”頁面盯著狀態(tài)從 Processing 變成 Available。這個過程可能需要幾分鐘也可能更久期間不要重復(fù)上傳同一個 ipa。4.5 上傳后的等待與二次失敗處理提交完新包之后給自己定一個規(guī)則第一優(yōu)先級不再是改代碼而是等狀態(tài)落定。我會把后臺頁面開著隔幾分鐘刷新一次同時留意郵箱新郵件。如果狀態(tài)最終變成 Invalid Binary先別慌看這次的錯誤碼跟上次是否相同。如果相同說明你的修復(fù)沒有命中根因需要回頭檢查是否真的把最新代碼打進了包如果不同說明問題不止一個蘋果后臺的檢查是一次性跑完的它會按規(guī)則逐項檢查你修掉一個另一個才會浮出水面。這也是為什么我建議你在本地先做完靜態(tài)檢查盡可能把多個問題一次解決而不是被后臺牽著走一輪又一輪。還有一點經(jīng)驗之談如果你連續(xù)兩次因為不同原因被拒大概率不是運氣差而是你的工程里積累了一批歷史問題。這時候花一個下午把圖標、架構(gòu)、權(quán)限、版本號幾類規(guī)則徹底過一遍比著急提交審核更劃算。5. 四個真實翻車案例復(fù)盤每次被拒背后的判斷邏輯5.1 案例一2.9.1 想降級發(fā)版被 90061 直接打回這個案例發(fā)生在一次緊急熱修復(fù)中。線上版本是 2.10.0因為某個功能出問題產(chǎn)品想快速發(fā)一個修復(fù)包開發(fā)同學順手把版本號寫成了 2.9.1理由是“這是基于 2.9 分支修復(fù)的不想動大版本”。上傳很順利后臺處理結(jié)束后直接 Invalid Binary郵件寫著 ITMS-90061。當時幾個人都沒想明白修復(fù)包為什么版本號不能比線上低答案很簡單蘋果不知道你的分支策略它只認數(shù)字比較。2.9.1 小于 2.10.0必須拒絕。處理方式把版本號改成 2.10.1Build 號在原有基礎(chǔ)上加一重新 Archive 后上傳。整個修復(fù)只花了幾分鐘但等待后臺處理和郵件往返浪費了大半天。這個案例告訴我們上架版本號沒有“邏輯合理性”只有“數(shù)字必須遞增”這一條鐵律。5.2 案例二CI 機器打出來的包架構(gòu)比預(yù)期多了一個另一個項目用的是自建 CI打包腳本在 xcodebuild archive 命令里設(shè)置了一些自定義參數(shù)。某天 CI 出來后上傳收到 ITMS-90087。排查時我先在本地復(fù)現(xiàn)用同一個 tag 在本地 Archive檢查lipo -info一切正常再用 CI 產(chǎn)物檢查發(fā)現(xiàn)二進制里多了一個x86_64架構(gòu)。根因是 CI 機器安裝的某個預(yù)編譯依賴 frameworkRelease 版本是從模擬器環(huán)境打的包混入了模擬器架構(gòu)而我們的打包腳本沒有在最終階段做架構(gòu)清理。處理分兩步先是把那個 framework 替換成真機版本的預(yù)編譯包然后在 CI 的打包腳本里加了一段防御性代碼在生成 ipa 之前用lipo -remove刪掉x86_64和i386架構(gòu)代碼如下APP_BINARY${TARGET_BUILD_DIR}/${EXECUTABLE_PATH} for ARCH in $(lipo -archs $APP_BINARY); do if [ $ARCH i386 ] || [ $ARCH x86_64 ]; then lipo -remove $ARCH $APP_BINARY -output $APP_BINARY fi done這段腳本放進 Build Phase 的 Run Script 里只在 Release 配置下執(zhí)行。從那次之后架構(gòu)類錯誤再沒有出現(xiàn)過。我的體會是第三方依賴越多的項目越應(yīng)該在自己的打包流程里加一道架構(gòu)過濾不要相信所有第三方庫都會自覺發(fā)布干凈的 Release 包。5.3 案例三設(shè)計源文件看起來是白底實際上帶透明通道這個案例是典型的“眼見不一定為實”。設(shè)計同學給了一張 1024x1024 的 App 圖標在 Finder 里預(yù)覽時顯示白底我們主觀認為沒問題放進 Asset Catalog 就直接歸檔上傳。后臺在處理結(jié)束后標記無效郵件提示 ITMS-90023說圖標含 alpha 通道。當時很不理解因為肉眼看到的就是白底。后來用命令查了一下sips -g hasAlpha icon.png輸出hasAlpha: yes這才確認問題。設(shè)計軟件的畫布雖然是白色但導(dǎo)出的 PNG 文件把所有不透明度不足 100% 的區(qū)域都記錄進了 alpha 通道。處理方式是讓設(shè)計在導(dǎo)出時勾選“移除透明通道”重新導(dǎo)出但為了應(yīng)急我用 Python 腳本把透明部分鋪成了純白底from PIL import Image img Image.open(icon.png).convert(RGBA) bg Image.new(RGB, img.size, (255, 255, 255)) bg.paste(img, maskimg.split()[3]) bg.save(icon_fixed.png)這個案例給團隊的教訓是圖標是否帶 alpha 通道不能靠眼睛判斷必須用工具驗證。后來我把sips -g hasAlpha加進了提審前的檢查清單。5.4 案例四權(quán)限描述寫成變量上傳后被判定缺失這個問題的隱蔽程度相當高。工程里為了多 Target 復(fù)用Info.plist 的部分字段用了$(變量名)的方式動態(tài)填充。某個權(quán)限的用途描述在 xcconfig 文件里配置成了變量但那個變量在某個 Target 下沒有被賦值展開后變成了空字符串。上傳后后臺認為該 Target 訪問了隱私接口但缺少用途描述直接標記 Invalid Binary。本地調(diào)試時因為用的是另一個 Target變量有值所以完全沒有暴露。排查時看錯誤碼指向權(quán)限描述但打開 Info.plist 檢查鍵值又確實存在花了一些時間才意識到鍵的值是空的。處理方式把該權(quán)限的用途描述從變量改成硬編碼的中英文雙語文案不再走 xcconfig。從那以后我要求團隊所有 UsageDescription 的值必須是直接寫在 Info.plist 里的字面量不允許用變量、占位符或“待補充”這類文本。蘋果后臺不關(guān)心你的變量有沒有值它只看最終產(chǎn)物里的鍵值是否可用。5.5 這些坑為什么總在提審前爆發(fā)復(fù)盤這四個案例之后你會發(fā)現(xiàn)問題有一個共同點它們?nèi)渴恰癆rchive 之后才會暴露”的問題日常開發(fā)完全碰不到。日常編譯運行用的是 Debug 配置模擬器架構(gòu)、未驗證的權(quán)限文案、帶透明通道的圖標都能正常工作因為系統(tǒng)根本不會給你做上架級檢查。這也解釋了為什么這些坑總是集中在提審前爆發(fā)——因為那是你唯一一次執(zhí)行完整 Product - Archive - Distribute 流程的時候。所以我現(xiàn)在的建議是把提審動作拆成兩條線一條是業(yè)務(wù)功能驗證一條是“上架健康檢查”。后者在 CI 里維護一套腳本專門在合并到主干時跑一遍架構(gòu)、圖標、權(quán)限、版本號檢查。雖然不能完全模擬蘋果后臺但可以攔截掉 80% 的無效二進制問題剩下的 20% 靠收到郵件后按錯誤碼快速定位基本夠用了。我在維護上架流程這幾年最大的體會是Invalid Binary 不是玄學它有固定的觸發(fā)面。你只要做到三件事——Archive 之后先自檢、收到錯誤碼先查表再改代碼、每次上傳前記錄好版本號和構(gòu)建號——這個錯誤大概率不會再深夜問候你。最后分享一個我自己的習慣每次提審前我都會把上次成功上傳的包的 Info.plist 和這次的做一次 diff只改必要字段不順手升級依賴、不變更工程配置。這能避免大量“改著改著不知道哪個改動導(dǎo)致包無效”的鬧鬼問題也算是我用無數(shù)次翻車換回來的血淚經(jīng)驗。