Download
Hello.
It's great to be back on stage at WWDC.
I'm really happy to talk to you guys about designing iPad apps for Mac.
Now, many of you here today have created awesome apps for iPad already, apps that help people be more productive, more creative, apps that entertain, that educate, that help people connect and communicate with each other.
We want to make it easy for you to bring those great experiences to Mac.
With keyboard and mouse or trackpad input, people can work with greater precision and speed.
Flexible windows allow for efficient and fluid multitasking workflows. And larger display sizes allow your app to present more information and actions at once.
Of course, some iPad apps just won't make sense on Mac.
Some used cases like navigation or augmented reality aren't suitable for a stationary computer.
And apps that rely on iPad hardware features like the gyroscope or rear-facing camera won't really make sense on Mac either.
But, for the rest of you, coming to Mac is a great way to offer the people who use your app with a more efficient and immersive experience. The first step in bringing your iPad app to Mac is to start with a solid foundation. Your iPad app should support features like multitasking and drag and drop as well as Auto Layout.
As we all know, Mac windows can be arbitrarily resized.
By fully supporting Auto Layout in your iPad app, your interface will be resizable on Mac.
Similarly, if your app supports drag and drop, you're one step closer to having a great Mac app.
We expect just about everything on Mac to be draggable and droppable.
Now yesterday, we introduced the ability for iPad apps to have multiple windows, like drag and drop, opening documents into their own windows is something that we all expect on Mac.
If your app supports this feature, you'll automatically get multiple windows support on Mac as well, which brings me to the next topic. What do you get for free? Free is good, right? To make the task of coming to Mac easier, many iOS interfaces and interactions will automatically be adjusted to macOS equivalents.
iOS split views will be drawn as split views on Mac, system-provided UIs like the file browser and activity view will be remapped to platform appropriate equivalents. Edit menus and iOS contextual menus will automatically be presented as contextual menus on Mac. Copy and paste, rich text editing, and key focus all come for free as well. Now in all of these cases, the mapping between iOS and macOS is relatively straightforward.
However, there are some key differences between macOS and iOS. Designing an app that feels appropriate for each platform involves understanding and accounting for those differences in your app. The biggest and most critical difference is that iOS was designed for touch, whereas mac was designed for keyboard and mouse input. Designing for touch involves offering touch targets that are larger and easier to access, especially when you're walking or moving around.
On Mac, using a trackpad or mouse provides physical stability and greater control.
And because pointers are small, people can target and manipulate interface objects with greater precision.
Smaller controls also allow Mac UIs to have greater information density or greater control density.
All iOS devices support Multi-Touch gestures like pan, rotate, and pinch. Some Mac setups don't have Multi-Touch input. So, if there's any interactions in your app or any actions that rely on gestural input to be performed, you have to find alternatives for the Mac.
When an iPhone is held with one hand in portrait orientation, placing controls in the middle or the bottom of the screen might make them easier to reach. So -- and the same is true for iPad in landscape orientation. People tend to grip on the sides, so placing controls on the left or right side may make them easier to reach there.
Obviously, on Mac, people do not hold or displace when they use them.
Placing controls along the bottom, the left or the right edges provides no ergonomic benefit whatsoever.
Every area of the screen is just as easy to reach as every other area.
And, speaking of displays, you'll need to consider how your Apple look on 1x non-Retina displays. Special care must be given to assure that glyphs in text look crisp and legible. Look, I know, we all basically understand that touch devices are different from desktop computers.
But what's less obvious is how interaction models and design patterns vary between iOS and macOS. These differences are the key to successfully translating your iPad app's design to macOS.
So, with that in mind, let's get into the details about how to design iPad apps for Mac.
As you can see, we have a lot to cover. You really may want to take some notes.
OK. Let's keep going.
Nothing is more critical to an app's design than how it's architected.
A logical and intuitive app structure helps people to find what they're looking for and it streamlines navigation.
iOS apps tend to be structured in one of three ways.
Some apps use tabs for organizing information into a small number of top-level sections.
Some present a top-level list of sections in a table view.
And some document-focused apps use -- they use a file/folder metaphor, might have a document browser UI at the top level. The chances are that your app matches one of these three archetypes.
The simple path is to find the closest macOS equivalent and just use that.
For tabbed apps, you could use a segmented control in the toolbar.
If your top-level navigation is a master list, you can do nothing and it'll show up as is on Mac, same thing with a document browser UI.
A direct translation of your app structure from iOS to macOS might be the right way to go.
It provides one key benefit.
It'll make the Mac version of your app instantly familiar to the people who are familiar with your iOS app already.
On the other hand, you might be missing out on an important opportunity to streamline navigation.
On Mac, sidebars are a powerful navigation tool. They easily accommodate a large number of options that can be grouped and labeled to help provide additional context and make them easier to scan.
So, if you currently have a tabbed app, you could present those tabs in a segmented control or you could put them into a sidebar.
Now, this obviously does not look great. It's not a very effective use of screen space. But if those four tabs have subsections, you can display those subsections in line. This greatly flattens an app's hierarchy and allows people to move directly between subsections. It can even allow people to customize these items to their needs.
As we saw before, if your app has top-level list or table view for navigating between sections, that translates directly. Split views are the way to get a sidebar on Mac. You just enable the translucent background and you're good to go.
And lastly, if your iOS app shows a document browser at the top level, you can use a sidebar for providing persistent access to folders or for displaying saved searches.
If you use a sidebar, there are two things to keep in mind.
First, sidebars are providing access to locations within your app or collections of documents.
They're not really meant for showing the documents or other kinds of content directly.
Second, the sidebar plays an important role in helping people understand which window or app has key focus.
Glyphs, selection highlights and the sidebar background itself are stylized to appear translucent when the current window is active. This effect goes away when the window becomes inactive. Knowing which window is going to respond to keyboard input is super important.
To support this effect, use a translucent background. Don't fill the sidebar in with a solid color or an image or pattern or anything like that. For selection highlights, use the system selection color rather than a custom color or like an app tint color.
And in general, you should use template images that have a vibrancy effect applied rather than full color images unless it's necessary.
OK. Next, let's talk about toolbars.
Toolbars are commonplace on the Mac. And chances are, you'll want to use one for your app. Placing controls into a toolbar makes them more discoverable. And it leads to a more stable user experience.
Toolbars create a top-down information flow which is the norm for Mac apps.
If your iPad app has any actions that are located along the bottom edge of the screen, doing the same thing in a Mac window can be very problematic. Mac windows are draggable. The bottom edge of Mac windows might be dragged out of you, or below the dock.
Clearly this leads to some usability issues.
When putting actions into the toolbar, keep in mind that a toolbar's contents don't change based on what area of an app someone is in. If they can't be used in a certain area of the app, they'll be disabled.
But toolbar action should only really get disabled if nothing is selected for them to act upon. So, if actions are only relevant in specific areas of your app, they probably should not be in the toolbar.
That said, you can provide contextually relevant actions in an action menu. Action menus can dynamically change based on the current view or selection.
For example, with a file selected in a Finder window, the action menu includes actions that can be performed on the file. And with nothing selected, the action menu contains commands that can be performed on the current folder that we're viewing. Now, action menus are not meant to be a catchall. So be selective about what you put into them.
OK. Next, let's talk about layout.
Mac windows are much, much, much, much larger than iPads. You'll have much more space to play with, especially in full screen. But taking advantage of all of that space requires a layout that's optimized for iPad.
Now, some iPad layouts are just blown-up iPhone interfaces, which looks really bad on an iPad. And it looks even worse on a Mac especially in full screen.
Optimizing your layouts for iPad and Mac requires special consideration.
For both devices, readable content margins keep text lines from getting too long so that they remain readable.
Breaking content into multiple columns can be a great way to maximize information density and using split views or master-detail views is a great way to utilize a wider display.
Split views streamline navigation by simultaneously displaying a list of objects and details about that object which reduces the need to navigate into and back out of an app hierarchy.
If you have a Split View in your app, it'll work great on Mac without modification.
Now, this may sound a little bit strange but making your layout work great on a Mac is probably the best way to identify and address layout issues for Mac -- for iPad. OK. Moving on to type.
On macOS, the baseline font size is 13 points. Most controls and labels use that font size.
On iOS, the baseline font size is 17 points. Showing an iOS app with 17-point type on a Mac would look totally out of place. Text would be way too large. So, to maintain consistency between Mac apps, the system will scale content areas down by 77 percent.
Seventy-seven percent, of course, as we all know, I don't even know if I'm pointing this out, is 13 divided by 17.
Everything in the main interface will be scaled uniformly. This approach means that you don't have to redesign or recode every screen for macOS.
But it does introduce a bit of complexity on the design side. When creating mock-ups of your iPad app, you'll want to recreate that 77 percent scale. So in Photoshop, for example, you can put your entire content area into a smart object and scale it down to 77 percent. And you can do similar things in Sketch, XD and other design tools.
On macOS, apps tend to only use a few different font sizes.
On iOS, text styles very much more dramatically. Text styles, the typographic system for iOS and they offer a wide range of size options.
Using some of the smallest size like footnote, caption one, caption two, can make text that's difficult to read on Mac.
Even the Mac size mini is often too small.
So, just -- you may find that you need to bump up text a little bit to keep it legible on Mac.
And, one final note about type, macOS doesn't support dynamic type. We'll always use the large size setting, it's just scaled down 77 percent.
OK. Now with iOS, every app has it in color which is used to show when elements are interactive or to highlight selected items.
Some apps go further by colorizing content area or bar backgrounds.
On Mac, things are a little bit different. It's common for people to have lots of open windows with lots of content in those windows and lots of files and folders on their desktop.
If macOS used color like iOS apps, the user experience would be really fragmented and overwhelming.
Mac interfaces should be more neutral. They shouldn't compete with a content that they present to people.
What people are -- that's what people are really interested in.
At the same time, translucency integrates your app into the Mac ecosystem. We all like to customize our desktop pictures and translucency lets those desktops influence how apps look and it brings them altogether into one cohesive experience.
Similarly, on Mac, highlight colors are a personal preference. If your app uses a different color to highlight selected items, it'll feel really out of place and it'll be downright confusing for the people who use your app.
It's worth pointing out actually that iOS is becoming a little bit more like macOS with respect to color.
With multitasking, apps are seen alongside each other far more often. A consistent visual look provides a unified user experience. With Dark Mode, people expect more control over how apps will look on their device. Apps that don't respond to their personal preference will feel out of place.
And, tint colors play a smaller part as well.
Steppers and segmented controls that used to be tinted are now neutral with iOS 13.
OK. And one last comment about color. As some of you may have heard already, the system colors on iOS have been completely overhauled. If you use these colors for your iOS app, they'll get remapped to macOS equivalents for both light and dark modes.
OK. Moving on to gestures.
UIKit gestures will automatically remap to trackpad or mouse events.
Single tap will be the same as a mouse-down event.
Long press will be mouse down and hold. Pan will be the same as a mouse drag. And the swipe gesture will be remapped to a drag in the proper direction.
On trackpads, pinching and rotating will work but they'll behave a little bit differently.
On the iPad, pinch and rotate use the middle point between touches to target objects or center the rotation and scale operation.
On Mac, the cursor's location will be used for these purposes. Screen edge swipes won't be remapped for obvious reasons. And depending on how you've used gestures, you may have some work to do. Some gestures just won't translate very well to Mac.
For example, pulling a scroll view to refresh its contents doesn't translate that well on the Mac.
For any actions that are triggered by gestural input, you'll want to find an alternative way to perform that action. You can use many bar menus, contextual menus or buttons in the toolbar or all of the above.
And one last note on Mac, you'll be able to receive mouse hover events. You can use this to display additional information about whatever the pointer is over.
So for example, pressing the stock chart in the Stocks app on iOS reveals the price of a specific point in time. On macOS, rolling over the stock chart reveals the same information. You should definitely take advantage of hover states. There're a powerful way for people to get information without needing to change their selection.
You'll also be able to create touch bars for your iPad apps on Mac.
Touch bars are a great way for displaying contextually relevant information and you can show different touch bars based on what area the app people are in or even what's selected. Most touch bar components and controls are available for you to use. Now, touch bars deserve an entire talk of their own. It's way too much to get into here. But you can learn more about touch bars in the macOS HIG.
OK. Next up, app icons. Mac app icons are the face of your app.
They help differentiate your app from dozens or hundreds of other apps that people may have installed.
And they show up all over the place, in the dock, app switcher, Launchpad, application folder and more.
By default, your iOS app icon will show up more or less as is, a square image that's masked by a continuous curve shape.
A subtle drop shadow will be applied so that it fits in a bit better with the other Mac app icons.
You can choose to stop here, or you can go the extra mile. And I encourage you to do so. Because of Mac app icon so much more visible, it really pays to have a great icon.
Mac icons have different design characteristics than iOS icons. They're not simply squares with rounded off corners. Mac app icons have unique silhouettes to stand apart from other app icons. At smaller sizes, those silhouettes can help keep icons easily distinguishable from each other. And, speaking of size, on a 1x display, app icons in the Finder are only 16 pixels tall by wide. At this size, every pixel counts. So it's a good idea to create pixel hinted icons at the smallest app icon sizes.
Mac app icons are, of course, crafted to accurately depict physical real-world objects. Many icons are rendered in 3D software so they have realistic lighting and material effects.
We have lots of information for you to reference about camera perspective and light source in the HIG if you choose to go this route. All right. We're almost there. I know it's a lot. Second to last is contextual menus. Contextual menus are the unsung heroes of Mac app interfaces. They let people know what actions can be performed on an object and they bring actions right to the pointer which completely removes mouse trouble.
On Mac, people basically expect contextual menus everywhere. So, it logically follows that you should add contextual menus to everything. Any object in your app should have an associated contextual menu that contains the most commonly performed actions.
If you've added contextual menus for your iOS app, they'll automatically be brought to macOS contextual menus. And the same is true for edit menus.
Whether you're designing contextual menus from macOS or iOS, the same basic rules apply. Here are six quick tips to keep in mind. First, avoid overwhelming people with too many options. Too many options makes it harder for people to find what they're looking for and it leads to menus that take a long time to scan. Focus on the most contextually -- most relevant functionality only.
Next, be succinct. One-word labels are typically sufficient. When writing labels, convey action, use verbs or verb phrases that suggest what the results of the action will be when it's performed.
Also, the order of commands is very meaningful. Put the most important stuff at the top and then group related items together. Going one step further, use separators to make the relationships between commands explicit.
Grouping commands together can be very meaningful and it helps people skip past entire sets of commands when they conceive from the first one or two that it's not going to be relevant to their current needs.
And lastly, use submenus to control menu length and hide away actions that aren't relevant.
Submenus are a classic example of progressive disclosure. They simplify decision making by reducing complexity.
OK. Now the last major consideration that I'd like to discuss today are menu bars.
Every app has a menu bar.
Menu bars are core to the Mac experience, go back all the way to 1984.
Menu bars were key to what made computers easy to use.
Designing your app's menu bar begins with this super fun exercise.
You write down all of the actions that a person can perform in your app and I do mean all of them and then you take note of what object or objects those actions affect.
Not only is this exercise excruciatingly fun, but it's also necessary.
Every action that someone can perform in your app should be available from the menu bar. This makes them easier to discover and lets people assign keyboard shortcuts to them.
It also makes them more accessible to people who are using full keyboard access. Once you've cataloged all of those actions, you'll need to find a place for them to go. macOS includes a standard set of menu items -- menu options like the app menu for commands that work -- operate on the app, file menu for commands that operate on files, edit menu for commands that operate on the content or objects within those files, format menu for formatting text, view menu for customizing the appearance of a window, window menu for commands that operate on windows. And help menus are for getting help and finding commands in those other menus.
Now, for many of your apps, these standard menus are going to be all that you actually need. However, it's often necessary to provide additional custom menus. If you have a couple of key object types in your app, with object specific actions, you should consider adding a top-level menu or two for them.
So, for example, in the mail app, there are two main object types, mailboxes and messages.
There are a number of actions that can be performed on those objects and none of those actions can be performed on the other type of object. So it makes sense to have one menu button for each of those objects.
At other times, it's helpful to organize actions by a larger workflow that they serve. In keynote, there are a variety of different object types that can be added to a slide and there's a whole set of actions for aligning and distributing, locking them, grouping them, moving them forward or backward. And because all of those actions affect all of those objects in a similar way, it makes sense to put them into a single menu based on the workflow they serve.
And once you've determined what custom menus to include in the menu bar, you'll need to create the menus themselves.
All of the tips that I just shared with you for contextual menus apply here with one important addition. The structure of menu bar menus is stable. Commands aren't added or removed after an app has been launched. Like toolbar actions, they disable when they can't be performed.
A stable menu system helps people to learn where commands are, even if those commands aren't currently available.
And, when someone sees a disabled command, they learn that the action that it performs is not currently possible, which is actually really useful information.
And, one more thing about menu bars. Assign keyboard shortcuts for the most common commands. Heavy keyboard users will thank you on both Mac and iPad. Your keyboard shortcuts will work on both.
When picking keyboard shortcuts, always follow precedent. You could find a long list of standard keyboard shortcuts in the macOS HIG on the keyboard page.
Look, we all appreciate it when we come to an app that we've never used, use a keyboard shortcut that we already know and get the intended result that we expected. Am I right or am I right? I think I'm right.
So you have to do the work to make that happen. So, that was a lot about menu bars but I wanted to focus on them because they're core to the macOS experience and require real consideration.
OK. Now, getting your iPad app running on a Mac should be pretty easy. But that's just the first step. Mac offers you an opportunity to increase the power, utility and efficiency of your app but realizing that opportunity involves some thoughtful design choices and a bit of effort.
Now, I know we've covered a lot of ground today. For those of you who weren't taking notes, shame on you. But, don't worry, I'm just kidding, don't feel bad, we have a dedicated page for you in the Human Interface Guidelines. It includes lots of useful tips and information about everything I covered today and much more.
And I highly recommend downloading the macOS Apple Design Resources. They're available for Sketch, Adobe Photoshop and Adobe XD. You can find all of that at developer.apple.com/design.
And you should also check out these great sessions about taking your iPad app to the next level and font management, all sorts of good stuff about font management.
Thank you so much for your time. I'm really looking forward to what you create. [ Applause ]
