Transcript
[ Music ]
>> Hello.
[ Applause ]
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?
[ Applause ]
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 ]