簡(jiǎn)介面向iOS開發(fā)者的Swift內(nèi)購(gòu)支付工具示例工程基于StoreKit框架實(shí)現(xiàn)App內(nèi)購(gòu)買IAP完整鏈路覆蓋消耗品、非消耗品、訂閱三類產(chǎn)品適合需要為應(yīng)用接入內(nèi)購(gòu)功能的移動(dòng)端開發(fā)者查閱與復(fù)用。資源壓縮包大小為66KB共31個(gè)文件類型上以9個(gè)Swift源文件為核心附帶5個(gè)plist配置、3個(gè)Objective-C頭文件與對(duì)應(yīng)實(shí)現(xiàn)、2個(gè)storyboard界面文件以及Xcode工程配置、entitlements權(quán)限文件等結(jié)構(gòu)緊湊便于直接打開工程對(duì)照核心代碼。示例通過InAppPurchaseManager封裝產(chǎn)品請(qǐng)求與交易監(jiān)聽完整演示了從SKProductsRequest拉取產(chǎn)品信息、SKPaymentQueue添加支付請(qǐng)求、paymentQueue(updatedTransactions:)處理交易狀態(tài)到恢復(fù)購(gòu)買和服務(wù)器收據(jù)驗(yàn)證的流程同時(shí)包含產(chǎn)品ID配置、觀察者注冊(cè)、交易隊(duì)列刷新、失敗與退款處理等實(shí)現(xiàn)細(xì)節(jié)。Info.plist中的App Transport Security配置與entitlements相關(guān)設(shè)置也已備好可減少實(shí)際集成時(shí)的踩坑成本。已有1701人學(xué)習(xí)下載對(duì)正準(zhǔn)備接入內(nèi)購(gòu)的中級(jí)iOS開發(fā)者尤其有參考價(jià)值。1. 蘋果內(nèi)購(gòu)支付工具在 Swift 里的真實(shí)定位不是“接個(gè) SDK”那么簡(jiǎn)單不少 Swift 團(tuán)隊(duì)把蘋果內(nèi)購(gòu)當(dāng)成一個(gè)“接上就能跑”的支付工具實(shí)際上它更像一套需要自建狀態(tài)機(jī)的業(yè)務(wù)系統(tǒng)。我在過去兩年里前后幫三個(gè)團(tuán)隊(duì)處理過內(nèi)購(gòu)相關(guān)的問題一個(gè)因?yàn)槭論?jù)校驗(yàn)放在了客戶端被刷了上千筆假訂單一個(gè)因?yàn)闆]處理 Transaction 延遲到賬導(dǎo)致用戶永久性丟單還有一個(gè)在審核前夜才發(fā)現(xiàn)“恢復(fù)購(gòu)買”按鈕在 iOS 15 的彈窗邏輯下根本走不通。這篇文章不打算給你貼一份官方文檔的翻譯而是把我在 Swift 里落地蘋果內(nèi)購(gòu)支付工具時(shí)反復(fù)用到的流程、配置、參數(shù)和踩坑記錄整理成一份能直接照著做的方案。適合已經(jīng)寫好 App、準(zhǔn)備接入或正在重構(gòu)內(nèi)購(gòu)模塊的 iOS 工程師也適合想搞清楚 StoreKit 1/2 差異再做技術(shù)選型的技術(shù)負(fù)責(zé)人。2. StoreKit 2 與 StoreKit 1選型前先搞懂兩代 API 的差異和遷移代價(jià)WWDC 之后蘋果把 StoreKit 2 補(bǔ)到了 iOS 15 及以上官方演示幾乎全是 Swift 原生 async/await 寫法。但很多存量 App 還背著 StoreKit 1 的 SKPaymentQueue 老代碼新建項(xiàng)目的人也容易被兩套 API 搞混。選型直接決定接下來幾個(gè)月的開發(fā)量新工程建議直接用 StoreKit 2老工程則要評(píng)估遷移時(shí)對(duì)交易監(jiān)聽、收據(jù)校驗(yàn)和訂閱續(xù)期判斷這三塊的重寫成本。我見過有人在 iOS 15 的 target 上強(qiáng)行混用兩代Transaction.updates和SKPaymentTransactionObserver同時(shí)掛一次購(gòu)買觸發(fā)兩套回調(diào)業(yè)務(wù)側(cè)重復(fù)解鎖用戶在會(huì)員頁(yè)被扣了兩遍權(quán)益。2.1 兩代框架的能力對(duì)比Transaction、Product、Entitlement 的差異先把能力對(duì)比放在前面后面所有代碼和踩坑都基于這張表。維度StoreKit 1StoreKit 2最低系統(tǒng)版本iOS 6iOS 15商品查詢SKProductsRequestDelegate 回調(diào)Product.products(for:) async/await發(fā)起購(gòu)買SKPaymentQueue.add(_:)Product.purchase()交易監(jiān)聽SKPaymentTransactionObserverTransaction.updates恢復(fù)購(gòu)買restoreCompletedTransactionsAppStore.sync()交易憑證本地收據(jù)文件Transaction.jwsRepresentation校驗(yàn)結(jié)果無內(nèi)置校驗(yàn)VerificationResult 校驗(yàn)兩代最本質(zhì)的差異是數(shù)據(jù)模型。StoreKit 1 把一次購(gòu)買拆成 SKPayment、SKPaymentQueue、SKPaymentTransaction 三個(gè)類狀態(tài)散落在隊(duì)列和代理回調(diào)里StoreKit 2 直接用 Product 和 Transaction 兩個(gè)值類型表達(dá)Transaction 自帶signedDate、expirationDate、revocationDate、productID、purchaseDate訂閱續(xù)期和撤銷都走同一條更新流下發(fā)。這對(duì)支付工具層意義很大訂閱續(xù)期會(huì)產(chǎn)生一筆新的 Transaction退款或撤銷會(huì)下發(fā)一筆revocationDate不為空的 Transaction如果你只按“purchased 就發(fā)貨”的邏輯寫訂閱場(chǎng)景一定會(huì)出問題。我見過不止一個(gè)團(tuán)隊(duì)在測(cè)試訂閱時(shí)發(fā)現(xiàn)“用戶退款后權(quán)益沒收回”追到根因就是把revocationDate忽略掉了。2.2 從 StoreKit 1 遷移到 StoreKit 2 的代碼路徑與關(guān)鍵改動(dòng)點(diǎn)遷移不是把方法名替換一遍核心是把“代理回調(diào) 手動(dòng)隊(duì)列”改成“異步序列”的思維。常見做法是先抽一個(gè)IAPService接口把對(duì)外的buy(productID:)、restore()、observeTransactions()抽象出來內(nèi)部再?zèng)Q定用哪一代實(shí)現(xiàn)。下面這段映射是遷移時(shí)最常遇到的三個(gè)改動(dòng)點(diǎn)。// StoreKit 1商品查詢走代理結(jié)果要等 didReceive 回調(diào) let request SKProductsRequest(productIdentifiers: productIDs) request.delegate self request.start() // StoreKit 2一行拿到結(jié)果失敗直接拋錯(cuò) let products try await Product.products(for: productIDs)productIDs是你在 App Store Connect 里建好的產(chǎn)品標(biāo)識(shí)符集合類型是SetString。這里有兩個(gè)容易踩的細(xì)節(jié)同一個(gè)產(chǎn)品 ID 重復(fù)放進(jìn)集合蘋果會(huì)忽略請(qǐng)求產(chǎn)品 ID 里如果混入了空格或大寫字母返回的數(shù)組會(huì)是空數(shù)組而不是報(bào)錯(cuò)所以guard let products.first是必須寫的防御邏輯。交易監(jiān)聽是遷移里最容易翻車的部分。StoreKit 1 要求在 AppDelegate 里掛一個(gè)常駐觀察者調(diào)SKPaymentQueue.default().add(observer)StoreKit 2 把監(jiān)聽改成Transaction.updates這個(gè)異步序列在每個(gè)更新到達(dá)時(shí)處理。關(guān)鍵是updates必須在 App 啟動(dòng)早期就開始消費(fèi)否則購(gòu)買完成后的 transaction 會(huì)一直留在隊(duì)列里下次啟動(dòng)才補(bǔ)發(fā)。// StoreKit 2在啟動(dòng)階段開啟交易監(jiān)聽 func startObserveTransactions() async { for await update in Transaction.updates { // update 可能是購(gòu)買成功、續(xù)期、撤銷、退款 let transaction try checkVerified(update) await handle(transaction) await transaction.finish() } }checkVerified做的是VerificationResult解包蘋果返回.unverified時(shí)不能繼續(xù)發(fā)貨.verified才能進(jìn)入業(yè)務(wù)處理。這個(gè)函數(shù)在下面第 3.2 節(jié)會(huì)給出完整實(shí)現(xiàn)?；謴?fù)購(gòu)買在 StoreKit 2 里變成了AppStore.sync()調(diào)用后同樣從Transaction.updates或Transaction.currentEntitlements里讀結(jié)果而不是像 StoreKit 1 那樣單獨(dú)走restoreCompletedTransactions的代理方法。3. 用 Swift 實(shí)現(xiàn)沙盒內(nèi)購(gòu)的最小可運(yùn)行流程從配置到收據(jù)校驗(yàn)3.1 在 App Store Connect 配置內(nèi)購(gòu)商品的六個(gè)步驟與關(guān)鍵參數(shù)很多人先寫代碼再去建商品等你調(diào)Product.products(for:)時(shí)發(fā)現(xiàn)返回空數(shù)組才意識(shí)到是商品狀態(tài)或協(xié)議問題。順序應(yīng)該是先把 App Store Connect 里的配置做對(duì)再開 Xcode。我一般按下面六步走在 App Store Connect 選擇對(duì)應(yīng) App 的“功能 - App 內(nèi)購(gòu)買項(xiàng)目”點(diǎn)加號(hào)。選擇商品類型。消耗型、非消耗型、自動(dòng)續(xù)訂訂閱、非續(xù)訂訂閱四選一。填寫“引用名稱”團(tuán)隊(duì)內(nèi)部識(shí)別用和產(chǎn)品 ID。設(shè)置價(jià)格與價(jià)格梯度。訂閱還要選訂閱組和結(jié)算周期。填本地化信息顯示名稱和描述。這一項(xiàng)為空或和 App 實(shí)際功能不符審核會(huì)被拒。提交審核信息里的截圖和備注然后保存。沙盒環(huán)境下商品不需要真正過審也能測(cè)但狀態(tài)必須是“準(zhǔn)備提交”或“已批準(zhǔn)”。關(guān)鍵參數(shù)表參數(shù)取值建議坑點(diǎn)產(chǎn)品 IDcom.公司名.App名.商品名全小寫創(chuàng)建后不可修改刪除也刪不掉只能停用商品類型消耗型用于金幣/道具非消耗型用于解鎖功能自動(dòng)續(xù)訂用于會(huì)員類型創(chuàng)建后不可修改價(jià)格點(diǎn)選擇蘋果提供的價(jià)格點(diǎn)調(diào)價(jià)不用提交新版本訂閱組同一個(gè) App 的多個(gè)訂閱歸入同組組內(nèi)價(jià)格梯度需一致否則被拒本地化語(yǔ)言至少填英文只有中文會(huì)要求補(bǔ)材料這里提醒一句非續(xù)訂訂閱是最容易被誤用的類型。它不會(huì)自動(dòng)續(xù)期也不能跨設(shè)備恢復(fù)需要自己處理多設(shè)備同步。如果做的是會(huì)員服務(wù)優(yōu)先考慮自動(dòng)續(xù)訂訂閱否則設(shè)備切換后會(huì)面臨“用戶明明付過費(fèi)新設(shè)備卻查不到交易”的投訴。3.2 沙盒購(gòu)買流程的 Swift 代碼從商品查詢到 Transaction 結(jié)束下面是一段能在 iOS 15 編譯運(yùn)行的 Swift 購(gòu)買函數(shù)完整處理購(gòu)買結(jié)果的三大分支。建議放在一個(gè)IAPService類里而不是直接在 ViewModel 里寫。import StoreKit enum IAPError: Error { case productNotFound(String) case failedVerification case unknown } func purchase(_ productID: String) async throws { // 1. 拉取商品信息 let products try await Product.products(for: [productID]) guard let product products.first else { throw IAPError.productNotFound(productID) } // 2. 發(fā)起購(gòu)買等待系統(tǒng)彈窗和用戶操作 let result try await product.purchase() switch result { case .success(let verification): // 這里的 verification 類型是 VerificationResultTransaction let transaction try checkVerified(verification) // 先發(fā)貨一般是調(diào)用服務(wù)端接口解鎖再 finish await deliver(transaction) await transaction.finish() case .userCancelled: // 用戶點(diǎn)了取消不做任何處理 return case .pending: // 家長(zhǎng)同意 / 余額不足 / 賬號(hào)待驗(yàn)證 // 此時(shí)沒有 transaction等 Transaction.updates 后續(xù)到達(dá) return unknown default: throw IAPError.unknown } } private func checkVerifiedT(_ result: VerificationResultT) throws - T { switch result { case .verified(let safe): return safe case .unverified: throw IAPError.failedVerification } }邏輯說明Product.products(for:)只接受SetString重復(fù) ID 和非法字符都會(huì)導(dǎo)致請(qǐng)求失敗靠返回空數(shù)組而不是拋錯(cuò)來表現(xiàn)所以一定要先guard let products.first。product.purchase()是異步掛起函數(shù)在調(diào)用期間用戶會(huì)看到系統(tǒng)購(gòu)買彈窗調(diào)用方的 UI 狀態(tài)要提前切到 loading。result的三個(gè)分支必須分別處理.success說明支付完成.userCancelled什么都不用做.pending是最容易忽略的它表示交易不能立即完成比如家庭共享需要家長(zhǎng)批準(zhǔn)這一單沒有同步返回 transaction真正的交易會(huì)在之后通過Transaction.updates到達(dá)。如果只處理.success這類訂單會(huì)丟失用戶那邊表現(xiàn)為“錢扣了但權(quán)益沒到賬”。參數(shù)說明productID對(duì)應(yīng) App Store Connect 里的產(chǎn)品 ID必須是字符串。checkVerified是泛型函數(shù)只對(duì)VerificationResult做解包不做業(yè)務(wù)校驗(yàn)真正的業(yè)務(wù)校驗(yàn)要放到第 3.3 節(jié)的服務(wù)端邏輯里。3.3 收據(jù)校驗(yàn)的取舍本地驗(yàn)證為什么只能當(dāng)兜底上面的代碼可以讓你在沙盒里彈窗、付款、解鎖但它離“支付工具”還差一個(gè)關(guān)鍵環(huán)節(jié)驗(yàn)證這個(gè) transaction 不是偽造的。StoreKit 2 的VerificationResult只能證明 JWS 簽名完整、沒被篡改不能證明這筆交易在蘋果服務(wù)器上真實(shí)存在。繞過它的常見做法是直接構(gòu)造一個(gè)假的Transaction對(duì)象由于VerificationResult解包后拿到的類型是值類型攻擊者可以在內(nèi)存里 hook 掉返回結(jié)果。因此生產(chǎn)環(huán)境必須做服務(wù)端校驗(yàn)?？蛻舳嗽谫?gòu)買成功后把transaction.jwsRepresentation發(fā)給自己的服務(wù)器服務(wù)器用蘋果的根證書驗(yàn)證簽名并拿著 transaction 的originalTransactionID和productID配合 App Store 服務(wù)端 API 二次確認(rèn)。本地校驗(yàn)只建議在弱網(wǎng)兜底場(chǎng)景用比如服務(wù)端暫時(shí)不可達(dá)時(shí)先用本地憑證臨時(shí)解鎖等網(wǎng)絡(luò)恢復(fù)后再確認(rèn)。// 獲取 JWS 收據(jù)并發(fā)送給服務(wù)端的示意 guard case .success(let verification) result, case .verified(let transaction) verification else { return } var request URLRequest(url: URL(string: https://your.api/iap/verify)!) request.httpMethod POST request.setValue(application/json, forHTTPHeaderField: Content-Type) let body: [String: Any] [ jws: transaction.jwsRepresentation, productID: transaction.productID, transactionID: transaction.id ] request.httpBody try JSONSerialization.data(withJSONObject: body) let (data, response) try await URLSession.shared.data(for: request) // 服務(wù)端返回 verified: true 再解鎖內(nèi)容這段代碼里jwsRepresentation是 StoreKit 2 最核心的收據(jù)載體一個(gè) JWS 字符串包含 transaction 的完整信息、簽名和證書鏈。注意transactionID和originalTransactionID是兩回事前者是每一筆交易的唯一 ID后者是這個(gè)用戶在這個(gè)產(chǎn)品上的首筆交易 ID。訂閱續(xù)期時(shí)前者變化、后者不變。服務(wù)端查重時(shí)用originalTransactionID做唯一鍵不要用transactionID判斷“用戶是否已購(gòu)買”否則續(xù)期一次就會(huì)多放行一次。4. 蘋果內(nèi)購(gòu)支付工具避坑手冊(cè)5 個(gè)從 Sandbox 到審核的翻車記錄這一章不按 API 順序走按實(shí)際高頻問題排每條都是“現(xiàn)象 - 原因 - 解決”你對(duì)照自己的項(xiàng)目排查就行。4.1 沙盒賬號(hào)登錄狀態(tài)混亂導(dǎo)致無法彈窗現(xiàn)象與解法現(xiàn)象在 Xcode 里跑真機(jī)點(diǎn)擊購(gòu)買按鈕沒有任何反應(yīng)控制臺(tái)也沒有錯(cuò)誤系統(tǒng)彈窗根本不出現(xiàn)。原因最常見的是設(shè)備 App Store 的登錄狀態(tài)和目標(biāo)沙盒賬號(hào)不一致或者上一個(gè)測(cè)試交易還掛在隊(duì)列里沒有被 finish。TestFlight 和 Xcode 沙盒環(huán)境對(duì)賬號(hào)狀態(tài)要求很苛刻有時(shí)候連 Xcode 都沒辦法替你切換沙盒賬號(hào)。解決先到系統(tǒng)設(shè)置里退出 App Store 登錄再在 App 內(nèi)觸發(fā)購(gòu)買此時(shí)系統(tǒng)會(huì)彈出沙盒賬號(hào)登錄框用 App Store Connect 里創(chuàng)建的測(cè)試賬號(hào)登錄。如果還是無彈窗檢查代碼里有沒有未 finish 的 transaction把所有 pending 的 transaction 調(diào)finish()再不行就換一臺(tái)干凈的真機(jī)模擬器在內(nèi)購(gòu)彈窗上表現(xiàn)不穩(wěn)定不適合做最終驗(yàn)證。這套操作相當(dāng)玄學(xué)但確實(shí)能解決九成以上的無彈窗問題。另外沙盒賬號(hào)只能通過 App Store Connect 后臺(tái)創(chuàng)建不要用真實(shí) Apple ID 測(cè)試否則會(huì)被蘋果封掉這個(gè)賬號(hào)的測(cè)試資格。4.2 訂閱續(xù)期與撤銷 Transaction 重復(fù)發(fā)放狀態(tài)機(jī)沒有覆蓋 revocation現(xiàn)象訂閱產(chǎn)品在用戶續(xù)期或退款后服務(wù)器重復(fù)發(fā)貨后臺(tái)日志顯示同樣的originalTransactionID被處理了多次。原因StoreKit 2 中訂閱會(huì)產(chǎn)生多個(gè) Transaction續(xù)期一筆、撤銷一筆。撤銷時(shí)會(huì)下發(fā)revocationDate不為空的 Transaction服務(wù)端如果沒讀取這個(gè)字段就會(huì)再次執(zhí)行發(fā)貨邏輯。解決在handle(transaction)里先判斷revocationDate。func handle(_ transaction: Transaction) async throws { if let revocationDate transaction.revocationDate { // 撤銷/退款收回權(quán)益不要發(fā)貨 await service.revokeEntitlement(transaction.originalTransactionID) } else { // 正常購(gòu)買或續(xù)期發(fā)貨 await service.grantEntitlement( originalTransactionID: transaction.originalTransactionID, productID: transaction.productID ) } }判斷必須放在發(fā)貨之前。revocationDate是Date?為空表示正常交易。還要注意Transaction.currentEntitlements也會(huì)返回已經(jīng)撤銷的 Transaction過濾邏輯要和這里保持一致建議把這段函數(shù)抽成公共方法Transaction.updates和currentEntitlements兩個(gè)入口復(fù)用避免兩處邏輯不一致。4.3 客戶端收據(jù)校驗(yàn)被繞過偽造票據(jù)和假訂單現(xiàn)象后臺(tái)出現(xiàn)大量同一用戶短時(shí)間內(nèi)“購(gòu)買”同一非消耗品的記錄但蘋果開發(fā)者后臺(tái)看不到對(duì)應(yīng)訂單。原因代碼里用VerificationResult通過就當(dāng)成功而VerificationResult只驗(yàn)證本地 JWS 的簽名鏈。攻擊者可以構(gòu)造一個(gè)簽名有效的假 transaction或直接把別人換取的 JWS 拿來重放。解決唯一可靠做法是讓服務(wù)端調(diào) App Store 的status接口核對(duì)交易狀態(tài)?？蛻舳四玫?JWS 后先做設(shè)備端完整性校驗(yàn)再把 JWS 和originalTransactionID發(fā)給服務(wù)端服務(wù)端用transactionID調(diào)蘋果 API確認(rèn)productID、purchaseDate、expirationDate與客戶端上報(bào)一致才算真支付。不要信任任何客戶端傳來的布爾字段業(yè)務(wù)上只認(rèn)服務(wù)端的結(jié)論。這里補(bǔ)充一個(gè)血淚經(jīng)驗(yàn)JWS 里的時(shí)間字段要用蘋果服務(wù)器時(shí)間不要拿客戶端本地時(shí)間做比對(duì)因?yàn)楣粽呖梢愿南到y(tǒng)時(shí)間繞過“未過期”判斷。4.4 審核被拒隱藏的恢復(fù)購(gòu)買按鈕與缺失的引導(dǎo)現(xiàn)象App 提審后收到 Guideline 3.1.1 拒審理由是“無法在 App 內(nèi)找到恢復(fù)購(gòu)買的功能入口”。原因非消耗品和自動(dòng)續(xù)訂訂閱必須提供恢復(fù)購(gòu)買入口且不能藏太深。很多團(tuán)隊(duì)把“恢復(fù)購(gòu)買”和“聯(lián)系客服”擠在設(shè)置頁(yè)底部審核員找不到。解決在購(gòu)買頁(yè)、會(huì)員頁(yè)和設(shè)置頁(yè)至少放一個(gè)顯眼的“恢復(fù)購(gòu)買”按鈕點(diǎn)擊后調(diào)用AppStore.sync()。// 恢復(fù)購(gòu)買sync 后等待 Transaction.updates 或 currentEntitlements func restorePurchases() async throws { try await AppStore.sync() // 手動(dòng)檢查當(dāng)前權(quán)益 for await entitlement in Transaction.currentEntitlements { if case .verified(let transaction) entitlement { await service.grantEntitlement(transaction) } } }注意AppStore.sync()不能讓用戶輸入 Apple ID 密碼。如果用戶在當(dāng)前設(shè)備上沒有購(gòu)買記錄系統(tǒng)彈窗會(huì)提示“已恢復(fù)”你不能把它當(dāng)作錯(cuò)誤處理。另外恢復(fù)購(gòu)買成功后要回到購(gòu)買頁(yè)刷新按鈕狀態(tài)否則用戶以為沒成功會(huì)反復(fù)點(diǎn)導(dǎo)致隊(duì)列里塞滿 sync 請(qǐng)求。4.5 多設(shè)備同步與延遲到賬Transaction 到達(dá)順序不可控現(xiàn)象用戶在同一 Apple ID 的另一臺(tái)設(shè)備上購(gòu)買當(dāng)前設(shè)備冷啟動(dòng)后沒有解鎖。原因StoreKit 的 Transaction 更新并不是實(shí)時(shí)推送Transaction.updates只負(fù)責(zé)“到達(dá)本設(shè)備”的交易。新設(shè)備啟動(dòng)時(shí)如果 App 沒有主動(dòng)檢查Transaction.currentEntitlements或調(diào)AppStore.sync()就不知道這個(gè)賬號(hào)在其他設(shè)備買過什么。解決App 啟動(dòng)時(shí)同時(shí)做兩件事第一檢查Transaction.currentEntitlements并恢復(fù)該 Apple ID 的已有權(quán)益第二訂閱產(chǎn)品要監(jiān)聽Transaction.updates里的續(xù)期事件。注意這兩套邏輯要冪等服務(wù)端按originalTransactionID去重客戶端重復(fù)調(diào)用grantEntitlement不會(huì)重復(fù)解鎖。延遲到賬的極端情況是用戶在飛行模式下完成支付transaction 會(huì)留在隊(duì)列里等網(wǎng)絡(luò)恢復(fù)如果你看到“錢扣了但沒發(fā)貨”先查隊(duì)列里有沒有未 finish 的 transaction。5. 打造自己的內(nèi)購(gòu)支付工具層封裝、隊(duì)列與狀態(tài)機(jī)的設(shè)計(jì)5.1 為什么需要自己的內(nèi)購(gòu)支付工具層把 StoreKit 關(guān)進(jìn)業(yè)務(wù)門外直接在 SwiftUI 的 ViewModel 里寫product.purchase()很快但后面維護(hù)會(huì)越來越難受。內(nèi)購(gòu)涉及啟動(dòng)時(shí)監(jiān)聽、購(gòu)買中狀態(tài)、購(gòu)買后服務(wù)端校驗(yàn)、恢復(fù)購(gòu)買四件事每個(gè)頁(yè)面都要處理這三個(gè)時(shí)序就會(huì)產(chǎn)生大量重復(fù)代碼。我一般會(huì)在工程里單獨(dú)建一個(gè)IAPService或IAPStore層把 StoreKit 全部關(guān)在里面業(yè)務(wù)層只看到幾個(gè)干凈的方法protocol IAPServicing { func purchase(_ productID: String) async throws func restore() async throws var currentEntitlements: AsyncStream[String] { get } }這個(gè)抽象帶來的直接好處是如果你要切到 StoreKit 1、或者接一個(gè)自己造的支付網(wǎng)關(guān)做灰度業(yè)務(wù)層完全不用動(dòng)。壞處是不要把協(xié)議設(shè)計(jì)得太細(xì)StoreKit 2 的異步序列和驗(yàn)證結(jié)果一旦被協(xié)議吃掉太多類型遷移時(shí)協(xié)議本身會(huì)變成絆腳石。我的習(xí)慣是協(xié)議里只暴露業(yè)務(wù)含義的方法比如purchase、restore不暴露Transaction、VerificationResult這些 StoreKit 類型方便以后替換實(shí)現(xiàn)。5.2 用狀態(tài)機(jī)管理購(gòu)買過程idle、purchasing、pending、failed 的遷移規(guī)則購(gòu)買不是一個(gè)瞬時(shí)操作服務(wù)端校驗(yàn)、網(wǎng)絡(luò)請(qǐng)求都可能讓流程中斷幾分鐘。我見過團(tuán)隊(duì)用布爾變量同時(shí)記“正在購(gòu)買”和“購(gòu)買失敗”兩個(gè)標(biāo)志位組合出四態(tài)結(jié)果漏了一種就翻車。更穩(wěn)妥的是在工具層定義一個(gè)狀態(tài)機(jī)。enum PurchaseState: Equatable { case idle case purchasing(productID: String) case pending(productID: String) case purchased(productID: String, transactionID: String) case failed(productID: String, error: Error) case restoring }狀態(tài)遷移規(guī)則如下發(fā)起購(gòu)買時(shí)從.idle到.purchasing。收到.userCancelled回到.idle。收到.pending進(jìn)入.pending等待Transaction.updates推送真實(shí)交易。收到.success且服務(wù)端校驗(yàn)通過進(jìn)入.purchased。校驗(yàn)失敗或拋錯(cuò)進(jìn)入.failed并允許用戶重試。恢復(fù)購(gòu)買開始到結(jié)束走.restoring結(jié)束后回到.idle并刷新權(quán)益。在IAPStore里的實(shí)現(xiàn)片段MainActor final class IAPStore: ObservableObject { Published private(set) var state: PurchaseState .idle func buy(_ productID: String) async { state .purchasing(productID: productID) do { let result try await doPurchase(productID) switch result { case .pending: state .pending(productID: productID) case .purchased(let transactionID): state .purchased(productID: productID, transactionID: transactionID) case .cancelled: state .idle } } catch { state .failed(productID: productID, error: error) } } }這段代碼里MainActor是 Swift 并發(fā)下的 UI 安全邊界state是Published讓 SwiftUI 直接訂閱界面變化。.pending狀態(tài)必須能被界面展示比如顯示“等待確認(rèn)中”不要把它當(dāng)錯(cuò)誤彈紅色提示。.failed狀態(tài)要帶上 productID因?yàn)橛脩艨赡茉趦蓚€(gè)商品之間快速切換如果沒有 productID界面不知道失敗的是哪一單。5.3 服務(wù)端二次校驗(yàn)的 Swift 實(shí)現(xiàn)把 JWS 收據(jù)交給自己的后端工具層里校驗(yàn)邏輯最容易寫散。我的做法是在IAPService內(nèi)維護(hù)一個(gè)ReceiptValidator專門負(fù)責(zé)把 JWS 發(fā)往服務(wù)端并返回校驗(yàn)結(jié)論。下面是一個(gè)最小結(jié)構(gòu)struct ReceiptValidationRequest: Encodable { let jws: String let transactionID: String let originalTransactionID: String } struct ReceiptValidationResponse: Decodable { let isValid: Bool let productID: String? let expirationDate: Date? } final class ReceiptValidator { let endpoint: URL init(endpoint: URL) { self.endpoint endpoint } func validate(_ transaction: Transaction) async throws - ReceiptValidationResponse { let request ReceiptValidationRequest( jws: transaction.jwsRepresentation, transactionID: transaction.id, originalTransactionID: transaction.originalTransactionID ) var urlRequest URLRequest(url: endpoint) urlRequest.httpMethod POST urlRequest.httpBody try JSONEncoder().encode(request) urlRequest.setValue(application/json, forHTTPHeaderField: Content-Type) let (data, _) try await URLSession.shared.data(for: urlRequest) return try JSONDecoder().decode(ReceiptValidationResponse.self, from: data) } }服務(wù)端要做的事是先用蘋果的 JWKS 公鑰驗(yàn)證 JWS 簽名再用originalTransactionID調(diào) App Store 服務(wù)端 API 查詢交易狀態(tài)最后比對(duì)productID與會(huì)話登錄的用戶是否一致。注意一個(gè)安全細(xì)節(jié)不要把整個(gè) JWS 原樣存進(jìn)服務(wù)端日志只存transactionID和originalTransactionID的哈希否則重放攻擊時(shí)日志本身就是泄露源。ReceiptValidationResponse里的expirationDate是給訂閱用的非消耗品可以忽略但最好統(tǒng)一在響應(yīng)里帶上方便后續(xù)加訂閱產(chǎn)品不換模型。6. 用自動(dòng)化測(cè)試撐住內(nèi)購(gòu)工具沙盒賬號(hào)矩陣與 Transaction 模擬手動(dòng)在沙盒上點(diǎn)購(gòu)買容易漏場(chǎng)景Xcode 14 之后內(nèi)置的 StoreKit Test 框架能在本地模擬商品、訂閱續(xù)期、退款、撤銷不依賴真實(shí)網(wǎng)絡(luò)和沙盒賬號(hào)。6.1 用 StoreKit Test 配置文件做本地模擬不依賴沙盒環(huán)境的自動(dòng)化測(cè)試在 Xcode scheme 里打開 StoreKit Configuration選擇一個(gè).storekit文件運(yùn)行時(shí) StoreKit 會(huì)使用本地配置替代 App Store。.storekit文件可以手動(dòng)添加并編輯也可以通過 Xcode 的 StoreKit Test 面板生成。常用配置項(xiàng)包括商品列表、價(jià)格、訂閱組、續(xù)期時(shí)長(zhǎng)、撤銷/退款的時(shí)間點(diǎn)。我用它做了兩個(gè)測(cè)試場(chǎng)景本地購(gòu)買成功且服務(wù)端 mock 返回有效用戶取消后狀態(tài)回到 idle。func testPurchaseAndGrantEntitlement() async throws { let store IAPStore() try await store.buy(com.example.premium) XCTAssertEqual(store.state, .purchased(productID: com.example.premium)) }這個(gè)測(cè)試要求 scheme 里啟用了 StoreKit Test并且 mock 了ReceiptValidator否則會(huì)真的發(fā)起網(wǎng)絡(luò)請(qǐng)求。跑通后續(xù)期、撤銷、退款這幾個(gè)場(chǎng)景都可以在本地模擬出來不需要去 App Store Connect 反復(fù)創(chuàng)建沙盒賬號(hào)。6.2 上線前的內(nèi)購(gòu)回歸清單十個(gè)必須手點(diǎn)的場(chǎng)景自動(dòng)化測(cè)試補(bǔ)不到服務(wù)端交互和審核體驗(yàn)因此上線前仍要手動(dòng)過一遍清單場(chǎng)景操作預(yù)期首次購(gòu)買非消耗品沙盒賬號(hào)點(diǎn)擊購(gòu)買解鎖權(quán)益二次點(diǎn)擊不重復(fù)扣費(fèi)重復(fù)購(gòu)買非消耗品再次點(diǎn)擊購(gòu)買彈窗提示“已購(gòu)買”或直接恢復(fù)購(gòu)買取消彈窗點(diǎn)擊取消狀態(tài)回 idle無日志異常訂閱首次購(gòu)買沙盒短周期訂閱能拿到 expirationDate訂閱續(xù)期使用本地模擬觸發(fā)續(xù)期第二次 Transaction 不重復(fù)發(fā)貨撤銷/退款本地模擬退款權(quán)益被收回恢復(fù)購(gòu)買點(diǎn)恢復(fù)換設(shè)備權(quán)益恢復(fù)且不重復(fù)弱網(wǎng)開飛行模式購(gòu)買無崩潰出現(xiàn)等待狀態(tài)服務(wù)端校驗(yàn)失敗mock 后端返回 500客戶端提示稍后重試狀態(tài) failed審核路徑從設(shè)置頁(yè)進(jìn)入會(huì)員能看到“恢復(fù)購(gòu)買”按鈕最后兩條必須手動(dòng)。我自己的習(xí)慣是每次提審前把十條完整跑一遍哪怕只改了一行 UI 代碼也跑因?yàn)閮?nèi)購(gòu)工具層的狀態(tài)機(jī)一旦被 UI 改動(dòng)干擾出錯(cuò)時(shí)定位成本極高。希望這些配置、代碼和踩坑記錄能幫到你。本文還有配套的精品資源點(diǎn)擊獲取