Guideline 2.3.1 - Performance

We discovered that your app contains obfuscated code, selector mangling, or features meant to subvert the App Review process by changing this app's concept after approval to the App Store.

The next submission of this app may require a longer review time, and this app will not be eligible for an expedited review until this issue is resolved.

Next Steps

• Review the Performance section of the App Store Review Guidelines.
• Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer Program.
• Once your app is fully compliant, resubmit your app for review.

Submitting apps designed to mislead or harm customers or evade the review process may result in the termination of your Apple Developer Program account. Review the Terms & Conditions of the Apple Developer Program to learn more about our policies regarding termination.

If you believe your app is compliant with the App Store Review Guidelines, you may submit an appeal. Alternatively, you may provide additional details about your app by replying directly to this message.

本人结合以往上架经验，给出目前iOS审核被拒3.2.1的最佳解决方案及操作原则、操作步骤。

从目前来看，iOS审核被拒3.2.1的最佳解决方案就是资质、资质、资质。有资质的账号，目前是解决iOS被拒3.2.1的最佳解决方案，套壳（即做假页面）、换新账号碰运气上架等方法皆为次等方案之选，非迫不得已，不要做之。

结合这段之间的iOS上架来看，有资质的账号，必须具备营业执照（有相应的经营范围）、金融许可证，ICP证为非必须条件。此处有两种情况：

1）有资质的账号，上架时，将营业执照和金融许可证提在附件中，如顺利过审，则ICP证为非必须。

2）有资质的账号，如已将营业执照和金融许可证加在附件中，但仍被拒，此时，ICP证则为必须。

是的，你没看错，有资质的账号，有时候也不是一次必过，有时候需要多折腾几次，最终，过审的几率还是很大的，几率大于90%。

那么，在具备了有资质的账号这一条件之后，要遵守什么操作原则，具体要怎么操作，才能增加上架的成功率呢？

从操作原则上来说，不管你的有资质的账号是自己公司的，抑或是其他渠道获取来的，要遵守的原则都是一样的，没有大的区别：

1）原则一：APP内的文案及技术支持网址文案要和账号公司适配；

2）原则二：APP介绍文案、应用内文案及技术支持网址文案不要出现账号公司之外的其他公司（APP真实归属的公司也不可以）；

3）原则三：从“侵犯用户隐私，疑罪从有”的角度去规避苹果审核的风险；

以上3条原则是操作的时候必须遵守的，如不遵守，则有可能大大拉低上架的成功率。

在弄清楚了上面3条操作原则之后，我们就会进入实际操作的内容，具体步骤如下：

1）将APP内关于原来公司的文案都切换成关于账号公司的，可由技术在后台配置实现，等上架成功后，再切换回来（重点关注banner图、关于我们、公告、注册协议）；

2）将技术支持网址里关于原来公司的文案都切换成关于账号公司的，功能如步骤1；

3）如有可能，在APP首页底部及技术支持网址底部添加“copyright ©账号公司”的文案，待上架后，切换成原来公司的即可；

4）排查APP、后台及技术支持网址的文案，防止出现除账号公司之外的公司名称；

5）将获取通讯录、获取地理位置等获取用户隐私的功能，针对测试账号进行处理，使得苹果审核人员用测试账号进行APP审核的时候，不会出现；

6）将营业执照、金融许可证打包，添加在后台附件中，供审核人员审核；

7）其他提审步骤如平常提审一般。

按此上操作原则及操作步骤，操作上架，可以大大提升过审率。

关于iOS 上架的其他问题，本人也会抽时间多写写，这些都是本人多年上架的心得，希望对诸君有所助益。

总结
上面的方法都是在和苹果打游击战的时候总结的经验，当然还有一些后期维护，怎么让苹果复审的时候看到审核界面，而不是我们给用户看的真正界面，可以利用CDN把海外和国内做一个分流，当然，如果你的app是针对海外和国内都有的，那就令当别论了。如果大家看了有什么问题的话也可以给我留言，能帮忙解决的我尽量帮忙～

我是iPhone7手机

在页面跳转或者按home键进出小程序的时候,微信小程序顶部会出现一条1px的空隙,很难看.滚动一下就会自动消失.然后重复之前操作又出现了.

