参与学生移动应用大赛有感 - 肘子的 Swift 周报 #161
内容提要
作者作为2026年移动应用创新赛评委，观察到AI大幅降低开发门槛，女性及非计算机专业参赛者比例显著上升，但也导致功能堆砌、需求趋同、缺乏工程深度等问题；小学生组坚持手写代码的探索精神尤为可贵。周报还推荐了SwiftPM多版本共存提案、Vapor的SSE实现、SwiftData回滚陷阱、Swift 6高速PSB解码器、SwiftUI动画机制与layoutPriority解析，以及AI时代技术栈选择等文章。
延伸解读
AI 降低门槛后的双面效应
文章指出，AI 让没有编程背景的学生也能独立完成应用，参赛者中女性比例明显上升，非计算机专业队伍增多。但实现成本降低也带来副作用：部分团队堆砌缺乏辨识度的功能，过度依赖 AI 代替真实调研，导致需求趋同，尤其面向弱势群体的作品出现“刻板需求”。这提示读者，工具普及不等于产品能力提升，克制与真实调研仍是关键。
工程深度决定作品能否走出 Demo
作者观察到，一些团队虽有绝佳创意，却因缺乏扎实工程基础，难以深化实现、构筑技术壁垒，最终止步于参赛 Demo。这与周报推荐的技术内容形成呼应：SwiftData 保存失败后的回滚陷阱、SwiftPM 多版本共存提案、PSB 解码器的性能优化，都说明真实产品需要处理异常、依赖与性能等工程问题，而非仅靠 AI 生成界面和功能。
手写代码的探索价值
小学生组中，不少孩子坚持在 Swift Playgrounds 一行行手写代码，作品虽有过时语法、混乱文件组织和不成熟实现，但作者认为这种不断尝试、犯错和修正的过程，比过度依赖 AI 包装出的精致成果更能带来扎实成长。这提醒读者，在 AI 辅助开发普及的背景下，理解代码运行机制和保留动手调试经验，仍有不可替代的学习价值。
技术栈选择因 AI 而更多样
周报中关于 AI 时代技术栈的讨论显示，AI 并未让技术路线趋于统一。Marc Prud’hommeaux 因 AI 承担更多编码工作而转向重视可移植性的 Rust；Junda Ong 则从相同前提出发，认为可直接用 Swift/SwiftUI 和 Kotlin/Compose 分别构建原生应用。Shopify 也从 React Native 转回原生开发。读者可从中看到，AI 降低维护成本后，原生与跨平台方案各有其合理场景。
Q&A
2026年移动应用创新赛上，AI普及带来了哪些积极变化？
AI大幅提升了参赛作品的视觉和功能完成度，同时降低了开发门槛，使参赛者构成更多元：女性选手比例达三分之一到一半，许多队伍由无计算机背景的学生（尤其是设计专业）组成，Coder身份边界变得模糊。
学生过度依赖AI开发应用会带来哪些问题？
文章指出三个问题：一是功能堆砌，缺乏辨识度；二是过度依赖AI代替真实调研，导致需求趋同，尤其面向弱势群体的作品出现刻板需求；三是缺乏工程基础，创意难以深化，止步于参赛Demo。
小学生组在移动应用创新赛中的表现有什么特别之处？
小学生作品创作目标纯粹，灵感来自生活小事或奇思妙想；不少孩子坚持在Swift Playgrounds中手写代码，尽管语法过时、文件组织混乱，但这种不断尝试、犯错和修正的探索过程比AI包装的精致成果更有价值。
SwiftData保存失败后为什么需要特别注意回滚？
save()失败后，未保存的修改可能残留在Context中，导致后续不相关修改也无法保存，或暂时性错误在后续保存时被意外提交。rollback()并非总能按预期工作，直接回滚未处理的删除操作可能导致恢复后的对象读取时崩溃，回滚前调用processPendingChanges()可避免。
SwiftUI动画在iOS和macOS上的底层执行机制有何不同？
在测试的macOS环境中，SwiftUI动画由主线程持续推进，主线程阻塞会导致动画停顿；而在iOS/iPadOS上，SwiftUI使用独立的AsyncRenderer线程计算动画值，即使主线程被阻塞，动画仍能继续，阻塞AsyncRenderer线程才会使动画停顿。
AI时代为什么有人依然坚持用Swift和Kotlin开发原生应用？
Junda Ong认为，既然AI降低了编写和维护代码的成本，直接使用Swift/SwiftUI和Kotlin/Compose分别构建原生应用更划算，维护两份实现并通过共享测试用例验证一致性，可能比引入跨平台技术栈更简单。Shopify也从React Native转回原生Swift和Kotlin，理由相同。
