导读：如果一款 App 没有服务器、没有账号、甚至不联网，还能设计推荐奖励机制吗？本文深入分析 PinDial 这款 iOS 通讯录增强工具的蓝牙面对面推荐系统，探讨在完全离线环境下如何建立用户之间的信任关系，并给出完整的技术实现细节与安全设计。
一、一个特殊的前提
PinDial 是一款通讯录增强工具。它最知名的功能是为 iOS 18+ 原生拨号盘建立中文拼音索引，让用户能够直接在系统原生拨号盘用 T9 键盘搜索中文联系人。
更特殊的是它的架构理念：
- 不注册账号
- 不登录
- 不上传通讯录
- 不联网同步
- 所有数据本地处理
对于很多工具类产品来说，这是一种非常彻底的隐私优先设计。但与此同时，也带来了一个现实问题——如果开发者想做推荐奖励，该怎么办？
二、传统邀请码为什么不成立
很多人第一反应都是邀请码：A 获得邀请码 → 发送给 B → B 输入 → A 获得奖励。
听起来很合理。但问题在于，邀请码真正依赖的其实不是邀请码本身，而是服务器。
传统邀请系统的流程实际上是：
A → 邀请码 → B → 服务器 → A 推荐数 +1
服务器负责记录邀请关系、统计推荐次数、发放奖励、通知推荐人。
而如果没有服务器，流程到这里就结束了：
A → 邀请码 → B
推荐结果无法回传。 A 和 B 根本没有通信渠道。推荐关系虽然发生了，但推荐人无法得到确认，奖励也无法发放。
对于无服务器产品来说，邀请码最大的问题不是防作弊，而是无法完成推荐结果的双向确认。
三、PinDial 提出了一种不同思路
开发者最终想到的方案并不是二维码，而是蓝牙。
推荐人点击「我是推荐人」，开始广播；被推荐人点击「我是被推荐人」，开始扫描。双方靠近后，自动发现彼此、建立加密连接、交换签名凭证、完成确认。
整个过程无需网络，无需服务器，无需账号。
四、蓝牙真正解决了什么
很多人会认为蓝牙只是为了防止二维码群发。其实不完全是。
蓝牙真正提供的是双向通信能力：
| 方案 | 通信方式 | 能力 |
|---|---|---|
| 二维码 | A → B | 单向传递 |
| 蓝牙 | A ↔ B | 双向确认 |
因此可以形成完整链路：
A 发起推荐 → B 确认 → B 返回加密签名 → A 验证通过 → A 推荐数 +1
在没有服务器的前提下，这可能是最关键的一步。
五、技术实现细节
这套系统的核心基于 Apple 的 MultipeerConnectivity 框架，它允许 iOS 设备通过蓝牙或点对点 WiFi 建立直接连接，不经过互联网。
5.1 验证协议（防重放攻击）
1. A 生成一个随机 nonce（UUID），通过加密通道发送给 B
2. B 使用 SHA256 对 (nonce + 固定盐值) 进行哈希签名，连同设备标识发回给 A
3. A 用同样的方式计算期望值，比对匹配则验证通过
4. A 验证通过后发送 OK 确认，B 收到确认后将「已推荐」标记写入 Keychain
（写入前已有 isReferred 检查阻断并发请求，防止竞态条件）
5.2 防逆向保护
与其他 App 不同，这个系统不存储简单计数（如 count = 3），而是存储每次验证生成的完整 SHA256 签名凭证数组。
- 计数由数组长度推导
- 逆向者无法伪造有效的签名凭证——除非知道编译进二进制文件的盐值
5.3 本地存储
| 角色 | 存储内容 | 存储位置 |
|---|---|---|
| 推荐人 | 签名凭证数组 | Keychain（iCloud 同步，换手机自动恢复） |
| 被推荐人 | 「已推荐」标记 | Keychain（iCloud 同步，卸载重装不丢失） |
Keychain 使用 kSecAttrAccessibleAfterFirstUnlock 属性（首次解锁后可用，支持后台访问），刷机后丢失，但卸载重装不丢失。
六、用物理距离代替服务器信任
这个设计最有意思的地方在于，它改变了推荐关系的建立方式。
| 传统模式 | PinDial 模式 |
|---|---|
| 服务器信任 | 物理接近信任 |
| 服务器告诉系统"A 推荐了 B" | 系统认为 A 与 B 发生了真实接触 |
| 依赖网络 + 后端 | 完全离线 |
这是一种完全不同的设计哲学。
七、推荐奖励的设计
PinDial 免费版允许处理 15 个联系人。
推荐人
- 每成功推荐 1 人，试用额度 +15（变为 30 → 45 → 全部解锁）
- 累计推荐 3 人后，解锁全部高级功能
- ¥8 的付费入口始终保留，推荐是替代方案而非唯一解
被推荐人
- 验证成功后，试用额度从 15 变为 30 个
- 一个设备只能做一次被推荐人（Keychain 持久化标记）
- 不是单纯的"工具人"——双方都获得即时收益
整个过程依然保持离线，不需要连接任何服务器。
八、App Store 审核合规
这个方案通过了 App Store 审核的必要条件：
- 使用系统级框架（MultipeerConnectivity），不涉及私有 API
- 蓝牙权限描述写明了用途：用于验证推荐关系，不上传个人信息
- IAP 付费入口始终保留，推广不是"强制拉人"而是替代选项
- 无服务器意味着零数据收集，与隐私标签「A 类——不收集任何数据」完全一致
九、总结
这套方案未必会成为主流增长模型。因为绝大多数产品都有服务器，也不需要承担这样的约束。
但它提出了一个很有意思的问题：
当我们拿掉账号、服务器和网络之后，是否还能建立用户之间的信任关系？
PinDial 给出的答案是：可以。利用现实世界中的物理接近，建立数字世界中的推荐关系。
对于增长行业来说，这可能不是效率最高的方案。但对于无服务器产品来说，它或许提供了一种值得研究的思路：
用双向近场通信代替服务器确认，用物理距离代替云端信任。
这也是我目前见过最符合「离线优先」理念的推荐机制之一。
