iOS_Mac Catalyst(iOS 设计规范翻译)


翻译文章 / 多领域 / 观点
泽泽先生 翻译,如需商业用途或转载请与泽泽先生联系,谢谢配合。

这是 iOS 系统设计规范翻译第二篇,热烈欢迎理性讨论,如有翻译不到位之处请批评指正。

原文:Mac Catalyst




When you use Mac Catalyst to create a Mac version of your iPad app, you make your app available to a new audience while giving existing users the opportunity to enjoy it in a new environment.

当你使用 Mac 催化剂为你的 iPad 应用程序创造 Mac 版本时,你既让你的应用程序获得了新用户,也给了老用户享受新的使用环境的机会。For developer guidance, see Creating a Mac Version of Your iPad App.

Before You Start

在你开始(为你的 iPad 应用程序创造 Mac 版本)之前

Most iPad apps are great candidates for adaptation, but some rely on iPad features that don’t exist on a Mac. For example, if your app’s essential features require iPad capabilities like gyroscope, accelerometer, or rear camera, iOS frameworks like HealthKit or ARKit, or the app’s main function is something like navigation, it might not be suited for the Mac.

绝大多数 iPad 应用程序都是进行改编的(至 Mac 版本)好的候选者,但也有一些(应用程序)的依赖 Mac 上不存在的 iPad 功能,例如,如果你的应用程序重要的功能 要求 iPad 具备像陀螺仪、加速器,或者后置摄像头等(硬件),需要使用在 iOS 系统框架内的  HealthKit 或 ARKit ,或者这个应用程序的主要功能是类似于导航这样的功能,这可能就不适合(改编至) Mac。

For apps that don’t require iPad-only features, the best way to ensure that your app will work well on a Mac is to make sure it works well on iPad. In particular, your app should:

对那些不要求 iPad 专属功能(专属硬件与软件)的应用程序来说,确保你应用程序能够很好的在 Mac 上工作的方式就是它能够在 iPad 上很好的工作,你的应用程序尤其要做到以下几点:

  • Support multitasking. Apps that do a good job scaling the interface to support Split View, Slide Over, and Picture in Picture approach the ultimate goal of supporting the extensive window resizability that Mac users expect.

  • 支持多任务处理。应用程序能够很好的进行缩放从而支持 Split View, Slide Over 及画中画等功能最终达到 Mac 用户期望的自如调整窗口大小的目标;


不清楚 Split View, Slide Over, and Picture in Picture 之间区别的同学,推荐大家看看这篇文章:《SlideOver、Split View和画中画的区别 iOS 9 分屏功能》

  • Support drag and drop. When you support drag and drop in your iPad app, you get the same support on the Mac for free.

  • 支持拖放。当在你的 iPad 上支持拖放时,那么你在 Mac 上也免费支持了此项操作。


Support drag and drop(拖放):如下图所示,拖放指的是类似于将网页图片拖动至邮件中等跨应用程序的内容拖动操作。想进一步了解的同学们可以进入 iOS 设计规范《Drag and Drop》

  • Respond to keyboard shortcuts, including common macOS shortcuts. Even though a keyboard may not always be available to your iPad app, both iOS and macOS users appreciate using keyboard shortcuts to streamline their interaction with your app

  • 响应键盘快捷键。包含 MacOS 常用的快捷键,虽然键盘可能不总是对 iPad 应用程序有用,但 iOS 和 macOS  用户都喜欢使用键盘快捷键来简化他们与应用程序之间的交互。

Plan Enhancements for Your Mac App

计划为你的 Mac 应用程序增加功能

When you use Mac Catalyst to create a Mac version of your iPad app, you get automatic support for fundamental Mac features, such as:

当你使用 Mac 催化剂来为你的 iPad 应用程序创造 Mac 版本时,你将自动获得对 Mac 基本功能的支持,类似于:

  • System Preferences

  • 系统偏好设置

  • Keyboard, trackpad, mouse, and Touch Bar input, including key focus and keyboard navigation

  • 键盘,触摸板,鼠标,内置触控条,包含光标和键盘导航

  • Window management

  • 窗口管理

  • Rich text interaction, including copy and paste and contextual menus for editing

  • 富文本交互,包含复制、粘贴及用于编辑的情景菜单。

  • File management

  • 文件管理


Contextual Menus


A contextual menu, or shortcut menu, gives people access to frequently used commands related to the current context. A contextual menu is revealed by Control-clicking a view or selected element in an app. For example, Control-clicking selected text in TextEdit displays a contextual menu containing text-specific menu items for initiating actions like changing the font and checking spelling.


想要进一步了解的同学们可以进入 macOS 设计规范《Contextual Menus》部分。

In addition, many system-provided UI elements automatically convert from iOS to macOS. For example, you get macOS-appropriate versions of the following iOS-provided items:

除此之外,很多系统提供的 UI 元素自动将由 iOS 改变至 macOS ,例如,你将在 iOS 提供的项目中获得适用于 macOS 的如下版本:

  • Split view

  • 分屏

  • File browser

  • 文件夹

  • Activity view

  • 活动视图

  • Form sheet

  • 表格

  • Contextual actions

  • 情景操作

