iOS 原生界面设计规范
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @user_fccf428b/ios-hig-design。
技能介绍
要解决的问题
跨端团队把 Android 习惯搬进 iOS 是最常见的返工来源:抽屉式导航、顶部 Tab、FAB 出现在 iPhone 上会让用户觉得「这不是原生应用」。更隐蔽的问题是硬编码颜色和字号——在 Dark Mode 下文字对比度崩坏,Dynamic Type 调到最大时布局溢出。另一类失败发生在细节:触控目标小于 44pt、忽略安全区导致内容被刘海遮挡、随意覆写边缘右滑返回手势。
核心能力
这套技能把 Apple HIG 拆成可执行的检查框架,而不是泛泛的原则列表。
- 三支柱判断:以 clarity、deference、depth 作为每个设计决策的底层依据,而非机械套用规则
- 原生习惯清单:
NavigationStack替代已废弃的NavigationView,.alert()/.confirmationDialog()替代自绘弹窗,.swipeActions处理列表行内操作 - 控件决策表:表单输入匹配
.keyboardType与.textContentType,选择场景区分 picker、segmented control 和 action sheet,破坏性操作强制红色加确认 - 图标体系:统一使用
Image(systemName:)与 SF Symbols,随字号缩放;App 图标导出 1024px 并遵循 superellipse 掩码 - 手势与触觉:三类触觉反馈(impact / notification / selection)对应不同语义,触发前调用
.prepare()降低延迟 - 无障碍:
.accessibilityLabel/.accessibilityValue/.accessibilityHint覆盖所有交互元素,对比度不低于 4.5:1,不以颜色单独传达含义
关键步骤:先用 6 项 Quick Diagnostic 快速定位硬伤,再按原生习惯项(语义色、系统控件、标准手势、SF Symbols)逐项加分,目标分 10/10。每个模块都指向 references/ 下的深挖文档——控件细节看 components.md,表单看 keyboard-input.md,交付前无障碍检查看 accessibility.md。
适用边界
它只约束「如何符合平台习惯」,不负责业务逻辑和交互创新。自定义手势只能用于补充操作,绝不能替换系统保留手势;.ignoresSafeArea() 只应用于背景层。App Store 会因辅助功能不可用而拒审,无障碍不是可选项。隐私权限、Widget、Siri Shortcuts 等屏幕外系统面由 privacy-permissions.md、widgets-extensions.md、system-integration.md 三份文档单独覆盖。
使用场景
- 用 SwiftUI 重写列表页,确认 `NavigationStack` 与 `.swipeActions` 的用法是否符合原生习惯。
- 设计稿进入开发前自查:触控目标是否达到 44×44pt,深色模式下语义色是否仍可读。
- 上线前给读屏用户补齐 VoiceOver 标签,让 `.accessibilityLabel` 覆盖所有交互元素。
- 从 Android 迁移到 iOS,把顶部 Tab 和抽屉导航换成 Tab Bar 与标准 push 导航。
适合人员
- 独立 iOS 开发者:一人负责整包、没有设计同事把关,需要按 HIG 逐项自检后再提审。
- 跨平台工程师:同一交互要同时落到 Android 与 iOS,需要明确哪些习惯不能照搬。
- SwiftUI 新手:能写页面但不确定系统控件与自绘控件的取舍,需要带代码示例的对照清单。
- 设计系统维护者:要统一团队的控件、图标与触觉反馈规范,避免每个模块各写一套。