ios馬甲包過審技巧匯總

❶ ios怎樣上架馬甲包

1. 你需要找到一家專業的馬甲包製作機構或者平台！

2. 需要不嫌棄馬甲包，既然是馬甲包，那就要有馬甲包的樣子，一個字多！！！！

3. 需要找到一家專業的上架服務商，你自己搞，搞死也搞不了多少個上去！
   

❷ 應用在蘋果App Store 怎麼上架以及審批

iOS APP上架App Store流程：

1、注冊開發者賬號

開發者賬號分為三種，分別是個人開發者賬號，公司開發者賬號，和企業開發者賬號。

2、創建APP ID、配置文件Profiles

創建APP ID，APP ID非常重要，上架流程就是用APP ID關聯在一起的。

3、創建iOS發布證書

創建iOS發布證書，下載P12證書文件。

4、打包ipa

利用iOS證書打包ipa，可以使用HBuilder工具打包。

5、iTunes connect創建APP

進入iTunes connect，選擇創建APP，輸入應用名稱、語言、套裝ID等，創建APP。

6、上傳ipa

APP uploader程序中，提交ipa文件。

7、填寫APP信息提交審核

iTunes connect中在我的APP中填寫APP的各項信息，提交審核，等待通過即可。

App Store審核比較嚴格，其實可以藉助蘋果簽名，這樣就可以不經過App Store，直接在蘋果手機上安裝了。

搜索微導流，點擊企業簽名，上傳自己的ipa文件，就可以完成在線簽名了。

❸ 如何解決馬甲包審核問題

iOS審核大體分為三部分，預審、機審和人工審核。
從最新的數據反饋得出，審核被拒原因TOP5條款有：2.1 App 完成度、2.3 准確的元數據、3.2.1 可接受的商業模式、4.3 馬甲包、5.1.1 數據收集和存儲。
開發者一定要遵守上述條款，增加過審幾率。尤其是在4.3馬甲包條款上可以利用第三方的代碼混淆工具來完成，改變同一個馬甲包的代碼而對功能又沒有改變，大大降低開發時間。可以使用頂象的iOS代碼編譯器，利用iOS代碼混淆技術來改變二進制文件。

❹ ios馬甲包怎麼上架

審核速度變慢

最近，蘋果審核團隊一度讓人以為進入樹懶狀態，應用相當長時間內處於「正在審核狀態」（in Review），很多小夥伴依舊寄託蘋果工作忙後面會處理的美好願景，事實並非如此。很多產品處於正在審核狀態長達一個月也並未進展，後面只能悲慘刪除應用重新提交。不排除有包等了兩個月才審的。對於蘋果為何沒有審核產品，個人分析認為是蘋果對於馬甲包過多的一種「冷藏」方式。簡單說，就是讓你的馬甲包一直處於正在審核狀態不予以後續任何干預。即使給蘋果寫郵件，或者在「Connect US」進行觸發，都是無濟於事。

團隊上家的五個App近期也中招了

❺ 各位大神，ios馬甲包現在還刷得動么

所謂了馬甲包，是為了針對蘋果審核嚴、無法刷排行榜想出來了一個方法。公司把同一套代碼，換個皮膚，換個名字，再換個蘋果賬號提交審核，只要審核通過，那此程序就相當於在蘋果市場多了一份曝光率，所以很多公司，給同一個代碼換十套，甚至百套名字、皮膚，從中獲利。此方法在游戲和彩票之類的APP使用最頻繁，游戲公司的收入至少有50%是來自這些馬甲包。
我個人覺得做馬甲包的行為屬於非正當競爭，屬於非常可恥的行為。此行為直接會讓所有的開發、市場、設計人員，不把重心放在產品上，而是放在如何發布更多的APP，如何在iOS排行榜拿下前十位置等等。值得慶幸的是蘋果市場的審核人員已經注意到這塊，目前在審核條款了加了好幾項相關說明，同時，在審核的時候也會通過機器初審的時候對比蘋果市場是否存在該二進制文件等方式。

❻ 如何提升iOS審核的通過率

