几乎每家经纪商最终都会提出要一款属于自己的移动应用。理由很充分：客户都在手机上生活，平台厂商的应用带着别人的 Logo，而交易者手机主屏上的一个品牌图标确实有价值。然后项目遇上 Apple 的审核团队，时间线就会翻倍。
这里会说明这些选项到底是什么、应用必须做什么，以及提交时通常会在哪些地方被拒。
将交易应用放到你名下的三种方式
第一种选择就是根本不做。你的客户下载平台厂商的应用并选择你的服务器。这样没有成本，没有应用商店风险，也完全没有品牌展示。对于一个新经纪商、业务量不大的情况下，这通常是第一年的正确选择。
第二种是来自平台厂商的白标移动应用，以你公司的名义发布。许多平台提供商都提供这种方案。你可以在一个已经成熟、经过验证的交易终端上使用你的名称和配色，同时也继承了上架、审核流程和更新周期。开发成本很低，但持续性的责任是真实存在的。
第三种是基于你的 CRM 和交易 API 构建的定制应用。这是唯一一种可以让应用在一个地方完成客户所需全部事项的路径：注册、上传文件、入金、开设新的交易账户，以及在图表旁边查看余额。它也是开发成本最高的方案，而且只有这种方案会让你承担每一次被拒的后果。
关于第三种方案，最好直说：对大多数经纪商来说，交易终端并不是差异化所在。真正在意图表的交易者通常已经安装了 MetaTrader 或 cTrader，不会为了你那版蜡烛图而切换。真正属于你的体验部分是账户区域，这也是为什么很多定制应用会处理开户注册、入金和账户管理，而把实际交易界面交给平台应用。
除了展示图表，应用还必须做什么
功能范围膨胀会毁掉这些项目，所以要尽早决定以下哪些内容属于第一版：
- 注册和登录，最好与网页客户区共用，这样客户不必维护两套身份。
- 使用手机摄像头上传文件，这是移动端开户注册在完成率上优于桌面端的最大原因。
- 入金和出金，包括你所在地区实际使用的本地支付方式。
- 账户列表、余额、杠杆和平台凭证。
- 关于保证金水平、文件审批和支付状态的推送通知。
这份清单描述的是应用壳里的一个 Traders Room ，这正是它应有的样子。如果同样的数据已经在驱动你的网页门户，那么移动端开发更像是一个界面项目，而不是平台项目。 CRM API 是移动开发者对接的接口，在任何人开始写第一行 Swift 之前，先确认它是否暴露了清单中的全部内容是值得的。Prop Firm 也有类似的清单，只是内容不同，因为对应的界面是 challenge dashboard ，包含规则进度、回撤和出金状态。
Push 值得单独说明。很多情况下，它正是开发应用的理由，因为它是唯一一个不需要和收件箱竞争就能触达交易者的渠道。保证金提醒、验证审批和支付失败，是客户真正想收到的通知，而且它们需要来自你 CRM 已经在使用的同一个 notification system ，而不是来自一个没人维护的独立工具。
如何通过 Apple 审核
这个类别的大多数被拒，都可以归结为四条指南。
- Guideline 3.2.1(viii) 是最先要读的一条。Apple 的原文是：“用于金融交易、投资或资金管理的应用，应由执行此类服务的金融机构提交，并且在你提供这些服务的地区必须具备必要的许可和授权。” 实际上这意味着开发者账号必须属于你持牌的实体，账号名称必须与牌照上的名称一致，而且你允许提供服务的国家/地区也必须与你实际获授权的范围一致。由开发代理替你提交应用，基本就是在主动寻求被拒。
- Guideline 4.3(b) 针对的是“与已广泛可用的产品几乎无法区分”的应用。品牌化的同一交易终端变体与这条线非常接近，这也是为什么针对单一经纪商去克隆一个知名平台，多年来一直都是一条艰难路线。防御方式是让你的应用做通用版本不做的事情，这也是为什么要优先构建账户区域，而不是再做一个图表界面。
- Guideline 4.2 会拦下过于单薄的应用。如果你的提交只是一个包着客户端门户的 web view，而其中没有任何原生功能，审核方很可能会问：相比移动网站，这个应用到底增加了什么。基于摄像头的文件采集、生物识别登录和推送通知通常是标准答案，而且这些功能需要在提交前就已经具备，而不是写在审核备注里承诺以后再加。
- Guideline 5.1.1 要求隐私政策明确说明你收集什么、如何使用、与谁共享，以及用户如何删除其数据。Apple 还期望应用内提供账户删除功能。对于有记录保存义务的受监管经纪商来说，这需要一个真正的回答，通常是删除应用账户，并清楚说明哪些数据必须依法保留以及保留多久。
有两件实用的事情可以缩短审核时间：给审核人员提供一个带有资金和持仓的账户的可用演示凭证，并附上一段简短的流程录屏。无法通过你的 KYC 门槛的审核人员通常会直接拒绝，而不会继续调查。
Prop Firm 的应用内购买问题
Prop Firm 还有一个额外的问题。Guideline 3.1.1 要求通过应用内购买来解锁功能或内容，并且明确禁止为此使用你自己的支付机制。挑战费是否属于数字内容，是你在构建流程之前就需要弄清楚的问题，而不是之后，因为佣金差异大到足以改变你的单客经济模型。
大多数运营方采用的安全做法，是把 challenge 购买保留在网页端，让应用仅展示和管理交易者已经拥有的账户。Apple 关于链接到外部购买的规则在近几年已经多次变化，而且不同地区也不一样，所以要阅读当前的指南原文，而不是两年前的一篇博客文章，这篇也一样。
Google Play
Play 通常更快，但也有自己的文书要求。任何带有金融功能的应用都必须在 Play Console 中完成 Financial features declaration，而 Financial Services policy 还会设置额外要求，这些要求会因国家/地区而异，包括某些市场中的牌照文件要求。第一次就如实填写声明，因为在被拒后再修改，速度会比最初审核更慢。
你还需要一个已完成的数据安全部分，并且它必须与你的隐私政策一致；同时，你还应提前规划 Google 的目标 API 级别要求，因为这会强制你每年进行一次技术更新，无论你的产品是否发生变化。
在你撰写商店文案之前，还有一件值得检查的事：复杂投机性金融产品的广告规则会限制你在两个商店以及广告中对交易的描述方式。暗示盈利的截图很容易让你被下架。
预算要按第二年算，不是上线期
构建报价只是小头。每年都会带来新的操作系统版本、Android 上强制性的 API 级别提升、你平台供应商的 SDK 更新，以及针对每一项更新的审查周期。没有维护预算的应用大约在十八个月内就会停止工作，而且带来的品牌损害比没有应用还大。
如果没有维护经费，诚实的答案是一个响应式客户专区，而不是一个应用。一个设计良好的 移动网页门户 可以在手机上处理开户注册、入金和账户管理，支持大多数设备上的网页推送，不需要商店审核，而且你决定更新的当天就能发布。
如何决定
看看你的客户专区流量中已有多少来自移动端，以及这些会话都在做什么。如果大部分是在查看余额和催促入金，那么应用会有帮助，而且范围也很明确。如果需求来自一个想拿点东西给潜在客户看的销售团队，那么一个品牌化网页门户就能以极低的成本完成同样的工作。
如果你确实要做，先发布账户专区，之后再根据数据决定是否增加交易界面。客户很少因为想要更好的图表而要求一个应用。他们提出要求，是因为他们希望自己的资金和文件一键可达——这与我们在审视 交易者真正希望从经纪商那里得到什么.
就您的移动端客户体验申请咨询
获得专业指导，帮助您为您的经纪商或 prop firm 选择合适的移动战略。我们将帮助您评估原生应用、品牌化的 Traders Room 还是响应式网页门户，哪一种最适合您的业务、客户期望和运营需求。
我们将一起审视您当前的客户旅程，并制定一项旨在实现长期可扩展性和可维护性的移动战略。