我研究了很久,发现我用HBX创建最原始uni-app默认模板,也是会出现.

请问有没有人跟我一样出现这情况?如何解决?

业余玩家自己开发的在线小说阅读app，算是倾注心血了吧，技术也就这样了

h5的app。开发快速，一套代码。双端上线，成本低，适合想做小说类app
刚起步的开发者或老板，待有用户后在转原生端

本人实在是没有什么ui美感，所以ui是要多垃圾有多垃圾，还在在此请教各位大神有没有什么好的
ui模板分享网站和图标分享网站

另外，此demo用的服务器很垃圾，几十块钱的，本来就是测试用的，所以网络吞吐量有限，如果网络请求gg了，不要怀疑，其实就是服务器gg了，多担待吧

此公布的为精简版本，好几个功能都删了，毕竟防君子不妨小人，h5的app，大家都懂得，所以大家在使用时
发现某个页面打不开或者某个功能无法使用，不要怀疑，就是此功能删了

此demo公布目的为大家帮忙找bug，和ui上的问题，因为本人用的iphone，所以在写代码的时候ui大部分以兼容ios为主

安卓机型就测试过几个，所以估计在安卓机型上ui匹配还有问题，当然，删除的那几个功能本人测试过没啥影响

各位找的bug可以在此贴下方留言，亦可在QQ和我反馈：QQ:2293979885

app下载地址：https://lanzous.com/ibxn9of

当然，此套源码也出售，下面放出app截图

uniapp定制开发、uniapp开发
uniapp定制开发项目
uniapp项目定制开发
1.需求明确，报价工期明确

2. UI设计图确认定稿
3. 后台搭建项目
4. 填充内容
5. 测试

自 uni-app 2.7起（2020.05.01），uni统计策略进行2项重要调整:

1. uni-app编译器将默认关闭uni统计

uni-app 2.7之前，当开发者未在manifest设置uni统计策略时，该策略为默认开启 uni统计。

自 uni-app 2.7起，包括 HBuilderX及cli，将从默认开启改为默认关闭，若开发者需要使用uni统计，请在manifest中开启。

提醒：开发者的现有项目，若想继续使用uni统计，在发布时请务必保证在manifest配置了开启uni统计

顺便也解释下策略调整的原因：目前DCloud的引擎月活已经接近10亿，而其中很多开发者并不登录uni统计后台查看数据。官方耗费大量资源采集和运算，无法对开发者产生价值。

开关uni统计，请在 HBuilderX 中打开 manifest.json ，选择左侧的uni统计配置选项，勾选所需平台的uni统计，如下图所示：

如果你不使用HBuilderX，也可以直接修改 manifest.json 源码开关 uni统计。

将 manifest.json -> uniStatistics 下的 enable 字段设置为 true 来开启 uni 统计

//...    
"uniStatistics": {    
    "enable": true//全局开启  
},    
//...

注意：uniStatistics支持分平台设置，比如若需仅开启微信平台的 uni统计，则在mp-weixin节点下设置uniStatistics ->enable即可，如下：

//...    
"mp-weixin":{    
    "uniStatistics": {    
        "enable": false //微信平台关闭统计    
    }    
}

2. 长时间未登录uni统计后台将自动暂停该业务

开发者开通uni统计后，建议定时登录uni统计控制台，查看统计数据，优化业务。

若开发者连续30天未登录uni统计控制台，则系统会暂停 uni统计的数据采集。

数据采集停止后，开发者可登录uni统计控制台，点击按钮恢复数据采集。

暂停期间，数据不再记录，历史数据不受影响。恢复后，暂停期间的数据也无法恢复。

暂停数据采集1周前，即连续未登录23天后，系统会发送提醒邮件，请各位开发者注意：

• 确保邮箱地址真实有效
• 注意垃圾箱等规则设置，确保能准确接收 DCloud 发出的通知邮件。

举例：

