.pkpass 是 Apple Wallet 用来承载 Pass 的文件格式:登机牌、会员卡、优惠券、活动门票都是它。它不是一个 App,也不是一张图片,而是一个结构固定的签名 ZIP 包。搞懂里面装了什么,关于 Wallet Pass 的大多数疑问就都有答案了。
对出海团队来说,这个格式还牵出另一个绕不开的问题:一旦顾客的姓名、邮箱、会员编号这类个人数据被塞进 Pass 里,这些数据怎么存、经谁处理、放在哪个国家的数据中心,就成了能不能安心对接欧洲、北美用户的关键。格式本身谁家都一样,格式背后的合规能力才是真正拉开差距的地方。
.pkpass 文件里到底装了什么
把 .pkpass 后缀改成 .zip 再解压,你会看到不多的几个文件。真正重要的是这四样:
- pass.json —— Pass 本身。字段、配色、条码、正反面显示的文字,一张登机牌之所以是登机牌、一张咖啡卡之所以是咖啡卡,全靠它。
- manifest.json —— 归档里每个文件的清单,附带各自的 SHA-1 哈希值。它是校验单,用来证明没有任何内容被篡改。
- signature —— 对 manifest 做的加密签名,用苹果签发的证书生成。正是这一部分让 Wallet 愿意信任这个 Pass。没有有效签名,就没有 Pass。
- 图片 —— icon.png、logo.png,以及可能的 strip 或缩略图素材,通常有 1x、2x、3x 三种分辨率,适配不同屏幕。
这就是整个包的全部内容。设计信息在 pass.json 里,图片放在旁边,manifest 加上 signature 负责证明这个包是真实且未被改动的。它是一个刻意做得朴素、但可验证的容器。
做一个 .pkpass 是不是必须要有 Apple Developer 账号
简短的答案是:要生成它,必须有;要接收它,完全不需要。
签名文件正是账号存在的原因。它必须用 Pass Type ID 证书生成,而这种证书只能通过 Apple Developer 账号获取,一年 99 美元。没有这个证书,其余每个文件你都能正确拼好,Wallet 依然会拒绝这个 Pass,因为它没法验证这是谁发的。
你的海外顾客完全不用关心这些。Developer 账号是对签发方 —— 也就是负责生成和签名 Pass 的企业 —— 的要求,不是对把 Pass 存进手机的人的要求。他们只需要点一下”添加”。证书相关的工作只发生在你这一侧、只做一次,远早于任何一个 Pass 送到用户手机之前。
.pkpass 和”通用 Wallet Pass”是一回事吗
“Wallet Pass”这个说法平时用得比较松,值得说清楚。.pkpass 特指苹果自家的格式。Google Wallet 走的是完全不同的路线,基于它 API 定义的 Pass 对象,而不是一个可下载的签名文件。
所以 .pkpass 只是 Wallet Pass 的一种 —— 苹果这一种。如果你要同时覆盖两个平台的海外用户,实际上是从同一份数据分别生成一个 Apple .pkpass 文件和一个 Google Wallet 对象,而不是一份文件通吃两端。对顾客来说体验是一致的,背后却是两条不同的技术路径。
怎么打开或测试一个 .pkpass 文件
上线前,几种实用的检查方式:
- 在 iPhone 或 Mac 上双击或直接打开文件,Wallet 会像顾客看到的那样直接预览。
- 想看细节,把文件改名成 .zip、解压,再用任意文本编辑器打开 pass.json。这是检查字段、配色和条码值最快的办法。
- 想验证签名,苹果的 signpass 工具和一些在线校验工具能告诉你 manifest 和证书是否匹配。一个在你自己设备上预览正常的 Pass,签名如果有问题,到了别人手机上照样可能失败。
完全绕开这套文件格式
大多数需要 Wallet Pass 的团队,根本不想碰 pass.json、不想管签名证书,也不想去调试 manifest 哈希。他们要的是一张顾客能添加、数据一变就自动更新的卡片。格式只是手段,不是目的。
你完全不用亲自碰 .pkpass 格式。Pushwoosh 负责签名和打包,你只管设计卡片,剩下的交给我们。这部分数据处理跑在通过 SOC 2 Type I 和 ISO 27001:2022 认证、符合 GDPR 要求的基础设施上,数据中心位于欧盟和美国,方便出海团队直接对接欧美用户而不用自建这套合规能力。详见 Wallet Passes。
