当前，微信不同类型账号的数量比例大致如下：

　　除了微信使用者属于零门槛的服务接受方外，公众号都是服务提供方。在订阅号、服务号、企业号三种公众号里，运营复杂程度和申请要求依次提高，拥有者数量也逐级减少。

　　毋庸置疑的是，对于应用号，微信内部已经绘制了一份宏图大业--零售业、餐饮业、医疗业、智能硬件，与各种类型的传统行业进行连接。然而，单单餐饮业，就有餐厅、酒水饮料、烘焙、甜品等类，林林总总，根本没办法用一种模式通吃所有。

　　为涵盖尽可能广泛的行业领域的互联网服务，微信必须赋予应用号更大的授权。这个授权主要体现在应用号页面开发的自主性上，因为只有让运营者自己去设计Web APP，才能保证服务的多样性。这样一来，检索应用号就像在应用市场中查找APP一样。

　　那么，运营者需要网页开发能力，会导致应用号的数量再降一个层级吗?

　　非也。

　　当前国内一些底层的交互型工具，用户可以通过对HTML5网页进行可视化编辑，来实现复杂网页的开发。因此，应用号运营者不需要是开发者，却可以像开发者一样根据服务需求来设计网页，制作出同样功能的Web APP。

　　所以，应用号如果想要实现数量的逆袭，必须有两个条件：

　　1、微信允许运营者自主设计入口页面;

　　2、运营者借助可视化工具制作应用号页面。

　　在这两个前提下，才能既保证应用号的服务质量，又能降低运营者的门槛。

　　推不推送，这是一个问题

　　对应用号进行"剧透"时，张小龙的一句话很值得玩味：

　　"他要找这个公众号的时候就像找一个APP，在平时这个号不会向用户发东西的，所以APP就会很安静地在那里，等用户需要的时候找到它就好了。"

　　这句话暗示应用号会采取"关注--需求激发--获取服务"这样的模式。换句话说，用户没有主动表达需求，应用号只能那么静静地待着，因此就没有向用户推送通知的能力。

　　一个需要用户主动打开才能提供服务的Web APP，会有什么限制?

　　假设某个医院有这么一个医疗应用号，提供预约挂号、缴费支付、医疗报告三种服务。

　　你到医院前，在家里挂号，准备等到差不多自己的号再出门。所以，虽然在家里，你有事没事就得刷手机，要不然就不知道究竟到哪个号了。看完病，用手机支付医疗费后，得做个检查。检查完，也不知道结果什么时候出来，你还得不停地刷手机--因为即便报告出来了，医院也没有权限给你推送通知。

　　因此，应用号能否主动向用户推送内容，将会是应用号提供的Web APP服务和原生APP的关键区别。换句话说，当应用号具有主动推送通知功能，才能最大限度上替代原生APP。