• 如果你最后一次登录uni统计控制台的时间为1月1日，则会在1月24日发出系统提醒邮件，经提醒后依然未登录uni统计控制台，则会2月1日0点0分0秒起停止采集uni统计数据;
• 如果你最后一次登录uni统计控制台的时间为2月1日，若当月有28天，则会在2月24日发出系统提醒邮件，经提醒后依然未登录uni统计控制台，则会3月3日0点0分0秒起停止采集uni统计数据;

效果如图所示，插件开发即将完成，到时会上传插件市场
本插件基于支付宝官方sdk开发
可选择调用支付宝沙箱环境支付
有完整的返回回调

Guideline 4.3 - Design
This app duplicates the content and functionality of other apps submitted by you or another developer to the App Store, which is considered a form of spam.
Apps that simply duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps.
The next submission of this app may require a longer review time。
4.3是什么？？？
简而言之，4.3是功能或者应用程序重复出现在App Store，跟别人已经上架的APP非常相似，以及上传马甲或者分包导致的被拒回复
我们分析一下有很多种可能，
您的应用程序提供了与应用程序商店提交的其他应用程序相同的功能集；它只是内容或语言的不同，这被认为是垃圾邮件的一种形式。
这个应用程序的下一个提交可能需要较长的审查时间，并且这个应用程序将没有资格加速审查，直到这个问题得到解决。那么，如果你的app真的是仿造别人的app，是不能通过的，可以通过修改ui界面，增加一些不一样的功能再打包提交。
你们在同一个账号下或者在其他账号下提交过这个包，如果发现你这个账号上前一个提交的包问题都没有解决，而且被延迟了，又提交了一个包，他们会特别严格的审核你的这个包，会做对比，慢慢发现是同一个包，改了一部分内容而已，直接打回，没有任何商量余地。重新换个账号新建一个app
还有可以是以下问题：
1、替换新的打包设备并进行断网打包，防止被苹果标记（4.3）
2、 修改工程 app名字：（xx.app） (4.3)
3、 添加垃圾文件和代码混淆：因为苹果扫描可能会进行API操作，建议所有垃圾代码都需要有相应的实现 过程，可以在实现类添加（4.3、2.3）
4、 避免因为第三步操作而出现2.3问题可以通过添加现有不包含第三方支付的一些渠道SDK (最好是偏大 一点的库，20M以上)来做混淆；（实践过，有一定成效）(4.3. 2,3. 3.1)
5、 修改调用链（4.3）
6、 更换服务器地址（4.3）
7、 工程里设置的info.plist里面有设置充值白名单的，eg: alipay需要删除（3.1）
8、SDK版本4.0.2不带第三方支付SDK “”
二、 资源修改 1、 修改文件结构：文件名字、文件目录（4.3）
2、 资源文件进行加密、不同马甲包使用不同的key加密 （4.3）
3、 添加多余的美术资源（20%以上进行混淆）
4、 剔除资源里面包含的（微信、支付宝等第三方支付图片）（3.1）
5、 更改登录界面，尽量显示出差异"
总结了：1，元数据方面修改思路
①修改应用程序价格，打造与原产品不同的价格级别；
②修改应用程序发布地区，打造与原产品不同的售卖地区或分不同地区运营；
③修改产品分类，打造与原产品不同的产品侧重属性分类；
④回复苹果产品设计理念等，表述产品情怀，希望打造独一无二的产品，比如功能目前会跟其他类似，会有相同情况；然后提出产品内某功能加以细节性说明，比如功能在市场上其他人还没做等等（此做法请慎重，描述好了ok，描述差了打脸）；
修改后回复内容可参考如下：
（主要表述方面侧重在于用户体验，及满足不同用户细化体验等方面）：
尊敬的苹果开发者审核，
您好，针对于贵方提出的4.3相关问题，我方目前已修改“地区/售价/分类”，主要目的在于针对不同的人群属性做运营方面的区分，我们希望给予用户不同的产品体验，包括应用程序内的功能侧重点，展现给用户的内容等等；希望贵方能重新审核，及时给予我方App通过审核并发布至App Store。
诚挚的问候！
2，二进制代码方面修改思路
①升级version，升级一个版本号提交审核；
②换bundle id，换一个包再提交审核；
③换开发者账号，换不同账号提交审核；
④修改素材及UI色调等，修改logo，修改主色调；
⑤修改功能界面等，此处可改功能可做小开关；
⑥添加垃圾代码或者注释块，此处主要防苹果机审扫描；
附：苹果的三种审核机制！
预审核—
扫描api，及plist文件字符缺失等；此处分两步，第一步为上传时苹果Application Loador等应用对于适配icon等的检查，第二步为上传后苹果的功能性检查，例如配置了Push功能但有缺失或者未打开功能，则会邮件提示等等；

