昨晚微信悍然发布了微信「小程序」，也就是之前微信自己和各方频频提起的「应用号」。《微信应用号小程序内侧：微信是一个操作系统、一个AppStore吗？》，张小龙在朋友圈这样说：
什么是小程序：小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。
我读了神的这条朋友圈之后，第一感觉是，这不就 H5 么，或者，这不就是 Web App 吗？以龙哥的谨慎和对创新的苛求，此举应该必有深意啊。为了不露怯我小心翼翼的和二爷探讨了这个问题，二爷说，窝也是这么认为了，为了不甘心平庸，他又在朋友圈发了一条这样的消息：
小程序在获客、留存、频率和能力之间提供了一个新平衡，重点是它处在什么环境，而不该孤立地去看它提供的特性。另外微信会把哪些现有的东西（比如朋友圈？关系？）引进小程序也是一个关键影响因素。
最终还是需要回归到用户场景和价值。
产品经理嘛，总会说些大家看不懂的话。
冯大辉老师也在第一时间写了一篇「微信公众号来了」，聊聊几百字简单介绍了小程序的功能，居然阅读过百万，想来真是令人发指。这一点充分证明了，没工作思想就是自由！（貌似冯老也订阅了 MacTalk…）。
那微信小程序，仅仅是 Web App 么？不一定。
Native App 和 Web App 之争由来已久，就像当年的PC 上的软件和浏览器之争一样。本地应用最大的优势就是对硬件资源的利用更加淋漓尽致，基于系统级别的 API，Native App 可以做出性能、设计、效果和流畅程度远远超过 Web App 的软件和服务。所以，在我能看到的未来，Web App 不可能完全取代 Native App，取代程序员就更是天方夜谭了。但是，对于很多创业者来说，也许 Web App 已经能够解决你 80% 的需求，如果增强型的 Web App，比如微信「小程序」，是否可以解决剩下那20%里的80%呢？有可能。
「小程序」常常让我想到 Java 最早推出的 Applet，也是嵌在浏览器里的应用程序，可以利用本地系统的一些特性。微信小程序差不多如出一辙，只不过环境变成了微信及其生态系统。这次微信推出的小程序，提供了丰富的框架、控件和系统调用能力，包括并不限于：框架、视图、各类基础控件、表单、多媒体支持、地图、画布、WebSocket、数据存储、位置信息、设备信息（包括系统信息、重力感应、罗盘等），这些能力最终都会以 JS SDK 的方式开放出来（我猜的）。想象一下，基于这些能力，对于互联网服务来说，已经可以做出超过现有 Web App 的功能了。当然，技术和框架永远只能做最基础的源动力，要做出真正打动用户的产品和服务，还需要创业者自己具备足够的想象力和执行力。
以前人们做互联网创业，要做网站；做移动互联网创业，要做 App；现在创业，如果是互联网服务方向的，最好的办法是先用微信的服务号或订阅号试试自己的创意是否真正解决了用户的痛点。有了「小程序」，这一步也许可以走得更远，从创意 Demo 直接做成产品，也是非常可能的。用户在哪里，就要去哪里提供服务，而现在，用户和用户的时间，都在微信上啊。更多微信解读：www.yangfenzi.com/tag/weixin
当然，类似京东、淘宝、亚马逊等大型电商，知乎和各种阅读类应用，各种工具类软件，都在各自的领域内属于高频应用，依然需要独立的 App。但现实也是很残酷的，独立 App 的推广成本实在是太高了：知道了不一定下载，下载了不一定使用，使用了不一定继续使用，继续使用的也不会购买你的增值服务……
世界就是这样，留下来的永远是最坚韧和把大部分事情都作对了的创业者！
有了「小程序」是不是大家都要一窝蜂的去做前端呢？没必要，无论前端多么牛逼，总要云端技术支持才行，否则就是无源之水，无本之木。所以，Java、PHP、Go、Lua 都是很好的技术栈，该写什么继续写什么吧。退一步说，如果大家一窝蜂去搞前端了，你留在后端领域，还是稀缺物种了呢。
无论技术，还是人生，都像河，会一直往前流淌，我们不能一直缅怀过去，也无法茫然的期待未来，只能抓住眼前的机会。如果你准备创业，或者正在创业，至少应该关注一下「小程序」了。
补一句，T3 会发布的，憋问了，好好看文章
豆瓣在互联网历史上是一家「独立存在」的公司，我很喜欢。2014年8月8日，豆瓣的创始人阿北说，我们今天发布了一个叫做「豆瓣」的新应用，我们希望它以后是所有人手里的「豆瓣」。
如今这个 App 的版本到了4.2，相比原来的版本，4.x 突出了更为多样性的内容，我喜欢这个版本，用它在豆瓣记录了一些书和电影的相关信息。点击原文或者长按二维码下载，在 App 里搜索池建强可以找到我。
【文/池建强MacTalk（微信号：sagacity-mac）】
·氧分子网（http://www.yangfenzi.com）延伸阅读：
我是微信服务号微软小英的开发成员。作为一个在微信服务号H5页面的开发中有一年多经历的团队，我们对应用号的推出还是非常期待的。在之前服务号的开发维护中，对微信公众平台我们可谓是爱恨交加，但总体上是一个很好的体验。
我们团队是以创业的心态做微软小英这个产品的，之所以选择微信服务号就是因为我们觉得它有助于“创业”的成功。下面我先分享一下我们的经验，然后再回答题主的问题，不然干巴巴说没有味道了。
爱：作为一个聊天对话学英语口语的产品，微信是我们目前的最重要的入口，无论从会话窗口的对话体验，到JSSDK的语音功能支持。微信平台为我们提供了一个跨平台的能力和口碑式传播的可能。从目前为止的情况来看，粉丝们通过公众号的名片分享和功能分享，是我们用户新增的一大来源，在此也顺便感谢关注使用和分享微软小英的所有用户们一下。另外，微信公众号的文章推送，数据统计等等功能也对我们的产品运营和用户研究很有帮助，也节省了我们很多的后台数据统计分析的时间成本。
恨：之所以说爱恨交加，其实是根据人的心理特点更容易记住痛苦的事情，所以在开发中遇到的一些问题，踩的坑更令我们记忆深刻一些。比如跨平台这个事情，我们最对不起的是Windows Phone用户们，由于WP的微信支持不足导致广大WP用户体验不了微软小英的特色功能，我们开发团队束手无策，除非自己些native app才能解决，另外安卓和iOS下面也有许多小的兼容性问题；微信录音采样率低也导致我们的先进语音识别评测技术还不能完全发挥出来。
可能对于很多类型的应用来说，服务号的体验不像语言学习这么有契合点，所以服务号貌似还不太像订阅号那么火爆（个人感觉）。看起来应用号小程序的适应性会更广泛，所以可能会吸引更多的创业团队加入开发大潮。个人觉得至少有两个问题微信需要解决才能让应用号成功，一个是怎么才能让H5页面有native app接近的流畅度，保证用户体验；另一个是H5页面的发布监管问题，开发者怎么能保证自己的app不会被微信封掉，有没有审核机制？用户怎么能保证自己安装的应用不会被开发者乱搞一通？H5的webpage是host在开发者这一端的话会比app store的模式要复杂得多。
说了一堆有关无关的话，现在来好好回答题主的问题，个人感觉应用号的出现给了广大创业队伍一个新的平台选择，接触用户，试错，快速迭代的机会可能会很多了；但是创业成功与否于平台的优劣关系并不是太大，因为竞争对手也能享受到同样的机会，关键还是看你的产品能不能满足用户的核心需求，解决痛点并且有靠谱的商业模式。宣传推广成本可能会降低一些，耐心打磨产品的重要性变高。当然，web前端工程师的发展前景应该会变得更好了
传说中的微信应用号终于开始内测了，名称是微信小程序，倒是符合张小龙一贯谨小慎微的产品风格。坊间也有未经证实的传闻，说这个名称是腾讯与苹果妥协的结果。无论最终名称是不是小程序，微信在吞噬用户和创业者的时间这件事上，野心却是一点也不小。
中国的互联网创业者是比较苦逼的一群人。做App的需要维护十余个安卓发行渠道以及适配N种主流机型；做O2O服务的烧钱望不到尽头，因为总有后来人捧着巨额筹码企图踢你出局；做内容的需要维护公众号、微博、今日头条、百家号等多个主流内容分发渠道。。。微信作为拥有覆盖华语移动互联网用户、日活惊人的超级App，是做C端产品触达用户绕不开的一座大山。现在微信宣布做应用号了，你做不做？不做，不甘心失去一个潜在用户入口。做，又是一笔开发和推广开支在对你狞笑。
我想大多数像我一样的创业者，已经在盘算应对策略了。这摊浑水，互联网创业者到底要不要蹚？我想从几个方面，分析一下微信应用号的风险所在。
大家要清楚一件事：微信是流量黑洞
微信建立在熟人的封闭社交关系之上。用户相互交换信息的方式只有两种：点对点交流以及微信群内交流。在社交场合或者其他社交产品中，用户建立关系的标志是互加微信，于是各种社交关系最终沉淀到了微信，这是微信竞争力最基础也是最重要的一环：社交流量黑洞。
基于这种模式的一切上层建筑，其信息流转方式都必须符合这种业务逻辑。微信公众号创立的本意是为企业搭建微信账户，形成客户关系管理平台。然而在微信的产品策略下，大量内容创业者从微博迁移到微信平台，把公众号做成了媒体号。但这里存在一个问题，即由于前述的微信社交流量是封闭的，则借助社交关系流动的、包括公众号在内的信息，都无法如微博一般自由扩散。于是内容创业者为了扩大受众规模，要么炮制标题党鸡汤文线上分发，要么线下推广，常见方式就是把二维码到处发放张贴。微信二维码本质是把线下流量转为线上流量，而这个线上流量，首先是属于微信的。这是微信的第二大黑洞：内容流量黑洞。
更要命的是，微信除了对自家的关联应用，对外并不开放社交关系链授权，这也是微信与同属大型社交网络的Facebook最大的区别。于是，无论是通过社交关系链吸引用户，还是挖空心思宣传公众号吸引订阅，用户和创业者帮助微信完成了原始的用户和活跃度积累。以张小龙为首的微信产品团队被舆论神化，我觉得也有一定的道理，但微信的优秀之处，是其封闭的业务模式设计，恰如黑洞或者貔貅之类。其产品的表现层，六年如一日地老龄化和过时，当然这是另一个话题了。
在这种只进不出的产品逻辑之下，应用号的用户增长效果，应该是打个大大的问号。并且，内测期间应用号的入口放置在“我”之下的二级菜单，是比较搞笑的，用户不会闲着没事跑到这里来翻应用。如果微信下决心开放更多应用号展示入口，将应用号嵌入微信的常规使用场景，效果会有所不同，但这又带来了一个问题，应用号五花八门，如何放进微信的高频场景而不显得突兀？这无疑是个棘手的问题，应用号理性的做法是会在相当长时间内保持单一入口，所谓的应用号红利期快速“涨粉”也无从谈起。毕竟说到底，所有的toC的生意，都是流量生意。如果一个平台不给你导流反而利用你提升其活跃度，那么很大概率上这不是一个好的创业平台。
微信在公众号和朋友圈运营策略上的强势，会在应用号上重演
微信以保护用户体验为名，对公众号及内嵌H5的强力封杀，相信很多创业者是领教过的。不可否认这里相当一部分死得不冤枉，但随着应用号的面世，我们不得不思考一个问题：微信的价值观，是否应该超越自身的范畴，作用于别的企业？
如果说公众号和H5由于以内容为主，勉强还可认为是微信的附属品，那么应用号则由于可提供（近似？）完整的线上用户服务体验，应该视为与原生App没有区别的应用个体，代表其运营方的全部心血而不只是宣传或者客服单元。但，恕我无法寄望于微信对应用号的管理措施会和公众号有所区别。微信从一个超级App进化到了准OS，如果没有针对这种角色变化重新制定管理规则，做到苹果App store审核流程一般明码标价、公平执行，那么作为应用号的运营方，头上常悬一把不知道是剑还是炸弹的东西，实在是太刺激了。要知道，苹果或者任何安卓应用市场把你下架了，你的存量用户并不受影响；一旦微信应用号把你下架了，那么。。。画面太美，容我哭会。
别忘了还有苹果老大哥在背后
据说，仅仅是据说，腾讯此次推出应用号与苹果达成协议，不会提供游戏和直播类的小程序。然而，来日应用号一旦壮大，且通过微信支付短路了苹果的分成收入，只怕苹果翻脸是分分钟的事。毕竟一旦开了这种头，这老大哥的位置，还能坐多久呢？商业利益一旦受损，苹果突然翻脸，微信会如何应对？到时候城门失火殃及池鱼，应用号的玩家们应该何去何从？
我腹黑地想，也许苹果从一开始就会把应用号扼杀掉。毕竟，光是一堆App的数据通过一个App流转（超越沙箱机制），由一个App审核和管理（超越App Store），这件事就足够猥琐了。在苹果和微信之间，我还是比较相信苹果的节操和正义感。
创业者何去何从？
有的朋友可能会说，你说了这么多，我们还不是一样要进驻应用号平台么？我不开发App，只开发应用号，这是节省了我的创业成本啊！
希望大家清醒认识到，壁垒降低的结果，是更多人会参与进来。如今大家对于风口和红利的追逐，已然超越了有枣没枣打一杆的境界，变成是不是枣树都乱敲一通。应用号的发布，在我看来，恰恰宣布了纯互联网创业时代的结束。比起明知是碗热翔还要捏着鼻子吃，我们还有个选择，就是趁早离席吧。
但愿微信通过后续的作为，证明我上边所说的，都是错的。
如果APP都消失了，
那微信该何去何从？
QQ又该如何面对？
支付宝又会如何抉择？
真正影响最大应该是苹果公司，截止到2015年8月，中国区苹果开发者数量已超1000000，而2014年8月中国区开发者数量还不足50万。
一个苹果开发者账号，99美元/年
100万开发者，100万x99美元/年
当APP面临消失时，苹果的开发者是不是也会随之下降呢？
进而，会不会导致iPhone的销量下降呢？
或许，今天微信之所以以微信小程序的形式出现，并不是偶然，而是被苹果公司狠狠的摆了一道。
苹果公司有着完整地生态链，所有的非越狱手机，APP下载途径都是App Store，同样，微信想要在所有的苹果用户都安装上，必然要向苹果公司低头。
微信要是想要断了APP的路，就得要让想要安装微信的苹果用户都越狱，显然这是不实现的。
苹果公司当年对Android就采用了一种招数，如果想要在App Store上架的APP里不能带有Android的Logo、标志和字眼，一下子开发者们提交版本都变得小心翼翼了。
据小道消息称，微信应用号之所以改成微信小程序，只因微信与苹果达成协议：
微信不能以应用号推广，所以改名微信小程序
微信小程序不能开发游戏类、直播类功能
微信小程序每个人最多只能关注20个
无论是否属实，APP不是一个时代进步过程中会灭亡的产物，他会结合更多地场景、以更多的方式出现在人们的面前。
微信订阅号偏自媒体
微信服务号偏向售后和营销
微信应用号对于微信而言更像是APPstore 应用市场
对于商家而言 增添了一波红利
对于用户而言 微信更占内存 体验会差一点
对于创业者而言，赶快在审核机制不完整 ，大家觉得好新鲜的时候，赶快弄一个大新闻，才是适合创业的行动家。
赶快做一个运行速度快，超级好玩，震惊寰宇的一个应用吧。
比如
《民主引领中国》
《赶快从梦中醒来》
等你火了，就有人供养你哦！
说是微信新推出了微信小程序。这名字听起来倒是蛮有点小清新的感觉。其实就是之前一直神神秘秘的应用号。只是换了一个更接地气的名字。
由于现在只是内测，只发出了100个内部测试资格。老卢，作为一个普通的技术人员，没有拿得出手的公众号，自然是没有这个机会了。但这并不妨碍我们对小程序的期待和热情。
微信小程序是啥？
简单说，它就是一个可以实现之前只能是原生态APP可以实现的效果和功能。比如说，一些酷炫的页面与转场，一些可以直接和手机硬件交互的功能，录音啊，拍视频啊，调用手机的重力感应啊，GPS啊等等。
这在之前的网页开发中，是不可想象的。这里能想象的空间太大了。
设想一下，有了微信小程序，你可以开发一个滴滴打车的功能。利用GPS，可以知道司机在哪，乘客在哪。程序可以就近给乘客安排司机。完成交易后，再利用微信支持接口完成支付。
当然要简单实现功能不难，怎么做好细节和用户体验，怎么能在激烈的市场竞争中胜出。这个比技术实现本身复杂太多。但至少微信小程序给了我们这个期待。
再比如利用手机重力感应模块，我们可以利用HTML5开发一些有意思的小游戏，比如赛车啊，打球啊，之类的。
微信小程序要革谁的命？
在推出微信小程序的活动上，微信创始人张小龙说，我们并不是要成为应用的分发平台，而是希望能给微信里那些优秀的公众号提供更好的技术，让他们能给粉丝提供更好更优的服务。
但话说回来，微信小程序若能成功，微信这个本身就是个超级的APP平台，就是个应用分发平台了。
很显然，很多APP技术开发公司麻烦大了，他们不可能一个APP开发，就要价数十万，狮子大开口了。当然他们也可能 一夜之间，向微信小程序开发转型。这个难度几乎是没有的。
而且微信小程序的开发需求远大于原生APP。
另一个受到较大冲击的是那些传统的网站建设的技术公司。其实老卢之前2年多时间也一直是从事这方面的创业。而且最近一两年，客户的需求也在向移动端，如微信公众号的二次开发靠拢。
这次微信小程序的推出，应该更会激发客户对微信公号的开发热情。
所以从长远讲，不管是APP还是网站建设类技术公司，利还是大于弊的。因为微信小程序在很多方面，确实比网站，以及APP更有优势。
微信小程序相较于网站，APP优势是啥？
网站这里特指传统的，在电脑上打开的网站。我们都知道，早在三五年前，移动端的用户就超过了电脑端。但由于某种惰性，技术开发人员直到这一两年才缓过神来，开始重视移动端。
传统的电脑上看的网站，自然不方便在手机上看了。而且手机用户花在手机页面上的时间并不多。他们大量的时间都花在于APP上。但我们都知道，手机的屏幕是有限的。我不可能一个应用，一个需求，就装一个APP。
于是要么把自己最急需的，最常用的一些需求的APP装上，看新闻，装一个今日头条，网易新闻啥的。那些不急，不常用的，就让超级APP来代替。比如看看八卦，学习下行业知识等，订阅一些公众号就行了。
从目前来讲，APP比手机网页好，手机网页比电脑网页好。手机网页在电脑上看起来还行，但需要我们输入网址域名，这在电脑上还好操作，在手机上，简单是让人抓狂。
虽然APP在体验上非常突出，但需要安装，需要消耗流量，占用手机有限的桌面空间。这种麻烦程序，甚至超出了APP的优势本身。
就到这里，你自然知道了微信小程序的好了。
1，不用安装，即开即用，用完就走。省流量，省安装时间，不占用桌面；
2，体验上虽然没法完全媲美原生APP，但综合考虑还是更优；
3，对于小程序拥有者来说，开发成本更低，他们可以更多财力，人力，精力放在如何运营好产品，做好内容本身；
4，对于用户来说，相较于各种APP，微信小程序UI和操作流程会更统一。这也会降低用户的使用难度；
5，对于小程序拥有者来说，相较于原生APP，推广更容易更简单，更省成本。
1）APP下载的简化，自动升级，自动安装等等已经大幅度降低用户使用难度
2）开发成本不是主要考虑因素，互联网公司主导了APP时代，对于拿到VC钱的创业公司来说，同时开发安卓、iOS的成本根本就不是大问题
3）用户体验为王的时代，Web App无论如何都差Native App太多，没有一个好的创业公司愿意牺牲用户体验
4）浏览器和搜索入口的弱化，由于过去几年培养的用户习惯，大部分用户的第一反应应该不是通过浏览器和搜索来发现业务，而是想去下载APP，浏览器和搜索更多回归到其本身核心功能（访问网站和搜索信息）
5）技术总监、程序员们是不会放弃自己的iOS和Android特长的，客户端开发高大上，Web开发矮挫穷，HTML技术就在客户端里面偶尔包装一下解决一些内容类服务快速升级的问题好了，Web技术只能作为一种辅助开发技术而不是客户端的主流开发技术
6）渠道推广的便利性，开发Web App哪有那么多渠道曝光度呢？又要SEO又要花钱买位置，和App渠道的各种免费推广曝光（如苹果推荐、小米商店的新品首发等等）差太远了
7）WP太糟糕了，如果WP强势，那会造成要开发三种客户端，这个确实不少中小公司就要掂量掂量了，WP这么差，大家都很开心，直接忽略好了
综上所述，这个已经不是纯粹技术问题，涉及用户感知、体验、渠道、开发者的所有生态环节，所以结论就是：在移动互联网时代，App为王基本不可逆转了。
未来其他或许有机会，如智能硬件、家居、电视什么的。
理由如下：
1、在apple的教导下，目前是大家使用手机/pad的主要形式是native app。
2、往长远看，下载、安装app是一个成本极大、极不人性的操作流程，未来一定不是app的天下。目前的native app只是受制于设备和网络链接质量，对用户体验保证的一种过渡解决方案。
既然说的是未来，那对未来的设定就远一些吧，毕竟这样胡扯起来比较有快感。。
说实话，我认为目前移动端以app为主导的用户体验非常糟糕而弱智，但以目前科技水平又无法突破，所以不得不采取的一种折中办法。大家可以试着回忆一下app使用经历，早上起来打开天气，查看今天的天气状况，之后返回桌面点开新闻客户端浏览当天最新资讯，正聚精会神的时候突然有个好友发来信息，你不得不切换到聊天软件回复，之后再返回客户端，将刚刚被打断的注意力重新集中回来，突然又冒出一个淘宝的打折促销推送。在移动端对app进行多任务操作对用户来说简直就是噩梦，就算单独使用一个软件，也时常被其他app不重要的通知给打断。
app体验如此不好，但是在当今时代又如此火热的原因我认为是因为技术限制实在没有更好的选择。但是，也并不用感到悲观。毕竟任何事物总是在不断进步，新事物代替旧事物，就像蒸汽机解放了手工劳动力，然后又被电气取代。app作为信息化时代初期的产物必然有存在的道理和一定的生命周期，但是绝对不代表未来。
未来有可能需要承载服务的设备会越来越少，用户完全不需要通过主动下载或者安装去获得服务。身边任何媒介都能获得服务，服务过程真正的退到幕后成为了隐形人，服务的最终结果成为自然而然的事情，世界又回到互联网未出现之前一样，大家真正关注的是人和世界本身。
原生应用仍是入口，HTML5会覆盖更多低频，长尾，跨App场景
1. HTML5(或Web App) 会覆盖更多 低频、简单交互的服务
举个例子，楼下面馆，近期就推出了自己的点菜H5站点，扫描二维码就可以打开餐馆的网站，选个面，点下单就OK了。 这种场景App是没法做的，你让用户在这种场景去下个8M大小的App么。很多人就来这个面馆一次，而且你让我点餐前还得下个App，我还不如叫服务员呢。
2. HTML5会接入更多的App，作为App间内容和服务打通的桥梁
这个看我们的微信朋友圈就知道了。第三方应用分享到微信的按钮应该也是标配了，分享到微信中的网页不仅仅是内容呈现，还包括一些简单的服务，比如嘀嘀打车的抢红包。
3. HTML5会接入更多的App，丰富App的长尾和低频服务。
还记得神经猫小游戏么，正式众多这样的小游戏，小web app丰富了微信的生态体系，但是这种现象级的小东西用App来做，就是杀鸡用牛刀了。
可能并不是Native App和Hybrid App之间的问题，LZ想问的已超出了App的范畴。移动端服务的载体有很多形式，可穿戴设备，多屏互动都是未来的方向。现在软硬件甚至传统媒体都在寻求多屏上的展现形式，用以形成立体的方式包围用户。可以在这些触点思考和用户连接的方式。
236个APP，大学四年没什么特别的爱好（工科女），但是会琢磨很多好玩新潮的APP，因此毕业时候谋得一份互联网 产品经理的职位。
因为工作原因➕个人爱好，所以会不停的更新手机的APP。
不要问是一种什么体验，因为手机是为自己服务的，我把每个APP都按照自己的想法分类好，遇到问题时候可以很快找到对应的APP帮我解决，这就够了，这就是极方便快速高效的体验。
没错，并不是每个都会经常用，但是我可以保证，我有需要的时候不用去找再去下载，提供的方便不止一点。
没有什么特别的体验，唯一的惊喜就是发现了iPhone上最多只能放15页App，再往后你下载的App就看不到了！！！真是一个奇葩的设定。。。
为什么我会留这么多App在手机上？一是因为我是个搞iOS开发的程序猿，看看别人家的东西可以学习一下吗；二是因为，我有「删除App恐惧症」！即使八百年没打开过的App我都不太敢删，特别是工具类App，总觉得说不定明天我就得用到它！
最爽的是，没事的时候，精神比较放松的时候，我会把之前下载了但还没打开过的游戏一个个玩一遍，把玩的不爽的都给删了，这时候就有一种朕正在批奏折的感觉吼吼吼
发现自己变得让人感觉更靠谱、更细腻、更有趣、更享受生活。
红包发在#微信#，零钱扣在#支付宝#，帐记在#Spendee#
说走就走靠#去哪儿#途牛#携程#艺龙#嘀嘀打车#格瓦拉#…，吃货离不开#美团#大众点评#食色#宅急送#饿了么#…
所有的灵感记在#备忘录#里，将要做的记在#Tassky#里，私密记在#Day one#里
静则#Flipboard#知乎##Zaker#poe#，燥则#Tinder#陌陌#遇见#Zank#
用#Enlight#美化照片显逼格，用#9Cut#处理图片发状态，用#美拍#记录生活，用#Heyday#回味生活
平时听#网易云#，偶尔听#美乐时光#，睡觉听#TaoMix#
一个人玩#Tap Titans#，两个人玩#TEN#，四个人玩#King of Opera#，一群人玩#疯狂来往#
总有些重要的人的生日要记在#生日管家#，总有些难忘的日子要记在#最美时光#
用#世界迷雾#留下自己的脚印，用#Sphere#欣赏未知的远景
装了232个 App，其中至少40个我会经常（一周至少打开一次）用到。
另外还有一些属于偶尔会用到，以防万一就留着了。
剩下的属于新 App 我想试试/好漂亮以后留着做参考。
我从第一代 iPhone 就开始用，但是直到 6 之前却从来都是使用的最低内存的版本（8G & 16G）。最开始还好，4s 之前不太需要考虑内存。但是到了 5 和 5s 时 16G 就已经捉襟见肘了，好多时候需要经常删除/下载/删除/下载/这么重复。
所以到了 6 我自然而然选择了 64G 版本，终于解决了怨念，（几乎）安装了自己的全部应用。
经常有人问我说你安装这么多应用干什么啊，其实我本人却并没有觉得我安装了多少，现在依旧保持着一周几个新 App 的速度在增加。
之所以感觉不多是因为在我的观念里，iPhone 早已脱离了手机最原本的属性，而成为了「生产力工具」。很多时候 iPhone 也是我会唯一携带的生产力工具，丝毫不能马虎。加上我是 Native 派，基本很少使用 Web App，所以这就注定了我手机里的 App 不会少。加上程序员都有的好奇心，有新 App 不试试也不可能。
如果真的仔细用的话，其实维持几十个常用的 App 是完全有可能的。比如我的社交工具，零零碎碎每天能用到的差不多就有十个了（我除了回答问题很少用电脑，电脑还是干活用）；修图一般一款应用肯定不够，也要多种合在一起；新闻也不可能只看一家的推送，所以选择 SmartNews，Economist 和日报这样的比较省时还方便；干活用的 App，那自然不必说肯定也要天天打开——这么一算我每天已经差不多要开20多个 App 了。然后总有些 App，属于「关键时刻型」，比如离线地图（Here），SPG 还有恶心的支付宝这类，其实打开的频率也不算低。这样综合下来，其实常用的 App 数量挺高的。
作为一名程序员加半吊子入门设计师，干活的重要一步就是研究新的 App（比如最近在试 Meerkat 和 Periscope）。从一款 App 的 UI 到交互再到内容和逻辑，也是不可能下了看一眼就知道的，必须留在手机里多用一段才可以评价。试用结束后，我一般容量不够之前也会一直留着；每次更新文档也都会看，有吸引我的地方就点开看看。
还有一些最特殊的情况，就是同一类别的应用，一款不够用：比如音乐的话，iTunes，Spotify，QQ音乐三者我里面的歌曲是不一样的…所以我也没办法只留下其中一个。还有 Kindle, iBook, Readmoo 这种互为竞争对手的，逼得我不得不都放在手机里啊。
最后就是些一个月用一次反正地方够就留着吧系列的 App：Telus 这种运营商应用，交电话费；各个航空公司还有酒店的 App，平时肯定不用但是需要的时候可以方便不少；还有各类邮政 App，查快递~
总结一下，超过 100 个 App 什么体验？方便。
/如果你是一位设计师或工程师，提升自己的能力最好的办法就是从学习那些优秀的应用开始；
如果你是一位设计师或工程师，为了保障自己将来的利益，自身做起来带动身边的版权意识是一件应该做的事情。
当然，你不需要花那么多钱。适量的购买加上关注合适的时机，每个月200块你就能体验到很多优秀的产品了。而200块也许你只能出去聚餐吃一次饭，买一件衣服。
现在有很多渠道能够帮你发掘到优秀的apps，关注打折信息。「Pinapps」或许就是其中不错的渠道之一。
H5还是Native。
你有Native的工程师，就做Native的。
你有精通浏览器的工程师，就做H5打包的。
等哪天你App量起来了，有钱了，能招募了一大波开发人员，再来做指点江山的事。
题外话，在微信这个移动端的事实浏览器面前，最短平快的试水方式是做微信内传播的H5应用。利用微信这条渠道，好东西会快速得到分发，收获种子用户。
百度UC不是要搞轻应用么，微信不声不响给你做了出来
HTML4，
Java, Java Applet
Adobe Flash,
MS Silverlight,
Xamarin,
PhoneGap
哪个不是想解决跨平台问题？
这玩意业内有个名字，叫“silver bullet”。这是一个希望单一解决方案完美解决所有问题的美好梦想。当然，从来没有被实现过。
HTML5永远也不可能超越原生app。跨平台解决方案不可能优于原生解决方案，否则那就是银弹了。历史上银弹从来就没有出现过。
早两年都H5是嗤之以鼻，特别是有些人叫嚣APP已死，H5才是未来。不知道这些人钻哪里去了。
H5要发威当然必须得指望游戏，现在流行的那种H5宣传页面，就是PPT玩剩下的东西，花里胡哨，不能形成商业模式。H5想牛逼当然必须搞游戏了，但不要指望跟Native去硬拼，必须发挥自己轻量化的优势。
我觉得商用wifi的portal页面可以成为H5一个发威的场景。这种比app更加轻、更加碎片化的使用场景如果能通过某个方式积累起来，将是很巨大的。比如chinanet的登陆页，没账号的用户为什么不可以让他玩上面的H5游戏呢？占用几个流量？每天多少PV被浪费了？玩爽了想下载native版本，作为游戏分发渠道，难道还心疼送用户一点流量？
oogle把那么多东西开源，但是有“兼容”过吗？
微软甚至把.net开源了，但是有“兼容”过吗？
苹果至今作为一个最封闭的大佬，代码有自己的系统用自己的规则自己定，不要说“兼容”了，连开放都不肯做。
为什么？
因为他们都有一颗想独吞市场的心。
所以html5最大的优点在他们看来是缺点。
你跨平台了，寡头用什么来绑定用户？
你跨平台了，寡头用什么来培养用户忠诚度？
你跨平台了，寡头用什么来做自己的平台增加粘着性？
这种东西的推动根本动力是什么？是屌丝平台的贡献。而屌丝的力量始终是有限的，因此短时间内html5肯定没戏。就算将来有戏了，几个巨头也会各自有一套标准或者各自有一套更有戏的不兼容的东西。
—————————————————————
评论里有人提到了java和php之类的语言跨平台。
但其实java和php以及html5本质上是不同的。
1.html5是标准，委员会只负责订标准，不负责在所有的浏览器上添加实现html5的功能的插件。
2.java和php是某种语言，分别由oracle和zend tech来实现各个平台上这种语言的解释器。
oogle把那么多东西开源，但是有“兼容”过吗？
微软甚至把.net开源了，但是有“兼容”过吗？
苹果至今作为一个最封闭的大佬，代码有自己的系统用自己的规则自己定，不要说“兼容”了，连开放都不肯做。
为什么？
因为他们都有一颗想独吞市场的心。
所以html5最大的优点在他们看来是缺点。
你跨平台了，寡头用什么来绑定用户？
你跨平台了，寡头用什么来培养用户忠诚度？
你跨平台了，寡头用什么来做自己的平台增加粘着性？
这种东西的推动根本动力是什么？是屌丝平台的贡献。而屌丝的力量始终是有限的，因此短时间内html5肯定没戏。就算将来有戏了，几个巨头也会各自有一套标准或者各自有一套更有戏的不兼容的东西。
—————————————————————
评论里有人提到了java和php之类的语言跨平台。
但其实java和php以及html5本质上是不同的。
1.html5是标准，委员会只负责订标准，不负责在所有的浏览器上添加实现html5的功能的插件。
2.java和php是某种语言，分别由oracle和zend tech来实现各个平台上这种语言的解释器。
APP井喷式发展，用户手机内存容量有限，html5的长尾应用已经越来越广了，无论是浏览器、微信、手Q，还是一切带webview的APP应用，都有html5应用场景，必定会有所发展。
但是html5在体验上依然稍逊于native app，它还需要一场技术革命，比如：手机系统、浏览器内核技术的支持，再比如，我国的运营商……
html5的发展趋势将越来越快，其技术也日趋成熟。到html5只是一个标准，就跟arm标准那样，标准保证了平台兼容，至于标准的定义更是大巨头互相妥协的结果，妥协就意味着缺失。html5标准接口跟本地原生的接口根本都不是一个量级。即使再怎么接近原生也无法百分百取代。
比如apple自产的metal引擎，号称性能全面压制opengles3（正因为标准达不到苹果的性能设计要求，所以苹果才自研），你觉得这个引擎你能在html5里面用到？另外从网络安全的角度也不可能让html5过于强大，你手机随便打开一个黑网站，岂不是通讯录，短信都被抓取？
iOS有可能没有什么感觉，但是Android感觉很强烈。
这种强烈的感觉就是非！常！卡！
本来以为亲儿子不会遇到卡的问题，但是在安装到大致120个应用的时候，明显有了一定的迟钝。
从视觉体验上来看，就是可以任性的按照颜色排软件，按功能排软件，按字母来拍软件，甚至可以把应用排成一句话（谁让大家都开始把一个字当成icon名呢）。
从使用体验上来看，就是上述说到的，卡，即时是原生OS；不过在升级到5.1之后似乎有那么几个瞬间感觉不那么的卡了，也是奇怪。而好处说来就多了
吃个饭：饭本找找特色餐厅，大众点评看看菜，美团买买团购券；
看电影：豆瓣找找最近上什么片子，评分如何，格瓦拉、猫眼、淘宝比比看哪个票价便宜；
下雨要回家：3公里以内用滴滴，滴滴没券了，用快的，3-5公里用一号专车，5公里以上用uber；
叫外卖：饿了么最近好像有券，啊，那家没入驻，那找找淘点点，或者外卖超人；
看视频：爱奇艺好多综艺！搜狐好多美剧！腾讯娱乐八卦多多多！土豆AB站有动漫！
以上仅仅是生活中的一些缩影，虽然没有那么夸张，但是其实生活慢慢的开始依赖这些APP，久而久之，手机中就常驻了这些APP，然后慢慢朝100+的应用发展。
每天无聊地跟内存做斗争
如果不是这个问题，我都不知道自己已经装了那么多APP了。日常使用感受是各种生活情景都能找到相关APP应对。但是经常使用的一些估计也和大家差不多，其他的有些是拿来体验的，有些是因为设计的特别漂亮精致的，有些是拿来参考学习的。
慕小七 为人性癖耽佳句，语不惊人死不休
谢不要我要回答正正好好一百个app2333
汤雨豪 CS专业学生
更新超多呗，2天更新了15个。
每天最少下载一两个比较有意思的APP体验。现在手机超过150APP（不好玩没意思的马上删）。体验就是，用谷歌原生的系统（不用什么启动器桌面什么的。）找APP真是个麻烦啊官方途径下载兼容旧版iOS的应用，我这几天才发现的方法：
1、找到你想要下载的应用，在电脑端itunes的应用商店（或其他已经升级到iOS7、8的apple设备）下载。【目的就是让这个应用进入你的已购应用列表】
2、在iOS6（或更老的，我没试过，只试过iOS6）设备上打开app store，然后点更新-已购项目-找到你要下载的软件，点击下载，就会发现弹出可下载最新的兼容版本的提示，然后下载之
如果通过正规渠道即通过app store下载的话，不太能，或者说看运气。有些软件在你系统版本达不到要求时会自动弹窗问你是否要下载一个旧版本，这样你就下到了，不过这种提供旧版本的并不多，就我所遇到的只有podcast和kindle的iOS客户端这两个（并不是说只有这俩，其他的兴许也有，只是我没遇到），其他的不行就不行了。
非正规渠道的话，可以通过同步助手等其他类似的软件下载，它们会提供旧版本给你，不过这样下载到的软件会闪退，虽然通过同步助手这些软件可以修复，但挺烦的，不想折腾。
我的目前也是保持在iOS6.1.3没有升级，越来越多的软件都不能用了，但好在主流的都还可以，所以我经常会去“屯”软件，把一些可能会用到的趁着还能下载赶紧下载下来，否则日后也会需要更高系统版本而下不了。
在电脑的iTunes 上获取相应的软件，下好之后再从手机打开iTunes ,最右的更新，点已获取的软件，点不在本机上的，再点下载，此时提示你现在的系统版本低，是否下载对应的app ,点是，等待完成就好了。如果是移动端, 视数据的重要性来定, 如果不重要, 那就忽视它. 如果重要, 就要额外做一个检查Documents(我这里假设你的数据文件放在Documents下)下的数据文件, 如果存在, 就SQL导出再加上按照新的数据结构导入到新的数据文件. 也就是两句SQL的事, 在升级后第一次进入应用的时候做这个事.
如果是服务端, 正常情况还是需要做接口层(当然, 我也遇到没做接口层, 直接远程数据库操作的, 对这种, 我无话可说), 接口层的变动幅度, 往往没有数据层的变动大, 有时候, 哪怕数据结构变化了, 但接口层还是一样. 如果是碰到数据层变化逼迫接口层变化的情况, 那就需要保留老接口的同时, 提供新接口服务, 直到使用老接口的app保有量低到一定程度, 再关闭老接口. 我的产品接口, 是在接口中加上一个v(version)参数作为版本判断标志.
豆瓣上的女孩都生性薄凉，微信上的女孩都住在泽西岛，知乎上的女孩长相都中等偏上，QQ空间上都是抽烟喝酒骂人纹身的好女孩
马云在微信上送给年轻人十句话，在微博上被逼捐款，在QQ空间上不小心暴露了自己的QQ号
豆瓣上的照片要逆光，微信上的照片美图秀秀白，知乎上的照片要凑够1000赞才能解锁
豆瓣上的笑容嘴角上扬，微信上的笑容点名挑战赛，知乎上的笑容蛤蛤蛤蛤，QQ空间上10亿人都笑了，赶紧转了吧
豆瓣上的婊子会被骂伪文青，知乎上的婊子会被骂这都有男朋友，QQ空间上的婊子会被艾薇儿看穿
微信上的文章看完要买面膜，知乎上的文章看到最后会有二维码，QQ空间上的内容看到最后男孩会沉默，女孩会流泪
青鸟殷勤为探看，码农年薪过百万。
脚上鞋儿四寸罗，学历起步藤校博。
西风岂是繁花主，高考堕落九八五。
欲与天公试比高，不如三本二幺幺。
山河自古有乖分，大家来看我健身。
十三学得琵琶成，励志早起背英文。
玉人浴出新妆洗，房价十万才合理。
朱帘绣柱围黄鹤，留不下是你卢瑟。
孟云归去不留痕，知乎提问看黄文。
春来江水绿如蓝，大清吃枣试药丸。
倚楼无语理瑶琴，全球公审穆斯林。
汉皇重色思倾国，却道知乎一片膜。
漏腿千人赞，露脸不给看；
三言两机灵，不看你滚蛋；
个个都有帅爸，人人曾经美妈；
健身的会做饭，码字的爱捣蛋；
没毕业的谈人生，云淡风轻；
三十岁的单身狗，岁月静好；
年薪五十万，我该怎么办；
月入三两千，租房好好干贴吧：一切不以交友为目的的回帖都是耍流氓，签到和抢沙发最能体现一个人的逼格
豆瓣：一切不以约炮为目的的顶贴都是耍流氓，文艺和加小组最能体现一个人的逼格
空间：一切不以转载为目的的看帖都是耍流氓，鸡汤和非主流最能体现一个人的逼格
微信：一切不以代购为目的的发帖都是耍流氓，微商和超链接最能体现一个人的逼格
知乎：一切不以集赞为目的的拼贴都是耍流氓，谢邀和公众号最能体现一个人的逼格
贴吧的互动性非常强，你的问题总能得到回答，我学英语时在翻译吧问的问题都得到了回答，放在知乎这根本不可能几乎没人鸟你，知乎的缺点显而易见，知乎不欢迎菜鸟，你从知乎的排版就能看出来。知乎系统不完善你的评论很容易被其他评论淹没，但系统不提供定位你评论的功能。
知乎的答案非常详细，这是我喜欢知乎的原因，用户素质平均值高，但很多答案华而不实。
豆瓣就是文艺青年聚集地，普遍崇洋媚，绕大圈说话，再举点没听过的国外例子，表示自己思想境界高，与众不同，大家都这样搞。
再说跟风，豆瓣和知乎跟风最严重，比如代购问题，关系好买个东西也不行?人就问代购什么地下一水的让他好好旅游。好心提醒就行了别老跑题。豆瓣跟知乎差不多大多假理智。贴吧跟风没豆瓣知乎厉害，有啥说啥，但吵起架脏话看着揪心。
知乎豆瓣用户非常会包装自己，甭管啥答案绝对给你扯到:他去过国外，照片绝对欧美风，天衣无缝大美人。
再说文章，知乎文章真心不长，长文章都是天涯转来的，答案也能说到点儿上。
贴吧可以叫水吧各种15字，好文章也有，都藏在海里，广告很low。
知乎充满正能量，每个人都努力让自己变得更好。豆瓣的人应该活的非常精致，或假装精致的人。贴吧什么人都有。
再说说骂人，知乎用户也骂人，但不直接骂，绕着圈侮辱你，你还没法直接骂他，会被举报。
豆瓣得得顺毛摸，心眼小，刁钻，看你不顺眼骂的你心疼。
贴吧就豪放多啦，sb，cnm满天飞，弄得乱七八糟。
说说购物，贴吧，豆瓣，知乎里边都有购物推荐，但知乎和豆瓣里边东西死贵死贵，华而不实，其实那种东西一辈子用不了几次就丢仓库了。还得说嫌贵去淘宝，淘宝是low逼我觉得说这种话的多半是学生要不就是不会生活的要不就是托只有一小部分是大款。
知乎和豆瓣用户喜欢给自己贴金子，说有的问题太幼稚直接百度就好了，自己却回答比百度还幼稚的问题。
知乎贴吧豆瓣用户也是人，本质没有不同，见到美女都会像哈巴狗一样，也都希望博得大家关注，满足虚荣心。
不管是知乎豆瓣还是贴吧，他们只是工具，不是你的
港湾，要善用好工具哦，比如知乎的历史地理文章图文并茂而且非常详细，数据分析也到位，豆瓣的影评非常好，贴吧互动性非常强，他们都有不错的购物推荐让你眼前一亮，但自己要会找。
豆瓣影评界聚集着很多才华横溢之辈，写出的影评有趣且意义非凡。好影评不是枯燥乏味的数据分析，也不是电影台词的摘抄本，更不是无病呻吟的梨花体，而是电影分析与文学写作的完美结合。这部分核心用户创造的优质内容，吸引了更多新用户加入豆瓣。
豆瓣初始就是一片空白，各种图片，评论，文章都是由用户一步步添加而来的。自己亲手做的东西往往更会让人有一种成就感，所以用户对豆瓣有着一种额外的归属感。豆瓣用户黏性特别高，也愿意在这个平台上创作影评，与友邻分享电影。
豆瓣最开始的那个时候很多有个人意识的人都在玩博客，新浪搜狐博客巴士等等。
影评这个东西很神奇，它来源于电影和个人感悟。
一般是观众在看到某些场景或人物时感受到了某种重合从而产生的评论。
当时的用户从博客发展到社交网络的过渡很自然。其实他们什么都没有意识到只是觉得在这里有更多人能够看到自己的感悟。比自己博客的效果好，有互动，所以就来豆瓣写了。
越多的互动和讨论，就越粘人。久而久之博客或许不写了。但是豆瓣是一定要去的了。
当时可选的平台很少，新浪博客被名人占领着，其他博客没有影响力，时光网的资料很全，但互动氛围很差。
在豆瓣上，你可能会因为一篇写了很久的影评，跟一堆人成为网上的朋友。
当时豆瓣的民意更加真实，其他的电影平台基本都是资料库。
但是10年左右，水军多起来，骂战多起来，影评中的枪手多起来。
我已经很久没正经写过影评了。偶尔写几句短评，也是在豆瓣。
当时可选的平台很少，新浪博客被名人占领着，其他博客没有影响力，时光网的资料很全，但互动氛围很差。
在豆瓣上，你可能会因为一篇写了很久的影评，跟一堆人成为网上的朋友。
当时豆瓣的民意更加真实，其他的电影平台基本都是资料库。
但是10年左右，水军多起来，骂战多起来，影评中的枪手多起来。
我已经很久没正经写过影评了。偶尔写几句短评，也是在豆瓣。
有次经过一个菜市口，看见竟然在卖某个品牌的内衣裤进去看了看质量都不错，还打折。但是我没买，后来去逛街，在百货商场看见了同样的牌子，而且不打折，可是明显生意是要比菜市口的那家好，这其实也是一个经济的案例，就像商业圈形成的某某一条街。本人就粗糙的概括为一条街理论吧。人往往有先入为主的观念，就像买电脑的一定会去电脑城，买菜的一定去菜市场，不会有人追逐一个街边小贩的（除了城管），买春的呢，一定是去烟花之地啦（哈哈），但是烟花之地的小姐真是世间尤物吗，在我看来卸下脸上的石灰粉，估计还不如街上的素人，但是他们打响了招牌，不管你进去了消不消费，首先它把你拉进去了，进去之后能抽身而出是本事（我也是豆瓣粉，一直没解毒），出不来是正常，然后进去的人不甘寂寞了，继续号召广大人民群众，然后前赴后继，前赴后继，前赴后继，吸收了更多更优秀的人才，猪也是靠不停吃饲料长膘的嘛。
我是公司的CEO，但同时也是航班管家的产品经理，让我用这个目前市场上占有率最大的手机商旅应用来做个例子，说明一下我们是如何考虑web app和native app的：
1）两大核心功能：机票查询和航班动态，全部是native app，主要是为了保证速度和稳定性，因为这时候的用户对效率很敏感。
2）辅助的服务功能：我们还提供诸如“机场登机口导航”、“机场商家地图”、“航空公司服务”以及“酒店查询”等功能，这些功能由于暂时不是用户的最基本需求，同时在业务上调整和增加的内容要求很灵活，所以我们采用内嵌web网页的方式来实现，将用户引导进入我们自己和其它第三方的网站里。这些功能都统一放在“实用工具”的分类里。
3）创新型功能：在一季度末，航班管家会推出“机场漂流瓶”以及“航班同乘人”等准社区服务，这都是基于web，并已经开始采用html5的一些方法，希望能够达到两个目的：在体验上接近native app，开发上具备更多的灵活性和跨平台性。
综上，作为一个移动互联网的应用开发商，我们更倾向于看重以html5为未来的趋势！
Web App从实现角度是不是可以分为几种：
直接使用移动设备浏览器使用；
使用本地封装Embed Browser来调用Web接口
使用Web技术（HTML，JavaScript，CSS）直接构建本地应用
从这个角度讲，后两种很难分清Web和Native的区别，由于HTML5的支持以及现在JavaScript/CSS/DOM等性能和稳定程度越来越高，他们的表现不一定会跟Native差别太大。
从开发者的角度来看，他们对技术的选择还是要依赖于自己的习惯、开发经验和工具，而基于Web技术的开发工具和各种lib也在完善中。而最关键的是，使用Web技术最大的好处就是跨平台。
话说回来，跨平台和Native也一直是争论的焦点，:)
总的来说，融合是趋势。但目前来说，Native app仍然是高品质产品的首选。
就好像Facebook iOS版本的开发者Joe Hewitt说的： “I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won’t wait.”(我十分想再一次成为Web开发者，但是如果浏览器到2020年才能做到Cocoa2010年就能做到的事儿，我不愿等待。)
1. 偏交互的Native，偏浏览的Web：交互指复杂操作，输入/选择什么的
2. 已稳定的Native，试错中的Web：H5页面用来做低成本验证很好
3. 访问硬件Native，信息展示Web：指手机里的各种传感器什么的
4. 核心功能Native，周边辅助Web：把工作量多投在刀刃上
5. 当时有5点，我实在想不起来了。。
Mobile web的月UV领先mobile app（8.9M vs. 3.3M）：
Native app用户每个月花的时间是mobile web用户的18倍（201.8分钟 vs. 10.9分钟）。不过要注意，native app的使用时间里，有近80%是花在了某3个app上。所以也要考虑自己的产品有没有潜力进入top3，还是会是在长尾里，去跟许许多多的app竞争那剩下的40分钟（201.8分钟*20%≈40分钟）。
接下来看功能和成本，mobile web和native app算是各有千秋。先说说Mobile web的优势：
搜索引擎入口。苹果的app store搜索众所皆知不好使，Google play store或者其他第三方的安卓商店我不是很了解，但如果一个产品是内容主导的，可能很多流量是来自搜索引擎，这也可能是mobile web访问量更多的原因之一。
即时更新。如果做native app的话，每次版本更新从审核、上架到用户更新是有一个时间间隔的，很有可能用户懒得更新，就一直运行着一个很久很久以前的版本，接触不到新版本里的功能。如果ship的版本有问题的话，大量用户可能直接就流失了，不像mobile web，有比较快的补救的可能。所以一般来说，mobile native ship的标准会更高。
设计和开发成本。Native app要为不同的平台进行设计和开发，有不同的规范和语言，mobile web在这方面的工作量会小很多。
Native app的优势：
可以调用web不能调用的硬件、或者有更好的硬件体验，比如：
摄像头
麦克风，前两者现在html5均可调用，但是体验不如native，而且跨浏览器兼容性也比较麻烦
加速度传感器
屏幕（常亮）
如果有产品的核心功能会涉及这些硬件，为了更好的用户体验和留存率，可能需要开发native app。
可以使用一些非常重要的OS功能，比如
推送通知，不过要注意的是，31%的用户几乎从来不允许app给他们推送通知
但也要看具体是什么app，比如Uber之类的ride sharing app就比较容易获得用户的允许（数据来自：New data shows up to 60% of users opt-out of push notifications (Guest Post) at andrewchen）
获取用户的地理位置：相比推送通知，用户对地理位置使用的接受度还是比较高的
离线使用：如果你的产品涉及到大量视频和图片，在国内流量有限的现状下，可能需要允许用户将媒体文件保存到手机上，以供离线使用，这时候web就爱莫能助啦
个性化内容：这一点比较有争议，因为mobile web也不是不可以做到，但因为app可以不用反复登陆，而且能够记录用户的点击和浏览行为，所以可以更准确地进行内容定制，这一点期待有更多的讨论~。
另外，native app相比web，有着更快的反应速度、更好的性能，因为mobile native直接与操作系统对话，而web app和操作系统之间还隔着一层浏览器。
总结：如果你想做一个企业名片之类的东西，让更多人知道自家产品，那也许一个网站就够了；但如果产品核心功能只有native app才能提供，或者你想要确保用户有更好的体验、更强的黏性，那可能就需要做native app。
*引用的文章数据来自ComScore《The 2015 U.S. Mobile App Report》，有兴趣的话可以去看看，56页的ppt，信息量很大。
native优势：1.在用户体验度上平均在说更加稳定 2.更能让用户记住，用户留存率比较高
劣势：1.开发成本大（因为一个版本的功能出来很快就能做出其中一部分让内测人员体验。而等我们全部做完了，已经过去一周了。然后提交给苹果审核，又要等一周。再等个良辰吉日发布，就过去了20天了。与此同时，我们有做出了更多的功能，调整了多处细节，还修复了几个bug–但用户只能再等几十天才能体验到了。而且还有的用户就是不升级。虽说我们能强制用户升级，但毕竟影响用户体验了）
2.分发的成本高（native的平台太多-主流的就有ios、android、windows三个平台，每个平台上的运营、推广都有不同的规则，三个平台就得适应三种玩法。）
web优势：相对与native的劣势：一个功能做好了就能上线，一天更新几十次都毫无压力。如果客户端只是个浏览器，那一切都会变得很简单。另外web统一性高，跨平台适用时开发量少。
劣势：由于其入口不明显（浏览器导航或者随意点击链接进入），让用户记住的门槛也随之拔高，每次推广导入的流量都可能沦为一次性努力，用户留存率低。
相比较的两者可以相互结合相互补：其实有不少的团队他们这两种模式都做了。他们先在web app上进行新版本测试，而后反哺native app的更新。或许现阶段手机浏览器的书签功能以及保存至蹦迪的功能还未被大多数用户所熟知习惯时，native app在桌面上的品牌形象还是创业者们无法舍弃的。
另外其实相对于浏览器、微信所带来的趋势是不可忽视的。根据百度的移动互联网趋势报告显示手机浏览器的使用时长还在逐步下降，相比之下有更高使用时长的微信导流能力更强，根据之前流出的微信5.0版本，微信公众账号已经有了web app store的雏形了。而且公众微信找好呈现出很强大的表现能力，技术也没有很多人想象中那么初级。
总结趋势：
native app：更多存在的是一些用户常用的垂直领域的app（就如同我们pc端的快捷方式）
对于一些使用频率不高的app，整合或许才是他们未来的出路。微信、百度的light app平台甚至是手机桌面上的搜索框等、都是整合的方式之一，做到用户有需求时能尽快找到即可
随着随着html5、浏览器的规范统一他也将在web app呈现出很多的表现形式，到时会有更多的web app会在手机浏览器上展现
项目是做H5游戏的平台，然后是上头领导的点子，所以也就下头跟着尝试做做看，不行就撤，这不，4次迭代就无限期暂停了这个项目。
一说到Web App就不得不说到H5，当H5出来的时候Web App才有的说。13年下半年还去参加了H5峰会，请了好多大公司的人来上台讲解H5是多么多么好，百度的工程师还现场为我们演绎了一个神奇的Web App， 不得不说如果App这么做，很多工作都可以从中解放出来了。虽然有各种专家出来演讲，但是场内的气氛一直都不是很活跃，最后到了抽大奖（乐视TV和各种平板） 的时候才开始火爆起来 = =。
所以即使是那么多专家在上面巴拉巴拉不停的说H5多么多么牛，但是大家仍然感受不到H5的好，仍然很迷茫，甚至我都觉得上面演讲的都有一些迷茫，这种迷茫度过了2013，走过了2014，迎来了2015。
为什么迷茫呢？
其实就是H5每天都在鼓吹的那些东西实际上到底有没有落地实现，这个有很大很大的一个疑问。这种情况一般开发者都只会做一个demo玩玩而已。另外一个就是性能，说到底，为什么现在APP仍然是Native大行其道？即使很多产品本来就有页面的，比如知乎，但是他还是要做客户端原生的App，为什么呢？原因还是Web App的体验不好，或者说小的效果，普通的东西可以实现，但是稍微要求高一点的东西性能就下去了。
举个例子，在原生的App上，一个类似页面滑动切换的效果，Native上，反应时间绝对是毫秒级别，不会感受到延迟，你手指只要开始滑动，页面就无缝的跟着滑动，但是Web呢？大家应该都经常去看微信里面各种H5的花哨分享页面吧，那个滑动能神流畅吗？反正我的小米就不行。
这只是一个小点，如果说整个应用都用H5来实现，那么很多基础的组件会遇到这种情况。很典型的是，一个按下态的效果，原生的效果是你按到了一瞬间就会显示，没有延迟，但是Web的往往会有肉眼可见的延迟，这一点带给用户的就是感觉这个按钮“很黏”，点的感觉不好。
再有就是有些特效再花哨一点，那么Web就吃不消了，这一点更加放大就是Native的游戏和H5游戏的对比，到现在，H5游戏还是只能做很简陋的游戏，而Native已经可以完爆H5了。这也是为啥会存在Egret这个H5用的游戏引擎，其加速的核心思想就是把Web的绘制转换为Native的绘制。当然这里说的是App，默认题主想问的是轻量级的而不是游戏，游戏也没啥好说的，性能一栏就卡死了。
除去上面几点，还有一点是开发者的心腹大患。你页面写东西快了，爽了，开发效率高了，但是这些东西都是浏览器在跑，很多东西不受你的控制，比如说你要定制缓存机制，对不起，浏览器没那么高级的缓存机制。比如说你要定制内存回收机制，这个我还没去了解浏览器的内存回收能不能自己做，这个也很难。但是原生代码里，你可以尽情的去发挥你的想象，想怎么玩就怎么玩。没有做不到只有想不到。但是最终给用户带来的是良好的体验。比如你的App要联网，要下载大的图片，那么你可以规定图片下载的规则，带来流畅度和用户数据流量的优化。如果你的数据都是网络获取的，你可以把最后一次拉取到的数据缓存下来，这样用户下次打开的时候，可以先看到原来的数据，不会一直去等你的网络拉取完成才能看得到数据，也不会因为没有网络而看到的是整块的白板。
还有一点，就是Web端的API对于本地文件的权限的问题，虽然我不做Web前端，但是也明白前端的代码不能轻易触及文件的直接操作，那么好了，你的一些文件操作将会变的麻烦，这些带来的是开发中的坑，这些坑肯能就会让你的开发周期变长，任何不可预期的变长在商业产品中都是要避免的。
假设，你的Web App终于用最新的H5实现了，用户体验也很好，你也比较满意，但是慢着，你觉得浏览器不会坑你吗？我遇到不知道多少Android上浏览器内核崩溃的问题，基本都河很难去找到真正的原因。另外还有大概8%的用户使用着Android2.3的版本，你觉得你的应用能很好的在2.3的浏览器和硬件上跑吗？
虽然Native同样面临着相似的问题，但是往往人们都不太愿意做第一个吃螃蟹的人，或许哪天一个H5的App能表现的超越Native的时候，那可能将会是一个里程碑。至于现在，大家还是深深的观望，观望，然后埋头继续写自己的Java代码。程序员当然都希望自己能够开发效率够高，绩效高，奖金高，然后迎娶白富美走向人生巅峰。
这个和2年前讨论是否SaaS（Software as a Service) 才是趋势，是不是差不多呢？混合还是不混合，都取决于本身应用的产品设计。我不知道定义上Native app是否指不需要网络一样工作正常的app？还是说整个界面只要在本机开发运行而不是通过webview界面的，都算native app？我自己觉得，一个计算器，显然就是native app最简单，飞机上我也能算算报销；但飞机落地后我用地图察看当地最新的团购，就显然是web app才更方便。
Native App的优势：
1.提供最佳的用户体验，最优质的用户界面，最华丽的交互
2.针对不同平台提供不同体验
3.可节省带宽成本
4.可访问本地资源
5.盈利模式明朗
Native App的劣势：
1.移植到不同平台上比较麻烦
2.维持多个版本的成本比较高
3.需要通过store或market的确认
4.盈利需要与第三方分成
Native App开发
Native App开发即我们所称的传统APP开发模式(原生APP开发模式)，该开发针对IOS、Android等不同的手机操作系统要采用不同的语言和框架进行开 发,该模式通常是由"云服务器数据+APP应用客户端"两部份构成,APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。
Web App的优势：
1.开发成本低
2.适配多种移动设备成本低
3.跨平台和终端
4.迭代更新容易
5.无需安装成本
Web App的劣势：
1.浏览的体验短期内还无法超越原生应用
2.不支持离线模式(html5将会解决这个问题)
3.消息推送不够及时
4.调用本地文件系统的能力弱
Web App开发
Web App开发即是一种框架型APP开发模式(HTML5 APP框架开发模式)，该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部 分，而应用的数据则是每次打开APP的时候，去云端数据呈现给手机用户。
其实现在已经慢慢有趋势，普通的创业团队难做native app了，原因是招人贵，适配的机器多，Ios和各种安卓系统都够折腾死了。
另一方面，手机上浏览器浏览一般的网站，体验已经不差。以我个人而言，使用UC浏览知乎，觉得真心比用知乎的APP体验好。
你只要做一个web app，招人方便，前端人才遍地，另外轻松适配各种手机。
所以长期看，还是更看好web app，这个趋势，会跟当年PC端是一样的。
发布于 2013-07-20 7 条评论 感谢 分享 收藏 • 没有帮助 • 举报 • 作者保留权利
4
赞同反对，不会显示你的姓名
丁超 对于求知，永远是呼之欲出的态度
4 人赞同
1、技术角度：web app 的平台载体大部分是浏览器，依靠html5，但是由于不完善、规范不统一等，相比Native app , 后者的交互体验将得到更好的发挥。即便运用Hybird ，也由于内核支持性能差，如果遇上要求较高的应用，操作起来，也会很多bug；
ps：身边一个前端工程师说：“运用html5，对浏览器要求高，倘若浏览器支持力度不够，那么应用加载慢，会是用户体验最大的诟病”。
2、用户使用角度：对粘性不高，但是碎片时间会使用到的应用，比如：移动搜索、应用推荐、网址导航，web app 相比于Native app 更符合用户习惯。比如用手机查询搜索，大多数用户首先还是倾向于点击浏览器，而不是下载一个百度***；
3、微信时代：这个是微信霸占移动终端入口的特殊年代，微信不仅带来社交和关注，还充当了浏览器，web app 在其的限制也比浏览器要少；
场景：关注***公共账户，在微信内打开推荐应用，享受服务，既增加公共账户的功能扩展，又能带来增值效应，比如电商购买商品；
从工程师的角度看, 当然希望web app是主流,让广大的工程师从一个又一个的native app中释放出来,去做更多有意义的事情. 记得访问facebook cto关于11年的开发重点的时,就着重了html5, 他也提到现在为了维护一个facebook的mobile version, cost很大, 不同的platform至少一个, 就算是苹果一家, ipad和iphone也是两个app, 我没做过android app开发,不知道android不同version,是不是开发也有差异(写到这句让我想到了android岂不是mobile os中的ie…悲剧). 另外, web app的流行也依赖于其他技术的成熟, 当仁不让的就是html5, 怎么让offline的用户体验用好用顺很重要. 而且我想如果web app dominate的话, 是不是手机的ram和cpu的利用率会更好些, 此点属于瞎扯.
但是从现状来看, 目前肯定是native app是主流, 不得不承认, 现在的大部分web app太难用了, 甚至没法用. 前几天还见到reader上有人分享了一个可以把web转成android app的应用, 间接的说明web app实在是太难用了.
前几天Techcrunch上还有一个激烈的讨论，是说google的应用转向native是webapp将失败的一个证明， 我觉得融合是一个真正的趋势， webapp+native的融合，现在越来越多的APP开发的趋势， 当然以html5为基础的webapp目前还有不完善的地方， 浏览器支持的API不够多， 调试工具的缺乏，都导致了webapp不能迅速的普及。Native的优势不言而喻，但问题就在于不能跨平台，开发成本高。对开发者来说，选择自己适合的， 小快灵的往前走就好了。
如果web app增加2个功能就完全可以和native app进行PK：
1、不用安装插件可以调用本地设备硬件和文件API
2、将网页的快捷方式放在启动栏或者桌面
关于Web App和Native App的争论一直没有停过，前段时间翻译了一篇文章，还没有翻译完，但是看了好几遍，很长的文章，不妨在这里整理一下里面的观点。
英文原文在这里：http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
当然还有一篇反驳的文章：http://danbricklin.com/log/2013_06_19.htm#jsspeed
这里我只说说第一篇文章中说到的一些观点，供参考。
========分隔君==============================================
作者在一开始提到了一个衡量标准：SunSpider
我们会发现在移动设备上JS的性能。
之后作者测试了原生代码和JS代码的性能差异，一个已有的测试基准：http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=v8&id=2&data=u32
发现LLVM保持了比Nitro快了4.5倍。
x86的结构对于ARM架构，更加适合于运行JS，请看对比数据。
作者加入了自己的iPhone 4S进行了对比。
ARM架构的程序必须保证10倍的性能提升才能和x86平台的进行对比。
从硬件角度，因为ARM发展的限制，期待摩尔定律来拉伸这部分的性能损失不太现实。
软件角度，文中说Jeff Atwood提到：
I found that the performance of JavaScript improved a hundredfold between 1996 and 2006. If Web 2.0 is built on a backbone of JavaScript, it’s largely possible only because of those crucial Moore’s Law performance improvements.
JS的性能这几年并没有大的提升，即使有也是得益于摩尔定律。
下面作者有引用了大段的“证据”说明JS“Not designed for performance”。
最后谈到了我们都知道的就是JS的垃圾回收机制，没有一个有效的垃圾回收机制。
还有就是JS的内存占用问题。
回归本质就是编译语言、JIT、解释性语言性能的讨论，对吗？
以上。
争论Web App和Native App那个是趋势其实是没有意义的。这只是技术方案不同而已。一个产品要预见到技术发展的趋势，做好两手准备。不要纠结于一个能调本地API一个要运行在浏览器里这些细节。凡是技术能解决的问题都不是问题。
其实不论哪种技术方案能够赢得未来，App这种服务形式才是趋势。App是对URL的革命，是对搜索引擎的革命。服务App化的趋势是阻挡不了的。
iOS 的 App 内普遍使用了 UIWebView 。而 Web App 在发展通过 JS 调用本地功能的技术。
所以相互融合是趋势。
赵瀚卿 CoreThink/OpenCMF/众筹/OTA/商务/PM
关于Web App以及非原生APP的开发，我司研发整理过这样一份表格，针对国内常用的三种框架：ionic/mui/freamwork7做了一个对比，我认为还是比较详细的，有问题欢迎交流，版权属于我司：南京科斯克OpenCMF－领先的互联网积木式云平台，作者为我司研发张玥同学。
分久必合，合久必分。操作系统提供商不会坐看维护的生态环境被他人窃取。
PC时代就有类似的问题
先是native的，之后出现web应用，两者共存，渐渐倾向于web，这之中网络环境、计算机速度提升占很重要的因素
现在移动开发，先从native开始，但现在越来越多的应用使用web，或者混合架构
同样有合还要有分，跟中穿戴、车载、智能家电发展起来后，又是native天下
其实现在已经慢慢有趋势，普通的创业团队难做native app了，原因是招人贵，适配的机器多，Ios和各种安卓系统都够折腾死了。
另一方面，手机上浏览器浏览一般的网站，体验已经不差。以我个人而言，使用UC浏览知乎，觉得真心比用知乎的APP体验好。
你只要做一个web app，招人方便，前端人才遍地，另外轻松适配各种手机。
所以长期看，还是更看好web app，这个趋势，会跟当年PC端是一样的。
发布于 2013-07-20 7 条评论 感谢 分享 收藏 • 没有帮助 • 举报 • 作者保留权利
4
赞同反对，不会显示你的姓名
丁超 对于求知，永远是呼之欲出的态度
4 人赞同
1、技术角度：web app 的平台载体大部分是浏览器，依靠html5，但是由于不完善、规范不统一等，相比Native app , 后者的交互体验将得到更好的发挥。即便运用Hybird ，也由于内核支持性能差，如果遇上要求较高的应用，操作起来，也会很多bug；
ps：身边一个前端工程师说：“运用html5，对浏览器要求高，倘若浏览器支持力度不够，那么应用加载慢，会是用户体验最大的诟病”。
2、用户使用角度：对粘性不高，但是碎片时间会使用到的应用，比如：移动搜索、应用推荐、网址导航，web app 相比于Native app 更符合用户习惯。比如用手机查询搜索，大多数用户首先还是倾向于点击浏览器，而不是下载一个百度***；
3、微信时代：这个是微信霸占移动终端入口的特殊年代，微信不仅带来社交和关注，还充当了浏览器，web app 在其的限制也比浏览器要少；
场景：关注***公共账户，在微信内打开推荐应用，享受服务，既增加公共账户的功能扩展，又能带来增值效应，比如电商购买商品；
从工程师的角度看, 当然希望web app是主流,让广大的工程师从一个又一个的native app中释放出来,去做更多有意义的事情. 记得访问facebook cto关于11年的开发重点的时,就着重了html5, 他也提到现在为了维护一个facebook的mobile version, cost很大, 不同的platform至少一个, 就算是苹果一家, ipad和iphone也是两个app, 我没做过android app开发,不知道android不同version,是不是开发也有差异(写到这句让我想到了android岂不是mobile os中的ie…悲剧). 另外, web app的流行也依赖于其他技术的成熟, 当仁不让的就是html5, 怎么让offline的用户体验用好用顺很重要. 而且我想如果web app dominate的话, 是不是手机的ram和cpu的利用率会更好些, 此点属于瞎扯.
但是从现状来看, 目前肯定是native app是主流, 不得不承认, 现在的大部分web app太难用了, 甚至没法用. 前几天还见到reader上有人分享了一个可以把web转成android app的应用, 间接的说明web app实在是太难用了.
前几天Techcrunch上还有一个激烈的讨论，是说google的应用转向native是webapp将失败的一个证明， 我觉得融合是一个真正的趋势， webapp+native的融合，现在越来越多的APP开发的趋势， 当然以html5为基础的webapp目前还有不完善的地方， 浏览器支持的API不够多， 调试工具的缺乏，都导致了webapp不能迅速的普及。Native的优势不言而喻，但问题就在于不能跨平台，开发成本高。对开发者来说，选择自己适合的， 小快灵的往前走就好了。
如果web app增加2个功能就完全可以和native app进行PK：
1、不用安装插件可以调用本地设备硬件和文件API
2、将网页的快捷方式放在启动栏或者桌面
关于Web App和Native App的争论一直没有停过，前段时间翻译了一篇文章，还没有翻译完，但是看了好几遍，很长的文章，不妨在这里整理一下里面的观点。
英文原文在这里：http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
当然还有一篇反驳的文章：http://danbricklin.com/log/2013_06_19.htm#jsspeed
这里我只说说第一篇文章中说到的一些观点，供参考。
========分隔君==============================================
作者在一开始提到了一个衡量标准：SunSpider
我们会发现在移动设备上JS的性能。
之后作者测试了原生代码和JS代码的性能差异，一个已有的测试基准：http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=v8&id=2&data=u32
发现LLVM保持了比Nitro快了4.5倍。
x86的结构对于ARM架构，更加适合于运行JS，请看对比数据。
作者加入了自己的iPhone 4S进行了对比。
ARM架构的程序必须保证10倍的性能提升才能和x86平台的进行对比。
从硬件角度，因为ARM发展的限制，期待摩尔定律来拉伸这部分的性能损失不太现实。
软件角度，文中说Jeff Atwood提到：
I found that the performance of JavaScript improved a hundredfold between 1996 and 2006. If Web 2.0 is built on a backbone of JavaScript, it’s largely possible only because of those crucial Moore’s Law performance improvements.
JS的性能这几年并没有大的提升，即使有也是得益于摩尔定律。
下面作者有引用了大段的“证据”说明JS“Not designed for performance”。
最后谈到了我们都知道的就是JS的垃圾回收机制，没有一个有效的垃圾回收机制。
还有就是JS的内存占用问题。
回归本质就是编译语言、JIT、解释性语言性能的讨论，对吗？
以上。
争论Web App和Native App那个是趋势其实是没有意义的。这只是技术方案不同而已。一个产品要预见到技术发展的趋势，做好两手准备。不要纠结于一个能调本地API一个要运行在浏览器里这些细节。凡是技术能解决的问题都不是问题。
其实不论哪种技术方案能够赢得未来，App这种服务形式才是趋势。App是对URL的革命，是对搜索引擎的革命。服务App化的趋势是阻挡不了的。
iOS 的 App 内普遍使用了 UIWebView 。而 Web App 在发展通过 JS 调用本地功能的技术。
所以相互融合是趋势。
赵瀚卿 CoreThink/OpenCMF/众筹/OTA/商务/PM
关于Web App以及非原生APP的开发，我司研发整理过这样一份表格，针对国内常用的三种框架：ionic/mui/freamwork7做了一个对比，我认为还是比较详细的，有问题欢迎交流，版权属于我司：南京科斯克OpenCMF－领先的互联网积木式云平台，作者为我司研发张玥同学。
分久必合，合久必分。操作系统提供商不会坐看维护的生态环境被他人窃取。
PC时代就有类似的问题
先是native的，之后出现web应用，两者共存，渐渐倾向于web，这之中网络环境、计算机速度提升占很重要的因素
现在移动开发，先从native开始，但现在越来越多的应用使用web，或者混合架构
同样有合还要有分，跟中穿戴、车载、智能家电发展起来后，又是native天下
移动互联网时代，网络淘金者争做移动应用的激情是无限的。在各大应用商店里搜个“公厕”都能有一堆帮你找厕所的应用。然而最近一则调查却告诉我们：60%的应用在下载一周后没有被再次使用。在我看来，许多网站过于注重原生应用（Native app）的开发而忽略了网页应用（Web app）。试问，你是否会为了这一时之需而在手机里常备个“上海厕所指南”呢，还是会事到临头在手机浏览器里谷歌一下？
Native or Web，两者之间的争论一直不断。网上的评论往往着眼于原生应用的性能优用户体验好。这里，我列举了原生应用不如网页应用的五宗罪。
罪1 – 烦人的下载和更新
手机原生应用大多在几兆到十几兆不等。说大也不大。但要知道，用手机的时候往往是出门在外。2G网络下，几兆大小足以让用户望而却步。另外，下载了就需要不定期更新。时不时跳出来的更新提示也确实烦人。
罪2 – 偷偷摸摸的后台进程
讨厌的后台进程一直偷偷地消耗着手机的内存资源和网络流量。要是时不时弹个广告神马的就更可恶了。
罪3 – 被滥用的权限
为了能够提供丰富多彩的功能，需要一些权限也无可厚非。但现在滥要权限的比比皆是。每多装一个原生应用，就多一份被偷窃隐私的危险。试想某个索要了查看手机全部联系人的应用，要是某天干不下去了，会不会拿这些用户资料来最后捞一笔呢？
罪4 – 可移植性的欠缺，程序员的噩梦
这一点是网上被提及最多的。为Android写的应用无法在苹果手机上运行。现在主流的移动操作系统就有三四种，再算上每个系统版本升级而带来的不兼容，所以开发原生应用的成本是网页应用的几倍。
罪5 – 无法被搜索引擎索引到的内容
目前的搜索引擎还无法深入索引原生应用里面的内容。应用的推广只能靠开发者登陆各大应用商店（App store）。这是非常低效的，就好比搜索引擎诞生之前，草根站长需要登陆各大网址黄页去注册自己的站点一样。不仅如此，以后每次应用更新，开发者同样地还得上传一遍各大应用商店。在短期内，这个问题似乎还没有一个很好的解决办法。
1. windows里的优酷的客户端比http://youku.com快多了
2. 如果你在乎jvm插在OS和应用软件中间带来的性能下降 同理你应该也会不爽webkit
3. 确实有人闻不出six god和chanel no5的区别 但也还是有很多人能闻出来 不过不可否认的是这俩东西都卖的很好
移动互联时代，还是产品为王的时代，一个产品要想赢得用户，必须要有极致的用户体验。所以，未来到底是Web App还是Native App的天下，主要还是取决于使用这两种技术的产品的用户体验的优劣。从目前来看，由于Web App依赖于浏览器的性能，Web App还只是适合做一些信息浏览类型的应用，如果想做一些复杂功能，特别是频繁与网络交互的应用，还是只能选用Native App。
看用来做什么产品吧，native速度快体验好，但是发布更新麻烦，webapp体验差，但是发布更新全部自己控制。不过随着硬件性能提升webapp的体验会越来越好，但是完全替代native不太可能。感觉Hybrid app是个不错的选择，另外Hybrid app中h5的比率会越来越大，native用来提供核心功能的流程体验
Native App开发即我们所称的传统APP开发模式（原生APP开发模式），该开发针对IOS、Android等不同的手机操作系统要采用不同的语言和框架进行开发，该模式通常是由“云服务器数据+APP应用客户端”两部份构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。
Web App开发
Web App开发即是一种框架型APP开发模式（HTML5 APP 框架开发模式），该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。
Web技术开发的APP发布能力强、开发效率高，但是功能弱，用户体验不好。Native APP就是原生APP，它的人际交互体验强，设备调用性能好，但是开发时间长，发布效率低。现在移动开发的趋势是将两种技术融合，将WEB技术在原生APP中实现快速的功能扩展，比如最新提出的应用号就是这个逻辑，做跨平台开发的APICloud也发布了SuperWebview，都是将WEB和Native快速融合的
相信未来移动领域在功耗或者电池技术没有突破性进展的情况，Native还是会略微领先，当然这种差距越来越缩小。人们总会被他们所有用的东西所束缚，例如一直使用的语言。那些习惯了解释性语言灵活性和功能强大框架的便利性的Weber，必然会使出浑身解数消弥这差距。
但我们是在移动环境，那些传承自半个世纪的教条也会有失灵的场景。例如Choose portability over efficiency。也许计算力不是问题，但电是问题。
换一个角度来看，设备最耗电的2大杀手信号和屏幕，前者不知道还有多大空间可以挖掘，后者已经有潜在的替代者，例如google刚出的眼镜和HP杳无音信的打印纸屏（如果我没有搞错）。
Web App+Native App相结合，最好啦~
就目前而言，应该是最好的解决方案…
但仍旧看好Html5带来的新的未来……扁平还是拟物”一样，答案不固定，常在两者之间反弹。 话说07年肾机问世之前，我们用没有3G的诺基亚看WAP网页时候，不一直是廋客户端时代吗。后来触屏手机出现，觉得上网时候网页有很多重复信息，为了避免浪费，于是就给各大网站弄个客户端（不过桌面电脑和平板当时还在用浏览器打天下）。新浪，腾讯，网易，与，微博，新闻，邮箱，这就有3*3=9种组合，从此胖客户端开始了。 11年我玩了唯一一个web app,不，这简直是一个web launchbox，它就是webqq。这是瘦客户端时代卷土重来。
移动应用开发不存在’one-size-fits-all’（万全之策）的解决方案。无论是采用混合、HTML5还是原生，许多开发者在项目的中期总会发现他们最开始采用的方法并不是最佳方案
Web和混合(Hybrid)应用正在成为热门趋势
Web平台（HTML5 & JavaScript）是创建跨平台应用的首选
个人私见，Web App应该会占上风，原生会没落，但不会被遗弃
这个要看的还是终端设备和网络通信的发展，NATIVE为什么会流行？那是因为智能手机的流行趋势，某种技术的被接受和流行，有时候取决的不止是功能方面，更多的在于用户，但很多时候用户是盲目的。
现在这种争论很多，首先大家对于Native app 和 web app的定义是否一样？widget插件算native 还是算 web？ 目前来看native app的用户体验好、用户留存率高，但同时增加了推广成本；web app虽方便，但是saas的弊病都有，用户需要的有时候是数据，而不是全部的网上页面download展示，并且从用户习惯角度，native app更符合用户习惯。总之，最终吸引用户使用的是产品的优质服务，所以这两种形态最好同时存在。
1）Javascript对于Web app来说是不可取的，因为速度太慢，而且影响体验。
根据测评，原生应用速度是 JS Web app 的 5 倍；JS Web app 与 IE8 相当，而 x86 C/C++（桌面应用）速度是 JS Web app 的 50 倍。
2）最可行的提速办法是将移动硬件性能提升到桌面硬件的水平，但是中短期内不太可能。
解决方案很明显，把 ARM 的速度提高 10 倍，快到可以与 x86 匹敌，那样的话无需做任何工作即可实现桌面 JavaScript 的性能！这个方案行不行得通取决于你对摩尔定律的信仰，是否相信 3 盎司电池能否支撑芯片的运作。
3） 从目前来看，JS语言本身的速度并没有改善，而做编程语言的人说在目前的语言和API的条件下，Web app的速度永远也赶不上原生代码
大部分的意见其实还是并存！我的意见就是：CEO大人，你为什么你让你的开发团队同时开发web app和native app呢，两者注定是长期并存的，既然如此何必那么纠结，两者都用用户量，让用户自己去选择！webapp是“未来”的方向，毕竟web能够真正支撑app也就是ajax以来的事情。为了增进交互体验，近几年mvc重心前移，未来比较能遇见的是后端主要基于restful接口提供数据，mvc部分更多由js框架来实现。不过目前来说，即使是angular/ember等比较强大的框架也还在不断的发展，大部分程序员们也还没有掌握得足够好以支撑大项目，浏览器方面也还有改进余地。有野心的团队已经可以尝试nodejs+ember这样的stackweb APP 现在确实不够完善，native APP现在还是占据大头，前几天历时八年HTML5标准已经完成。HTML5的崛起已经势不可挡。而且现在PhoneGap的出现已经说明了很多问题。还有jQuery Mobile 虽然HTML5标准刚刚达成一致，但是还不能说明Web App具有明显的优势。从现阶段来看，定论Web App和Native App哪个能代表未来还为时尚早。因为二者都有各自明显的优势，也有各自的劣势。
Web App具有更新快，不需要像Native App那样每次的版本更新都需要经过应用商店提交审核，且网页的推广相对比较容易，而且Web App完全可以在未开发完成之前就可以上线，开发和上线同步。
而Native App在用户体验上确实要好于Web App，能够实现更多炫酷的效果，能让用户完成的操作也更多。
我的观点是，Web App比较适合用于开发轻度、用户使用频次不太高的应用，比如美容、整形、电子商务之类的；而Native App比较适合用于开发重度、用户使用频次高的应用，比如大众点评。
以上是我对Web App和Native App的理解，希望对你有帮助！
如果是将来物联网的话，首先很多的小节点无法运行浏览器，无法构建BS，只能建立简单的CS，然后BS浏览器访问本地的一些外设比较难， 比如spi，com口或者usb之类的，不适合一些数据采集设备等等。这是项目中遇到的一些问题，不知道以后会不会解决。