原文來至：http://www.cnblogs.com/haohao-developer/p/5626821.html
負責 iOS 應用開發的同學們，想必已被 APP Store 的審核機制折磨心累不止。新的一年，又一輪審核即將來襲，你們做好准備了么？
為了幫助各位 iOS 應用開發的同學免受折磨，騰訊 Bugly 特邀互娛 iOS 預審組的同學通過大量的數據分析，對蘋果的審核機制進行了一番總結，連夜趕稿寫出提升 iOS 審核的通關秘籍（因為內容較多，因此分為上下兩篇），來與大家分享。
經過互娛 iOS 預審組近一年的數據監控，分析過往提審被拒的案例，我們對 iOS 的審核進行了縝密分析，統計出最常見的被拒原因：

通過以上案例，並結合《蘋果應用商店審核指南》，大體可以將審核工作分為三塊：客戶端資源檢查、應用內容檢查、提審資源檢查，我們將通過這三步來為您揭秘iOS審核的真相。

第一步：客戶端檢查篇
客戶端檢查的主要目的是通過客戶端配置檢查來保證客戶端符合蘋果的開發者規范以及其他更新的要求，包括存儲系統、配置文件、網路連接（VPN）、icon檢查、私有API檢查，提審前的審核會覆蓋這幾個部分的各個測試點。

1.存儲系統檢查
蘋果官方對用戶數據存儲有嚴格的規范，因此如果要通過審核，首先要了解一下蘋果官方數據存儲指引的相關內容：

被拒條款：2.23
Apps must follow the iOS Data Storage Guidelines or they will be rejected.( 應用啟用iCloud存儲功能後，必須遵守iOS數據存儲指南，否則將被拒。)
被拒案例
被拒原因描述如下：
We found that your app does not follow the iOS Data Storage Guidelines, which is required per theApp Store Review Guidelines.
In particular, we found that on launch and/or content download, your app stores 5.6 MB. To check how much data your app is storing:
Install and launch your app
Go to Settings > iCloud > Storage & Backup > Manage Storage
If necessary, tap 「Show all apps」
Check your app』s storage

The iOS Data Storage Guidelines indicate that only content that the user creates using your app, e.g., documents, new files, edits, etc., should be backed up by iCloud.
Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app.
Data that can be recreated but must persist for proper functioning of your app - or because customers expect it to be available for offline use - should be marked with the 「do not back up」 attribute. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKey attribute.
簡評:
應用在啟動時就在Documents下產生了5.6 M的數據，說明不是用戶自行創建並用於備份的，通過修改應用，在document目錄加一個不備份的屬性(NSURLIsExcludedFromBackupKey)後審核通過。再來總結一下iOS5以後的存儲規范：
ü 只有那些用戶生成的文檔和其他數據或者是那些不能被你的應用所重建的數據應當保存在/Documents 目錄內。這些數據文件將會自動的通過iCloud備份。
ü 那些可以重新下載或者重新創建的數據應當保存在/Library/Caches 目錄內。你可以把資料庫緩存文件或者可下載的內容如雜志、報紙、地圖應用的數據等放入緩存目錄里（Caches directory）
ü 臨時需要的數據應該保存在/tmp 目錄內。盡管這些文件不會備份到iCloud里，但記住不再需要它們時立即刪除掉這些文件，這樣它們就不會繼續浪費用戶設備的儲存空間了。
ü 使用「do not back up」屬性指定不需要iCloud備份的文件（比如需要離線環境使用的文件；該屬性能在任何目錄下生效）。由於這些文件佔用設備空間，所以應用需要有一套定期監控與清理這些文件的機制。
應對措施
本例中該應用未啟用iCloud備份，如果啟用了iCloud備份，則可以通過把較大的數據（模板類、聯網下載的數據等）存到/Library/Caches目錄，則同樣可以解決問題。

2.配置文件（Info.plist）檢查
每個 APP 都使用Info.plist文件來存儲以上的元信息，就是通常所說的 「屬性列表」。IOS用Info.plist來決定bundle所顯示的icon，當前app支持打開的文檔類型，等等其它的信息。正如以上所提到的，Info.plist本身是一種結構化的文本文件，它包含了一些重要的配置信息。關於此部分的檢查，我們通常關注如下方面的內容：