机审—

此处扫描支付SDK等，及马甲情况，机器扫描主要看代码块，可参考百度蜘蛛抓取网站模块原理；如遇部分无法过机审情况可尝试加速绕过机审（不是100%成功）；

人工审核—

此处主要检测功能或者App体验测试，例如用测试账号登录App体验功能，或其他是否明显bug等，ipv6也在此处检测
尝试还是不通过加V18064099649

抛开uni-app可以开发多端，而5+App只能开发App不谈。本文只谈仅做App的情况下，uni-app的App和5+App有什么区别。

5+App是DCloud上一代产品，基于webview扩展的混合开发技术。
它的每个页面都是一个webview加载一个html页面，调用原生扩展能力时通过webview的桥通信实现。
5+App可以满足常规App的开发，并且基于html开发比较简单。但距离第一流互联网体验要求的App而言，5+App难以满足这种要求。

于是DCloud新出了uni-app。
uni-app引入了独立的jscore，逻辑层和视图层分离，并且视图层支持Webview渲染和nvue原生渲染的双渲染引擎，开发者可以做出更高性能和体验的App。

uni-app比5+App的改进具体包括：

引用独立的js引擎，将逻辑层和视图层分离，用多线程解决卡顿问题

webview是单线程的，不管多少个webview，它们的js跑在同一个线程里，会互相影响。js即运行逻辑，又操作页面渲染，经常会阻塞。

引入独立的js引擎（jscore）后，由单线程变成双线程。将逻辑层和视图层分离，逻辑层运行在jscore里，视图层仍然在webview里，可以大幅提升页面加载体验。

比如新页面动画进入时，在5+App里，需要先打开一个新webview，然后这个webview里的js代码去联网下载数据，下载数据后填充到页面，这样等待时间会很长。
但在uni-app里，打开新页面时，联网是在始终都存在的jscore里进行了，同时另一个线程打开了视图层的webview页面，它们双线程并行工作而不是串行，所以新页面内容加载非常快。

5+App要想加快新页面速度，往往需要做预载。这增加了内存占用和代码复杂度。uni-app无需预载，可以快速加载新页面。

当然引入独立的jscore也会有代价，就是Android包体积增加，一个Android的js引擎大约7M的体积。iOS由于系统自带jscore，不需要新增js引擎体积。

双线程还有一个负面问题是两个线程之间通信是需要时间的，高频通信不能像在webview里那样自由写代码，需要依靠uni-app提供的renderjs方案来解决这类问题。（react native也有这类阻塞问题，但它没有解决方案，不如uni-app）

支持原生渲染

5+App是webview渲染的，而uni-app是双渲染引擎可选。视图层可以用webview渲染，也可以用原生渲染。nvue原生渲染支持带来大量的好处，由于内容较多，本文不列举，请另行参考：nvue使用指南

原生插件系统改进和生态区别

5+App是基于Webview的js桥通信和原生能力对接的，这种做法，需要在原生层和js层编写大量代码才能互相对接起来。
uni-app是jscore和原生能力对接的，此时原生插件编写，主要是写原生代码，插件开发工作量大幅减少、插件使用也变的更加方便。
DCloud已经淘汰了5+App的原生插件扩展模式，并且为uni-app建立了插件市场，有几千款插件。
所以uni-app有丰富的原生插件生态，这对开发者很重要。选择5+App将无法享受这种生态。

底部选项卡的逻辑

5+App的启动逻辑，是先打开lauchWebview，然后由这个Webview加载页面内容和逻辑，包括创建底部选项卡。每个选项卡都是一个Webview，以父子Webview嵌套方式排版。整个应用的启动速度和内存占用都比较高。
在uni-app里，App启动时是原生先根据pages.json描述绘制底部选项卡，这个速度是非常快的。并同时打开jscore，jscore的启动时间也比Webview快很多。不同的选项卡的Webview不是父子嵌套，渲染压力和内存占用都要好很多。

