Transcript
[ Music ]
[ Applause and Cheers ]
>> All right.
Let's do this.
Hi, I'm Paolo, and later on,
I'll be joined by my colleague,
Tom here on stage.
And we are here today to
introduce you to SF symbols.
Symbols play a very important
role in interfaces.
They are effective at
communicating meaning.
They can indicate which items
you have selected.
They can be used to visually
differentiate one type of
content from another, and
symbols appears in -- appear in
various contexts throughout the
system.
This creates a sense of
familiarity throughout the user
interface.
Symbols are used in a variety of
ways, and designing symbols
comes with an inherent
challenge, which is pairing them
nicely with the other essential
element of any UI, which is
text.
Text is used in a variety of
point sizes in the UI, and so
are symbols.
We use symbols a lot, and so do
you.
We want to make your job easier.
Now in iOS 13, we redesigned all
our symbols.
You'll notice how the symbols
have a rounder look, and how
generally they are a bit heavier
in weight, making them more
visible.
They're also designed to
perfectly match and align with
text.
And while we took great care in
redesigning all the symbols in
the system that you may already
be familiar with, we are
thrilled to announce that we've
extended this list, and designed
many more, which we call SF
symbols.
They are a platform-consistent,
high-quality set designed by
Apple for you to use in your
apps.
They come in vector form, which
means they are scalable, and
will render great at small and
large point sizes.
They come in weights that match
our family of system fonts, San
Francisco -- all the weights.
And there's over 1,000 to choose
from.
If these are still not enough,
you can even customize them and
create your own.
Let's look at them in more
detail.
They're designed to work with
text.
They're specified in typographic
points, like text.
When symbols appear next to
text, they all sit nicely on the
same baseline.
When symbols and text are
positioned vertically, there are
two most common cases -- whether
the text supports the symbol, or
the symbol supports the text.
Horizontal alignment ensures
that everything looks great, and
this is possible thanks to their
margins,
which are not necessarily the
same, as you can see in the
bottom-right blue rectangle.
Margins are invisible, but
they're always considered when
laying out elements on the
screen.
Let's look at weights.
SF symbols have been carefully
drawn to look great at different
weights, from ultra-light to
black, just like our system
fonts.
Every weight has been drawn
manually, and special
consideration went into each
design.
Thinner weights have a
distinctive, beautiful elegance,
while the heavier ones strive to
maintain detail and visibility.
There is a need for using
symbols at different sizes when
they are next to text, even if
the text size doesn't change.
This is something that many of
us already do, depending on the
amount of emphasis that the
symbol may need, and how much
space is available.
So with iOS 13, we turned this
into a system.
We call these scales -- small,
medium, and large.
It's important to notice here
that the point size of the
symbol is still the same.
It's just the scale that
changes.
Each scale remains
weight-matched with the text,
and, mind you, it's not just
linearly-scaled, the stroke
thickness is adjusted to the
weight of the text, and the
other great benefit is that
using scales means that
automatically they're optically
vertically-centered to the cap
height.
This way, vertical layout
between symbols and text is
automatic for all three scales.
So where are these scales used,
and when should you use a
particular scale?
Well, here are 3 UI examples.
They all use 17-point text, but
the container for each of these
symbols have different heights.
So the text is the same size in
all 3, and the symbols are as
well, but the symbols use a
different scale in order to best
fit their space.
And in some places, like
toolbars, your kit will do the
right thing, and will pick the
correct scale for the control
automatically.
So when we put all this together
-- resizing, scaling, and weight
-- it means you can use them
with dynamic type, and
everything just works.
And of course, symbols can be
localized, too.
Here's an example of the Voice
Memos app, running in English,
and running in Arabic.
Notice how the time control
reflect the numeral system of
the locale.
If you're wondering how to make
sense of all these symbols,
well, each symbol has a unique
name,
and most symbols come in
variants that can be outlined or
filled.
They can be enclosed in a circle
or a square, and may come with a
standardized system of badges.
And we made it convenient for
you to use these symbols.
First, they are included in the
San Francisco fonts available
for download, so you can use
them in your design prompts.
The scales are accessible by
open Type Features.
The default scale is medium, and
small and large can be selected
through the Typography panel, or
application-specific UI.
And as a reminder, these fonts
are for design only, not for
deployment.
So how do you use these symbols?
How do you access them and get
them into your designs?
Well, to help you with that, we
created a new app, which is
called SF Symbols, and this is
what it looks like.
It will let you browse symbols,
either in a collection view or
in a table view.
It will let you search them by
name, and preview them in
different weights that the fonts
come in.
You can download the SF Symbols
app with the new fonts from
developer.apple.com/design, and
speaking of design, design
resources -- the new design
resources on developer.apple.com
also use symbols.
They reference them by name, and
some of the system icons are now
symbols, too.
So if you were using some of
these, they will automatically
use the new designs.
Now that we've seen how to
discover the symbols available
to you, let's look at a real
example.
Here's a spec that you might
have put together for your app.
You can see how before maybe you
had to do something like this --
specify your images, the
rectangular bounds, and explicit
pad and insets, and now, symbols
greatly simplify the paradigm.
You just have to specify a name,
its point size, and alignment,
maybe its weight and scale if
appropriate.
So I'm working on this app with
Tom, and here the symbol in the
second row is a bit too generic.
It's a list of beverages, so I
want to replace it with
something more appropriate,
something that conveys that
these are tasty, hot beverages.
So I think I'm going to change
it, and I want to go for a
teacup.
That teacup looks great.
I'm sure Tom will love it, but
it's not included in the set of
symbols that we provide.
Well, the SF Symbols app lets
you customize and create your
own symbols.
In order for you to do that, you
need to start by exporting the
symbol from the app, and symbols
can be exported through their
template.
This is what a template looks
like.
It has all the weights, and all
the scales for the symbol.
The template is in SVG format,
which means it can be edited by
most design tools.
It's specially constructed to be
navigable and usable through any
of the design stage, and the
very same template is also
directly used by Xcode as a
source artifact.
No more tens of hundreds of
files floating around.
So let's look at how we did our
teacup.
First, we went to the SF Symbols
app, and we looked for a good
starting point.
Our teacup is enclosed in a
circle, so I think the circle is
a great starting point.
And so, I searched for circle,
and it's there.
So I can select it and export
its template from the File menu.
I can save it, and now it's
ready to be customized.
I can open it in my editor and
notice here how the layers have
unique names.
These names are important.
They help identify each
individual configuration of the
symbol, the weight, and their
scale, so you've got to be
careful when you're drawing to
make sure that your outlines are
actually inside the appropriate
layer.
So I start my customization
work, and I put my teacup inside
the regular at the medium scale.
I make sure that it's centered,
and optically balanced, and then
I scale it down, just for stroke
thicknesses, and I put it in the
small regular scale.
And then I repeat the process,
and I scale it up just for
thickness, center it, make sure
it's looking good for a large
regular scale, and so forth
until the template is complete.
At this point, I'm ready to
export the SVG from the design
tool.
I can hand it off to Tom, and
I'm sure he'll take great care
of it.
In fact, he doesn't have to do
much.
It's ready to be dropped in
Xcode as-is.
So if you want -- don't want to
provide all the weights for your
symbol, you have to provide
regular at medium scale at
least, then the scales for
regular.
Then same bold for the bold text
feature, and if you want to
support all dynamic-type styles,
then include medium and bold as
well.
Of course, you should take into
consideration the typographic
palette of your app.
You may need thinner or heavier
weights.
So to recap, we got to know a
new library of symbols that
match San Francisco.
They are vector-based and come
in different weights and scales.
You can browse them through the
SF Symbols app.
We saw how to use them in your
specs, referenced them by name,
and how to specify their
positioning, and finally, you
can customize symbols using the
SVG template exported from the
SF Symbols app.
Now, I'd like to invite Tom to
the stage, so he can tell you
all about how to use these
symbols in code.
[ Applause ]
>> Thank you, Paolo.
[ Applause ]
Well, I'm really excited, and
the first thing I would want to
do is see if I can use one of
these symbols in my own apps.
And I have this simple slideshow
app, and it has some UI that
allows you to change the speed.
But I'm really not very happy
with these images.
They're very basic, so let's see
-- they're a good candidate for
changing, and let's see what it
does if we have a symbol in the
Symbols app.
So let's fire up SF Symbols, and
search for tortoise, because
maybe we can use the classic
[inaudible] style tortoise and
hare.
Turns out, there is one, so I
can use this.
That's great.
And the hare is there, too.
Perfect. Now, how do I use them?
It's very simple.
We're introducing new API called
UIImage(systemName that works
very similar to the existing
APIs.
You just pass in the name you
copy from the SF Symbols app,
and that's it.
If we build and run -- wow, bam,
that looks amazing, and it was
just two lines of code.
Perfect. Now, Paolo sent me a
spec, because we're working
together on this app, and he
really has to stop putting hot
Belgian chocolate there, because
now I really feel like hot
Belgian chocolate.
But he gave me this spec, and it
looks very different than the
one that I got before.
It's -- there's less
information.
I like that.
That's less work for me, but
let's focus on this image,
because there's a new teacup
there.
He also gave me a file,
teacup.svg file that I need to
import into my asset catalog.
Well, it's definitely a teacup.
There's a lot of them.
He really put some effort into
it, and that's what I like about
Paolo.
He has, like, great attention to
detail.
So now, my image is there, and I
can just use UIImage(named to
get to my teacup.
If we run this, I get this.
This is a real nice and sharp
teacup, exactly what I wanted,
but I'm not sure if you have
noticed, when I imported the
file, there are now two teacups
in my asset catalog.
It turns out you can now have
two images with the same name,
but they are -- have a different
type.
So let's step back for a moment
and explain what's happening.
We're going to use envelope,
because the teacup is not a good
example.
Up until now, UIImage(named was
pretty straightforward.
You have an image in your asset
catalog, and you can get it out
using the API.
Now, with symbols, it becomes
more complicated.
You can actually have an image
with the same name, and there
might be three versions of it.
You might have a system symbol
with this name.
You might have a custom symbol
with the name, and your old
non-symbol image might still be
there.
For system images, there's no
problem.
They're in a separate name
space, because there's a
separate API for them.
And so they are -- there's no
conflict there.
It also means you can never get
a custom symbol using this API,
and you can never get a system
symbol using the UIImage(named
API.
They are totally separate.
For custom symbols, it's a
little bit different.
We prioritize things now, so
we'll first look for a symbol
image.
And if we can find one, we will
return that, and otherwise,
we'll look for a non-symbol
image, and then you get that
back.
Now, you might say, "Well,
that's really annoying, because
what if I want both?"
But there's a good story for
this.
With the same line of code, I
can run my app on iOS 12 or
earlier, and I get the old
image, the bitmap image in this
case.
And if I run my app on iOS 13 or
later, I get the symbol image.
So I don't have to write any
version-checking code to get a
different image for the
different OSs.
Just provide 2 images with the
same name, and it works out of
the box.
If you do want to use the old
image on iOS 13 or later, you
have to duplicate or rename it.
So let's -- going back to our
slides, and one other thing that
we have is the configuration on
this teacup.
It should be large.
How do we do this?
We create a new type that we
introduced, SymbolConfiguration,
and we create one with a large
scale.
The other configuration
properties that are on the
object are unspecified.
We only have a large scale here,
and then we can use the
imageView to display our image.
There's a new property on
UIImageView called
preferredSymbolConfiguration
that will tell the imageView to
use this configuration to render
a symbol image.
It will have no effect on
non-symbol images.
If we run this, what a
difference a scale makes.
Now, you can also use this
configuration to change the size
of a symbol.
You specify a point size, and
optionally, a weight or a scale.
Now, an important point here is
that symbol point sizes are not
screen point sizes.
Symbol point sizes are expressed
as font point sizes.
They're typographical in nature.
The screen point sizes describe
the dimension of the image, the
width and the height.
Now, a picture says 1,000 words,
so let's see that and visualize
this.
Like, we have this -- our circle
symbol next to the "Favorite"
text, and they are both
specified using the system font
at 28 points.
Now, you might expect this image
to be 28 x 28 points.
Well, it turns out, it isn't,
and these values are the actual
correct values for this symbol
at this configuration.
And the image is not even
square, and it's a circle.
So for symbols, you have to let
go of describing the image using
a dimension.
You have to use the symbol
points, and you can think of it
as a piece of text.
Because if you have a piece of
text, you describe it using the
font point size, and not using
its dimensions.
It's the same.
Another way to configure a
symbol is using a text style,
and that means that the symbol
will behave according to the
dynamic text style rules.
It will behave the same as a
piece of text with the text
style.
So it matches great with text
styles.
And imageView will automatically
change the size of the image,
and look up the right size at
run time, depending on the
preferred content size category
of the app.
You can see this in practice.
Like, the text is nice and
large, and the symbols scaled
accordingly.
And they have the nice -- the
same weight.
So images can change size
dynamically, and we have to talk
about this, because you usually
want to constrain an image by
width and height.
And since a symbol renders
always -- it's a vector.
You could be inclined to always
specify this width and height,
but it's actually not a good
idea.
First of all, it's not really
correct.
You can see on the screenshot
that the symbol is described as
a 17-point symbol, which is
really small, but it still
renders as a very large image,
because the width and height are
there.
But you can also see that it's
not entirely correctly centered.
Like, it's a little bit off to
the left, and a little bit off
to the top.
And secondly, it's not
performance -- this is not the
most performance way to display
a symbol image.
So what you want to do is not
constrain the symbol image at
all, and have it be its natural
size.
In this case, we changed the
size of the symbol to 500 points
to match the size that we had
before, and it looks a lot
better, because it -- the
centering is better than before,
and the size is more correct.
This will also be more
performance.
So if you do need a fixed size,
set the point size, but
otherwise have the symbol react
to the symbol configuration,
because even a large symbol
configuration or a small-scale
configuration may make a big
difference for the size of the
same symbol.
Now, there's a lot of
configurations here, and we've
established that symbols are --
Paolo mentioned before that
symbols are really made to work
with San Francisco, our system
font, but they work with any
font.
So you can use this API,
SymbolConfiguration(font, to
create a configuration that
matches the font you give it,
and it works with system fonts.
It works with dynamic type
fonts, but it also works with
custom fonts.
And especially for custom fonts,
it will create a more
high-fidelity configuration than
the one you can create manually
by copying the values from the
font into your configuration.
So it's better to use this for
custom fonts.
And when you already have a
piece of text or a label that
has a font configured, this is
an easy way to create a
configuration that matches that
font.
And the last thing about
configurations is that they are
immutable.
You can't change them.
So what if you do want to change
them?
Well, you have to combine them.
There's a method called
applying, and it applies the
specified configuration to the
one that you're calling it on.
So we'll take the configuration
you're calling it on, and then
take all the specified values in
the other configuration, and
override, or set them on the
base configuration.
And you get a new configuration
that you can use somewhere else.
But they are immutable, and the
configuration themselves won't
change.
Now, let's talk about layout.
We have this simple comments
section in our app, and we want
to expand a little bit for our
next version, and also start
using symbols here.
And we have this avatar
placeholder.
I'm going to focus on just one
row, and Paolo suggested
switching to a new symbol.
So let's try that.
That looks a lot better.
So normally, if you would align
images with a piece of text, you
would use center alignment --
vertical center alignment, and
in most cases, that would look
like you would expect, and it
would be the easiest.
Now, for symbols, there's
actually no difference.
You can still use vertical
center alignments, and it's
actually preferred.
UIKit will actually take the
typographic information in the
symbol and use it to properly
visually align the symbol versus
the piece of text, and that
might actually happen that the
frames of the two elements are
not matching up together.
So the center is optically and
not absolute, but you don't have
to do anything.
The system does it for you.
There's, of course, also cases
where labels have more than one
line, and vertical centering
works great here, too.
Same for symbols, we'll still
use the typographical
information to properly align
for the center of the label.
This is great for disclosure
indicators, for example.
And looking back at our view,
the disclosure indicator sits at
the right place where I want it,
but I actually want that avatar
placeholder to be next to my
first line.
So let's move it.
In this case, you can use
baseline alignment, and up until
now, it would be a bit hard to
make this happen.
You could do edge alignment,
because you know the text and
the label would be there, or you
could do baseline alignment, but
have to calculate offsets, so it
would be weird.
And in this case, for symbols,
we can just baseline align, and
that's it.
Thank you.
[ Applause ]
And you can actually inspect
this baseline because we
introduced a new property on UI
Image called
baselineOffsetFromBottom, and it
expresses, like it says, the
offset to the baseline from the
bottom of the image.
And it's an optional CG float.
Why? Because not all images have
baselines.
Symbols come with one by
default, but other images don't
have one.
So you have to check if the
image has a baseline in order to
see if you can use it.
In Objective-C, there's a
separate [inaudible] for it,
because they don't have
optionals.
Now, these baselines might be --
have unexpected values.
In this case, we have two symbol
images.
They're right next to a piece of
text.
They have the same size, and
they share the same baseline.
But if we visualize their
bounds, you can see that the
chevron is sitting high above
the baseline, and the cloud sits
over the baseline.
And looking at their values, you
can see that expressing the
offset from the bottom means
that going up is a positive
offset and going down is a
negative offset.
It also means that it's valid
for an image to have a baseline
that is outside of its bounds,
in this case, the chevron.
And if you have a baseline value
of zero, it doesn't mean that
you don't have a baseline.
It means that the baseline is
the same as the bottom of the
image.
It's a bit surprising, but it
works.
Now, the good thing is, we also
added API to add baselines to
images.
You would use
withBaselineOffsetFromBottom,
and you would get a new image
that has a baseline configured
like you asked for.
Again, this is an offset in
screen points from the bottom of
the image.
Now, the nice thing is, the
image will start behaving like a
symbol.
It's not a symbol, but will
behave like a symbol, because it
has some typographical
information.
And so, you can use the same
layout for symbol images as for
regular images.
You don't have to check does
this image have a baseline?
Then I use this layout, or the
other way around, and this makes
that a lot easier.
And looking at our example, we
now have actual avatars, and
some rows without avatars, and
it looks much better.
And I only had to do baseline
alignment for this first line.
It's really easy.
I also want to touch briefly on
horizontal alignments.
You can see that the images are
horizontally aligned on the same
column, and you do this by
specifying an offset that you
want to align to, and then
center the images on that
offset.
It's pretty easy.
And then you can go from that
offset to the text, or from the
edge to the text.
So you should actually center
align, even horizontally, the
images instead of applying a
leading or a trailing constraint
there.
Now, let's go back to our spec.
What I wanted to say is that,
like, by default, it's probably
a good idea to start with center
alignment, both horizontally and
vertically.
In most cases, that's what you
want, and the system will handle
everything for you.
It will use typographical
information if it's available,
and otherwise, it will use the
old-style just centering.
And in this case, Paolo
specified baseline alignment,
because the second line -- the
second item has two lines.
So we'd need to use the
baseline.
Then we can fall back to
baseline alignment, but that's
also very easy.
And this spec also properly
specifies horizontal alignment
of the images.
It makes the spec a lot easier
to read.
Now, let's go back to buttons.
Buttons -- there's a lot of
buttons in UIKit.
We have two types of buttons,
system buttons and regular
buttons.
Let's start with the system
buttons.
First of all, all buttons in
UIKit come with a preset symbol
configuration, and for system
buttons, it's body large.
That means that it reacts to
dynamic type changes, has a body
text style, and a large scale.
Now, wouldn't it be great if you
could create system buttons,
like the info button in the
available Wi-Fi networks list,
but to create your own system
buttons that looked exactly the
same, with your own symbol
image?
Well, we thought it was a good
idea, and we added some, an
initializer on UIButton that
allows you to create a system
button with any symbol image.
And it will behave like an --
like a regular symbol image.
[ Applause ]
Now, let's go to regular
buttons.
In this case, I have a pop-over,
and they're used as actions in
this view.
And symbols really shine here.
They're really in their place.
A regular button comes with a
medium-scale preset.
Now, having said -- talking
about these preset scales, what
if you want to change them?
Well, there's similar API on
UIButton, as on UIImageView,
called
PreferredSymbolConfiguration
forState.
That works exactly like the
other content accessors on
UIButton.
You can set a configuration for
certain states.
And it gives you maximum
flexibility because you can set
an image, you can set a
configuration, or you can set
both, and it will work
perfectly.
Another button example is this
one.
It kind of shows what we mean
with symbols and text really
shine together, but it doesn't
mean that they're always close
together.
These two buttons really belong
together, and they're configured
in the same way, both the left
button and the right button.
The preferred symbol
configuration is matched with
the font of that right button,
and the only difference between
the two is that the left one has
a symbol, and the right one has
a piece of text.
And you can see that they share
the same baseline, and because
their configuration is exactly
the same, they also share the
same metrics, and it makes
layout a lot easier.
And to round off our button
story -- I mentioned there's a
lot of buttons in UIKit.
We'll go to bar buttons.
We have updated all the artwork
in UIKit to use symbols.
It not only applies to bar
buttons, but everywhere, and bar
buttons feel right in place with
the new artwork.
Now, if you do back-deploy to
older systems, you have to keep
in mind that if you create
custom artwork, on older
systems, you still get the
previous, thinner artwork than
the new, updated artwork.
So keep that in mind if you
create assets for your
back-deployment.
You can use symbols in bar
buttons with images.
We have existing API for this,
and you just put a symbol in
there.
And it will feel right in place
with the system buttons.
You don't have to do anything
here.
That's all you have to do.
And again, like regular buttons,
bar buttons come with the preset
configuration.
And in any non-compact size
class, like in portrait mode on
your phone, the configuration
will be large.
If you then rotate your phone,
and end up in a compact size
class, we will change that
configuration on the button to
be medium.
And this will call the symbol to
slightly be smaller, and to fit
perfectly in the more compact
bars.
It also means that you don't
have to provide a secondary
image anymore, because the
system does all the work.
It will scale using the built-in
symbol scales.
[ Applause ]
And on the iPad, we're -- we
always have a large, because of
the things I mentioned before.
Now, another thing about symbols
is rendering modes.
Any regular image has, like,
color data built into it, but
for a symbol, it's different.
It has an intrinsic mode.
It doesn't have an intrinsic
color.
So we use the tint color to
render the symbol, and if we
don't have a tint color, we'll
use black.
But don't rely on that black,
because it don't want -- work
nice with dark mode, and it
might be subject to change.
How does this work?
The rendering mode on any image
is automatic, and up until now,
for any image, that would
usually resolve to always
original.
Now, in -- with symbols, that
changes.
Non-symbol images still usually
resolve to always original, but
symbol images will resolve to
always template.
And that means that we'll use
the tint color to give them a
color, and that's all there is
to it.
You can change the rendering
mode on an image with the
existing API.
Now, I've covered the basic
UIKit controls, but sometimes,
you do want to draw an image in
a graphic context.
And you would probably use
draw(in Rect.
Now, for symbols, like I
mentioned before, that's
probably not a good idea,
because they want to be their
natural size.
So it's better to use draw(at
and have the image decide how
large it wants to be.
But we have a problem.
We have this image, but it's too
small.
By default, images come with an
unspecified configuration.
Nothing is specified, and if
we're just -- if you have to
render it, and we don't find a
specific value, we'll fall back
to the system defaults.
And in this case, that ends up
with a pretty small image.
Now, I can create a
configuration to make it larger
-- 34 points, and a bold weight,
and then use new API
withConfiguration to apply that
configuration to the image, and
get a new image with that
configuration built in.
Which results in this larger,
slightly more bold teacup, which
is exactly what I wanted.
Going back to our pop-over,
Paolo also asked me to change
the text here, because symbols
feel at home in text.
Can we replace some words with
symbols?
Well, we can, but symbols are
typographic in nature, but they
are still images.
So we have to use an attributed
string with an NSTextAttachment.
Now, this code will look
familiar, but we have a new
piece of API,
NSTextAttachment(image that will
create a text attachment with
the image attached.
Now, this text attachment is a
bit smarter than the regular
one.
It knows about symbols, and it
will actually inspect the string
around the symbol to complete
the configuration of that symbol
as much as it can.
It will look at the font size.
It will look at the font weight,
but it will also look at the
color, and then the completed
image will be drawn.
[ Applause ]
The old API, or the existing API
creating a text attachment and
then assigning the image still
works, but it won't get the
matching behavior.
And of course, you can also use
this new API with any regular
image.
Paolo also wanted some color
here.
Looks better.
Yeah. And we created some new
API to do this.
You can tint an image now.
So withTintColor applies a color
to the image, and it does so
very efficiently.
It will only render the color
when it needs to, and then it
will look at the most efficient
way to do this.
And before, you would probably
have to rasterize an image, and
render into a graphics context,
and then apply a color.
You don't have to do that
anymore.
This takes care of this.
[ Applause ]
And it's especially important
for symbols, because they don't
have an intrinsic color, and
this will give them a color.
Now, symbols also have a
different rendering mode.
So if you really want that color
to pop out, you have to change
the rendering mode, and you can
do it in one go with this
optional parameter.
Now, these two APIs are not in
the first beta, but they will
come soon.
So we've seen a lot of API, and
we think we provided you with a
great tool set to make your apps
really shine in iOS 13.
But there's a few tips.
Prefer horizontal and vertical
centering over edge alignment.
It's a bit of a mental shift,
but once you figure it out, it
really works out.
And try to build your layouts
from the smallest element up to
the largest element.
It's pretty easy to start with
something small and then use it
as a building block to make
something larger.
And be flexible.
Image sizes can change.
Allow your image views to be the
size of their image but be aware
of the fact that they can
change.
It can be at run time, or it can
be over app launches, or even
over system updates.
Caching images usually doesn't
help.
It's a great source of bugs, and
the system already does its best
to provide the best performance
that it can.
And caching really gives you an
override, so there's no need to
do that.
And finally, rasterizing is, in
most cases, the worst solution,
or the least-optimal solution to
fix the problem.
So save your CPU cycles for
something useful, and let the
system rasterize an image.
So try to avoid rasterizing
images, especially symbol
images.
The accessibility and
localization sessions this
morning were -- are very
interesting to check out,
because symbols make adaptation
in those areas a lot simpler.
And there's the Implementing
Dark Mode tomorrow, where
symbols also really shine
because of dark tint color.
There are two labs you might be
interested in.
There's a text and SF symbols
lab, and fonts lab on Thursday,
and there's a design lab on
Friday afternoon.
And of course, you're welcome at
any of the UIKit labs.
Thank you so much for listening
and enjoy the rest of your WWDC.
[ Applause ]