如何用 AI 做 iOS 应用开发

iOS 应用被打回，往往栽在平台规范上

iOS 应用的难点常常不在功能本身，而在 Apple 平台的一整套隐性规范。UIKit、SwiftUI、SnapKit 之间该选哪个、能否混用，组件选型一开始就要想清楚；界面要避开刘海和底部安全区、按钮热区不能太小、间距要守住 8pt 体系；Dynamic Type 放大后文字不能截断、深色模式下颜色要用语义色、VoiceOver 要能正常读出。这些 HIG 要求平时容易被忽略，却直接关系到体验质量和能否顺利上架。

这个技能能帮你把住哪些关

它把 Apple 平台体验质量拆成一组可核对的检查项。组件层面，指导 UIKit、SwiftUI 和 SnapKit 之间的选型，UIKit 项目要迁移或混用 SwiftUI 时也能给出统一决策。布局层面，校验安全区域、触摸目标和 8pt 间距体系，避免按钮热区和安全区出问题。体验层面，覆盖 Dynamic Type、深色模式和 VoiceOver 要求，确保放大字号、暗色和读屏都正常。集成层面，提供导航、权限请求、生命周期和系统集成的检查清单。它贯穿 HIG 合规、系统手势保留和语义颜色使用，从新建界面到上线前核对都能搭得上。

怎么用它

用法是把应用场景、界面需求和技术栈用自然语言说清楚，由它给出组件决策和检查清单。例如可以这样对它说：

它适合这些场景：新建 iPhone 应用、需要确定 Tab、导航栈和页面结构；已有界面要符合 Apple HIG、无障碍和深色模式规范；UIKit 项目要迁移或混用 SwiftUI、需要统一组件决策；上线前核对权限请求、动态字体和系统交互行为。

大家常问

SwiftUI 和 UIKit 的差别是什么？

UIKit 是命令式框架，靠开发者手动创建 UIView、配置 Auto Layout 约束、在回调里调 setText 和 reloadData 来同步状态；SwiftUI 是声明式框架，用 @State、@Published 等数据源描述 View body，框架按状态自动差分重绘。底层的 App 生命周期、签名和上架审核两者完全共享，差异集中在"谁来驱动 UI 更新"这一层。

iOS 开发里为什么要严守 Safe Area？

Safe Area 是 iOS 系统按当前设备形态和界面状态动态计算的安全可视区域，排除了刘海、状态栏、Home Indicator 和系统手势区。来电状态栏、横竖屏切换、iPad 分屏都会触发 safeAreaInsets 变化；不绑定 Safe Area 的硬编码布局会被遮挡或与系统手势冲突，App Review 4.1 明确把这点作为审核检查项。

Dynamic Type 是什么，为什么 iOS 应用要适配它？

Dynamic Type 是 iOS 7 起的系统级文字大小自适应：用户在设置里调整字号后，系统通过 UIContentSizeCategory 通知前台 App 重新计算字号。UIKit 用 UIFontMetrics 加 adjustsFontForContentSizeCategory 自动响应，SwiftUI 用 @Environment(\.sizeCategory) 与 @ScaledMetric 联动。不适配会在大字号下文字被截断，也会在 App Review 的无障碍审查中被追问。

iOS 应用为什么要适配深色模式？语义色和写死的固定色值差别是什么？

iOS 13 起系统会通过 UITraitCollection 注入当前外观模式，深色模式不是开关而是渲染管线的输入参数。语义色（如 label、systemBackground）写在 Assets Catalog 的 colorset 里，编译期落进 .car 文件，运行时由 CoreUI 按当前 userInterfaceStyle 自动选色；写死的固定色值不会随系统切换，深色模式下会出现对比度塌陷和可读性问题。