软键盘优化

• Android软键盘底部灰一下的问题
  5+App的软键盘，在Android上，弹出和收起时，底部会灰一下，因为键盘移动的速度很快，而Webview的大小调节速度没那么快。
  uni-app里则没有这个问题。
• 软键盘右下角按钮自定义问题
  Webview里的软键盘，右下角按钮无法自定义为“发送”。uni-app通过提供nvue原生渲染解决了这个问题。

区域滚动长列表的体验和自定义下拉刷新问题

Webview的页面超长滚动没有问题，但区域想要长列表滚动就性能非常差了。
这需要uni-app的nvue里的list组件或recycle-list组件来解决。没有这种技术，很多优秀的交互做不出来，比如可吸顶、可左右滚动的区域长列表。
包括区域长列表的自定义下拉刷新，也无法在5+App的框架下给出高性能的方案，还是需要nvue的refresh组件。

同屏多Webview的内存消耗

5+App里经常需要做Webview的嵌套或同屏覆盖：

1. 比如要盖住map等原生组件，就需要再创建一个webview去盖住它。
2. 比如左右拖动的顶部选项卡+长列表，需要创建多个webview形成webview group才能保证体验。
   这些做法非常占用内存，并且屏幕渲染时要处理的逻辑非常多，导致渲染变慢。
   uni-app里完全没有同屏多webview并存的现象，它通过nvue来解决上述问题，一个nvue页面的内存占用要比一个webview的内存占用小太多了。

WKWebview的坑

由于Apple废弃了灵活的UIWebview，强推WKWebview，这对传统混合开发的应用造成了很大的限制。
WKWebview的跨域问题让人非常烦恼，内存不足时自动单页面崩溃（白屏）问题更是无解。
uni-app的js由于运行在jscore而不是WKWebview里，所以不存在这些问题。

uni统计

uni-app同时配套了一个强大的uni统计系统，https://tongji.dcloud.net.cn/。
uni统计可以免打点统计非常多内容，是运维的好帮手。

技术支持和社区生态

uni-app有十几万人的官方QQ群/微信群，各个群都活跃。网络上的视频教程、经验分享也更多。
5+App的使用人数比uni-app少很多，交流群活跃程度、资料丰富度都不及uni-app。

5+App的优势

虽然uni-app优于5+App很多，但5+App也有一些优势：

1. 入门简单：uni-app要求开发者必须掌握vue。而5+App只需要会html即可。
2. 包体积小，Android不需要引入7M的独立js引擎。不管Android还是iOS都不需要引入1M的uni-app基础组件框架
3. 5+app的Android最低版本支持到2.3、iOS最低支持7。而uni-app的Android最低是4.4、iOS最低9。事实上Android4.4是2013年发布的，更低版本的手机在市场上基本没有市占率了。

所以DCloud的建议是，除非你只会html但不会vue，也不想学vue，且对App的性能体验要求不高，不需要扩展原生能力，或者必须要支持Android4.4以下的手机，那么可以使用5+App。其他场景则应该使用uni-app。

简明易懂的前端算法面试教学，接地气&说人话&大量图解，带你从编码基本功到手撕大厂真题、构建坚不可摧的算法能力体系。

详细问题描述

页面在onShow中延迟启动扫码框，当延迟时间比较小的时候，bug出现：在开启扫码框后，点击返回，扫码框退出，返回到本页面，再次返回，返回主页面，在这时，无法再次进入页面。
但延迟时间大一点，这个问题就消失了。

async scanQrCode() {  
            let _this = this;  
            let status = await _this.checkPermission();  
            if (status !== 1) {  
                return;  
            }  
            uni.scanCode({  
                onlyFromCamera: true,  
                success: function(res) {  
                }  
            });  
        },  

onShow() {  
        //页面载入执行扫码  
        var _this = this;  
        setTimeout(function() {  
            _this.scanQrCode();  
        }, 300);  
    }