To ensure that your app gives people a rich Mac experience, it’s essential to enhance this foundation and go beyond simply displaying your iOS UI in a macOS window. Before you dive in and update specific views and controls, become familiar with the main differences between the platforms so that you can create an app that feels at home on the Mac. (For comprehensive design guidance for macOS apps, see macOS Human Interface Guidelines.)

为了确保你的应用程序能够给人们丰富的 Mac 体验,当然重要的是增强基础,而不仅是在 Mac 窗口陈列 iOS 的 UI 元素,在你深入了解并更新特定视图和控件之前,先熟悉两个平台之间的主要不同,这样你就可以在 Mac 上创造出让人感觉宾至如归的应用程序。

iOS and macOS each define design patterns and conventions for user interaction that are rooted in the different ways people use their devices. For example, iOS conventions such as swipe to delete, action sheet commands, and controls at the bottom of the screen are optimized for to

uch interactions on a handheld device. In a similar way, macOS conventions such as dedicated keys and keyboard shortcuts, menu commands, and controls at the top of the window are optimized for keyboard, mouse, and trackpad interactions and a separate display.

iOS 和 macOS 植根于用户使用设备的不同方式各自定义了用户交互的设计模式和惯例,类似于滑动删除,动作列表命令框,屏幕底部控件等 iOS 惯例是 iOS 系统对手持设备进行的针对性优化结果。按同样的方式,macOS 惯例是专用键和键盘快捷键,菜单命令,窗口顶端控件等,这些(控件设置)也都是对鼠标、触控板和单独显示等交互进行的专门优化。


1.swipe to delete(滑动删除):如下图所示,无论是 Android 系统还是 iOS 系统,滑动删除都是很常见的操作。

