给微信小程序配一个 App 如何？

Web1.0 时代以及 Web2.0 前期的“眼球经济”，即以吸引用户长时间观看内容、使用工具为导向，占有用户的“屏幕时间”（Screen time），从中寻求各种“变现”机会（例如让用户看到更多广告）。移动互联网普及后，一方面因为智能手机的“尺寸因素”（form factor）导致了用户在行住坐卧中利用碎片时间操作弹丸之地的屏幕，彻底抛弃被一根网线绑定、长时间正襟危坐的用浏览器“网上冲浪”（一个 20 年前的概念）的行为，另一方面社交化的内容创作、内容传播进入大繁荣，人们很难再有耐心和忠诚度去自行光顾一个网站。

所以，继续用信息化时代的观念看待 App 开发，视之为另一种网站并试图按 Web1.0 时代的套路去运营的企业，都遭遇失败 - 大部分的 App，只是躺在用户的手机里，“尘封”，被遗忘。

小程序这种轻量的、实用主义的发明，随需随用、用完即走，特别符合移动互联网时代的特点，可以说是既极大程度提升了用户体验，又助力了很多企业的数字化展业。

但是企业完全依托互联网平台小程序也有利弊。它的用户，首先是互联网平台的用户，企业要触达用户即便是存量客户，也并不容易。从这个角度看，企业变成了第三者方，是“提供插件的”，和“用完即走”的用户之间的关系非常弱。

想当初，企业采用小程序来实现自己的业务场景数字化，不外乎这几个原因：

可是时至今天，世界也变化了不少。首先，公域流量变得越来越昂贵；其次，已经转化成存量的客户，在互联网平台上不好触达与服务，受平台的各种规则制约；再是当自家的业务复杂度增加起来，个性化需求越来越多的时候，难以灵活订制。何况还有商业隐私数据落在第三方平台的顾虑，数据就是资产，这些资产的归属权就是一个问题；对企业而言，留存在第三方的运营数据，使用上也非常不便。

企业发展前期，也许顾不上什么数据资产的保护和利用，但是在发展起来后，是时候重新审视自己的数字化策略。

有些企业或者事业单位，确实有这个趋势或者需要。以广东省政府的粤省事 App 最近上线为例，政府单位通过互联网平台向市民提供各种小程序化的便民服务固然是必须的，但是随着数字化政务的发展，最终可能还是需要把各种政务设施工具聚合起来提供一站式的服务，便于老百姓搜索、发现、使用。此外与政务相关的用户数据，在 App 中由所属政企单位掌握，更加合规与便利。

还有别的例子。例如包括金融机构在内，“对公”业务通过互联网平台去触达与服务客户，也不是特别的便利。ToC，营销与服务一体化，对客户是用户体验好，对企业是提升转化率；ToB，营销与服务，未必都合适“一体化”，也许在互联网公域上营销，在私域的 App 上服务并维持长期关系，更加合理。

App，依然有它的存在之道。它沉淀了企业和客户之间最直接的数字关系。

再玩 App，肯定不能再按传统“信息化”的思路来。

什么是“信息化”思路？在自己的 IT 系统和互联网入口之间，构建一个充当“缓冲区”、“转换器”的所谓“技术平台”，再在前端挂上几张“皮” - 例如基于 HTML 的网站、iOS/Android App、以及小程序应用等等。这是非常典型的由内而外的思路：业务电子化 -> 电子系统对接网络变成信息 -> 输出到互联网。这个做法，本质上是把异构技术做转接，例如银行、证券或者政企等等的一些自 90 年代以来沉淀的、甚至是“古典互联网”之前的历史遗留系统，架构上与互联网不匹配，需要整一个技术转换器。前面的展现形态随着用户手里的科技设备升级而换换“汤”，但是后面的“药”还是那几样、“处方”还是那一款。

“信息化”的做法，依然需要继续，这个毫无疑问，因为对于很多企业、很多业务、很多场景来说，信息化还没有完成呢。可是需要及时结合“数字化”方面的考量。对于 App 来说，符合数字化特点就是：

