据 Bloomberg 记者 Mark Gurman，以及 MacRumors、9to5Mac、AppleInsider 等媒体报道，iOS 27 预计会在 Apple Wallet 里加入一个新入口：Create a Pass。

按目前报道，iOS 27 会在 6 月 8 日 WWDC 预览，并在 2026 年 9 月面向公众发布。苹果还没有正式发布这项功能，所以现在只能把它看作爆料信息。

有意思的地方不在“Wallet 多了几张彩色卡片”。真正的变化是，苹果可能把 Wallet 凭证的创建权，从开发者和第三方工具手里，放一部分到普通用户手上。

这补的是一个老缺口：很多人手里有会员卡、纸质票、屏幕二维码，但就是放不进 Wallet。

Create a Pass 怎么用：从“等商户接入”变成“用户自己补一张”

多家报道对流程的描述接近：用户在 Wallet 里点击现有的“+”按钮，除银行卡、交通卡、邮件中的凭证外，会看到 Create a Pass 选项。

创建方式有两种。

一种是扫码。用户可以用相机扫描纸质卡、纸质票券，或者另一块屏幕上的二维码。

另一种是手动创建。也就是在编辑器里填写信息，再生成一张 Wallet 凭证。

目前报道提到三种模板：Standard 橙色、Membership 蓝色、Event 紫色。名字很直白，对应通用卡、会员卡和活动票。

项目目前报道中的做法直接影响
入口Wallet “+”按钮新增 Create a Pass不必先找第三方生成器
创建方式扫码或手动填写纸质卡、纸票、屏幕码有机会进 Wallet
模板Standard 橙色、Membership 蓝色、Event 紫色覆盖通用卡、会员卡、活动票三类常见场景
创建门槛不需要 Apple Developer 账号、Pass Type ID、证书签名普通用户和小商户绕开 PassKit 开发流程

最后一行最关键。

过去想做一张正式的 Apple Wallet pass，通常绕不开 PassKit。开发者账号、Pass Type ID、证书签名、.pkpass 打包，这些词对开发者不陌生，但对一家小店来说就是门槛。

Create a Pass 如果按报道落地，至少会把“个人保存一张卡券”这件事降到系统功能级别。

为什么重要：PassKit 用了 14 年，小商户一直缺席

Apple 在 2012 年随 iOS 6 推出 PassKit。它的设计并不落后：商户生成 .pkpass 文件，用户点击加入 Wallet，之后可在时间、位置、锁屏等场景被调出。

航空公司、连锁零售、影院、票务平台很适合这套模式。它们有开发团队，有后端系统，也有维护凭证的动力。

小商户不是这样。

一家咖啡店、健身房、图书馆，或者一个社区活动组织，可能只需要给几百个人发会员卡或入场码。让它们为了这件事配置证书、维护后端、适配 Wallet 设计规范，成本不低。

所以现实常常是：大品牌进 Wallet，小店继续发纸卡。久而久之，Wallet 成了“能接入者的卡包”，不是“所有卡券的卡包”。

Create a Pass 的价值就在这里。它不让小商户立刻变成开发团队，而是让用户把已有的二维码、条码或票面信息，自己收进 Wallet。

对普通用户来说，动作会很简单：先别急着找第三方 App，把常用会员卡和纸质票券留到 iOS 27 测试版信息更清楚后再判断。如果只是“把一个码放进 Wallet”，系统入口可能够用。

对小商户来说，短期也不必立刻采购一套 Apple Wallet 凭证系统。更现实的做法是先确认自己现有的二维码、条码、会员编号，能不能被 Create a Pass 正常识别。能识别，就先省下一部分数字化成本；不能识别，再考虑正式接入或第三方方案。

对第三方 Wallet 凭证生成工具来说，基础功能会承压。只解决“把一个码做成 Wallet 卡片”的产品，价值会被削薄。

但这不等于第三方工具没有活路。Android 端、网页生成、批量分发、团队协作、跨平台分享、与商户系统集成，这些不是一个 iPhone 本地编辑器天然能覆盖的事。

苹果补的是个人入口，不一定补完整运营系统。

还要看四个变量：条码、同步、导出、更新

现在最容易误读的一点，是把 Create a Pass 当成“所有卡券都能完美进 Wallet”。目前没有证据支持这个结论。

报道只讲了入口、模板和大致流程。真正决定好不好用的，是下面这些细节。

待确认变量为什么重要影响谁
条码类型是否支持 Code 128、PDF417、Aztec 等常见格式，还是主要支持二维码纸票、会员卡、登机或活动凭证用户
iCloud 同步自建凭证能否在新 iPhone、Apple Watch、iPad、Mac 间同步多设备用户、换机用户
.pkpass 导出能否把自建凭证分享给别人，或导出备用家庭共享、活动转票、团队分发场景
商户更新能力商户能否更新积分、等级、场次、有效期小商户、会员系统服务商

条码兼容是最现实的坑。

很多纸质票券和会员卡不是二维码。超市、健身房、图书馆、活动票可能使用不同条码格式。如果 Create a Pass 只识别有限格式，用户会遇到“看起来能扫，实际用不了”的尴尬。

同步也很关键。Wallet 本来就是一个高频工具，换机、Apple Watch 使用、跨设备查看都很常见。自建凭证如果只留在本机，价值会打折。

还有安全和隐私边界。

用户手动创建一张凭证，不等于商户认可这张凭证。Wallet 里能显示一个码，也不代表后端系统会放行。更敏感的会员信息、票券转让、动态码、实名票，都可能涉及验证规则。

所以这项功能的边界要看苹果怎么设计：它是一个“个人卡片收纳器”，还是会给商户留下认领、签名、更新的通道。

这也是接下来最该看 WWDC 和首批开发者测试版的地方。

如果它只支持本地保存，那就是一次很实用的体验修补。能少带几张纸卡，已经有价值。

如果它支持更完整的同步、格式兼容和更新机制，Wallet 才会从大品牌凭证夹，往日常卡券容器再走一步。

回到开头那个问题：这次变动反常在哪里？

苹果过去很少把系统级凭证创建权交给普通用户。Create a Pass 如果成真，说明 Apple Wallet 终于开始处理长尾卡券这个脏活、细活。

难的不是做三张模板。难的是让一张用户自己创建的卡，既方便，又可信，还能在真实商户场景里用得上。