iOS 客戶端包含非 IAP 的訂購和支付功能，就一定會被 App Store 拒絕嗎？

12-30

我們的應用上傳 App Store 時被蘋果拒絕，具體如下。是由於什麼原因導致的？應該如何進行修改？註：我們的 app 裡面包含了一些業務訂購，和一些充值的功能。蘋果原反饋如下：

11.12 Apps offering subscriptions must do so using IAP,
Apple will share the same 70/30 revenue split with developers for these

purchases, as set forth in the Developer Program License Agreement
We found that your app offers the user subscriptions with a mechanism other than
the In App Purchase (IAP) API, which is not in compliance with the App Store Review Guidelines.

While your app maybe be intended to enhance the experience of your existing
subscribers, with the exception of the content specified in Guideline 11.14, if
the subscribed product is used within the app, the subscription must be offered
in the app using IAP.

App Store Review Guidelines 裡寫明不準的事，你做了，可能會被拒，可能不會。

App Store Review Guidelines 裡寫明不準的事，看到其它 app 做了，於是你也做，被拒。你說：「那個什麼什麼 app 也是這樣的！」蘋果會說：我們每天要審很多 app，漏網之魚是有的，但這不成爲你也可以不守規則的理由。

如果打算鑽空子，就要做好被拒的打算，準備預案。另外，僥倖上了，過一段時間又被拒，都是有可能的。如果願意承擔這些後果，可以不遵守規矩。

上面都給你解釋了原因，我來給你個解決辦法

做兩個網頁，第一個A網頁地址內置在程序中，第二個B的網頁地址不要內置

然後在A網頁上做一個鏈接，引導用戶轉到B網頁進行支付

在用戶要支付的時候，通過UIWebView顯示A網頁，使得用戶跳轉到B網頁進行支付，然後程序通過頁面代碼確認支付流程結束

千萬不要在A網頁放置任何支付內容，Dropbox的SDK就是這麼死的……

我了解的幾個軟體這麼繞了一下最後都沒大有問題了，不過蘋果的Review……很神奇……

樓主你現在被盯上這一點了，要不然就把功能推後吧，在以後的更新中再加上，你現在重新提交他們還是會盯著支付這個點看的……

是的。豆瓣閱讀曾經因為在新手引導里提到需網頁端購買後同步（其中指明了網頁地址）而被拒絕上架。

個人經驗，如果你想繞開蘋果支付。

不要在提交審核的過程中有任何違背App Store Review Guidelines的行為。就算審核通過上架後也保留蘋果的IAP支付方式，不要在應用中暴露很明顯的非官方的IAP方式（比如直接一個功能頁面什麼的）。

可以通過一些活動或者類似遊戲世界頻道廣播這種短暫但頻繁出現的形式引導用戶轉向線下充值，線下充值提供高於直接IAP支付的收益。這樣就算麻煩點，用戶還是願意去轉線下的。

個人覺得只要是聯網應用，可操作性就要大點，不知道我的經驗對你是否適用。

淘寶客戶端和京東都怎麼上的？

為什麼我的一個電商APP順利通過，而一個WIFI上網認證，在線購買上網時長死活過不了呢？

也是個人開發紅包功能的經驗。蘋果對第三方支付是很排斥的。咻咻紅包捕手是個用戶向用戶轉紅包的支付流程，採用支付寶也被蘋果無情的拒絕了。

申訴也無效。後來無奈採用了iap，蘋果很痛快的就給上線了。前次拒絕還有些小問題，這次也忽略了。30%提成啊，夠黑。這讓我想起馬雲的一句話，支付寶不僅只想做個掙錢的公司，而是要創造創新生態的公司（大意如此），蘋果公司一切都是為賺錢而去的。還好用蘋果的都是有錢人