营销展业获客，服务存量客户，既要小程序，也要 App，两手都要硬！而且这两者是配合的打法，理想的图景是这样的 :

首先，在互联网各大平台上，通过公众号、视频号、小程序进行营销获客和服务的闭环是必须持续打造的。哪怕是政务、金融、医疗服务等合规要求高、数据隐私敏感的行当，依然需要通过互联网触达用户、向用户提供便利服务功能。

引进来。对于转化过来的存量用户，可以通过公众号、小程序引导跳转至 App，让用户获得更丰富的服务内容、或者使用有隐私数据敏感性的、有合规监管要求的功能。

走出去。App 中的一些功能，也可以随时被用户分享传播至互联网的各种社交、电商、支付、衣食住行的流量平台中，以小程序的形式出现。

企业在互联网上可以提供多类业务多种服务，有多个小程序，但它们同时也都可以聚合在企业自己的 App 中，一站式的供存量用户的发现和使用。无论是运行在互联网平台上，还是运行在企业自营 App 中，交互体验都是无差异的。

可以说，在互联网上做一款符合数字化要求一点的 App，起码包括这样一些必要条件：

FinClip 技术基本上已经帮助开发者实现了这些必要条件。任何业务逻辑都以小程序方式开发，这些小程序可以编译运行在互联网的一些流量平台里，也可以运行在企业自己的 App 中，用户体验 100%一致，只是运行的环境发生变化。采用 FinClip SDK 的 App，也同时自动获得分享转发小程序以及从小程序从第三方跳转回 App 的能力。

但不仅于此，FinClip 还可以进一步帮助开发者把这个 App 给“生成”出来，也就是说，打造一个符合数字化特征的 App，现在有两个简易的手段。

办法一。你已经有现成的 App，希望实现敏捷、连接、传播分享的能力？可以把 FinClip SDK 嵌入到 App 中，把新功能按小程序方式开发，这些新功能都将可以被上架、分享到微信等互联网平台中；你也可以把已经在微信等地方上架的小程序的代码，重新在 FinClip 编译上架，迁回到自己的 App 里

办法二。你没有 App，但有一个用户量不少的微信/支付宝/其他小程序，希望通过自己的 App 去沉淀、长期服务存量客户；或者你有多个互联网平台上的小程序，希望把它们同时聚合到自己的 App 中，向存量用户提供一站式的使用便利。FinClip 可以帮助自动生成这么一对分别运行在 iOS 和 Android 上的 App，供你使用。

假设公司 A 的 IT 只有三四个人的小团队在维护一个微信小程序 ABC，怎样能让他们以最透明无感的方式获得一对 iOS/Android App 呢？可以按“把大象关到冰箱里”一样的步骤：

现在，公司 A 已经获得了一个 App，这个 App 将马上可以运行公司 A 的 IT 之前开发投产过的小程序 ABC（但还是需要在 App 上架一次 - 在微信上架的版本毕竟只能运行在微信里面）。

但是，如果原来的小程序是基于微信进行登录认证？没有问题，一行代码不用改，稍作配置（见 FinClip 小程序支持微信登录），即可搞定。

当用户使用公司 A 的上述 App 打开小程序 ABC 的时候，会是怎样的体验呢？App 将跳转微信，让用户在微信侧完成登录授权，然后定位返回到小程序 ABC。

TCO - Total Cost of Ownership，即“总拥有成本”，如果技术上能降低开发、维护、运营 App 的这个成本，对企业重新自主掌握自己的 App，有极大的帮助促进。

FinClip 的技术理念，是促进企业可组装式的应用开发。当 App 的应用逻辑以小程序开发，当 App 的原生基础技术如支付、人脸识别、OCR、音视频、加解密等成为 FinClip 运行沙箱的技术插件，开发者的注意力焦点，已经不再在 App 本身，而是在业务逻辑的开发调试上。App 只是一个壳，它可以被组装、被自动化反复生成，它的维护成本将被降至最低。此外，App 的代码可基于《个保法》、数据安全相关的一系列法律法规生成，保障符合相关规定、通过相关检测。

当发行一款自己的 App 变的简单可靠又高效的时候，你会考虑拥有一个吗？