2022 年 WWDC22.playground Day 1 的原片由少数派账号发布，属于 swift.gg、T 技术沙龙、老司机技术与少数派参与协作的系列活动。嘉宾观点均为录制时的判断。
同一场发布会，在不同人眼里并不是同一份清单。开发者会问新框架怎样进入现有项目，设计师会问新的窗口形式是否容易理解，内容创作者会问手机、平板与电脑能否减少工作中的设备切换，媒体则会继续追问：这些变化最终能不能帮助一个小团队活下来？
WWDC22.playground Day 1 把这些人放到了同一场讨论中。张思琪主持，老麦先回顾发布内容，飞猪从产品与交互提出问题，小希从创作者和使用者角度回应，Justin 与自力以对谈展开设计与技术观察，王巍（喵神）再从开发平台和工具的角度归纳趋势。最后，老麦把焦点转向独立开发者的产品故事、早期用户与持续经营。
节目开头有一段发布内容速览，覆盖 M2、新款 Mac、iOS 16、iPadOS 16、macOS Ventura 与 watchOS 9。正文讨论更有价值的部分，是这些变化之间的关系，而不是把规格再复述一遍。
发布会的第一印象：明显的变化之外，还有更深的入口
开场回顾时，老麦把本届更新理解为对既有系统的继续完善，以及对生态联系的加强。它未必让每位用户立刻看到“颠覆性的产品”，却可能把能力推进到更靠近日常使用的位置。
锁屏就是其中一个例子。字体、颜色和组件让屏幕更个性化，但老麦更关心的是入口：如果用户可以更早看见一件事情的状态，是否就能减少打开应用、找页面、等待结果的步骤？在通知已经很多的情况下，新入口怎样帮助用户完成任务，比多占一个展示位置更有意义。
听写和从照片中提取主体，也引发了类似的联想。老麦并没有只把它们看成独立功能，而是设想把语音输入、图像处理和简单编辑连接起来，形成更轻松的记录方式。手帐只是现场举的一个方向，不是已经验证的新市场；它体现的是一种寻找产品机会的方法——观察几个现成能力能否一起减少某段工作流程中的阻力。
对钱包、地图、消息、家庭等更新，他也提醒需要考虑地区和使用习惯。一段全球发布会的演示，并不意味着每个地方都能马上获得同样体验，更不意味着当地用户原来的任务方式会自然改变。这个判断后来反复出现在圆桌中：开发者既要看平台提供什么，也要看自己的用户实际上怎样生活。
他举 iMessage 编辑与撤回、钱包分期、地图更新为例：功能可以在 Keynote 上讲得很顺，但在国内的使用频率、服务接入和支付习惯不一样，未必形成相同机会。智能家居的新标准也引起他兴趣，不过他同样没有假定不同厂商生态会立刻互通。这些限定让“发现新入口”有了下一步：先验证本地用户是否真的需要它。
CarPlay 引发的争论，首先是体验由谁决定
飞猪选择下一代 CarPlay 作为最令自己意外的内容。他认为，展示已经不只是把手机中的导航或媒体放到车内屏幕上，而是进一步进入仪表信息、车辆控制和多屏体验。
由此产生的第一个问题不是界面能否画出来，而是车厂、手机平台与使用者之间怎样分配决定权。车厂有自己的品牌、功能和安全要求，Apple 则希望提供一致的体验；消费者可能喜欢统一的界面，却未必知道背后的协作需要多少工作。
老麦对此保持谨慎。他认为预览很吸引人，但当时仍不清楚各家如何交换数据、接入到什么程度，以及最终会有哪些真正可使用的车型。自力则用开放协议和硬件合作作类比，设想车厂可以主动提供接口，平台负责组织体验。这些都是现场讨论方案，并不是已经公开的完整技术架构。
飞猪随后又把问题拉回独立开发者：如果未来出现一个重要的新界面平台，第三方能做什么？他明确承认，当时还不知道新一代体验会向第三方开放到什么程度；一场预览尚未意味着新的应用市场开放。
他把问题放进十五年移动应用发展的背景里：手机市场已经成熟，开发者自然会寻找下一个重要界面。车可能成为候选，但展出的仪表盘、空调和多屏联动需要汽车厂商参与，不能只靠一个 iPhone 应用单方面完成。老麦接着追问，新界面究竟叠在原车系统之上，还是更深地接管其功能；自力则提出类似 HomeKit 协议接入的设想。几种说法分别是问题、类比和猜想，现场没有一份确认过的架构图。
王巍补充了一个必要区别：当时已有面向部分应用类别的 CarPlay 开发能力，但既有框架的存在，不等于所有新展示的车辆控制功能都可以由第三方任意使用。
他把这层区别说得更具体：开发者此前已能为音乐、导航、电动车充电等获准类别制作 CarPlay 应用，需要取得相应权限，并可借助 Xcode 中的目标设备与模拟器开发。飞猪问的却是新预览中贯穿仪表盘、多个屏幕和车辆控制的体验。对前者有工具和审核路径，并不能回答后者是否向普通第三方开放。自力注意到主驾到副驾连续屏幕与中控的组合，借 HomeKit 想象车厂主动接入协议；那是他对合作边界的猜想，不是已公开的接口设计。
Apple 的2022 年公告也为讨论划定了时间范围：这是下一代 CarPlay 的预览，车型会从次年晚些时候开始公布。所有车辆并未因此立即获得升级，Apple 也没有在这场大会上宣布自有汽车。嘉宾提出的“是否为未来汽车铺路”，当时仍是悬而未决的问题。
iPad 的窗口变多了，工作是否真的更容易
飞猪谈到另一个比规格更切身的问题：iPadOS 的多任务交互不断变化，用户和开发者都需要反复学习。
他能理解 Stage Manager（台前调度）在 Mac 与 iPad 之间提供一致思路的价值，但也担心有限的屏幕空间被侧边区域、Dock 和多个窗口共同占用。一个原本习惯全屏阅读或创作的人，面对更多窗口之后，究竟是更容易完成任务，还是多了一套需要管理的界面？
从开发者角度，压力还不只在窗口数量。一个最初为 iPhone 设计的应用，到了 iPad 就需要处理侧栏、多列、横竖屏和不同内容密度。可变窗口再加入之后，设计要面对更多宽度与使用情境。飞猪的疑问并不是反对新功能，而是提醒大家：功能完整和交互清楚，是两种不同的工作。
王巍回应说，系统并非让每个团队从零解决这些问题。已有的自适应布局、尺寸类别与分栏组件，可以承担相当一部分标准界面的行为；外接显示器也是理解新多任务体验的重要情境。但如果希望创造更特别的产品，仍然需要设计判断。遵循标准可以减少基础工作，不会自动替人决定一个工具该怎样被使用。
飞猪说自己平常在 iPad 上几乎总是全屏工作，需要回消息时才临时从 Dock 拉出另一应用。台前调度把工作区和 Dock 长时间留在屏幕边缘，可能挤压原来的内容。他还从 iPhone 应用迁到 iPad 的经验出发，列出侧栏、多列、旋转方向、内容密度，再加上可缩放窗口，设计维度变多。王巍的回答针对的是标准界面的工程起点：Auto Layout、size class 与分栏组件可以处理不少基础变化；它没有否认飞猪关于学习成本和产品体验的担心。
老麦则把期待放在自己的工作流程上。他过去买过 iPad，希望在移动办公中减少对 Mac 的依赖，却往往因多任务或外接显示体验又回到电脑。这一次他想再次尝试，但没有在节目中宣称 iPad 已经能够替代所有电脑工作。
后续讨论进一步提出：iPad 也许不必以“完全变成 Mac”为目标。触控、手写、听写与图像处理组合起来，可能形成另一种创作和管理方式。这个观点和飞猪对学习成本的疑问并不冲突；一种新的工作形式能否成立，恰恰要看它是否真正减少了负担。
老麦拿出一台早年的 webOS 平板，说明卡片、堆叠和手势并非全新想法：当年的做法很有趣，却也让普通用户承担学习成本。他没有因此断言台前调度会重蹈覆辙，而是提出另一种可能——苹果也许正在让笔、手指、听写和抠图承担过去必须靠键盘、鼠标完成的轻量工作。这个判断要经过真实工作流检验。小希便给出了反例和边界：文字类内容可以在 iPad 上处理，但拍视频时她仍更信任 iPhone 相机，剪辑也仍等待合适的软件。
创作者看连续互通：已有设备能不能少做一次准备
小希从内容创作者的角度讨论 MacBook Air、iPad 与 iPhone。对于 M2 和新外形，她既感兴趣，也会考虑现有设备是否已经够用、价格是否值得，以及自己的剪辑工作是否真需要更换硬件。她谈的是 2022 年发布时的取舍；发布会性能数字也不是她自己剪辑工作的实测结果。
她更直接关心的是连续互通相机和桌面视角。拍摄讲解时，如果既要拍到脸，又要拍到桌面操作，通常需要额外准备设备和角度。把已有 iPhone 的相机接入电脑，是否可以降低这类内容制作的门槛，因而成为一个很具体的问题。
小希当时使用两套机位分别拍人和手，起初还以为演示中的手机被架在桌面上方；得知桌面视角利用超广角画面和计算处理后，她才意识到现有设备也许能少承担一次布置。Justin 的惊喜也在这里：同一部手机同时给出人像与近似俯拍的画面，是硬件视角和软件矫正共同完成的结果。但两人都没有在录播里做自己的拍摄质量测试。
Justin 后来也提到，桌面视角是自己在发布会中产生惊喜的一刻。相比孤立地比较摄像头像素，这个例子同时涉及设备硬件、画面处理和用户当前正在做的事。对刚开始创作的人，利用现有设备完成第一步，可能比立刻配齐专业器材更有吸引力。
嘉宾仍然保留了适用范围。专业拍摄不一定因此舍弃原有器材；剪辑工作也不只是相机输入的问题。小希期待 iPad 上出现更完整的创作软件，这在本场仍是期待，不是当时已经发布或已体验的能力。
对游戏的讨论也类似。Metal 与新芯片让大家关注 Mac、iPad 上的内容可能性，但原生游戏数量、适配质量和实际帧率仍要等产品验证。节目没有把一段演示直接当成整个游戏生态已经改变的结论。
跨设备和应用之间的协作，是本场反复出现的共同主题
Justin 把前面零散的例子归纳成两条线：设备之间更加容易协作，应用之间也更加容易围绕同一项任务连接。
锁屏组件与手表上的信息展示有相近之处，手机相机能进入电脑工作流，共享内容可以与消息中的对话关联。嘉宾关心的不是“每个设备都获得同样功能”，而是用户不必在每个边界重新安排一遍工作。
Safari 共享标签页组提供了一个小尺度的例子。几个人共同计划旅行时，资料往往散落在不同人的浏览器中；如果能共享正在看的内容，协作就可以围绕资料本身展开。Freeform 的讨论则指向另一类任务：需要不断补充想法、图像和结构的开放式讨论。
这种便利也带来取舍。老麦描述，自己作为媒体工作者需要体验其他品牌设备，但已有工作方式越完整，临时换出去就越容易感到不便。对他而言，生态既吸引人，也可能降低尝试其他产品的意愿；换一套工作方式是否值得，仍取决于使用者自己的任务。
Justin 把协同又分成设备之间与应用之间。前者包括锁屏信息与手表复杂功能的相似表达、手机相机进入电脑工作流；后者包括共享资料和在消息对话中围绕同一内容继续协作。他说的是自己从多项发布中看到的方向，而不是宣称所有设备和应用当时已具备无缝互通。
从系统设置到 Passkeys：怎样减少用户反复做的事
Justin 与自力的专场采用轻松的对谈形式，但讨论的问题很具体。对于重新设计的 Mac 系统设置，自力更看重侧栏在不同项目之间切换的便利；旧界面中反复进入、退出的过程能否减少，是他判断设计的出发点。
对 M2 的讨论则围绕代际更新与产品组合，而不只是新数字。Apple 的当年公告称其采用“第二代 5 纳米技术”；节目里关于其他制程称谓、后续高规格芯片、Mac Pro 和产品库存策略的说法，属于嘉宾的推测与玩笑，并非发布计划。
谈到 Passkeys 时，两位嘉宾最在意的是每天都要重复的登录步骤。记密码、使用密码管理器、跨设备登录，对用户来说并不是偶尔才发生的工作；如果这一过程变得简单，收益会不断重复出现。
这里需要把类比与机制分开。节目用加密钱包帮助理解公私钥，但 Passkeys 不是一种“把脸当作网站密码”的做法，也不能据此承诺用某个助记词就能任意迁移所有凭据。Apple 的WWDC22 课程解释的是基于 WebAuthn 的公开标准：设备使用私钥响应验证，服务端保存公钥，生物识别等方式用于本地用户验证。相关服务还需要完成接入。
Justin 用仿冒登录页说明他期待的安全收益：用户输入传统密码时，可能把密码交给钓鱼网站，还可能在别处重复使用；Passkeys 让站点验证公钥对应的签名，不要求用户向页面交出一个可重复输入的秘密。自力则从日常体验追问，如果自己已经用 iCloud 钥匙串，还会减少哪些步骤。两人把安全机制、跨设备同步和服务端接入分开讨论，也承认能否普及取决于网站和应用的支持，不能仅靠 Apple 宣布功能。
因此，嘉宾期待的“少记密码”有明确技术基础，却不能消除所有账户安全问题。Passkeys 基于开放标准，服务端仍需接入；讨论发生在 2022 年，当时跨平台迁移等体验仍要继续观察。
设计奖作品提醒大家：一个小功能，也可以有完整的表达
讨论从系统能力切换到具体作品。Justin 说，观看这些应用和游戏，让自己重新想到刚入行时那种想做一个有趣东西的心情。
他们选择的例子并不都以功能繁多取胜。(Not Boring) Habits 将习惯记录变成有明显视觉、触觉和游戏感的体验；Overboard! 通过角色与叙事方式改变玩家参与推理的角度。两者在 Apple 的2022 年设计奖记录中属于“愉悦与趣味”类别的获奖作品。
节目还谈到《笼中窥梦》（Moncage），关注它通过不同视角产生空间连接与顿悟的感觉。这些作品在本场被讨论，并不意味着它们都获得了当年的奖项。
Justin 与自力在现场视频里把三个作品连起来看：(Not Boring) Habits 把每日打卡做成手势和反馈丰富的游戏式交互，Overboard! 让玩家从特别的叙事位置进入推理，《笼中窥梦》则让立方体不同面的场景在旋转时彼此接上。它们所需的技术和体量不同，却都展示了一个小概念如何被完整地表达。主持人另提到来自不同华人团队的提名作品，讨论的并非只有最终获奖名单。
小希选择了“专注面条”。她描述自己需要工具帮助安排工作，但传统计时器容易显得枯燥；把一段专注时间表现为做成一道食物，让完成任务变得更可感知。这个例子并不是证明某款应用能提高多少效率，而是说明同样的计时功能可以有不同的情绪体验。
她特别喜欢把手机盖下去当作锅盖的动作：短时间完成一碗面，较长的一段专注时间还能逐步加入配菜。奖励不是又一条完成通知，而是让任务时间在画面里留下变化。老麦在后段进一步谈到开发者从家庭生活取来的插画灵感，说明这份亲近感也来自产品背后的经验。
这里的共同判断是，小工具不必靠不断堆积功能才能形成差异。交互、视觉、反馈、文化和故事都可能成为用户愿意留下来的理由。这个主题也自然连接到最后关于独立开发的讨论。
未出现的头戴设备，为什么仍占据一段很长的讨论
AR 与 VR 是本场反复被提起的未来方向。嘉宾将 ARKit、RoomPlan、图像理解、空间定位、图形处理与芯片能力放在一起，设想这些积累是否会服务于新的设备形态。
他们讨论了可能的交互方式：如果不依赖传统手柄，手部动作、声音或视线能否成为输入？如果多人处于同一个空间体验，分享与协作会怎样发生？这些问题体现了产品设计者对现有输入方式局限的关注，却不是某款未发布设备的功能表。
主持人还提出，从物体扫描到房间扫描，是否能看出平台在逐步构建理解空间的能力。王巍回应说，平台有时会先积累数年的工具，再组合成新的产品。但两人都没有在节目中展示可证明具体未来硬件方案的证据。
嘉宾把这些工具视为未来设备的可能积累，但在 2022 年还没有证据把它们连接到一款确定的产品。RoomPlan 的设备条件、ARKit 图像能力也各有边界；几项技术并列出现，不意味着它们已组成完整的头显方案。
话题之后短暂延伸到 iPad 外设和 DriverKit。主持人问，若能更好连接硬件，创作者最想补上什么；小希再次回到游戏和实际创作体验。这个环节没有确定一个产品方案，但有一个一致的方法：新接口只有进入一个清楚的使用场景，才可能从技术机会变成产品机会。
开发者视角：看清平台方向，再决定今天学到多深
王巍把讨论重新拉回大会名称中的“开发者”。对不少用户来说，Keynote 结束后当天的关注就结束了；对开发者，Platforms State of the Union 和后续课程才刚开始。
但课程很多，并不代表每一项细节都需要立刻学透。一个产品若还要支持较旧系统，新能力可能暂时无法进入主流程。王巍因此建议把平台趋势与即时实现需求分开：知道两年之后工具可能怎样演进，有助于今天做选择；真正准备采用某个 API 时，再深入实现和兼容细节。
他将当年的观察归纳为“内部继续整合、外部持续开放”。内部包括跨设备共享的界面思路、Swift 与 SwiftUI、导航、布局、图表，以及开发工具；外部则包括行业标准、面向服务的接口与更公开的示例代码协作方式。这是他的分析框架，不是 Apple 官方对自身战略的完整定义。
具体技术中，他关注 Swift 正则表达式的声明式写法、包插件与构建流程，以及并发代码检查的演进。对已有代码来说，工具给出的警告可以成为逐步调整的线索；具体警告行为仍取决于编译器版本与项目设置。
他举正则表达式构建器为例：正则并非新发明，变化是 Swift 的表达方式可以把过去难读的模式拆成更可理解的组合；包插件则让格式检查等工作进入构建流程。谈到“对外开放”，他没有只说 Passkeys：HomeKit 相关的 Matter 标准意味着跨厂商协作，WeatherKit 和地图服务提供网络调用方式，Xcode Cloud 则把持续集成纳入平台服务。他还注意到 Food Truck 示例放在 GitHub 上，开发者可以观察项目怎样提交和演进，而不只是下载一个最终压缩包。以上是他由多个发布点归纳出的趋势，不等于每项服务对所有项目同样适用。
他举出的技术点还有 Swift Charts、NavigationStack、自定义布局、App Intents、WidgetKit、WeatherKit 与 Xcode Cloud。清单背后的逻辑不是“今年全部迁移”：有的改善 UI 表达，有的把开发和构建流程往平台服务延伸。作为已经维护旧系统版本的开发者，他认为先把平台方向看清，等项目真正能采用某项 API 时再研究细节，比追着每节课程立刻改代码更合适。
SwiftUI 的导航与布局也是重点。新的导航方式可以更直接地表达路径与跳转；跨平台工具则有机会让重复工作减少。但“共享工具”不等于“一次写完所有平台的设计”。自力后来对新应用的期待，仍需要面对不同设备的交互需求。
王巍还由 SwiftUI List 的内部变化，设想它将来是否可能更少依赖 UIKit。Apple 的iOS 16 发布说明只确认 List 不再使用 UITableView；SwiftUI 整体是否摆脱 UIKit、能否运行于 Apple 以外的平台，仍是另一层问题。
工具收益也以个人经验为限。王巍介绍自己项目升级后构建更快，并对 SwiftUI 调试支持感到欣喜；他同时提到 Beta 中遇到的问题。它们说明新工具值得试验，但不构成所有项目都会同样提速或适合立刻迁移的保证。
他的示例项目在新 Xcode 下 clean build 从约十分钟降到约八分钟，属于个人测得的迁移体验；同一轮尝试也遇到 CloudKit 相关崩溃。把“快了”与“还有 Beta 问题”并排看，才能理解他为什么建议观察工具趋势，同时对生产采用保留余地。
随后的问答没有回避 SwiftUI 的难点。Justin 追问性能调优像不像黑盒，王巍谈到一次状态变化可能引发过大的更新范围，并坦言自己尚未确认这一届是否已有对应的新工具。这个回答把未知留下来，也为 Day 3 更细的实践讨论提供了入口。
独立开发者怎样把作品持续做下去
在最后约 16 分钟，老麦谈到少数派观察与支持产品的经历。话题不再是哪个系统功能最亮眼，而是一个团队如何让有价值的作品持续更新。
他回顾选品时重视的原创、审美、实用和趣味。过去推荐一个新应用后，可能很快发现它停止维护；因此，一个作品是否找到可持续的收入与工作方式，和它最初是否吸引人同样重要。
他以自己接触过的工具产品和小团队为例，说明付费模式、合作分工与长期迭代可以相互支撑。案例反映的是当时各团队的经历，收入与人数也随经营变化；相同做法未必产生相同结果。
老麦讲到一个壁纸产品：最初作为团队内部实验，难以负担持续服务，后来由离职同事接手并调整付费方式，才有资源继续迭代。他又提到扫描工具的开发者，起因是想给备考的伴侣一个更轻便的扫描体验；这段来历帮助产品被理解，后续则仍要靠服务与更新留住用户。案例之间没有统一的变现公式，但都说明“做出来”只是开始。
这些案例还回答了“推广是否只能靠买流量”。老麦说，扫描工具的开发者曾写下为伴侣制作应用的缘由，读者先理解他为什么要减掉繁琐操作，才开始讨论产品。一个由少数派内部实验而来的壁纸应用，则在原团队难以长期承担服务成本时，通过交接与付费方式调整继续维护。他另提到一个小型扫描团队在异地协作、并在系统扫描能力增强后寻找新产品方向。它们分别说明故事、收入和产品更新是三项不同的工作，不能把一次传播当成长期经营。
设计背后的故事是他反复强调的部分。以谜底时钟为例，他谈到开发者为了表现某种灯光效果，了解了制作方式与相关视觉文化；以专注面条为例，他谈到生活经验怎样进入画面与反馈。产品故事在这里不是凭空包装，而是让用户理解开发者为什么把一个细节做成这样。
他建议开发者自己保留并讲述这些过程，而不只是等待媒体替自己写一份报道。一个扫描工具为什么开始做，一个原本平常的功能为什么被重新安排，往往比堆砌形容词更容易让目标用户理解产品。
第二个重点是早期用户。下载量很大不一定意味着可持续，人数较少也不意味着没有价值；关键是是否找到明确需要这项服务的人，以及提供的体验是否值得他们持续支持。老麦特别强调反馈关系，因为产品方向的修正和长期改进，往往来自那些认真使用它的人。
他还回忆一个接受过平台交流指导的独立游戏团队：开发者据反馈继续打磨，后来获得推荐。这个经历说明主动寻求具体意见可能有帮助，却不建立“参加辅导就会被推荐”的因果保证。对于早期用户，老麦强调先看他们是否真正需要、是否愿意持续付费，再看绝对数量；少量愿意反复指出问题的用户，也可能比一次大量下载更能帮助团队决定下一步。
第三个重点是合作。独立开发不一定只能由一个人承担设计、编程、推广与服务全部工作；有互补能力的人可以合作，但需要把利益与发展方向说清楚。他还介绍了少数派当时希望通过社区加强开发者与用户直接沟通的计划，那是 2022 年的设想。
最后，嘉宾与主持人都谈到自己接触平台交流、辅导或推荐支持的经历。它们可以提供帮助，却不保证参与后一定获奖、被推荐或盈利。更可靠的启发是：作品之外，还需要建立反馈、合作与沟通，使产品有机会从一次创作变成持续工作。