被拒條款
Multitasking Apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.（多任務應用只允許在後台運行如下相應的服務：VoIP，音頻播放，地理位置，任務記錄，本地提醒等。）
被拒案例
被拒原因描述：
We found that your app uses a background mode but does not include functionality that requires that mode to run persistently. This behavior is not in compliance with the App Store Review Guidelines.
We noticed your app declares support for VoIP in the UIBackgroundModes key in your Info.plist but does not provide any Voice over IP services.
We recognize that VoIP can provide 「keep alive」 functionality that many app features would like to use. However, using VoIP in this manner is not the intended purpose of VoIP, which, as indicated in the iOS Application Programming Guide, is that: 「A Voice over Internet Protocol (VoIP) application allows the user to make phone calls using an Internet connection instead of the device』s cellular service.」
It would be appropriate to add VoIP features or remove the 「VoIP」 setting from the UIBackgroundModes key.
簡評:
應用為了實現後台保持在線的功能，在 Info.plist 中定義的 UIBackgroundModes，間接聲明了支持 VoiP 功能，實際應用被蘋果認為並未按照 Voip 的定義去實現，導致被拒；從 Info.plist 移除了 UIBackgroundModes（VoIP）和相關代碼後審核通過。總結，應用首次提交審核時，有爭議的功能盡量先砍掉，先保證盡快上架。

3.網路連接（VPN）
大多數App的審核伺服器是部署在中國，然而蘋果的iOS審核團隊卻又是在美國，他們進行審核時，使用的是美國網路，跨洲際的網路連接，難免會出現時延大、抖動、丟包等網路問題，因此被拒。
應對措施
為了提前驗證App後台伺服器基於此場景下的反應，預審團隊採用美國VPN方式來模擬蘋果審核團隊的訪問網路環境。

4.Icon檢查
蘋果官方對iPhone、iPad、iPod等應用程序的icon有明確的要求：要求ipa包中必須包含180x180，120x120，76x76，152x152尺寸的PNG格式的icon（詳見下表），並且不同尺寸的icon內容要一致。

5.私有API檢查
私有API是指放在PrivateFrameworks框架中的API，未公開的API是指雖然放在Frameworks框架中，但是卻沒有在蘋果的官方文檔中有使用說明、代碼介紹等記錄的API。
之前 APP Store 便下架了包括《爸爸去哪兒2》、《找你妹》在內的256款APP，原因是調用私有API，很明顯，蘋果明確不允許App使用這類API。
被拒條款：2.5
Apps that use non-public APIs will be rejected.（使用非公開API的應用會被拒。）
被拒案例
被拒原因描述如下：
We found that your app uses one or more non-public APIs, which is not in compliance with the App Store Review Guidelines. The use of non-public APIs is not permissible because it can lead to a poor user experience should these APIs change.
We found the following non-public API/s in your app:
descriptionWithCalendarFormat:
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple』s private APIs to avoid your application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a static library included with your application. If you do not have access to the library』s source, you may be able to search the compiled binary using 「strings」 or 「otool」 command line tools. The 「strings」 tool can output a list of the methods that the library calls and 「otool -ov」 will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.
We appreciate that you may have made the precautions in your code for using non-public APIs, however, there is no way to accurately or completely predict how an API may be modified and what effects those modifications may have. For this reason, we do not permit the use of non-public APIs in App Store apps.
簡評：
這個條款被拒的描述文字比較多。先來看看蘋果API的分類：
1) Published API（公開的API）：又稱 Documented API（文檔中記錄的API）。是蘋果通過 Cocoa Touch 向全世界第三方開發者公開的所有 API 。
2) UnPublished API（未公開API）：又稱 Undocumented API（文檔中未記錄的API），是指雖然放在Frameworks框架中，但是卻沒有在蘋果的官方文檔中有使用說明、代碼介紹等記錄的API。按蘋果的說法，未公開的API是還不夠成熟，可能還會變動的API，等完全成型了後會變成公開的API，但是目前不對其提供承諾，就是系統版本升級後可能會失效。
3) Private API（私有API）：指的是SDK下的 PrivateFrameWorks框架下的API，真實存在於 Cocoa Touch 中。私有API是蘋果明確規定不能使用的API，當然在越獄渠道沒這個限制，比如91渠道。
被拒文字中的non-public APIs，後兩種分類都算。源碼中如果恰好定義了方法與非公開的API重名，也會導致被拒；比較常見的是，使用的第三方靜態庫中，包含了非公開的API，那麼可以通過strings或otool命令來查找相關的API：
strings LibName.a | descriptionWithCalendarFormat
或
strings AppName.app | descriptionWithCalendarFormat
其中.app是編譯結束後Build目錄下的文件。
使用otool –ov LibName.a 輸出Object-C類結構以及定義的方法。
應對措施
採用自動化工具掃描來實現，實現原理如下：
1、獲取未公開庫：基於iOS的SDK，mp出全庫，全庫減去私有庫和公開庫後，得到未公開庫（non-public API）；
2、獲取頭文件方法和成員的列表：使用Otool等工具，對ipa的可執行文件進行反編譯解析，獲取頭文件中方法和成員的列表；
3、與未公開庫、私有庫進行匹配：將列表中的方法和成員，分別與私有庫和未公開庫進行匹配，如未有匹配成功項，則掃描通過，如有匹配成功項，則掃描不通過（給出告警和API名稱）。

