WWDC22 Playground 最后一晚谈了接近四小时。张思琪主持，weak self 的两位主持人、谜底科技的六一与 Ellen、Sorted 开发者 Harry、王秋丽、戴铭和学生开发者张博士，从各自这一周的体验出发，谈怎样发现技术、怎样做出产品，又怎样让它得到持续使用。
这场讨论可在 2022 年录播中回看。文中的新系统指 iOS 16 等当年版本；奖项、团队状态、运营经验和未来设备猜想也均属于当时。它的主线不是把 WWDC 功能清单再念一遍，而是追问：新能力到了开发者手里，距离好用的产品还差什么？
Labs、Lounge 与同行交流，分别能解决什么问题
从 11:42 开始，六一与 Ellen 回忆谜底时钟入围 Apple Design Awards 的一周。他们最珍惜的收获之一，是因此认识 Waterllama 团队，交流设计、推广与运营。谜底时钟当年是入围者，未获最后奖项；这段经历的价值也没有被他们缩减为获奖与否。有人从现场发回应用被展示的画面，有同行在公布结果后互相安慰，这让原本遥远的国际开发者圈变得具体。
与独立团队不同，秋丽的 WWDC 往往撞上电商大促。她描述的第一步是安装新系统与开发工具、验证现有应用、在内部整理变化，再划分适配风险与新功能机会。对成熟产品而言，新 API 的吸引力要与当前用户的稳定体验一起考虑。
Harry 对 Labs 的利用更主动。他会预先写好问题，附上应用资料，而不是临场问一个泛泛的问题。他举例说，一次讨论崩溃报告时，工程师提前做了调查，现场能直接讨论可疑位置。这是他的具体体验，不代表每次预约都会得到同等准备或保证解决。远程形式节省了现场奔跑、排队的成本，也让无法赴会的人有机会接触工程师。
Digital Lounges 的价值则在另一层。波菲喜欢“共同观看”的安排：视频讲到一个主题，主讲人和开发者可以同时在频道里补充、提问，许多人立刻看到同一条线索。他有时干脆先看问答，再回头看视频，以免两边信息同时涌入。戴铭提到自己报名频道太少，后来才发现还对其他方向感兴趣；张博士则分享像素图标挑战，说明 WWDC 不只是一组技术课程，也有动手练习与设计交流。
weak self 主持人的另一段回忆把视野从官方活动拉到同行之间：一款应用的特殊交互、一次偶然介绍，可能在几年后变成另一个人的新产品。这里既有技术求解，也有不急于问尽商业细节的互相欣赏。主持人随后提到海外社区活动，想表达的是不同经历的人会提出不同问题；不能把几场活动的观察变成各地开发者群体的统计结论。
让人记住一个应用的，常常是使用时的一个瞬间
36:31 的应用讨论没有把个人偏好当评奖标准。戴铭喜欢谜底时钟的细节，也喜欢 Procreate 不必先读厚手册就能开始画画的体验。秋丽从笔记和音频应用中看到简洁、顺滑及持续维护，职业习惯让她也会查看版本历史。
波菲讲 Transit 的方式尤其具体。他搬到新城市后，会担心坐过站、错过换乘。单纯给出最优路线还不够：当计划被打断，用户需要马上看到附近能坐什么、下一站在哪里、怎样重新安排。让他留下印象的不是某个别人从未做过的功能，而是这些信息能在焦虑发生的那个时刻连成可操作的流程。
这也为之后三段产品分享定下基调。好设计可以很漂亮，但还必须回答人在什么情况下打开应用，以及打开之后有没有更容易完成想做的事。
两个学生作品：从 AR 引导到手语学习
43:54 开始，张博士介绍一个 AR 创作项目，以及当年 Swift Student Challenge 的手语学习作品。前一个项目首先处理的并非精美模型，而是进入 AR 前的准备：光线、环境纹理、怎样移动设备、什么时候已经完成扫描。用户不知道跟踪为何失败，如果应用只给一个摄像头画面，就会把技术限制变成困惑。
他把界面分成现实中的虚拟物体、摄像头视角和固定在屏幕上的控制层。按钮应当容易找到，但不能挤满小屏幕、挡住主要场景；背景不断变化时，控制层也要保持可辨认。官方的 coaching 引导可以帮助建立基础流程，产品仍需决定怎样把它融入自身体验。他还描述通过技术交流联系工程师排查问题的经历，强调遇到框架疑点时不必完全闭门调试。
第二个作品受到电影《CODA》的启发，希望让听人主动了解手语，而不是把交流负担全交给聋人或重听者。作品先提供基础知识问答，再介绍简单字母和词语，最后加入动作识别；SwiftUI、自己训练的模型及相关视觉技术服务于这一条学习路径。比赛作品的体量有限，它不是完整手语翻译系统，也不能由此推断识别所有手势的可靠性。
六一从评委经历补充，学生的创意会给经验丰富的开发者新刺激。其他嘉宾把话题延伸到视频通话字幕与文字转语音：如果产品只依赖看屏幕或听声音，就会让一些人无法使用。这里更值得保留的是设计责任，不是把某类社会议题写成获奖公式，更不沿用原谈话里对残障群体过于绝对的能力描述。
Sorted：先明确为什么需要它，再累积被看见的机会
57:34 开始，Harry 把产品、推广和持续经营放在同一条线上。待办工具已经很多，Sorted 的切入点不是再做一个列表，而是让用户决定一件事何时做、预计做多久，并把这些安排放到一天之中。临时变化发生后，交互还要支持快速把后续任务整体延后。这是一个从真实安排工作的方法反推界面的例子。
他反复强调先把产品做好，随后才谈媒体。在早期，团队没有只盯着最大的平台，而是让较小的媒体、播客与创作者接触产品，逐步得到使用反馈与介绍机会。后来被 App Store 关注、围绕新版本沟通，是他们的具体成长路径，不能简化为“找媒体就能获得 Apple 推荐”。
分享中提到提前数周告知重要版本计划，给编辑团队留出准备时间。这个数字是当时合作经历的一部分，并非所有团队必须遵循的固定承诺。被推荐也不是经营的终点：曝光窗口有限，持续更新、参加社区活动和保持沟通，才能让产品继续被理解。戴铭在问答里回应，自己做 MVP 曾经失败，听到这段分享后，最受启发的恰是产品质量与向外交流要同时推进。
谜底时钟：声音、材质与用户邮件怎样改变产品
1:11:09 的分享由 Ellen 主讲。她先交代谜底科技当时的小团队与多款产品，也坦率说并不是每款都同样成熟。谜底时钟的起点来自 OffScreen 的用户：人们专注时喜欢打开翻页钟，团队因此思考，能否把看时间本身做得更有趣。
他们去家具店和中古店观察时钟，也买真实物件研究。霓虹主题参考真实灯管、点亮过程与声音；辉光管时钟则让团队去了解这种物件的历史和质感。数字时钟并非只需换一套背景图，显示方式、动画节奏、声音和触发动作会一起构成体验。例如接上电源才点亮的霓虹钟、能随着设备动作散落的积木数字，把熟悉的物理联想放进了屏幕。
应用的首次打开同样经过设计。用户即使没有看过介绍，也应明白这是一款时钟应用，还能使用小组件与其他工具。Ellen 用“很少折腾手机的人也能理解”来描述文案目标，并没有声称已完成严格的目标用户测试。
最有分量的一段来自一封用户邮件。团队原以为这款应用主要靠视觉吸引人，一位视障用户却喜欢它的声音，还询问为什么不同主题的报时节奏不同。这让他们意识到，自己的用户模型漏掉了一群人，随后补上 VoiceOver 支持并亲自测试。缩放、屏保等需求也来自用户的不同使用方式。包容性在这里不是额外贴上的标签，而是每天回复邮件之后，承认原先想象不完整，再把遗漏补进产品。
Ellen 还谈到小组件、iPad 指针与键盘、Mac Catalyst 和系统入口。应用打开次数不高，不代表没有价值；适当的系统整合能让功能在需要它的时候出现。她随后展示多语言商店文案、截图和预览，以及应用内活动和产品页实验。用用户熟悉的语言介绍产品，也是体验的一部分。
这里要区分两类行动：商店描述可以优化；Apple 的产品页优化实验，当年明确支持比较图标、截图和预览，并不等于所有商店文本都能在同一实验里 A/B 测试。广告和社交媒体合作则属于团队经营手段，不保证固定下载收益。录播中的推荐数量、下载量是团队当时自述，本文不将其换算为经审计的业绩或普遍营销公式。
App Clip：先缩小任务，再检查整条唤起链路
1:30:26 开始，秋丽把话题拉回业务适配。App Clip 适合把应用中的一件核心任务拆出来，让用户在扫描、浏览或相关场景中快速完成，不必先进入完整应用。它不适合因为主应用功能多，就把同样的复杂度硬塞进一个更小包体。
她关注的是从开发到唤起的一整条链：独立 target 怎样与主应用共享部分代码；应用和网站怎样配置关联域名；后台怎样设置卡片、链接和不同体验；最后怎样分别通过本地运行与 TestFlight 验证。一个 App Clip 可以根据不同入口进入不同体验，不等于每个入口都要做一个互不相关的应用。诊断工具的意义在于把“打不开”拆成可检查的配置问题，而不是只反复重装。
2022 年的官方更新给出了明确边界：最低系统为 iOS 16 时包体上限提高到 15 MB，兼容更早系统仍需遵守原来的 10 MB 限制；App Clip 可以读取 CloudKit 公共数据库，不能据此推导为完整 CloudKit 读写权限。钥匙串迁移让安装完整应用后的敏感数据衔接更直接，但共享钥匙串组与 iCloud Keychain 并不属于该支持范围。高级体验的 API 则用于自动化管理入口与相关信息。这些范围来自 WWDC22 官方课程。
问答谈到包体限制、工具型应用是否有必要采用，以及大体量业务如何找到合适入口。嘉宾期待电商场景继续探索，但没有在现场确认某个产品上线日期。录播提及的不活跃清理天数也未当作固定规则写入；技术选型不能依赖一个尚未核实的自动保留期限。
Passkeys 需要整个登录链路一起改变
1:45:27 开始，weak self 主持人把 Passkeys 看作可能超出 Apple 生态的一项重要变化。讨论先从密码重复使用、记忆负担和服务端泄露风险出发，再解释公钥与私钥的分工：服务端保存用于验证的公钥，客户端使用对应凭据完成验证，用户不必把一段可重复使用的密码交给网站。
Face ID 或 Touch ID 是本地授权体验的一环，不是把面容或指纹当作网站密码上传。用其他设备登录时，也不是简单把私钥复制到对方电脑。2022 年 Apple 的介绍建立在 WebAuthn 等既有标准之上，覆盖账户创建、认证及跨设备场景。可对照当年的 Meet passkeys。
因此，结论不是“从此没有账户安全问题”。服务仍需处理恢复、会话、兼容路径和整体账户安全；原有密码与新机制也可能并存。嘉宾最后提醒，把这件事带回公司讨论时，应同时找前端、后端和其他客户端同事。它不是仅由 iOS 工程师加一个按钮就能完成的适配。
锁屏、Watch 与 App Intents：把功能放到更短的路径上
1:54:12 的讨论回到使用场景。Ellen 说，她原先打开待办应用，经常在解锁手机之后被别的东西带走。如果锁屏就能看到下一件事，用户看一眼就可以放下手机。这与把用户尽量引入应用的思路不同：缩短路径有时意味着少打开一次应用。
Watch 复杂功能与锁屏小组件在有限空间、扫一眼的信息设计上有相通之处。嘉宾认为新的 WidgetKit 流程和预览减少了反复向手表安装测试的负担，但仍需要真机检查。Harry 已有小组件基础，因此能够较快做出锁屏版本；这个速度依赖现有代码和设计，不能推广为任何应用“几分钟适配完成”。团队的小组件使用数据也只是自身样本，不说明所有类别都应优先采用同样入口。
接着谈到 App Intents。旧的 intent definition 编辑与本地化流程曾让团队花很多时间排查，代码作为主要声明方式，让逻辑更容易阅读、复用和测试。Harry 介绍自己在 Labs 问到的做法：构造某个 intent，调用执行逻辑，测试输入与结果。单元测试能覆盖其中的业务行为，最终仍要在设备上验证系统入口、权限和实际交互，不能把代码层测试写成整个 Siri/快捷指令体验的替代。
现场还以当年的健康码、支付扫码等入口表达一个共同愿望：高频任务不该埋在多层界面里。它们属于 2022 年的具体使用背景，并非本文在今天推荐继续使用的产品方案。
SwiftUI 的进步，体现在少写补丁和更清楚地表达状态
2:07:21 开始，戴铭用带玩笑的说法形容自己的感受：过去费力补齐的能力，后来成了官方组件。图表、底部弹层、Grid、定制布局、分享入口和导航，都是他觉得能减少绕路的方向。真正让他高兴的不只是代码短，而是接口能更直接表达想要的东西。
这段讨论也包含真实的迁移成本。新组件到来后，已有应用不一定能立即替换；过去为旧行为写下的方案，需要评估、改动和验证。喜欢新技术，与不想总重写旧代码，可以同时成立。Xcode 的图标资源处理、参数补全和编辑上下文提示，也因为影响每天的工作而受到关注。
NavigationStack 引出一层更深的解释。SwiftUI 希望开发者描述状态与界面的关系，导航路径也应该成为可表达的数据，而不是散落在许多视图中的跳转动作。另一位嘉宾看到 UIKit 仍在更新，同时单元格等局部可以嵌入 SwiftUI，认为这让已有项目有更渐进的采用方式。官方当年课程也包含这些跨框架整合。
由此得到的是更丰富的选择，不是 UIKit 已经失效。嘉宾尤其提醒，两套框架的思路不同；先理解各自的状态、生命周期和布局方式，再在需要时连接，通常比把旧写法直接翻译成新语法更可靠。对未来新硬件将如何采用 SwiftUI 的判断，仍是录制时的推测。
Swift 语言层面也被提到：distributed actors 使跨进程或设备的调用模型更值得探索，some 与 any 让一些抽象表达更清楚。这不意味着分布式调用自动消除网络失败，也不意味着两个关键字可以互换。录播没有展开完整示例，本文保留其关注方向，不把一段兴趣分享扩写成未经展示的课程。
AR 想象很大，RoomPlan 能做的事情必须说清
2:31:31 开始，张博士与波菲讨论未来的空间交互。两人从 VR、AR 与混合场景的差异，聊到遮挡、手势、固定界面和空间中的物件。虚拟海豚不应该永远盖在真实的人前面；三维按钮的可发现性、可触达性，也不能简单照搬手机上的点击。
他们据此想象时钟出现在墙上、天花板变成星空、虚拟窗户显示天气，以及界面怎样跟家庭自动化联动。这些是 2022 年讨论者的产品设想；少数课程更新、图像抠取或某个演示，并不能证明 Apple 已公布某款设备、系统名称或交互规范。
讨论中有一段很必要的降温：RoomPlan 提供的是房间结构与物体类别等参数化结果，不是随手得到一套精细、带真实纹理的完整房产模型。张博士在早期试用中还遇到尺寸表现问题，这属于当时观察，不能写成所有正式版本的永久缺陷，也不能断言何时已修复。RoomPlan 与 Object Capture 组合能否产生新体验，是待开发者实现的方案。当年的官方 RoomPlan 课程说明了它的实际输出与工作方式。
随后两人把视野放到户外。要在城市某个地点展示相应内容，仅识别到一个相似物体还不够，定位、地图与现场识别可能需要共同参与；这些能力还有地域和设备条件。内容制作成本同样重要：即便追踪和渲染能跑起来，团队能否持续制作足够好的三维内容，仍决定了产品的边界。对其他房产产品底层实现，现场只是探讨可能性，本文不替未公开方案下结论。
链接与启动：工具升级之外，仍有属于产品自己的问题
2:51:59 开始，波菲推荐观看解释原理的课程，特别是链接器与运行时的历史。随着代码和库增多，构建时间、运行时查找、包大小及启动成本之间的取舍会越来越明显。理解这些来龙去脉，比只记一个“提速开关”更有助于判断自己的项目。
戴铭接着讨论并行构建、开发阶段可省下的工作，以及发布时仍需做的优化。现场偏向减少不必要的动态库开销，但不能由此推出静态链接在任何项目都更好；依赖结构、共享代码、构建和分发方式都影响结果。对 Apple 为什么在某个时间点推出优化的商业动机猜测，也不作为事实保留。
还有一个官方工具很难替产品团队回答的问题：代码虽然被引用，真实用户是否使用相应功能？编译期能判断的可达性，与运行中实际发生的使用，不是一回事。嘉宾讨论了手动埋点、类初始化记录和更细粒度插桩，各自涉及观测成本与覆盖范围。这里没有提供可直接照搬的安全删除名单；没有观测到使用，也不足以证明一个功能可以删除。
系统和工具升级可能带来收益，但团队还要考虑最低版本、用户升级意愿和内部工具链迁移。把这些问题放在一起，才是这段“等官方优化”玩笑背后的现实工程判断。
App Store 经营也需要实验，而不是只看下载总数
3:04:22 开始，六一回到自己每天使用的 App Store Connect。他关注提交流程、应用内活动、自定义产品页与产品页优化，原因很实际：团队不断发版本、维护多种语言，希望减少后台重复操作，也希望知道商店展示到底哪里有改进空间。
与 Waterllama 团队交流时，他才发现自己的图标配置方式影响了后台能否使用相关实验功能。这说明同行交流甚至可以发现日常工具中一直没被看见的入口。对方分享的转化率提升是特定实验的个人报告，不是任何应用换图标都能得到的收益。可借鉴的是用实验比较方案、观察曝光到下载的转化，而不是照抄另一个产品的图标。
当年介绍的 Benchmarks 将相近应用分组，帮助开发者理解自己在若干指标上的相对位置，并对隐私做处理。分位位置可以提示调查方向，但不会自动解释转化差异的原因，也不是给应用质量打一个总分。官方课程同时说明了怎样结合产品页优化和自定义页面继续验证。
嘉宾还提出面向开发者的小工具机会：多语言 release notes、用户评论回复及后台批量操作，都可能通过 API 改善。不过现场也有人提醒已有同类产品，不能把个人没见过写成市场上没有。是否值得做，仍需理解实际用户、接口权限与维护成本。
收官问答：技术更顺手了，参与大会仍有成本
3:14:25 之后，每位嘉宾谈最满意与不满意的部分，讨论并没有在主要演讲结束后停止。
很多人同时喜欢线上课程的制作质量，又想念线下偶遇。共同观看、主讲人答疑和开发者交流，可能适合混合形式；这是一组愿望，不是下一届大会的安排。时差则是反复出现的问题：白天工作，凌晨等待预约，再在相隔数小时的两个 Labs 之间熬夜，机会开放并不代表参与成本消失。
Harry 喜欢当年减少重复工作的新 API，甚至想为新项目提高最低系统版本；这表达了他的产品取舍，不要求所有团队一起放弃旧设备。戴铭喜欢锁屏、Stage Manager 与家居空间相关的想法，其他嘉宾也从不同工作习惯出发给出偏好。秋丽则提醒，大促期间的适配与规则变化会冲击既定计划。她对 TestFlight 限制与审核流程的抱怨保留为当时业务体验，不把未复核的具体名额、期限及动机写成今天的政策。
最后一个讨论回到知识怎样被再次找到。主持人怀念能够快速翻阅的幻灯片；有人提醒官方视频已有文字稿，随后大家澄清，真正的需求是跨课程检索，并直接定位某个小知识点。看过、理解过，不代表一个月后还能迅速找回。笔记、链接与可检索的整理因此成为开发工作的一部分。
收尾的感谢与抽奖结束了这场长谈。贯穿整晚的并不是一个“最值得学的新功能”，而是多种开发者经验相互补足：大团队带来稳定性与流程，小团队带来产品细节与经营，学生带来新的问题意识，社区让这些视角能在同一个晚上碰面。