Introducing the New System Fonts – WWDC15 – Videos – Apple Developer

Download

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 the square.

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. Thank you.

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 — — 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. Or NSFont. 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.

[Applause]