6.硬體與版本差異
iOS 2007年作為手機系統發布至今，已經陸續套用到iPod touch、iPad以及Apple TV等產品上，並更新了多個版本。而蘋果的硬體也在不停地推陳出新，外部市場上也已經有比較多的產品硬體版本，面對如此之多的硬體及系統版本，怎麼去保證提審版本的質量，是一直困惑測試和產品團隊的大難題。
被拒案例

對應措施
1、與蘋果關注同樣的驗收版本：推測蘋果審核團隊設備驗收選型也會遵循原則：驗收最新發布的兩個系統版本，兩個硬體版本。保證游戲可以在市場佔有率最高的兩個系統版本及硬體配置上可以流暢運行。
2、關注beta版本：蘋果在新版本上線前會發布beta版本做少量測試，此時需要跟進beta版本，可以提前發現問題，避免突然版本發布造成措手不及。

總結：
1、實際上存儲系統的檢查是一套規范，遵循同系列理念，比如用戶本地存儲空間與蘋果iCloud伺服器存儲的合理使用，節約空間；

2、Info.plist文件檢查實際上是xml文件的鍵值檢查，並且值檢查關系是並列的。通過存儲文件、plist用例的檢查，基本避免了因該類原因被拒的情況；

3、通過自動化工具掃描是否調用了私有API， 蘋果除了對提審版本掃描還會不定期對線上的版本進行掃描，所以別想著通過雲控開關或者代碼下發來繞開私有API。同樣需要注意的是，不調用私有API，但跟私有API函數重名也會被apple認為違反了私有API規定。

❼ ASO優化技巧：如何飛躍馬甲包的那些坑

