Fonts lay at the intersection of design and engineering. Get introduced to typographic principles and how they apply to the San Francisco fonts. Hear what makes this family of fonts unique and how to effectively take advantage of their advanced features. Learn best practices when designing and implementing interfaces with text.
ANTONIO CAVEDONI: Hi, everyone.
My name is Antonio Cavedoni.
I am a member of the team
who designed the new San Francisco fonts,
and I am thrilled to be here to introduce them to you.
So on the agenda today we are going to look
at the San Francisco fonts, how they were designed,
and what they mean for our platforms.
We are going to look at some new features
and how you can make your apps more awesome with them,
both coding-wise and design-wise.
And lastly, we are going to talk
about some potential API pitfalls that you may run
into when adopting these new fonts in your apps.
So let's get started.
Text is everywhere.
And fonts make text possible.
But fonts also have a voice.
And good fonts enhance your app content and your user interface,
and they do not get in your way.
You read fonts all the time, and you read them
on different screens, on different devices,
and at different point sizes.
You also read them at different viewing conditions,
such as light conditions or viewing distances
or screen sizes and resolutions.
So we set out to improve on the typography of our platform,
and we came up with a new typeface design
that we call San Francisco.
San Francisco is a new family of typefaces designed by Apple
in California, and it is both inconspicuous and beautiful.
San Francisco unifies our platform
with a consistent typographic voice and a reading experience.
So this is what it looks like.
San Francisco is what is called in typography as a grotesque,
which is another word for a sans serif.
And this is the family tree.
The San Francisco design is comprised
of two main subfamilies.
We have SF, which ships on iOS and OS X, and SF Compact,
which ships on the Watch.
Both families have two cuts that are called optical sizes,
and they are text and display, and I will talk
about these in a second.
And all of the fonts have six weights for the text families
and nine for the display ones.
So again, SF ships on iOS and OS X,
and SF Compact ships on the Watch.
So now let's look at the difference between these two.
SF and SF Compact are sibling designs,
meaning they are related but not equal,
and the biggest formal difference
between the two is how we handle the round shapes.
In SF, they are round, and in SF Compact,
they are actually slightly flat.
So that achieves two main goals.
The first is stylistic, but the second one, more importantly,
is functional, so these flat sides allow us
to have more space between the letters,
which means they are more legible when they are smaller.
And this seemingly inconsequential feature repeated
over and over and over again
in text really does make a big difference.
So now let's look at proportions,
which are actually similar between SF and SF Compact.
So I will just focus on SF for a minute.
I am going to go over some typographic terms you may
already be familiar with, so please bear with me.
Latin text lies on what is called the baseline.
Lowercase letter align with something that is known
as the x-height, which is the height of the lowercase x.
And the uppercase aligns at the cap height.
We also have a descender, which is where lowercase letters
that are below the baseline align, and an ascender.
Now, for proportions,
the SF family has compatible overall metrics
with the previous UI fonts that we shipped,
which means your apps won't experience a lot
of vertical reflow.
In fact, they won't experience any vertical reflow at all.
But within these compatible vertical metrics,
we actually change the proportions a little bit.
For example, we made the uppercase shorter a little bit.
The reason we did this is because we wanted it
to work better in mixed-case settings.
And also, we increased the height
of the x-height a little bit.
So we made the lowercase go towards the uppercase.
And again, that improves mixed-case settings
but also makes the lowercase larger,
which is what you read the most,
and so it's for better legibility.
And lastly, the numbers align with the uppercase.
So SF is a pan-European font,
which means it covers the Latin script, which includes languages
like Polish or Icelandic or Hungarian or even languages
that need stacking accents, like Vietnamese.
But it also covers the Cyrillic script, which is used
in Russian, and the Greek script.
So that's San Francisco.
It is a new family of typefaces that we designed at Apple.
iOS and OS X ship with a font family called SF,
and SF Compact ships on the Watch.
The families have different proportions --
sorry, similar proportions, but they are different designs.
Now, both fonts are available for download for you today --
actually, right now -- and you can get them
from the Apple fonts page, developer.apple.com/fonts.
But please remember that these are prerelease,
so they will get finalized once the final OSes ship.
So before I move on to talk to you about optical sizing,
which is the big idea in the San Francisco family of typefaces,
I need to tell you about some principles of design.
Visual perception is largely about illusion.
And what I mean by that is imagine you have two shapes.
You have a square and a circle.
And you want to make people think that they are looking
at shapes that are the same height.
So you put them side by side,
and you align them mathematically,
and the circle actually looks too short.
So to address that, you actually have to cheat, meaning you have
to make the circle larger.
In typography, we say that you make the circle overshoot
So in other words, if you want to make two shapes look similar,
you often have to make them dissimilar.
Now, this does not apply just to the shapes themselves,
but it applies to the space around the shapes as well --
I'm going meta here and showing you the slides --
and what I am trying to get at here is if I put that text
in the middle of the slide, like this,
it would actually look too low.
So again, to make shapes look similar,
you have to actually make them divergent.
And as a bonus, do you guys know what this character is,
what it's called?
The pound, the hashtag.
In Italy, we call it the cancelletto,
which means small gate.
It is, of course, the octothorpe,
and the octothorpe is the intersection of four lines,
and where these four lines meet,
that area in the middle can get very dark and actually can kind
of clog up at smaller sizes.
So if you see it small, you can hardly notice that it's there.
So what have you to do there is you kind of have to cheat again.
You have to not actually make the intersection
of these four lines but make it a larger square.
So that's the octothorpe in our heavy weight of San Francisco,
and we do this in type design all the time.
So again, visual perception is about illusion.
And with that, I want to talk to you about optical sizes.
Which is this branch of the family tree that you saw before.
Imagine you have a piece of text in two sizes in the same font.
By the way, this word doesn't actually mean anything.
It's something that we type designers use to look at fonts
and kind of judge their rhythm
because it has flat and round shapes.
Anyway, you look at it, and you may notice
that the smaller version of this text is not really legible,
and the reason is in a grotesque typeface like this,
where letters are nice and close to each other,
if I simulate low vision by blurring it out,
the smaller size font -- in the smaller size font, letters start
to kind of blend, right?
So what you want to do there is you want
to do something like this.
Meaning you want to kind of adjust it
so it's more legible when it's small.
So you may be thinking that all I did there was just animate it
and make it slightly wider, and actually,
I am changing the outlines completely on you.
So before I show you the differences
between these two fonts that are called Display
and Text, by the way.
Display doesn't mean screen, but it means typing sizes
in typography, and text is the text sizes,
so the display font is used for larger sizes
and text for smaller ones.
I have to tell you about negative space,
which is the space inside letters, around letters,
and inside the contours.
Negative space is critical
for telling shapes apart and for reading them.
And in the example before, actually, in the bottom --
in the text font, there was almost twice as much the space
than in the display font.
So another thing that could be an issue in grotesque typefaces,
such as San Francisco, is that these shapes look beautiful
when they are really large, but they have similar structures,
and they can become confusable.
So when you superimpose them, you may notice
that they all have the same overall morphology,
which means they all have these areas at the top
and at the bottom that are curvy.
They all have these two areas that we call counters that are
in the same -- roughly the same position
and roughly the same size.
They also have this semi-horizontal area
in the middle, and they are really defined by these areas
that we call apertures.
If you imagine air going to the letter,
that's where it would flow in.
So you really want to change the display --
the text fonts versus the display one, and when we do so,
let me just show you some examples.
In a lowercase a, for example, we actually change the size
of the overshoots because we want the round shapes to pop
out more from the x-height at smaller sizes.
We also open up the aperture right there.
And we do the same at the bottom of the lowercase g.
In the lowercase s, we open up these apertures as well.
We make the r nose or flag larger, and we do the same
with the lowercase f and the lowercase t;
they're larger and slightly taller.
The lowercase i is an interesting one
because what happens there is the dot on the i visually starts
to collide with the stem at really small sizes,
and so we actually make it larger and higher up.
So there are two distinct font families in SF and SF Compact.
They are called Display and Text, and they are used
at different point sizes.
The system automatically switches between the two for you
so you don't have to do anything to adopt them.
And that's optical sizes.
There are two optical, size-specific families
in San Francisco: Text and Display.
The system switches between the two at 20 points,
so you don't need to know this if you are coding
for the new platforms; however,
you do need to know the difference
if you are designing your app because design apps
like Photoshop, or Sketch, or other apps
like these don't actually do this for you,
so just know you have to switch between these two fonts.
So now that we looked at size-specific features
such as optical sizes, I want to tell you about something else
which is size specific, and that is tracking.
Tracking is a modifier on the native spacing of letters,
and if you saw that animation and you thought, oh, yeah,
he changed the kerning on that string, you are almost right.
There is a subtle difference between tracking and kerning.
Tracking applies both positively and negatively to all the glyphs
in a font, and kerning really only applies
to a specific pair, individual pair.
So that's kind of the big difference.
Tracking is global, and kerning is local.
Now, the San Francisco fonts have inside
of them embedded per each font a tracking table
which is size specific,
and it defines point sizes and tracking values.
It achieves something like this, right?
So it makes the smaller text spread apart
and the bigger text closer together.
And you don't need to know these values, again, if you are coding
to the new San Francisco fonts, but you do need to know them
if you are drawing your app in Photoshop because, again,
they do not do this for you.
This tracking table is available for download
with the system fonts with the same page
that I showed you earlier.
So that's what tracking is all about.
Next, I would like to talk to you about weight.
Font weight is the measure of how thick
or thin the strokes of the letters are.
Now, the text families of San Francisco and SF Compact
as well, SF and SF Compact, have six weights for the text fonts
with their italics, and they have nine weights
in the display fonts.
And you may be wondering why it is that we have more weights
in Display than in Text.
And the reason is that the extreme weights
of the family are really designed for titles,
and so it wouldn't make sense for them
to be used below 20 points.
So some of these weights are actually new,
brand-new in our platforms, and so previously it was hard to get
to them or the ones that were there previously,
and now we are giving you new APIs to actually get
to all the range of weights and system font.
They are both in UIKit and AppKit,
and they are a new parameter added
to the systemFontOfSize API call,
and these are the arguments that are taken.
Now, you have all these weights, and you may be wondering,
how do we actually use them?
And I don't mean from a coding point of view,
but from a design point of view.
So you have three main goals
that you can achieve with weight.
The first one is differentiation.
You can create difference in a piece of text,
and you can create a hierarchy.
The second is to achieve similitude.
And the third is a stylistic purpose,
so you want to achieve some sort of voice.
So let's look at these.
Imagine you have a piece of text and you want to call out a word,
make it active, make it a link, make it emphasized.
Weight is a great way of doing that.
You can also have a list of items and create a hierarchy
in there by saying the first one actually is the one I want to --
it is the title of the list, and the other ones are the things
that are being enumerated.
But you can also use weight in a more subtle way,
which is to create similitude.
Consider this example, which is kind
of vernacular to Watch Glances UI.
You have a bigger number and some smaller text underneath it.
Now, if you set them both in the same font weight,
the smaller text might look too light.
So if you want to achieve similitude there, what you have
to do is you have to make the weights dissimilar
to make them similar.
So you can make the bottom font regular rather than light.
So if you follow this principle of larger sizes, lighter weight;
and smaller sizes, heavier weight,
you can roughly make things go towards each other
and be harmonious.
But lastly, you can also use weight for voice.
To show you what I mean, I created a new revolutionary app.
It's called Bee Weather, and it's a weather app for bees.
I really wanted to be punchy and bold, but what I want
to show you is that if I just take the same --
exact same layout and I change only the font weight,
I can create a completely different stylistic effect,
a completely different voice.
And if you are sitting there and you are thinking, oh,
but the color is deceiving me, I actually made Zebra Weather
as well, which -- [Laughter] -- proves my point better.
So you can really use weight to achieve a stylistic effect.
However, remember that fonts are there to serve the text,
so legibility is our first concern.
You want to establish a hierarchy
with consistency and clarity.
And if you don't feel comfortable doing that,
iOS already has a system that you can adopt
that has a hierarchy embedded within it of sizes and weights
that go along together.
These are the text style APIs that are used for Dynamic Type,
which also give you all the Dynamic Type advantages,
such as users can go in their preferences,
change their font size, and your app will react accordingly.
When working with weight, you also have to remember
that there is a setting both in iOS and watchOS
to change the weight of the fonts on people's devices,
and so if you are relying on weights that are too bold,
you might hit a ceiling there, and on the other hand,
if you are relying on fonts that are too light,
text might be illegible.
So there is no hard-and-fast rule about how to use weight.
But these rough guidelines can give you some ideas.
So these are the weights of the San Francisco font family.
There are new ones available to you and APIs
that go along with them.
The same guidelines about legibility, hierarchy,
and the elusive quality of taste apply to their usage.
Next I want to talk to you about another feature
of the San Francisco family, which are typographic features.
So features make fonts active because they are pieces
of behavior that is embedded inside a font.
They primarily make complex scripts possible,
but they can also be used
to access extended glyphs inside a font.
Sometimes they can be the only mechanism
or sometimes they can be a convenience mechanism
to access these extended glyphs.
So to give you an example of what features can do,
let me tell you about fractions.
So you are looking at this, and you are typesetting in your app,
and you are thinking, actually, I know that there is a glyph
like that in Unicode, and I can just go see
if San Francisco has it, which it does,
and you typeset it, and you are done.
Great. But what happens when you have
to typeset something like this?
Which is not in the font and is not in Unicode?
So you could write code that iterates through that string,
and moves along, and creates some other versions
and repositioned versions of all these glyphs,
and you may also change the weight because you want
to make it look similar to what's next to it.
Maybe you even remember
that there is a fraction slash inside the font.
You go check it out in San Francisco,
it's there, boom, you put it in.
And you just wrote a bunch of code
that you could have just thrown away
because the fraction feature does exactly the same
for you automatically.
And it also works for arbitrary fractions.
So the way this works is not by having a ligature for 65/324.
I don't have that glyph in my font.
I actually have smaller versions of all these numbers
and of this fraction slash that get assembled together
by the system based off of the font.
And the great thing about this is
that these are individual glyphs,
which means tracking will apply to them as well.
So features are discoverable, and you can enable them
in the Typography panel, which is a piece
of UI inside the Font panel of OS X.
But you can also enable them in code,
which is the most common scenario for you guys.
So here I am using the new systemFontOfSize weight API
to get the light weight.
I can get a font descriptor out of it.
Once I have that, I can actually modify it by adding attributes
to it, and some of the attributes can be the features.
I can turn on one feature at a time, I can turn it off,
I can also do groups of features all together.
And once I have that font descriptor,
I can create another UIFont out of it.
So other features that are available to you are things
like superiors and superscripts or inferiors and subscripts.
Or also uppercase forms that are used when you want
to typeset math symbols or other symbols
in between numbers or capital letters.
But there are some features in San Francisco
that are really special to this design, and I just want
to call them out to you.
The first one is the vertically centered colon,
which is by default the colon aligns with the lowercase,
so it sits on the baseline,
but when you are typesetting the time, you really want it to be
in the middle of these numbers vertically.
So we use this everywhere, in our lock screen in iOS,
we use it on the title bar of OS X, on the Watch,
we use it on our stopwatch apps, so we decided
to make this automatic because it's so common
to typeset the time in UI design.
But you may want to opt out of it if necessary.
The feature code to opt out of it is the same as the one
to opt into it, essentially.
Another feature is alternate shapes for numerals 6 and 9.
So these two shapes are beautiful when they are large
in their vernacular, their grotesque genre; however,
they do have an issue with confusability.
They can be confused when they are really small either
with each other or with an 8.
So for that, we actually designed alternate shapes of 6
and 9s inside the San Francisco fonts
that have these flat sides, and we use them in situations
like the small dials on the Watch.
We use them on the serial number on the back of your Watch.
But you can also use them in serial numbers
where the context is not enough
to tell you what are you looking at.
So because their usage is context dependent,
we don't actually turn it on for you automatically.
But it's available with the -- this feature code that you see.
And next I want to kind of combine two ideas.
The first is typographic features that we just saw,
and the second one is optical sizes that we saw earlier.
And so the display and text fonts are really designed
differently, and we take into consideration the point sizes
that they will be used at.
So if you are typesetting a fraction in display sizes,
it's fine if you have the curly shape of the 6, but if you are
in text fonts, you really want the other shape
because that's -- imagine that would be set at 12 points.
The fraction would be probably 6 points, right?
So we actually designed them differently
and spaced them further apart.
And we do this for a whole host of glyphs
in our San Francisco font.
So we make them different between text and display
on purpose to make them either be more beautiful
or more legible.
So these are typographic features.
They are behavior that is embedded inside a font.
Some features are automatically turned on for you
by System Font, and others require you to opt into them.
So next I want to talk to you about numbers for a second,
not the app, but actual numbers inside the font.
So we type designers spend a lot of time thinking about the shape
of numbers to make them look beautiful
or functional or all these things.
But I want to tell you about the spacing
of numbers, their widths.
By default, on our platforms, numbers are always monospaced,
meaning they all have the same width, which is great
if you need typeset something like tables, for example.
Monospaced numbers are really handy
because they make everything align.
You can also achieve layouts with, like,
multiple columns with them.
However, they are not the only numbers
in the San Francisco fonts.
We also have what are called proportional numbers,
where each number has its own "natural" width.
So there are situations where, of course,
monospaced numbers are clearly what you want.
For example, like this, when you have proportional numbers,
they will actually wiggle around,
and monospace numbers actually stay put.
But you may also typeset numbers in static labels,
such as when typesetting a date or a phone number
or a read count in an inbox or an email address or a URL.
In those cases, really, you want proportional numbers instead.
So let's take a -- do a case study with an app like Calendar,
which is fairly numbers heavy.
And if you look at how we use numbers in this app
and how we typeset them, you will notice
that they don't really align with anything else,
and they really are in line with other text,
meaning they could use -- they should use,
and they do use proportional numbers.
So knowing this, we decided to take a big leap here,
and change the default of our platforms
to actually give you proportional numbers by default
and make you opt into monospaced numbers.
Now, there is a precedent for this, and that's the Watch,
which actually ships with proportional numbers by default.
But it is a big change, and it may affect layout.
So because of that, we have provisions in place.
If your app is not linked against iOS 10.11 --
sorry, OS X 10.11 and iOS 9,
you still get monospaced numbers by default.
The system turns on the monospace feature for you.
And -- but if you do recompile, you get proportionals.
And there is a new shortcut API available in AppKit that kind
of abstracts away the feature code
that I was showing you earlier, so it makes it easier
for you to adopt this.
So lastly, we are going to look at some potential pitfalls
in our font APIs, both with these new fonts
and with existing fonts.
First of all, the curious amongst you may have noticed
that in the preview builds of OS X and iOS, the SF fonts ship
with a name that is -- it starts with a dot.
What that dot means is that that name is Apple private,
so please don't rely on it being stable.
We've also seen some framework developers
that use their own font-loading code,
such as game framework developers, for example,
where they rely on the fact --
on the assumption that fonts are going to be
in a specific place on the file system.
Now, this is very brittle, and we would like you
to treat font paths as opaque, meaning you can access them
through Core text -- you can access font through Core text,
and you don't have to go hunt for them on the file system.
Also, if you access system font by name,
the fontWithName API is really meant for user fonts.
So if you have your own fonts, you can call them that way
and that's great, but if you instantiate a system font,
later on you extract its name and then you try
to create another font out of that, well, now you are opting
out of all the automatic things that system font does for you,
such as the automatic features, the size-specific behavior,
the automatic tracking, and all these things,
so we recommend you don't do this.
And instead, you can actually use font descriptors,
which completely encapsulate the behavior of a font,
so this is the recommended way for using font objects.
Lastly, with optical sizes,
we are really challenging some old assumption
as to how fonts work, so for example, if you typeset a word
at 15 points and later on you apply a scale to your matrix
and you reuse the same font object, well,
you are getting a font that is designed for 15 points at,
I don't know, 120 points.
What you really want to be doing there is actually reinstantiate
the font again for that specific point size,
and you will get the right behavior.
So we really want you to treat fonts as opaque objects
if possible, so use the system APIs to get to them.
Fonts with optical qualities really break old assumptions.
And relying on the system font APIs will give you the right
behavior all the time.
So that's -- please use these.
And that's all we have for today.
So we looked at the new San Francisco fonts,
we looked at concepts like optical sizes,
the big idea in San Francisco.
We looked at automatic tracking, the weights
and the features of San Francisco.
We looked at the big change coming up in numbers
in our platforms, which means
that they are becoming proportional by default.
And we looked at some potential pitfalls in our APIs.
So if you have questions, you can get in touch with Mike
or Curt, or go on our Developer websites.
There's also a session about Watch Design Tips
and Tricks later and a Text and Fonts Lab
where we can answer your questions.
So thank you very much.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.