在发布原生 App 时，如何按 iOS 与 Android…

为原生或跨平台 App 设计 UI 时，判断哪些模式是平台强制约定、iOS 与 Android 差异在哪、以及何时该统一设计。

适用场景

解决思路

1. 识别哪些 UI 模式属于平台强制约定，梳理 iOS 与 Android 之间的有意义差异，并帮助团队决定何时分别遵循各平台、何时采用统一的跨平台设计。
2. 导航：iOS 从屏幕左边缘右滑返回、左上角返回按钮；Android 使用系统返回手势（任一边缘滑动）或预测性返回，应用栏中放返回箭头。
3. 导航：iOS 主结构为底部标签栏，iPad 上用侧边栏；Android 为底部导航栏或导航抽屉（汉堡菜单）。
4. 导航：iOS 基于栈，每个标签页有独立历史栈；Android 全应用单一返回栈，标签页默认不保留独立历史。
5. 导航：iOS 底部导航最多 5 个标签、标签可不带文字；Android 为 3–5 个标签且必须带文字。
6. 导航设计含义：iOS 用户期望从左边缘滑动始终返回，需保留该手势区域；Android 由系统返回手势处理，应用内左滑可用于抽屉而不冲突。
7. 控件：开关在 iOS 用 UISwitch（胶囊形、列表中右对齐）；Android 用 Switch（滑块加轨道，可内联或置于列表）。
8. 控件：破坏性确认在 iOS 用底部操作表（action sheet）并带红色破坏性选项；Android 用带文字按钮的对话框，破坏性操作使用红色/错误色调。
9. 控件：日期/时间选择器在 iOS 用滚轮选择器或内联日历；Android 用日历并可选文字输入。
10. 控件：选择菜单在 iOS 用选择器滚轮或操作表；Android 用暴露式下拉菜单或模态底部面板。
11. 控件：主按钮在 iOS 为填充矩形、表单中占满宽度；Android 为填充按钮（Material 3 默认圆角）。
12. 控件：浮动操作在 iOS 不是约定，应使用上下文按钮；Android 用 FAB 作为主表面操作，位于右下角。
13. 控件：下拉刷新在 iOS 用原生 UIRefreshControl；Android 用 SwipeRefreshLayout，手势相同但视觉不同。
14. 排版：iOS 系统字体为 SF Pro（文本）/ SF Compact（手表）；Android 为 Roboto / Google Sans。
15. 排版：iOS 要求支持动态字体（Dynamic Type），用户可系统级控制文字大小；Android 使用可缩放像素（sp），必须尊重系统字体缩放。
16. 排版：iOS 使用其文本样式（Large Title、Title 1–3、Body 等）；Android 使用 Material 字体层级（Display、Headline、Title、Body、Label）。
17. 排版：两个平台都要求 App 尊重用户的系统字体大小偏好；不缩放的硬编码点值是两平台上的无障碍失败。
18. 手势：滑动删除在 iOS 是表格视图中的标准操作；Android 为滑动消除/归档（视上下文而定）。
19. 手势：长按在 iOS 触发 Peek/上下文菜单（iOS 13+ 上下文菜单）；Android 进入上下文操作模式，长按用于选择。
20. 手势：下拉刷新与双指缩放两平台均为标准操作。
21. 手势：返回滑动在 iOS 为保留手势，始终用于返回；Android 为预测性返回手势，应用可选择加入预览。
22. 视觉：图标库在 iOS 用 SF Symbols（数千个、可变字重、自动缩放）；Android 用 Material Symbols（圆角、描边、锐利变体）。
23. 视觉：圆角在 iOS 更大，使用“squircle”超椭圆曲线；Android 适中，Material 3 在组件上使用明显圆角。
24. 视觉：系统颜色在 iOS 为随深/浅色自动适配的动态颜色；Android 为 Material You 动态取色，由壁纸生成。
25. 视觉：模态呈现在 iOS 为从底部滑入并带抓手的面板；Android 为标准或模态底部面板，或全屏对话框。
26. 严格遵循各平台约定的场景：原生或接近原生的 App，平台流畅度是重要质量信号（银行、健康、工具类 App）。
27. 严格遵循各平台约定的场景：与 OS 功能深度集成的 App（分享面板、小组件、Siri/Google Assistant）。
28. 严格遵循各平台约定的场景：拥有大量熟悉平台的高级用户的 App。
29. 采用统一设计的场景：各平台功能高度对等、设计一致性可降低维护成本的产品。
30. 采用统一设计的场景：跨设备连续性重要的产品（例如用户在 iPhone、Android 与 Web 之间切换）。
31. 采用统一设计的场景：用户主要与产品自身设计系统而非 OS 可供性交互的 B2B 工具。
32. 混合方案：多数跨平台产品采用中间路线——统一的视觉与组件语言，但在导航（系统级约定）、系统控件和手势冲突处做平台特定适配。产品看起来像自己，行为像 OS。
33. 不要：在 Android 上使用会与上滑手势冲突的底部标签栏。
34. 不要：抑制 iOS 的滑动返回手势——用户触发却无反应会困惑并降低信任。
35. 不要：在 Android 上使用 iOS 操作表，或在 iOS 上使用 Android 对话框作为主要决策模式。
36. 不要：忽略任一平台的动态字体/SP 缩放——固定文字大小是无障碍失败。
37. 不要：无理由地把 FAB 模式移植到 iOS——它在 iOS 没有原生先例。
38. 最佳实践：在每个主要设计阶段前阅读当前平台指南；iOS HIG 与 Material 3 更新频繁。
39. 最佳实践：在提出方案前，审计各平台原生 App 中你正在设计的交互。
40. 最佳实践：维护组件映射文档：设计系统怎么称呼、iOS 怎么称呼、Android 怎么称呼。
41. 最佳实践：在各平台真机上测试——模拟器行为与手势处理与物理设备不同。
42. 最佳实践：对平台特定模式存疑时，使用 OS 自带的做法：它已被测试、已被熟悉。

适用边界 · 注意事项

• 需要与 OS 功能深度集成、平台流畅度是核心质量信号、或用户以熟悉平台的高级用户为主时，不应强行统一设计。
• 不要用平台 A 的决策模式（如 iOS 操作表、Android 对话框）替代平台 B 的原生模式。
• 不要忽略动态字体/SP 缩放，也不要无理由地把 FAB 等无原生先例的模式移植到另一平台。