一、什麼是馬甲APP?
馬甲APP指的是在常用的用戶名外再注冊的其他名字的APP。俗稱：替死包
二、馬甲APP與真實APP的區別是什麼?相同點是什麼?
1、應用名稱不一樣。
2、關鍵詞不一樣。
3、應用圖標。不一樣。
4、應用截圖。不一樣。
5、開屏圖片。最好不一樣。
6、其餘的,比如主APP的一些品牌因素,最好去掉。
三、為什麼要做馬甲APP?
1、A/B測試。馬甲包初期，很多公司,用主APP測試不方便而且馬甲APP可以隨意更改。早期馬甲包主要是為了做測試用，後來演變成了倒量的一種方法和渠道。
2、覆蓋更多關鍵詞。眾所周知,一個APP關鍵詞只能覆蓋100字元。所以多做一個APP覆蓋的字元可以更多。
3、刷榜。很多文章講過什麼是刷榜,怎麼刷榜等等。刷榜雖然性價比高,但是刷榜是有風險的,萬一被蘋果下架了,影響極其惡劣。但是馬甲不一樣,掛了就掛了,再做一個。馬甲刷到很好的位置的時候,就有了用戶量,有了用戶量就能產生價值。你的回收就會更好。
4、渠道。你的馬甲有流量了,相當於你多了一個渠道,你可以選擇為自己導流,與別人進行換量合作。
四、馬甲APP的成本。
1、賬號成本。注冊一個開發者後台,務必是個人開發者,記得務必和主APP不是一個賬號。目前金融類的必須要企業賬號，所有這類產品成本稍高些
2、開發成本。如果跟主APP長得差不多的話,估計2天搞定問題不大。
3、運營成本。後面素材更新啦,刷榜啦,等等。
總體下來,成本不高的。
五、馬甲APP怎麼做?
1、分包運營。不同的包運營的手段不同，主包盡量不要做太多的動作，馬甲包可以機刷，可以換量，可以找下游渠道聯運
2、分包計費和流量情況，不同的包流量情況，也可以很清楚的看到，如果不滿意蘋果的後台數據，可以接入第三方數據平台
3、市場備用。
4，給主APP導流。能導多少算多少吧。免得萬一掛了,毛都沒了。
六、馬甲APP如何推廣?
通過機器刷關鍵詞下載好評,把搜索結果榜單刷上去。
觀察了很多馬甲APP,覺得大多是設計感很差沒有質量的,所以用戶搜索下載了安裝後卸載率較高。因此我認為應該是APP矩陣策略,有高質量的矩陣APP產出,這些矩陣APP把握用戶更加垂直的需求來拉新,再去互相導流,而不是單純的為了ASO而生產馬甲APP做牛皮癬。個人見解。
最後,在群里看到一個運營口訣,覺得挺有趣的,分享一下:
推廣強,運營弱,做矩陣
推廣弱,運營強,做整合
推廣弱,運營弱,做外包
推廣強,運營強,隨便玩
七、馬甲App存在的問題
1.卸載率居高不下,馬甲通過刷子把關鍵詞刷上去後,所憧憬的當然是流量轉換為下載激活量,但問題是,有許多的馬甲App粗製爛造,有些功能缺陷明顯,用戶體 驗極差,從而導致用戶剛下載就卸載;
2.被下架風險極高,大家都知道馬甲不可能通過正常手段慢慢優化,絕大部分都是狂刷,也正因為如此,馬甲APP是蘋果下架的風險系數是非常高;
3.在馬甲App小有成就時,就應迅速導量,別等到馬甲App的用戶規模達到一定的數字後才開始導,那樣的話,如果馬甲App被下架的話,可就連湯都沒剩下的了,導量這種事是宜早不宜遲。
適合玩馬甲包矩陣的產品：游戲類、金融類、新聞資訊類
目前馬甲包過審難度加大，主要是因為蘋果審核規則的變化
Ipv6的問題：
1、多環境下模擬測試找問題：有時候蘋果關於 IPv6 的審核流程未能完成，問題也可能出現在了其他位置：
• 比如網路延遲是常見的情況之一，在配置好 IPv6 之後，因為網路延遲導致了蘋果審核無法正常進行，那麼我們可以通過模擬來測試，比如模擬外網環境；
• 同時我們也應該測試是否會有 Bug 導致卡在某個頁面，例如有測試賬號的 App，是否會出現輸入手機號後書輸入驗證碼無法登陸情況（蘋果未點擊「獲取驗證碼」按鈕），以及蘋果輸入驗證碼少或者多幾位情況。
先讓技術那邊查實，是否確定是IPV6的問題，如果是，那就修改之後重新提交就行，如果不是，那就尋找蘋果遇到的問題，而並非一定是 IPv6 本身的問題。
2、架設國外伺服器解析：還有一個很常見的情況是因為蘋果在外網，因為某些原因，經常會無法訪問國內伺服器網路。那麼我們可以購買韓國或日本伺服器來假設 IPv6 供蘋果進行測試。
3、拍攝 IPv6 網路下正常視頻反饋：配置好 IPv6 後使 用 10.3.1 設備在 IPv6 環境下測試（根據蘋果設備情況，自己架設 IPv6 環境），如果多次測試無誤，可拍攝視頻上傳至 YouTube，反饋給蘋果審核視頻鏈接處理。
1.2的問題
1.2主要是蘋果認為你的應用名稱沒有體現出你的品牌或者是和你的公司不符合。這類解決辦法要麼修改App名稱，體現你的公司品牌，或者是蘋果回復郵件，帶上可以證明的文件，比如軟著，或者是授權書等。
2.3的問題
一般來說2.3是侵犯了他人品牌詞或者是副標題出現了競品詞，需要重新命名。這類問題一般解決辦法就是去掉誤導性品牌詞和描述話語，然後蘋果回復郵件。
4.2的問題
4.2是垃圾應用，或者說是應用太過於簡單，只有一些簡單的H5，沒有核心功能，這部分被拒絕的主要是蘋果認為你功能不夠，建議可以添加一些垃圾功能來豐富一下應用內容，其他方面和4.3類似。
4.3的問題
4.3拒審核是目前急需解決的問題，之前馬甲包拒審基本上表面的東西修改之後重新提交，過審的概率很大，或者直接換賬號提交，但是現在馬甲包不過審，用戶量上不來，KPI怎麼完成，午餐還怎麼加雞腿呢？
目前的方法有下面幾種，具體還需要根據情況分析1、修改產品的icon，名稱，副標題，描述，預覽圖
2、打包的時候盡量不要用同一台電腦或者使用新Mac
3、不在在同一個IP段上傳馬甲包
4、修改銷售地區，價格，分類，上線後改到你需要的銷售地區和價格
5、也可以把已上架的App做下架處理，馬甲包過審後，再做上線處理，這個方法可能會影響一段時間用戶體驗
6、直接給蘋果打電話或者發郵件，說明為什麼要這么做
第1條是基礎，其他是輔助手段，最重要的是第6條，蘋果下架不是手段，它想知道你為什麼這么做，如果你有合理的理由，蘋果那邊會給你通過審核的。
現在馬甲包被下架的很多，現在很多都是大改，包括UI，登陸界面，iocn，描述，標題副標題，預覽圖等等，現在代碼層次修改主要是增加垃圾代碼，批註的增加，就是為了方式蘋果審核機掃層次，但是現在也有很多代碼添加了很多也會被4.3打回來，4.3還是需要大家一起想辦法的。4.3次數太多對賬號影響也很大，有很大的幾率會被封號處理。

