一个 App，两套商店规则：用 Flutter 把服务平台同时上架 Google Play 和 App Store

SolveMY 是我开发的一个服务平台，用一套 Flutter 代码和一个 Go API 同时支持 Android、iOS 和网页。上架 Google Play 很顺利，通过 Apple 审核则让我学到了更多。如果重来一次，下面这些我会从第一天就规划好。

设计定价前先读懂支付规则

Apple 的审核指南要求，数字商品和在 App 内解锁的功能必须使用应用内购买，并且限制你引导用户使用其他付款方式。我们最初几次提交正是因此被拒。解决办法是让定价展示按平台区分：iOS App 不显示任何价格和升级入口，从 iOS App 打开的网页同样隐藏，而 Android 和电脑网页保持不变。越早这样设计，越能避免几周的反复提交。

把推送通知当作两套系统

Android 和 iOS 的推送都经过 Firebase，但 iOS 需要单独的 APNs 凭证。有一次，一个只适用于 iOS 的配置块被附加到了每一条消息上，结果 Firebase 连 Android 的消息也一并拒绝，手机好几天都没有提醒，而 App 内的通知列表看起来一切正常。平台专属的配置就让它只作用于对应平台，并做一个能证明推送确实送达设备的管理工具。

旧版本 App 永远不会消失

用户更新 App 很慢，所以 API 必须对几个月前的版本保持兼容。改动尽量做成“只增不改”。我们加入聊天“对所有人删除”功能时，被删除的消息仍以纯文本加标记的形式返回，旧版本无需更新也能显示合适的占位文字。

深度链接：冷启动不一样

打开一个正在运行的 App，链接传来的是短路径；冷启动时传来的却是完整网址，而且路由可能在处理完链接之后又执行了启动页跳转。把两种情况统一处理，并让启动页跳转保持幂等，否则你的二维码只会把用户带到首页，而不是正确的页面。

这些都不玄妙，却正是“在我手机上能跑”和“已在两个商店上线”之间的那段路。