Platform Conventions 是一项面向跨平台产品设计的设计规范技能，核心是帮助团队在 iOS Human Interface Guidelines（HIG）与 Android Material Design 3 之间做出正确取舍。
用途 该技能用于识别哪些 UI 模式属于平台强制约定，梳理 iOS 与 Android 之间真正有意义的差异，并帮助团队判断何时应分别遵循各平台约定、何时适合采用统一的跨平台设计。它适用于发布原生 App 的场景。
为什么平台约定重要 用户绝大部分时间都花在操作系统及其原生 App 上，已经对导航、控件和交互模式形成了牢固的肌肉记忆。当产品在没有明确理由的情况下偏离平台约定时，用户不得不额外花费认知成本去理解产品，而不是直接使用产品。
主要差异：iOS（HIG）与 Android（Material Design 3）
导航
- 返回导航：iOS 为从左边缘右滑；返回按钮位于左上角。Android 为系统返回手势（从任一边缘滑动）或预测性返回；应用栏中显示返回箭头。
- 主要结构：iOS 底部 Tab bar，iPad 上为侧边栏。Android 底部导航栏或导航抽屉（汉堡菜单）。
- 导航历史：iOS 基于栈，每个 Tab 拥有独立栈。Android 全应用单一返回栈；默认情况下 Tab 不维护独立历史。
- 底部导航：iOS 最多 5 个 Tab，不要求标签文字。Android 3–5 个 Tab，要求标签文字。
- 设计启示：iOS 用户期望从左边缘滑动总是返回，应保留该手势区域。Android 上该系统返回手势已处理返回，应用内从左边缘滑动可用于抽屉而不会冲突。
控件与组件
- 开关：iOS 为 UISwitch，胶囊形，在列表中右对齐。Android 为 Switch，滑块与轨道，可内联或出现在列表中。
- 破坏性确认：iOS 为底部操作表（action sheet），破坏性选项为红色。Android 为带文字按钮的对话框，破坏性操作用红色/错误色。
- 日期/时间选择器：iOS 为滚轮选择器或内联日历。Android 为日历加文本输入替代。
- 选择菜单：iOS 为选择器滚轮或操作表。Android 为展开式下拉菜单或模态底部面板。
- 主按钮：iOS 为填充矩形，表单中占满整行。Android 为填充按钮，M3 默认圆角。
- 悬浮操作：iOS 非惯例，应使用上下文按钮。Android 为 FAB，主要表面操作，位于右下角。
- 下拉刷新：iOS 为原生 UIRefreshControl。Android 为 SwipeRefreshLayout，手势相同、视觉不同。
排版
- 系统字体：iOS 为 SF Pro（文本）/ SF Compact（手表）。Android 为 Roboto / Google Sans。
- 动态字体：iOS 要求支持，用户可系统级控制文字大小。Android 为可缩放像素（sp），必须遵循系统字体缩放。
- 字体比例：iOS 使用文本样式（Large Title、Title 1–3、Body 等）。Android 使用 Material 字体比例（Display、Headline、Title、Body、Label）。
- 两个平台都要求 App 尊重用户的系统字体大小偏好。不缩放的硬编码点数是两个平台上的可访问性失败。
交互与手势约定
- 滑动删除：iOS 在表格视图中为标准操作。Android 为滑动关闭/归档，视上下文而定。
- 长按：iOS 为预览/上下文菜单（iOS 13+ 上下文菜单）。Android 为上下文操作模式，长按进入选择。
- 下拉刷新：两平台均为标准。
- 捏合缩放：两平台在地图、图片中均为标准。
- 返回滑动：iOS 保留，始终用于返回导航。Android 为预测性返回手势，应用可选择加入预览。
视觉与图标
- 图标库：iOS 为 SF Symbols（数千个，可变字重，自动缩放）。Android 为 Material Symbols（圆角、描边、尖锐变体）。
- 圆角：iOS 圆角更大，采用“超椭圆”曲线。Android 适中，Material 3 在组件上使用明显圆角。
- 系统颜色：iOS 为动态颜色，自动适配深色/浅色。Android 为 Material You 动态取色，由壁纸生成。
- 模态呈现：iOS 为从底部滑入的面板，带抓手。Android 为底部面板（标准或模态）或全屏对话框。
跨平台设计决策
何时严格遵循各平台
- 原生或接近原生的 App，平台熟悉度是关键质量信号（银行、健康、工具类 App）。
- 深度集成 OS 功能的 App（分享面板、小组件、Siri/Google Assistant）。
- 拥有大量平台资深高级用户基础的 App。
何时适合统一设计
- 各平台功能对等度高、设计一致性可降低维护成本的产品。
- 跨设备连续性重要的产品（例如用户在 iPhone、Android 或网页之间切换）。
- B2B 工具，用户主要与产品自身设计系统交互，而非 OS 提供的能力。
混合方案 多数跨平台产品采取中间路线：统一的视觉与组件语言，但在导航（系统级约定）、系统控件和手势冲突方面做平台特定适配。产品看起来像自己，行为上像操作系统。
不应做的事
- 不要在 Android 上使用底部 Tab bar，如果它与上滑手势导航冲突。
- 不要屏蔽 iOS 的滑动返回手势——用户触发后若无反应会困惑，信任度下降。
- 不要把 iOS 操作表用在 Android，也不要把 Android 对话框用在 iOS 作为主要决策模式。
- 不要忽视任一平台上的 Dynamic Type / SP 缩放——固定文字大小是可访问性失败。
- 不要无理由地把 FAB 模式移植到 iOS——它在 iOS 上没有原生先例。
最佳实践
- 在每个重大设计阶段前阅读当前平台指南；iOS HIG 和 Material 3 更新频繁。
- 在设计某个交互前，先审查各平台上的原生 App 的做法，再提出方案。
- 维护组件映射文档：设计系统如何称呼某物、iOS 如何称呼、Android 如何称呼。
- 在每个平台的真实设备上测试——模拟器行为与手势处理和物理设备不同。
- 对平台特定模式存疑时，采用 OS 中已发布的方案：它已经过测试，也已经为用户所熟悉。