❽ iOS馬甲包審核被拒如何過審

4.3一般存在3種情況，可以根據被拒回復進行判斷，如果你真的看不懂被拒回復，下面一一列舉，逐一排除，黑色字體是解決方案
第一種：簡稱代碼重復，代碼重復使用也有三種情況
1.可能你之前用這套源碼上過一個包，現在用這套代碼直接改一個logo跟名字再上一個馬甲，這種基本會直接4.3
這種情況基本要改源碼，第一步：工程中的文件夾的名字全部進行修改。第二步：每一個工程都有一個類前綴, 我們需要取一個長一點的類前綴, 並且這個類前綴在你的整個工程一定是一個唯一的字元串, 我們假設這個類前綴是PayDayLoan, 現在我們需要生成一個控制器, 控制器的結尾Controller也需要用一個特定的字元去代替, 比如:Director,剩下的View以及object做法類似, 就不一一介紹了,做馬甲的時候就是把這些名字用另一個唯一的字元去代替, 盡量長一點。第三步：把另一個其他的工程中的類全部導入進來, 主要是混淆代碼, 在現有的工程中調用, 可以沒有任何效果, 只是單純調用方法。
註：單一的加入垃圾代碼混淆沒用的！
2.如果你的這套源碼在一個賬號上提交過，但是被拒了，後來因為其他原因你不得不在別的賬號上重新提交此源碼，這種情況第二個賬號基本也會報4.3
這種情況需要在第一個賬號做一下處理, xcode新建一個應用, 直接用之前提交過的bundle Id打包，logo用一個純白或者純黑的圖片, 將這個新建的應用提交到應用市場, 構建版本中將之前被拒的包移除, 用這個新的應用頂替之前被拒的包, app名字改成 「作廢-此應用不再提交」 後面再隨便加一個數次, 因為這個名字別人已經用過了, app描述跟app名字一樣, 剩下的信息全部刪除.最後點擊保存即可．不需要提交審核。
3.你的源碼只要提交到itunes connect裡面，就算沒提交審核，當你再次使用此源碼提交審核的時候，基本都會報4.3
這種情況的解決方案參照2
第二種，界面功能相似
這種情況簡單的改源碼已經沒用了，需要在原有的app上加一些不同的功能，我用借貸類舉例說明該如何解決，其他類型的app可以參考
以下舉兩個應用說明, 分別用A應用與B應用代替, 你需要如何處理並且如何回復審核人員
1.A應用 是給沒有信用卡的用戶使用的一款借款App，B應用 是給有信用卡的用戶使用的一款借款App.2.A應用的最高借款額度是1000元, B應用 的最高借款額度是25000元.3.A應用的還款時間是7天與14天, B應用 的還款時間是28天. 4.A應用 內部有貸款計算器功能, B應用只是一個普通的貸款app, 並無其他功能5.兩款app是我們公司內不同的部門開發的app, 分別針對不同的用戶人群.
第三種，app名字被用過
這一種，可能是最容易被忽略的，取名字之前一定要先搜索app store有沒有同名應用，盡量避免同名應用