2、Action Sheet(动作菜单/动作面板/行动列表):“是由用户操作后触发的一种特定的模态弹出框 ,呈现一组与当前情境相关的两个或多个选项,用户可以使用 Action Sheet 启动某个任务,或者确认是否开始执行某个可能具有破坏性的操作。Action Sheet 属于 iOS 规范,近年来 Android 平台也出现了类似功能的控件。”——摘自《这个控件叫:Action Sheet/动作菜单/动作面板/行动列表》(,推荐大家关注这个专栏,里面有很多关于控件的知识。

The conventions and design patterns that have the biggest impact on adaptation can be grouped into four key areas.

对转换( iOS 至 macOS 过程)的惯例和设计方式有最大影响的部分可以总结为以下四个方面:

Navigation. Many iOS and macOS apps organize data in similar ways, but they use different controls and visual indicators to help people understand and navigate through the data. For specific guidance, see Adopt macOS App Structure and Navigation Conventions.

导航。大多 iOS 和 macOS 应用程序以类似的方式组织数据,但他们使用不同的控件和视觉指示器来帮助人们理解和浏览数据。

User input and interactions. Although both iPad and Mac accept user input from a range of devices — such as the Multi-Touch display, keyboard, mouse, and trackpad — touch interactions inform iOS conventions, whereas keyboard and mouse interactions originated the conventions for macOS. For related guidance, see Support macOS User Interactions.

用户输入和交互。虽然 iPad 和 Mac 都支持人们从一系列设备上进行输入——类似于多点触控显示器,键盘,鼠标和触控板——触摸交互决定了 iOS 的设计惯例,而键鼠搭配决定了 Mac 的设计惯例。

Menus. Mac users are familiar with the persistent menu bar and expect to find all app commands in menu bar menus. iOS, on the other hand, doesn’t have a persistent menu bar, and iOS users expect to find app commands in the app’s UI. For related guidance, see Put App Commands into Menus.

菜单。Mac 用户对持久(存在)的菜单栏很熟悉,并期待在菜单栏中找到所有应用程序命令,从另一方面来说,iOS 没有一个持久(存在)的菜单栏, iOS 用户期望通过应用程序中的 UI 元素来找到应用程序的命令。


persistent menu bar 应该是指如下图所示的类似于 WPS 的常驻菜单栏这种形式的菜单栏。

Content scaling. Text in the macOS version of an iPad app looks the same as it does in iOS because SF fonts are available on both platforms. However, the baseline font size in iOS is 17 pt, whereas the most common font size in macOS is 13 pt. To ensure that your text and interface elements are consistent with the macOS display environment, iOS views automatically scale down to 77%. For related guidance, see Typography.

内容缩放。iPad 应用程序的 Mac 版本中的文本和其在 iOS 中看起来一样,因为 SF (San Francisco)字体在两个平台上均可使用,然而,在 iOS 中的基础文字大小是 17 pt ,在 macOS 中最常见的字体大小是 13 pt ,为了确保你的文本和界面元素在 macOS 环境呈现的(与 iOS)一致,iOS 视图自动按比例减小至 77%。

In addition to adopting macOS interaction and design conventions, you need to update your visual design and layout to take advantage of the wider Mac screen in ways that give macOS users a great experience. For example, you might:

除采用 macOS 交互和设计惯例外,你需要更新你的视觉设计并通过(对 iPad 应用程序)合理布局有效利用 Mac 更宽的屏幕从而给 Mac 用户一个很好的体验,例如,你可能可以:

  • Divide a single column of content and actions into multiple columns

  • 将单列内容和操作划分为多列

  • Present an inspector UI next to the main content instead of within a popover

  • 在主内容旁边放置查看器界面元素而非弹出框旁边



我的问题:不知道 inspector UI 指的是什么,哪位知道的小伙伴可以不吝赐教下。

  • Simultaneously show two or more levels of an app’s hierarchy

  • 在一个 APP 层次结构中同时显示两个或更多层级

For more guidance, see Visual Design Considerations.

Ideally, viewing your iPad app from the perspective of macOS design conventions can suggest ways to improve the iOS version, too.

Although you want to make sure that each version remains true to the conventions of its platform, take this opportunity to revisit the design of your original app.Especially if your iPad app originated on iPhone, consider reassessing the ways you lay out views and controls to see if there are places where you can make better use of the large iPad screen.

虽然你希望保证每个版本都遵循平台惯例,但还是要抓住这个机会重新审视原应用程序(非本平台应用程序)的设计。理想情况下,通过 macOS 设计惯例视角审视你的 iPad 应用程序,也可以提出改进 iOS 版本的方法。

特别是源于 iPhone 的 iPad 应用程序,重新考虑界面视图布局和控件(位置),看是不是能够更好地利用 iPad 的大屏幕。

Adopt macOS App Structure and Navigation Conventions

采用 macOS 应用程序结构和导航惯例

Well-designed app navigation reflects the structure of the data and supports the main purpose of the app in ways that follow the platform’s conventions. To help macOS users feel at home in your app, you need to translate the iOS navigation conventions to the equivalent macOS conventions.

设计优秀的应用程序导航能够反映数据结构,以遵循平台惯例的形式达到应用程序主要目的,为了帮助 macOS 用户在应用程序中宾至如归,你需要将 iOS 应用程序导航惯例转换为对等的 macOS 应用程序惯例。

Most iPad apps use either flat or hierarchical navigation, and some use a combination of both. Flat navigation presents areas of functionality or categories of data as peer groups that are always available. For example, Music and App Store use flat navigation to give people persistent access to high-level areas such as Library, For You, Browse, Today, and Games.

Hierarchical navigation presents information in a tree-like organization through which people navigate by choosing one item per view until they reach their destination. In Settings, for example, people can customize text replacements by choosing 。General > Keyboards > Text Replacement.

Typically, iPad apps use the following UIKit controls to implement navigation:

大部分 iPad 应用程序要么使用扁平导航要么使用层级结构导航,或者两者兼备。扁平导航将功能区域或数据类别显示为始终可用的对等小组(同一优先级),例如,音乐应用和 App Store 使用扁平导航让人们始终能够访问高优先级区域,类似于 Library, For You, Browse, Today, 和 Games 这 5 个部分。

层次化导航采用树状信息组织方式,通过让人们在一个视图中选择一项内容最终到达目的地,例如在设置中,人们能够通过“通用> 键盘> 文本”来进行文本替换的操作。

通常,iPad 应用程序使用 UIKit 控件来实现导航。

  • Tab bar. A tab bar supports flat navigation by displaying top-level categories in a persistent bar at the bottom of the screen.

  • 标签栏。标签栏通过将高优先级类别显示在页面底部的持久(始终固定)栏中来实现扁平化导航。

  • Page control. A page control displays dots at the bottom of the screen that indicate the position of the current page in a flat list of pages.

  • 页面指示器。页面指示器通过始终在页面底部呈现点的方式在扁平列表或页面中指示当前所在的的页面位置。

  • Split view. A split view enables hierarchical navigation by presenting items and functionality in a primary view (also called a master view) and a secondary view (also called a detail view). When people select an item in the primary view, a split view displays the content associated with that item in the secondary view.

  • 分屏视图。分屏视图通过将项目和功能呈现在首要视图(也称为主视图)和次级视图(也称为细节视图)来实现层级导航,当人们在主视图中选择一项时,分屏视图在次级视图呈现相关联内容。


如下图所示,页面指示器(Page control)是我们常见的控件。

If you use a tab bar in your iPad app, consider using a segmented control or the sidebar background style in a split view controller. Both items are similar to navigation conventions in Mac-style windows. To choose between these items, consider the following:

如果你可以在你 iPad 应用程序中使用标签栏,考虑在分屏控制器中使用分段控件或侧边栏背景样式。这两种导航惯例在 Mac 风格窗口中都是(用户)熟悉的,为了在这些项目中进行选择,请考虑以下内容:

  • A segmented control and a tab bar both accommodate similar interactions — such as mutually exclusive selection — so a segmented control is a good alternative for a straightforward adaptation. A segmented control is ideal for iPad apps that don’t have a lot of hierarchy within each tab, because it can be paired with a sidebar to enable navigation within a tab.

  • 分段控件和标签栏都可以容纳相近的交互——类似于互斥的选择——而分段控件可能是进行简单改编(由 iOS 至 macOS)的很好选择,分段控件对不用在每个选项卡中区分太多层次的 iPad 应用程序来是理想的选择,因为这样可以与侧边栏配对从而在选项卡中导航。

  • A sidebar displays a list of top-level items, each of which can disclose a list of child items. Using a sidebar streamlines navigation because you can let people view each tab’s contents within the sidebar. Sidebars are a good choice for displaying app-defined or user-defined categories that don’t change very often. For example, the Following and Suggested categories in the News sidebar don’t change, even though people can change the items listed in each category.

  • 侧边栏展示顶级项列表——它们中的每一个都可以展示子项目。使用侧边栏可以简化导航,你可以让人们查看侧边栏中所有选项卡的选项,侧边栏也是很好的选择去展示那些不用经常更改的由应用程序定义或用户定义的选项,例如,在新闻应用程序侧边栏以下类别和建议类别不能修改,即使人们能够改变每一个种类中的列出项。


“分段控件(segmented control):Segment Controls(分段控件)是 iOS 原生控件之一,分段控件是一组分段的线性集合,每一个分段的作用是互斥的,即点击某分段使之处于触发状态。”——摘自《《这个控件叫:Segment Controls/分段控件(附录与Tabs的区别)》(网址:》

侧边栏(sidebar ):

侧边栏,顾名思义,一般是在界面的侧面,如下图所示,更多会放在界面左侧的位置,在移动端设计中,由于屏幕大小有限,侧边栏是以抽屉导航的形式呈现,而在 iPad 及电脑端就是固定(持久)的形式作为软件的顶级导航呈现。

我的问题:following 该如何翻译,哪位同学知道。

You can also combine a segmented control and a sidebar in your app. For example, you might use a segmented control to contain the tabs, and a sidebar to display the contents of each tab. Regardless of how you adapt the tab bar, be sure to give people quick access to each tab’s content through the macOS View menu. To learn more about menus, see Put App Commands into Menus.

你同样可以在你的应用程序中组合侧边栏和分段控件,例如,你可能使用包含选项卡的分段控件并使用侧边栏去呈现每一个选项卡中的内容,无论如何调整选项卡,确保在 Mac 视图菜单中能够让用户快速访问每个选项卡中的内容。


如下图所示是在 iPad 设置应用程序中的侧边栏与分段控件组合形式。(我们可以发现 iPad 的分段控件视觉设计有所改变,之前选中状态使用蓝色填充,现在使用整体使用灰白色,视觉重量更轻。)

If you use a split view in your iPad app, macOS automatically translates it to a split view in the Mac version of your app. On both platforms, a master view is a good choice for presenting a list of items that can vary — such as the list of mailboxes in Mail — because it lets you include labels and icons and it supports sorting and filtering. However, if your content hierarchy is deeper than two levels, the middle levels between the master view and the current detail view aren’t visible in the Mac-style window. To ensure that people can retrace their steps, include a back button in the toolbar.

如果在你的 iPad 应用程序中使用分屏视图,macOS 能够自动将其转换为 Mac 版本下的分屏模式。在两个平台上,主视图是很好的选择去呈现可更改的项目列表——类似于在邮箱应用程序中的邮件列表——因为它让你包含了标签和图标,并支持排序和筛选,然而,如果你的内容层级深度超过两层,在主视图和当前细节视图层级之间的中间层级在 Mac 视图是不可见的,为了确保人们能够返回,请在工具栏中设置返回按钮。

If you use a page control, or another way to enable lateral navigation, give people specific controls to view pages. If you support this type of lateral navigation, you can help people navigate through pages in your Mac-style window by displaying a Next/Previous button in the toolbar and adding navigation commands to a menu bar menu. For example, Stocks in macOS displays both a Back button in the toolbar and Next Story and Previous Story commands in the View menu.

如果你使用页面指示器,或者以其他方式启用横向导航,请为用户特供特定控件(可能是箭头一类的图标)去浏览视图。如果你支持横向导航类型,那么你能够帮助人们通过展示“下一步/上一步”按钮及在菜单栏菜单添加导航命令实现在 Mac 风格窗口中的导航。例如,在 macOS 股票应用程序视图菜单中显示一个返回按钮和下一篇及上一篇文章命令。

If you support multiple windows in your iPad app, you get support for multiple windows in the macOS version, too. In addition, many macOS apps let people open documents or other content in a new tab instead of in a new window. For example, people can open a different webpage per tab in a Safari window or a different file system location per tab in a Finder window. When people use System Preferences to prefer tabs over windows, the system dynamically adds the relevant menu items to an app’s menus, such as View > Show Tab Bar and Window > Show Next Tab.

如果在你的 iPad 应用程序中支持多任务窗口,你同样会在 macOS 中获得多任务窗口支持。此外,很多 Mac 应用程序让人们在新的选项卡中打开文件或者其他内容而不是新的窗口,例如,人们能够在 Safari 浏览器的每个选项卡中打开不同的网页或在 finder 窗口的每个选项卡打开不同的文件系统,当人们在系统偏好设置中选择选项卡而不是窗口时,系统会动态向应用程序项目添加相关菜单,类似于视图>显示标签栏和窗口>展示下一个选项卡。

Support macOS User Interactions

支持 macOS 用户交互

Selection persistence is a fundamental difference in user interaction between iOS and macOS. Because many macOS users expect to control apps and the system using only the keyboard, the selected state of objects must persist so that people can use one sequence of key presses to select an object and a second sequence to act upon it. In contrast, iOS users expect to act upon an object without selecting it first, so objects don’t need to retain their selected state. As a general rule, iOS apps don’t tend to be optimized for keyboard interactions.

选择持久性是 macOS 和  iOS 用户交互的基本不同,因为很多 macOS 用户期望仅通过键盘就可以控制系统和应用程序,对象的选定状态必须持久这样人们就能够使用第一种按键序列去选择对象和第二种序列去对其进行操作,相反,iOS 用户期望不用选择就可以对某个对象进行操作,这样对象就不需要保留选定状态,在通用规则下,iOS 应用程序不需要针对键盘进行交互优化。


“people can use one sequence of key presses to select an object and a second sequence to act upon it. ”:如下图所示,这部分指的是在 Mac 上可以将光标置于某个控件上尝试是否可以点击,而在 iOS 上没有光标,也就没有尝试点击的机会。


  • macOS users often want Next and Previous buttons in place of iPad or trackpad gestures such as swiping among pages.

  • macOS 用户通常希望下一步和上一步按钮代替 iPad 或触控板在页面上滑动的手势。

  • On a Mac, people expect to use the Delete key or select a Delete command in a menu, so displaying a Delete button in the UI is usually unnecessary.

  • 在 Mac 上,人们期望使用删除键或者在菜单上选择删除命令,所以在 UI 元素中显示删除键通常是不必要的。

  • iOS users are accustomed to pulling down on a view to refresh the contents. In contrast, Mac users expect to use a menu command, such as Check for New Content.

  • iOS 用户习惯于下拉视图去刷新内容,相反,Mac 用户期望使用菜单命令,类似于更新新内容(的图标或者按钮)。

As you translate iPad user interaction patterns to Mac interactions, focus on letting people manipulate objects in ways that adhere to platform conventions.

当你从 iPad 用户的交互方式转换到 Mac 交互方式,专注于坚持让人们以遵循平台惯例的方式进行操作。

Keyboard Input


Be prepared to support keyboard conventions that let people change a persistent selection by using arrow keys or by pressing letter and number keys.


If it makes sense in your app, take advantage of the fact that Mac users can easily use the keyboard and the mouse or trackpad at the same time.

如果它(操作)在你的应用程序中是有意义的,充分利用 Mac 可以同时轻松使用键盘、鼠标或触控板这个事实。

If you implement UIKeyCommand in your iPad app to define keyboard sequences for commands, the macOS version of your app translates these shortcuts to the menus. For example, you should map each major view area, such as each tab, to the keyboard shortcuts ⌘1, ⌘2, and so on for display in the View menu of the macOS version of your app.

如果你使用你的 iPad 中的 UIKeyCommand 去定义键盘序列命令,你应用程序的 macOS 版本可将这些快捷键转换至菜单,例如,你应该将类似于每一个选项的主要视图区域映射到键盘上的快捷键 Command 1, Command 2,从而在你应用程序的 macOS 版本视图菜单中进行显示。


UIKeyCommand :一种对象,即在键盘(硬件)上特定的按键及其产生的操作。

在 macOS 中运行的 iPad 应用程序可以使用 UIKeyCommand 创建具有键盘快捷键的菜单元素。想进一步了解可进入 UIKit 《UIKeyCommand》部分。

If there’s a Delete button in the UI of your iPad app, consider removing it from the macOS version and letting people use the Delete key or the app’s Edit > Delete menu command instead.

如果你的 iPad 应用程序用户界面中有删除按钮,考虑将其从 macOS 版本中删除,并允许用户使用删除键或使用应用程序的“编辑>删除”菜单命令来代替( iPad 应用程序中的删除操作)。



When your iPad app runs in macOS, most gestures convert automatically. For example:

当你的 iPad 应用程序在 macOS 上运行,大部分手势操作会自动转换,例如:

iPad gesture iPad 手势

Translates to mouse interaction转换为鼠标交互

Touch and hold触摸和长按

Click and hold点击和长按


Left click and drag点击鼠标左键并拖动

iPad gestureiPad 手势

Translates to trackpad gesture转换为触摸板交互



Touch and hold触摸和长按

Click and hold点击和长按


Click and drag点击和拖拽






The two touches in the pinch and rotate gestures get sent to the view under the pointer, not the view under each touch.



Put App Commands into Menus


On a Mac, the menu bar at the top of the screen gives people a consistent location for commands that control both apps and the system. The menu bar contains the standard and custom menus supplied by the current app, in addition to the Apple menu, which lists system-level commands that are always available. Mac users expect every macOS app to make all its commands available in the menu bar.

在 Mac 上,固定在屏幕顶部的菜单栏通过调用命令的形式控制应用程序和系统,菜单栏由当前应用程序提供,其中包含标准菜单和自定义菜单,除了苹果菜单外,它还列出了始终可用的系统级菜单命令,Mac 用户期望每一个 macOS 应用程序的菜单栏中所有命令始终处于可用状态。


You must use UICommand to represent each command in your iPad app so that these commands can be put into macOS menu bar menus. To support keyboard shortcuts for commands, use UIKeyCommand.


你必须使用 UICommand 去代替每一个在你 iPad 应用程序中的命令只有这样这些命令才能被放置在  macOS 的菜单栏菜单中。为了能够支持键盘快捷键命令,请使用 UIKeyCommand

Because iPad apps use controls to display commands in the main UI, finding a logical and intuitive menu bar location for every app command is a key part of the adaptation process.

因为 iPad 应用程序是在主界面上使用控件去呈现命令,为每个应用程序命令找到符合逻辑和直觉的菜单栏位置是适应过程(iPadOS 转换为 macOS)中的关键部分。

To design the menu bar menus for the macOS version of your app, start by listing all the actions that people can perform and grouping them into the categories defined by the standard menu bar menus. For example:

为给你的应用程序 macOS 版本设计菜单栏菜单,首先需要通过罗列所有人们会执行的操作,并将他们分组到标准菜单栏菜单定义的类别中,例如:

  • App Name

  • 应用程序名称

  • File

  • 文件名

  • Edit

  • 退出

  • View

  • 视图

  • Window

  • 窗口

  • Help

  • 帮助

NOTE:Most macOS apps include a View menu and a Window menu. Although these menus may seem similar, they have different purposes. People use the View menu to customize the appearance of app windows and to move among different functional areas, whe reas they use the Window menu to navigate, organize, and manage the collection of windows in an app. To learn more, see Menu Bar Menus.

注释:大多数 macOS 应用程序包含视图菜单和窗口菜单,虽然这些菜单可能看起来很相似,但他们有不同的用途,人们使用视图菜单去定义应用程序窗口外观并在不同的功能区域间进行移动,他们在应用程序中使用窗口菜单去导航,组织,和管理应用程序窗口集合。


关于 View menu 与 Window menu 详解,大家可以进入 macOS 设计规范《Menu bar Menus》部分了解一下,在我们经常使用的 Photoshop 等软件当中都有视图菜单和窗口菜单。

If some of the actions on your list don’t make sense in the standard menu bar menus, you might need to add a custom menu. Mac apps often add a custom menu bar menu for commands that are associated with either a core app object or a core app workflow. For example, Mail in macOS uses the Message and Mailbox menus to list commands that operate on these fundamental app objects. In contrast, Keynote uses the Arrange menu to list commands associated with the core workflow of arranging objects in a slide deck.

如果在你的列表中的部分操作在标准菜单栏菜单中并没有意义(无法以符合逻辑的方式放到标准菜单栏类别之中),你可能需要增加定制的菜单栏,Mac 应用程序通常会为核心应用程序或核心应用程序工作流定制菜单栏。例如,在 macOS 中的邮箱应用程序使用消息和邮箱菜单列出对这些基本应用程序对象进行操作的命令,相反,keynote 使用排列菜单列出与幻灯片中排列对象的核心工作流相关联的菜单命令。

After you group your app’s actions into menus, you need to order the items in each menu in a way that makes sense. Each standard menu defines a recommended order for items, so it’s important to follow this order for the items that you support. For example, Mac users expect the File menu to present items in this order:

在你将你的应用程序中的操作以组的形式置入菜单后,你需要以有意义的形式对每个菜单中的项目进行排序,每个标准菜单都定义了项目的推荐顺序,因此对于你支持的项目遵循这个顺序是很重要的,例如,Mac 用户期望文件菜单按以下顺序显示:

  • New...

  • 新建

  • Open...

  • 打开

  • Open Recent

  • 最近打开的

  • Close

  • 关闭

In a custom menu bar menu, you should order the items according to importance, frequency of use, or another scheme that makes sense in your app. Menu bar menus can also contain submenus and separators that help group items in logical ways. To learn more about these menu components, see Menu Anatomy.


Also, it’s important to support keyboard shortcuts for all common commands in your menus so that both Mac users and iPad users who use keyboards can benefit. In addition to enabling the shortcuts for standard menu items, you can also define shortcuts for custom items. If custom menu items make sense in your app, be sure to review the guidance for creating custom keyboard shortcuts in Defining Keyboard Shortcuts.

同样,对在你菜单中的常用命令去支持键盘快捷键是很重要的,这样就可以让使用键盘的 Mac 和 iPad 用户都能受益。除了为标准菜单项目启用快捷键外,你也可以同样为定制项目定义快捷键。如果定制菜单项目在你的应用程序中有意义的话,一定要回顾在定制键盘快捷键指南中的定义快捷键的方式。

Contexual Menus


Contextual menus help people discover the actions that they can perform on an object without opening a menu bar menu. If you support context menus in your iPad app, the system automatically converts them to contextual menus in the macOS version of your app.

情境菜单能够帮助人们在不打开菜单栏菜单的情况下发现他们可以对一个对象执行的操作,如果在你的 iPad 应用程序中支持情境菜单 , 在你应用程序 macOS 版本中将自动将其转换为情境菜单。

To give Mac users the best experience, look for additional places to support contextual menus. For example, if there are common actions that people can perform on an object in your app, add a contextual menu that lists these actions. You can also add a contextual menu to a view that represents an object — for example, folder objects in the Finder support contextual menus that offer actions like Open in New Tab, Rename, and Duplicate.

为了给 Mac 用户最好的体验,寻找其他位置去支持情境菜单,例如,如果这里有能够对你应用程序中的对象执行的常见操作,增加一个情境菜单去罗列这些操作,当然你同样可以将情境菜单添加到表示对象的视图中——例如,对 finder 中的文件夹对象支持情境菜单,可以提供类似于在新的选项卡中打开,重命名和复制等操作。

Visual Design Considerations


To help your iPad app look great when it runs in macOS, take into account the platform differences in the following areas of visual design.

为了帮助你的 iPad 应用程序在 macOS 上运行得很好,(我们需要)在以下视觉设计领域考虑平台之间的区别。



Mac users expect to resize app windows to just about any size from full screen to as small as the app permits. To support this type of infinite resizability — and to take advantage of the Mac’s wider display — use the regular width and regular height size classes and consider reflowing elements in your window’s content area to a side-by-side arrangement when necessary.

Mac 用户期望能够从全屏到被应用程序允许的(能够调整的)最小大小之间调整应用程序窗口大小,为了支持这种类型的无限大小调整——也为了利用 Mac 更宽的屏幕——使用正常宽度和正常高度尺寸级别,并在必要时考虑将窗口的内容区域元素更新为并排放置。

As much as possible, adopt a top-down layout. macOS apps place the most important actions and content near the top of the window. If your iPad app provides controls in a toolbar or navigation bar, put these controls in the window toolbar of the macOS version of your app.

尽可能接受自顶向下的布局。macOS 应用程序将最重要的操作和内容放置在窗口顶部附近,如果你的 iPad 应用程序在工具栏或导航栏提供控件,请将这些控件放置在你的 macOS 版本应用程序的窗口工具栏。

Consider moving controls from the main UI of your iPad app to the toolbar of your macOS window. Also, list the commands associated with these controls in the menus of your macOS app’s menu bar.

考虑将 iPad 应用程序的主要用户界面控件移动至 macOS 窗口工具栏。在 macOS 应用程序菜单栏中列出与这些控件相关联的命令。

NOTEIn macOS, a toolbar button is always visible, but the current context might make it unavailable; in iOS, a toolbar button is always available, but the current context might remove it from the toolbar. For example, if your iPad app includes a toolbar button that works in only one tab, the macOS version displays the button as unavailable in all other tabs. To avoid confusing people, it can work better to use a "gear" button in the toolbar instead, because the items in a gear button's menu differ depending on the current app section.

macOS 注释:工具栏按钮总是可见的,但当前的内容下它可能是不可使用的,在 iOS 中,工具栏按钮总是有用的,但当前文本可能将其(按钮)从工具栏中移除。例如,如果你的 iPad 应用程序包含的工具栏按钮仅在某个选项卡中可用,macOS 版本会在其他选项卡中将其(工具栏按钮)显示为不可用,为了避免使用户困惑,使用工具栏“gear”按钮来代替能更好的工作,根据当前应用程序项目的不同“gear”按钮菜单中会显示不同的内容。


我的问题:gear 本身有齿轮的意思,但在这里应该不是设置按钮的意思,有哪位同学知道如何理解。

Relocate buttons from the left or right edge of the screen. On iPad, placing buttons on the middle left or middle right screen edges can help people reach them, but on a Mac, this ergonomic consideration doesn’t apply. You may want to relocate controls to the top or bottom edge of the content area or put them in the toolbar of your macOS window.

从屏幕的左边缘或右边缘重新定位按钮。在 iPad 中,将按钮放置在中间靠左或中间靠右的位置能够帮助人们接触到他们,但是在 Mac 上,这种人体工程学的考虑并不奏效,你可能将他们(按钮)放置在(屏幕)顶部或内容区域底部边缘或将它们(按钮)放在 macOS 窗口中的工具栏中。



Use the system selection color on both platforms. In general, iOS apps define the colors used to tint buttons and to indicate selection, but in macOS, people expect to use System Preferences to choose the selection and button colors they want.

The dynamic system colors designed for iOS backgrounds automatically map to appropriate macOS equivalents, as shown below.

在两个平台上都使用系统选择的色彩。通常来说,iOS 应用程序定义了给按钮着色的色彩并指示选中(点击状态下)的颜色,但是在 macOS 中,人们期望使用系统首选项去进行选择并确定他们想要的按钮色彩。

为 iOS 背景设计的动态系统的颜色将自动映射到 macOS 上适当的同等位置上,如下所示

iOS coloriOS 颜色

Equivalent macOS color 等效 macOS 颜色





tertiarySystemBackground 第三级背景

selectedContentBackgroundColor (overlaid with quaternaryLabelColor)选中内容背景颜色(用第四级标签颜色)

systemGroupedBackground 系统分组背景

windowBackgroundColor 窗口背景颜色

secondarySystemGroupedBackground 第二级系统分组背景



selectedContentBackgroundColor (overlaid with quaternaryLabelColor) 选中内容背景颜色(用第四级标签颜色)

Other semantically defined iOS colors — such as the system colors and the label and separator colors — map to similarly named macOS colors. For guidance, see System Colors (macOS) and Dynamic System Colors (macOS).

其他语义上对 iOS 色彩的定义——类似于系统色彩、标签与分隔符色彩——(也会)映射到相近的 macOS 色彩上。

Don’t tint buttons in table rows. In your iPad app, you use a tint to show that buttons in table rows are active, but in macOS, tinted buttons in table rows look out of place.

不要给表行中的按钮着色。在你的 iPad 应用程序中,你可以给表行中的按钮着色从而显示按钮是可点击状态,但是在 macOS 中,表行中着色的按钮看起来是不合适的。



Although the automatic scaling performed by the system gives good results without requiring you to specify different font values on both platforms, you might not get the best results in every situation.


Make sure small type is legible on the Mac. Be prepared to increase some of the smallest font sizes you use in your iPad app so that all text remains legible in the macOS version. Also, note that Dynamic Type is not supported in macOS.

确保小字体在 Mac 上是清晰的。准备(在 macOS 上)增加在你 iPad 应用程序中使用的最小字体,这样所有文本在 macOS 视图上都能够保持清晰。另外,注意macOS 上不支持动态字体。

Custom Icons and Glyphs


Create a macOS version of your app icon. Great macOS app icons are noticeably different from great iOS app icons — for example, macOS icons can have nonrectangular shapes and are often skewed and rotated. By default, macOS applies a drop shadow to your iOS app icon so that it feels more at home on a Mac, but it’s better to design a Mac-specific version of your app icon. To learn more about how to approach the design of a macOS app icon, see App Icon.

为你的应用程序图标创作 Mac 版本。好的 macOS 应用程序图标是显著区别于好的 iOS 应用程序图标的——例如,macOS 图标可以是非矩形且通常是倾斜和旋转的。默认状态下,macOS 会给你的 iOS 图标添加阴影这样(图标)就可以在 Mac 上(看起来)感觉更自在,但更好地方式是为 macOS 定制一款图标。

Create platform-specific glyphs, if necessary. If your iPad app uses custom glyphs that reference the platform in some way, create new glyphs that feel at home on the Mac. Xcode provides a separate asset catalog you can use in your iPad app for macOS-specific glyphs.

如果需要的话,创造平台特定的符号。如果你的 iPad 应用程序以某种形式引用平台定制符号,创造新的符号会让人们在 Mac 上更自在,Xcode(软件)提供了分开的资产目录,你可以在 iPad 应用程序使用 macOS 的特定符号。



  • Typography:字体排印,是一种涉及对字体、字号、缩进、行间距、字符间距进行设计、安排等方法来进行排版的一种工艺。

  • font:一个成套的字体。

  • character:字符,书面语言中带有意义的最小的单位。

  • glyph:标志符号,字符这些形状中任何一个形状即称为一个标志符号即 glyph。

Typography 是以上概念中最大的概念,涉及到字体及字体之间的整体关系,而 font 是整套字体,类似于苹方就是一整套字体,而 character 在英语中就对应每个字母,例如:“A”就是个  character  , character 是个抽象概念,就是不管是什么字体的 “a”都无所谓,他们都是同样的 character ,而 glyph 是个具象概念,也就是每一个不同字体的“a”都是一个 glyph ,类似于在苹方这套字体中,即使不同的粗细的“a”也对应着不同的 glyph,也就是任何一个新的形状都是一个 glyph 。



If you supply app settings that appear in the iOS Settings app, macOS automatically displays these items in a preferences window in the Mac version of your app. By default, macOS adds a toolbar button to the preferences window for each item in your iOS settings, giving it the standard system preferences icon and the title you used for the item’s view in the Settings app.

如果你将应用程序的设置置于 iOS 设置应用程序(系统设置)中, macOS 会自动将这些项目呈现在 Mac 窗口视图的偏好设置选项中,默认状态下,macOS 为 iOS 设置应用程序(系统设置)中的每个设置项都在偏好设置窗口增加了工具栏按钮,提供标准的系统偏好设置图标并使用在(iOS)设置应用程序项目视图中使用的标题。

As Mac users expect, your preferences window appears when they choose the Preferences menu item in your app menu. However, there are a few ways you can refine the display of your settings items and make your app’s preferences experience feel more Mac-like.

就像 Mac 用户期待的那样,当他们在你的应用程序菜单中选择偏好设置菜单项目时你的偏好设置窗口就会出现,然而,这里有几种方式能够优化设置项的显示方式并让你应用程序的偏好设置体验如同在 Mac 中一样。

Customize the icon for each item’s toolbar button. Because macOS automatically uses the standard system preferences icon for your settings items, people will have to read each toolbar button’s title to distinguish among multiple items. To improve this experience, supply a custom icon for each settings item.

为每个项目工具栏定制图标。因为 macOS 为你的设置项目自动使用标准的系统偏好设置图标,人们需要阅读每一个工具栏按钮标题从而在众多项目中进行区分,为了提高这部分体验,为每个设置项提供定制图标。

Make switch controls easier for macOS users to understand. Unlike iPad apps, a macOS app often displays a confirmation alert when someone uses a switch to make changes in System Preferences. In addition, a switch in iOS Settings can include a small amount of text that provides more information about how the switch affects the user experience. In the Mac version of your app, you can provide a brief description to accompany a macOS switch and you can specify content to display in a confirmation alert when people use it to change a setting. For developer guidance, see Displaying a Preferences Window.

让开关控制变得易于 Mac 用户理解。不像 iPad 应用程序,当人们在系统偏好设置中改变设置内容时 macOS 应用程序通常会出现确认表单,此外,在 iOS 设置中的开关能够包含少量文本内容去提供更多关于开关如何影响用户体验的信息,在你的应用程序 Mac 版本中,你能够在 macOS 开关中提供简要说明并当人们使用它去改变设置时呈现特定内容的确认页表单。

未完待续,下一篇《iOS_Interface Essentials》,敬请期待。

- 位站酷推荐设计师推荐 -



    • 文章标签