❾ 跪求：馬甲包上架技術，ios 代碼混淆 馬甲包過審技術！！！

從收集今年每月審核被拒原因得來的大量數據中可以看出，被拒原因 TOP3：條款 2.3、2.1、4.3（元數據、App 的完成度、重復 App/馬甲包）一直是穩定的居高不下，因此開發者們一定要遵守這三條條款，以增加過審幾率、節省與蘋果糾纏的時間，勿要存在僥幸心理，挑戰蘋果。

若想通過審核，除遵守上面幾項條款以外，在4.3問題上主要是改變二進制代碼，如果是同一個包（馬甲包）想要改變二進制代碼而對功能又沒有任何改變，可以使用幾維安全提供的安全編譯器，利用混淆的技術來改變二進制文件。

幫助過審的同時，還能利用IOS開發子團隊開發的包過審馬甲包加密混淆編譯器可安全編譯C、C++、Objective-C、Swift代碼，支持安卓 NDK和iOS馬甲包項目

支持iOS項目［APP、動態庫、靜態庫］和安卓NDK項目［SO動態庫、靜態庫］!

❿ ASO優化技巧：如何解決馬甲包審核問題

解決辦法
第一種情況：更改標題，精減字數至10字以內，如果有做多語言版本的朋友，建議每個語言版本的標題一致。 第二種情況：直接重新提交一個新包，新建個App，可以用老開發者賬號，也可以用新的；個人建議用新開發賬號為佳。
開發者發布商（用於顯示上架開發商的名字，原先大家都是按照自己開發者的名字的，我在7月2號上架成功後客戶說包不是很好，因為提審詞不怎麼樣，所以一直感覺有點對不起客戶，於是就像一塊石頭每天壓在心裏面，直到7月5號的那天我在一邊吃早餐一邊編譯的時候，突然想到這個方法，當時團隊的夥伴都以為我在開玩笑，諷刺的說你以為是某吧然後發廣告？雖然我的想法不被看好，但是我還是試著嘗試了幾次，沒想到成功了）
名字修改有以下三種操作
1.首次編輯
新賬號創建一個app，開發商在第一次操作的時候就把大量的關鍵詞和長尾關鍵詞設置好
2.郵件修改
郵件修改，需要和鄧白氏公司就行申請更改，這個是走正規路線，所以比較麻煩，不建議走。
3. 轉讓app更改
個人轉移過來，或者公司轉過來就會顯示（我這里有全新的各類開發者賬號，大家如果沒有可以找我）
注意：這2.1的操作需要公司開發者賬號必須是全新的（網路科技類型）公司賬號才可以，有過提交記錄都不可以以及個人賬號不行哦。
還有一個方案就是直接把你的公司名字改為關鍵詞！