WWDC2019 Session 210

Transcript

[ Music ]
[ Applause ]
>> Hello and good afternoon.
I'm Chris Dreessen.
I work on the Cocoa Frameworks.
And we're going to be talking
about what's new in AppKit this
year.
So, let's dive in.
We have a lot of functionality.
We have some additions to
NSColor, some additions to
NSScreen.
We have a whole grab bag of
features to help you with text
and fonts.
We're going to do a little pub
crawl right here in this
session.
We're going to talk about
toolbar and Touch Bar and
sidebar.
And then we're going to talk
about some new control
functionality in AppKit and
macOS 10.15.
And we'll wrap up our section on
AppKit by talking about NSEvent.
We'll take a small jump and go
into some foundation features
including some geometry
enhancements and new formatters
to make localization easier than
ever.
And then we'll wrap things up
with some notes on system
extensions in macOS 10.15.
So, before we do that, though,
let's go ahead and address the
big thing.
In macOS 10.15, AppKit is not
the only UI framework on the
system.
We have two new UI frameworks
joining us.
So, one of these you've probably
already heard of and that's
UIKit.
In macOS 10.15, you can
recompile your apps and run your
iPad apps on the Mac.
And if you have a
well-maintained AppKit app, this
is probably not going to be very
interesting for you.
But, if you have an iPad app
you've never brought to the Mac
or you've had an iPad app you've
been investing a lot in the last
decade, not so much the Mac,
this could be very neat.
You will still use AppKit to add
the finishing touches to your
UIKit app for things like
toolbar and Touch Bar support.
But we think that can be very
interesting.
The other new framework-- and
we're really excited about
this-- is SwiftUI.
And SwiftUI is this neat
declarative way of describing
your user interfaces and the
transitions between them, ways
of binding them to your model
data.
And this we think is a great way
for making UIs.
It's Swift native and supports
all sorts of Swift language
features that we really like.
Again, this is something you
will use in conjunction with
AppKit.
You will embed it in view
hierarchies potentially all over
the place.
So, there are sessions about of
these frameworks all throughout
the week and we think you'll
enjoy them.
On to AppKit.
So, in macOS 10.15, we have some
new system colors in NSColor.
We have teal and indigo.
These are system colors which
means they're actually dynamic.
Depending on which appearance
you use they can look
differently.
But we think these are great
colors and you'll enjoy using
them in your apps.
We also have an under the hood
change in NSColor we want to
talk about.
And that's-- that NSColor is now
using the tagged pointer system
we also use for NSNumber and
NSString.
And what is a tagged pointer?
Well, normally for NSColor, we
would store the various
component values or other
information as eye bars in an
allocated object.
And with tagged pointers, we
instead condense that
information down to a smaller
number of bits and store in the
pointer itself.
So, there's no separate
allocation.
If you had code that was very
heavily allocating or
deallocating NSColors, you're
going to notice a performance
one from this, so we're excited
here.
Generally, that's going to be an
invisible change for you but
there is a case I want to point
out.
If you're accessing a derived
property of the color, for
example the CGColor, with the
non-tagged version, that could
be cached as an eye bar in the
color and it's possible the
CGColor would live as long as
the NSColor.
In the snippet we have on
screen, you could see that we
passed that CGColor to a
ContextSetFillColorWithColor,
and that would have worked OK in
the past.
With tagged pointers, using it
outside the autorelease pool is
potentially hazardous.
So, it'd be a good hygiene not
to do that anyway but something
to be aware of just in case.
So, a lot of us have used color
panel.
And there is a near and dear to
us eyedropper tool in the color
panel that lets you click it and
bring up a magnifier like this
and then select a specific color
on screen to read the RGB values
of.
In macOS 10.15, we're exposing
this functionality to you too
with a new class called
NSColorSampler.
So, NSColorSampler is very
simple.
It has a single class method on
it called Show.
You pass a block to show and we
will call you back with the
selected color or nil if the
user canceled out of this.
And we're really excited to
share our implementation with
you too.
If you have your own
implementation something to be
aware of in macOS 10.15 is that
Screen Recording is going to
prompt for user permission.
And this is something that
doesn't happen if you use
NSColorSampler itself.
There's another NSColor API that
we find incredibly useful.
We call it the Dynamic Color
Provider.
And it's really just a new
initializer on NSColor.
It takes two arguments.
One of these arguments is a
block and that block accepts an
NSAppearance.
When we go to resolve the color
either because we're drawing it
in a bitmap context or writing
it to a file or using it as a
layer background color, we're
going to call this block with
whatever appearance is
appropriate at the time.
In our snippet on screen, we use
the NSAppearance bestMatch
method to tell us whether the
requested appearance was more
like aqua or more like darkAqua.
And we have hard-coded colors
for each of those cases.
This can be very useful where
you want to have some
programatic decisions and
dynamism in your use of NSColor
in your application and this is
much simpler than trying to
propagate a hard-coded literal
color across a view hierarchy on
appearance change.
So I mentioned there were two
arguments.
The other argument is a name.
And the name is very significant
for coding purposes.
If you send one of these colors
over an NSConnection-- an
NSXPCConnection, when we decode
it we're going to look it up by
name.
So it's also important to
register that color on both
sides of the connection.
So colors are great.
NSColor is great.
And they're all better with
screens to view them on.
So we'll talk about some
NSScreen improvements.
If you're ever implemented a
screen picker control, you may
have wanted to have a
user-facing string to identify
an NSScreen with.
And if you use the inherited
description method from
NSObject, your users probably
were not content with NSScreen
0x6000261e460.
So, in macOS 10.15,
NSScreen.localizedName will give
you a nice human readable string
to describe that screen.
All right, talking about screens
more generally.
Over the last many years,
screens have been getting
brighter and brighter and
brighter.
And there are very few people
who run their screens at max
brightness anymore.
And if we apply this to a
specific picture, we can imagine
that black is a zero component
value and one is the white
component value.
And as we dim that screen, we're
sort of compressing what one
means in absolute terms.
We are emitting fewer photons
per unit value in our software.
But that monitor hasn't lost
that ability to produce bright
colors.
We can instead allow Extended
Dynamic Range content, content
that isn't clamped in the zero
to one range and keep using the
maximum brightness potential of
that monitor to make some images
where we have things brighter
than our reference white point.
And this isn't actually a new
feature.
This is something you've been
able to do on a number of Macs
since macOS 10.11.
There's two APIs that would help
you do this.
One of them is
NSScreen.maximumExtended
DynamicRangeColorComponentValue.
It actually does stuff.
It's not just the longest
Objective-C property name you've
ever seen.
And what we would do is when
your system was in the Extended
Dynamic Range mode, it would go
ahead and tell you the maximum
component value you could use
before clipping would happen, so
that could be 1.3 for example.
If the system wasn't in this
mode, it would just return 1.0.
So you put the system in this
mode using a different API and
that is CAMetalLayer.wants
ExtendedDynamicRangeContent.
There is also an API
NSOpenGLView called
wantsExtendedDynamic
RangeOpenGLSurface.
And when either of those is set
to true, you can get that extra
headroom from this API.
So something we've added in
macOS 10.15 isn't even longer
Objective-C property name.
The important bit is actually
shorter.
That's the maximum potential
piece.
And this will tell you that
headroom, that maximum value,
even if the system isn't in the
extended dynamic range mode, and
that can be very useful if you
are working with extended
dynamic range content, you might
have multiple possible pipelines
you can send your image data
through.
And a floating-point pipeline
for extended content is probably
more expensive than a BGRA
pipeline, for example.
So knowing that you have that
headroom to play with ahead of
time let you conditionalize that
support.
So there's another API I want to
talk about specifically for the
new Apple display we saw
yesterday.
And that display is absolutely
amazing because of how bright it
can get.
It can sustain a thousand nits
indefinitely.
And because of that ability, we
like to say it's a reference
quality display.
We can say that for a specific
component value, there were will
be an absolute number of nits
for that pixel.
Now, it's very bright but it's
not infinitely bright.
If you go ahead and produce a
bright enough pixel value, it
won't actually be able to
represent it and that reference
quality attribute we talked
about will be compromised.
We'll have to scale the image
content down to fit in the
brightness range available.
And that's what the NSScreen
maximum reference value is
telling you.
If you exceed this value, you're
not going to be able to dish out
absolute nits anymore.
OK. So I mentioned CAMetalLayer
as part of a way of getting
extended dynamic range content.
And I want to point out
something that if you're using
MetalLayer on the Mac today, you
should be doing, and that you
should be paying attention to
which screen and which metal
device you're going to see
MetalLayer is going to be
displayed on.
That's a little convoluted.
You have to get your window and
your window screen and your
screen's device description.
And then you have to ask it for
this hard-coded string that you
found on our documentation but
we never exported in any of our
headers.
And finally you'll pass that CD
direct display to figure out
which device to use.
And it's worth it because that
will allow you to avoid moving
the data between GPUs across the
system bus but we've made this
better in macOS 10.15.
CAMetalLayer and MetalView have
a new preferred device property
that will answer that question
for you.
It really reduces your code
around this.
So we're excited that you get to
use that this year.
And that covers what we wanted
to say about screens.
And now we're going to go into a
whole diversity of text
features.
The first of these I want to
mention is NSTextView uses
adaptive color mapping for dark
appearance.
And this is a feature that you
can turn on and off and text at
it.
I have snapshots of them in both
the aqua and darkAqua
appearances using colors from
the system crown crayon picker.
And you can see that when this
feature is activated, snow and
licorice for example almost
invert colors.
Meanwhile the more saturated and
vibrant colors retain that same
color character but changed
brightness to better match the
appearance therein.
So this can be very useful for
making text use with plain
content where you want them to
fit in with the current
appearance.
And it can be very useful for
each text documents where the
desire to make them fit it is
more important than making them
appear exactly as they will on a
printed page for example.
Generally, we think this is the
right thing to do but if you
have an app that's focused
around authoring rich text
content, you probably want to
either opt out or offer the user
the ability to turn this off so
they can decide that they want a
representation matching printed
content more than their screen.
So I think most people in this
room are familiar with
NSSpellChecker if not as a
developer then as a user.
And in macOS 10.15, we're happy
to announce that NSSpellChecker
has a successor.
And that successor is
NSTextCheckingController.
So, NSSpellChecker works with
NSTextView but
NSTextCheckingController works
for the variety of systems we
use in UIKit and WebKit and
AppKit.
And you can use it yourself by
implementing the NSText checking
client protocol.
But in addition to spell
checking it does other things.
It does grammar checking.
It can do data detection to find
URLs and phone numbers and
dates.
And you can control all of that
and configure whether it's going
to a merely highlight
misspellings or automatically
correct them.
So we think it's a very flexible
API and if you're big on text
input, it's something worth
checking out.
The small edition related to
text is that almost all of the
NSText related classes support
secure coding now.
So if you wanted to use these as
part of a vocabulary over NSText
PC connection, they will work
splendidly.
We're probably all familiar with
NSFont and slightly few of us
are familiar with
NSFontDescriptor.
NSFontDescriptor is a neat class
that lets us look up and
transform fonts using sort of
semantic attributes about them.
So I made a little sample up
here.
And the top row is a font I've
hard-coded in Interface Builder.
But the subsequent rows I've
configured using the
NSFontDescriptor system design
API which is new in macOS 10.15.
And lets me go ahead and say, I
want to switch to a rounder font
or a Serif version or a
monospaced font.
And there's a session about this
which we'll go on to much
greater detail about it but we
think this is a great way of
stylizing your applications.
So, if anyone has a
cross-platform app where they
are writing rich text documents
on both macOS and iOS or even in
app that has not cross-platform
where they are reading documents
from the other platform, you may
have hit a situation where even
though the document is
specifying the same font sizes,
they visually look very
different.
And that's because we have very
different screen densities
between our iOS devices and Mac
devices.
In macOS 10.15, we have new
attributed string APIs that you
can use when reading and writing
attributed strings to rich text
documents.
And you can tell us what the
source and destination operating
systems are and we will
automatically adjust font sizes
to make them appear visually the
same.
In this case we brought our 160
point font down to 120 point
which is roughly where they're
visually the same height.
The last text feature I want to
talk about is an addition to
NSLayoutManager called
usesDefaultHyphenation.
And in the past, you'd be able
to get the NSText Class that's
hyphenate for you by using an
NSParagraph style to control the
threshold of hyphenation.
This layout manager property is
a little bit easier to use.
It defaults to off, in which
case you get no hyphenation like
on the left.
And if you set in on it we'll
pick up a default value for
hyphenation.
And you can see on the right
that we've hyphenated
encyclopedia and
internationalization.
So we think these text APIs will
really help you polish the
corners and edges around your
text systems.
We have some great new stuff in
NSToolbar.
The first edition is a new
property on NSToolbarItem called
isBordered.
In the past, if you wanted to
get this push button style
appearance in an NSToolbar, you
would have to allocate your own
NS-- or instance of NS button
and configure it and then you'd
use it as a custom view on your
toolbar item.
And that would work but it was
extra effort for you and
additionally you couldn't take
advantage of NSToolbarItems
built in support for automatic
enabling and disabling.
But if you go ahead and use this
isBordered property, you'll get
all of that for free.
Additionally, NSToolbarItem has
a new title property which lets
you configure your toolbar items
to be a string-based buttons
instead of iconic ones.
And this is distinct from the
label property which would
appear below these buttons if we
had configured the toolbar as
your labels as well.
And that is not the NSToolbar
related class to gain
functionality in macOS 10.15.
We have also added a number of
features to NSToolbarItem group
to make it incredibly versatile
and useful.
And the first of these is a
number of convenience
constructors for it, and these
are just going to let you build
the same great toolbar UIs in
fewer lines of code.
But NSToolbarItem group has
become more flexible at the same
time.
If you look at the image on the
right side of the screen, you
can see that it now has support
for representing its items as a
segmented control and it can
also represent them as pull-down
and pop-up menus too.
And so this makes it a very
versatile toolbar control
because of the way is uses the
other toolbar items as
vocabulary, we can also
automatically create a collapsed
representation for when you have
too many toolbar items for the
window widths.
There is a very similar effect
you can get using a new
NSMenuToolbarItem class.
And this is much like the menu
item representations of the
toolbar item group but it uses
an NSMenu as currency instead.
And that's significant because
you can use NSMenu features like
submenus or separator items or
even the ability to use a custom
view for your menu items.
So it's a very powerful tool if
you want to have sophisticated
drill-down behaviors in your
toolbar.
NSTouchBar has also received a
few enhancements in macOS 10.15.
The first of these I want to
note is a new class property on
NSTouchBar itself and that's
isAutomaticCustomize
TouchBarMenuItemEndabled.
And that will sound familiar NS
application has that exact same
property.
You could use this Touch Bar one
in a code where you want to
defactor in such a way to not
reference the NSApplication.
And one example of that is if
you're writing UIKit
application, you're not going to
have an NSApplication instance
to talk to anyway.
A more significant control is
the new NSStepper Touch Bar Item
class.
Just like an onscreen stepper,
this is very useful for when
you're doing a discrete entry
for things such as dates and
numbers but given the larger
size in the Touch Bar and the
horizontal layout, you can also
use this for new applications
like visually selecting the tool
on a drawing app.
So we're really excited about
this new Touch Bar Item class.
We think you'll be able to put
it to good use in your
applications.
NSSlider Touch Bar Item has a
few small enhancements too.
You may have experienced a case
were used an NSSlider Touch Bar
Item and it was a little bit too
small for your taste.
You could fix this by grabbing
the slider from the Touch Bar
Item instance and adding auto
layout constraints to it.
In macOS 10.15, you can just set
the minimum slider width
directly on the item and we'll
take care of that for you.
Similarly, if your slider has
global ambitions, you can now
check them by using the maximum
slider width property.
And lastly, we'll talk a little
bit about sidebar metrics.
In macOS 10.15 you can toggle
the size of a sidebar using the
setting and the general pane of
system preferences.
And we default to medium but you
can also use small and large.
And I want to call this out
because if you haven't known
about this feature you maybe
have not been including artwork
appropriate for the small and
large sizes.
So if you're using bitmap
artwork, go ahead and have
representations for that or use
a resolution independent
version.
Similarly, there's a new feature
in macOS 10.15 to allow
automatically picking the light
and the dark appearance, that's
also available in the general
[inaudible].
OK. We covered controls for
toolbars and Touch Bars.
Let's talk about some controls
that are more broadly
applicable.
The first of these, we're
excited to announce this is
NSSwitch.
And NSSwitch is a full subclass
of NSControl.
It supports bindings, it
supports formatters, but it
exists alongside the existing
check box functionality.
A question you probably have in
your mind is when should I use
NSSwitch and when should I use a
checkbox?
And if you are already using a
checkbox, you should probably
keep using a checkbox.
They're generally the right
control to use.
We think NSSwitches are better
used when you have a really
heavy toggle, something that's
toggling a lot of functionality
on and off.
And in this example I have here,
we have a master toggle on the
left which is going to enable
all of the individual sharing
services on the right.
In macOS 10.15, we've invested a
lot of effort in
NSCollectionView.
And one of the things we're
excited to talk about is
compositional layout.
And in this scheme, you no
longer need to subclass
NSCollectionView layout to
modify it.
There are number of interesting
features you can throw in, such
as container-relative sizing,
layout breaks and sections as
well as nestable groups, and
also making individual sections
scrollable.
And of course, all of that works
in both right to left and left
to right languages.
There's also a new collection
view feature called diffable
data sources.
And these are identifier-based
data sources that let us track
things like the addition or
removal of items or the movement
of an item between two locations
and we can automatically infer
the right animations to use.
So this means you won't have to
use performBatchUpdates or
reloadData.
OK, backing away from specific
controls to an IB feature.
IB storyboards are a really
great way of connecting the
various view controllers in your
application.
And historically, your view
controller would be initialized
through in it with coder and
you'd have to find a different
way of getting different
information into the view
controller.
That wasn't necessarily
difficult but it did mean your
code was factored maybe more
broadly than you wanted.
If you look at the snippet here
you can I have a function called
showPetDetails and this returns
a new view controller passing
along a coder from IB as well as
inserting our own notion of a
selected pet name.
So this is a great way of
bundling those separate
initialization and configuration
steps.
And the other important thing to
note about this is there's this
IBSegueAction annotation
attached to this function.
And by doing that, we can go to
the connections inspector and
interface builder for our segue
and wire it up directly to this
method.
So we think this is very useful
for adding extra configuration
into your view controllers and
storyboards.
So, a great feature of all
AppKit controls is how they
support auto layout.
They automatically know how to
measure their content and feed
that into auto layout engine.
And that means that you can do
things like change the strings
on these text fields and buttons
and auto layout would just
automatically reflow view
hierarchy and window for us to
look great.
Sometimes, though, there are UIs
where that's actually not
important.
So in this grid view, it's the
grid that is determining the
size of everything else and the
intrinsic size of these labels
doesn't actually matter.
But normally, AppKit would still
go ahead and measure these
controls and feed them into the
auto layout engine even though
they won't affect the final
result.
In macOS 10.15, you can turn
that off.
NSView gains two new properties
to turn off the measurement
behaviors for both horizontal
and vertical axis.
And we think that can be a great
way of getting back some
performance in UIs where you
know the intrinsic size of the
control isn't going to matter.
There's one other controller
related thing I want to talk
about and it's a bit more broad
than NSControl.
That's NSResponder and its
behavior relating to block
capture.
So if you look at our snippet on
screen, you can see we have two
blocks.
We have an outer block that's
going to be executed on the
background thread and we have an
inner block that's going to be
executed on the main thread.
And this is a fairly common
pattern.
We do our work in the background
and then we go ahead and assign
the results of that work, to the
UI on the main thread.
But this snippet in macOS 10.14
could have led to crashes and
the corruption.
And that's because if the only
thing retaining this field is
these blocks, the order of
destruction of the blocks isn't
defined.
If the outer block, deallocates
last, the text field will
deallocate on a background
thread and the text field by
virtue of being a responder is
part of the responder chain.
It can be part of the view
hierarchy or the key view loop,
so there's all these global data
structures that aren't safe to
modify from the background which
is what dealloc would do.
In macOS 10.15, this isn't a
problem.
NSResponder will automatically
move the dealloc method for it
and its descendants to the main
thread.
So it becomes safe to capture
these in blocks without being
concerned about where those
blocks are released.
And we think this is going to
remove a whole complex set of
crashes from many of your apps
where the corruption from doing
work on a background thread
isn't visible until seconds or
minutes afterward.
So, I want to talk about open
and safe panels for a moment.
We have a fairly broad change in
macOS 10.15.
And that's that open and safe
panels are now using a separate
process.
This is a behavior that's
already been present for
sandboxed applications and we've
simply brought it over to the
remaining apps.
Generally, this should be a
silent change.
We don't think you're going to
notice anything here apart from
some performance and security
benefits.
However, if you were
sub-classing open and safe panel
and relying on specific view
hierarchy configurations, you
might run into problems and we'd
be happy to see you in the labs
to talk about those and help
work through them.
We also have some new NSWorspace
methods in macOS 10.15.
These are methods that can open
one or more URLs or open an
application.
And that will sound familiar
because you'll think NSWorspace
already has methods to do that.
It does but the new methods are
asynchronous.
So they're not going to block
the main thread at all.
When the application finishes
launching or the operation is
canceled, we will call you back
using a completion handler.
And in addition to be an
asynchronous, these methods also
offer a high degree of control
over how we launch those URLs
and applications.
And that control is achieved
through the new NSWorspace open
configuration object.
This is just a sampling of the
knobs it has to play with but
you can control whether the user
needs to participate on this
process.
So for example, if you're
requesting a server mount or if
we don't know what application
to use, the user might need to
pick which application and you
can instead suppress that
behavior and just cancel the
open process.
You can also control whether an
application or document is added
to the Recents menu.
And there's an entire variety of
things for controlling which
applications can be hidden on
launch or which are activated in
the background or foreground.
So we think whatever your URL
application opening needs,
NSWorspace will accommodate it
wonderfully in macOS 10.15.
We're going to talk events for a
little bit.
And there's a feature I want to
show you.
And this is-- if you hover your
mouse over the green button in
the window title bar, you're
going to get this new menu.
And the first set of options
concerns things like making a
window full screen or
positioning it in a shared full
screen space.
And those are fairly useful.
But there's another feature that
I think is even more useful and
that's the ability to move a
window to another display.
As someone who is constantly
moving their laptop to different
external monitors, I found this
to be incredibly useful but you
don't actually have to use a
conventional display, iPads will
function as additional displays
now too.
So you kind of see where I'm
going with this given that the
iPad application is named pencil
draw and we have this beautiful
cursive script on there.
This supports Apple Pencil so
many iPads can now function as
tablet devices for Macs.
So in macOS 10.15, we're going
to have many more tablet users.
If you've been thinking about
adding tablet support to your
app at any point in the last
many years, now is a great time
to adopt it.
So I'm going to show what you
need to know to do that.
Tablet events come in basically
as normal mouse events.
There's a difference though and
that's if you pay attention to
the NSEvents subtype field,
there is a tablet point value
there.
And when you see a tablet point
event it, one, comes from a
tablet but it's also going to
have pressure information
attached.
And paying attention to that
pressure information is critical
for making things like that nice
cursive stroke where you have
different pen width throughout
it.
If you've used the pencil APIs
on iOS in the past, there was
something that you could do by
registering a handler to
retroactively receive updates to
pressure in the past.
That is not present on the Mac.
You can just pay attention to
the pressure field in the
NSEvent.
There's another convention
related to the Apple Pencil I
want to mention.
And this is that you can double
tap it the side of the pencil
and it will switch whatever the
current tool is in the drawing
app for example.
And we call this the change mode
event.
There's a new event type for it
on this event and there's a new
responder method to handle
directing that through the
responder chain.
In many cases, you might want to
have tablet functionality that
isn't actually anchored in a
responder subclass like a view
but you might still want to
handle events directly and
there's a way you can accomplish
this using the existing local
event monitor API.
So if you look at the snippet on
the bottom of the screen, you
can see that we use the NSEvent
add local event monitor for
events function to catch these
change mode events.
And then we just cycle through
our tools and we return the
event allowing it to flow
through the rest of the
responder chain.
So that can be a great way of
factoring your code more
usefully.
OK. Let's talk about a
foundation feature.
We have some new geometry data
types.
I know normally when we get into
foundation everyone is on the
edge of their seat.
This year, you can pick which
edge of the seat you're on
[laughter].
The data types are
NSDirectionalRectEdge,
NSDirectionalEdgeInsets, and
NSRectAlignment.
And instead of working in
currency like min-X or max-X or
left and right, these are using
leading and trailing identifiers
instead.
So they'll automatically flip
based on context in the left to
right or right to left system.
And NSCollectionVeiw uses these
exactly for this purpose.
We think you'll be able to adopt
them directly in your
applications too.
Another foundation feature I
want to talk about that will
help with localization is new
formatters.
The first of these is the
NSRelativeDateFormatter.
And NSRelativeDateFormatter has
two important properties, a
dateTimeStyle which allows you
to pick whether you're sort of
working in absolute units or
more colloquial terms, the one
week ago versus last week, as
well as the unitStyle
controlling how verbose or how
terse our languages.
There's also a new
NSListFormatter class.
And NSListFormatter is
interesting in that instead of
formatting sort of a scalar
object, it will format an array
of objects instead.
And it will do that by using a
separate item formatter for each
object individually.
The value the ListFormatter adds
is in knowing where to place the
commas between the individual
formatted strings as well as
whether an Oxford comma is
necessary or a conjunction.
There's a section covering this
in much greater detail later,
which I encourage you to check
out.
Foundation also has a new
feature we're very excited about
called Combine.
And Combine is a Swift API for
connecting properties of the
objects in your applications to
other properties in your
application.
So a specific example I want to
show is this awakeFromNib method
we've implemented where we go
ahead and we bind to the name
property from our model object
to the value of an NSTextField.
And whenever that name changes,
that text field is going to
update its string.
So this is incredibly powerful.
It has applications beyond just
UI binding.
And there's another section
dedicated to specifically this
that we think is going to be
fantastic.
So go ahead and check that out
this week too.
And finally, I want to mention
some changes in system
extensions for Mac OS.
We have a small addition to the
system extension family in the
form of a non-UI file provider
action extension.
And if you are familiar with UI
base file-- or file provider
action extension, this is the
same thing but sometimes you
just don't need that extra UI.
You can do without it and this
satisfies that need.
Something else that we think is
even more interesting is there's
functionality that in the past
you would have had to use a
kernel extension to add at the
OS.
And we've now made system
extensions to do similar things.
We have new network extensions.
We have DriverKit to help
writing certain types of device
drivers.
And we have a new endpoint
security system that will help
write antivirus software.
So if you have been writing
kernel extension all these
years, we think these will be
very useful for you.
We're excited with a security
enhancements we get to make
around this and we think you'll
be excited about not doing
kernel-mode debugging anymore.
So, that covers our additions.
I want to remind you of many of
the great things that we covered
today.
We had additions for NSColor
including new dynamic system
colors, new ways of embedding
your own programmatic dynamism,
under the NSColor system as well
as the ColorSampler class you
can use yourself for picking
colors directly from the screen.
We covered a number of APIs and
NSScreen including those for you
to make a great usage of
extended dynamic range.
And we have an entire variety of
text enhancements.
If you want your apps to look
great in Dark Mode and you're
presenting either simple or rich
text, the Dark Mode enhancements
are going to great, the text
tracking controllers will let
you enrich your own text engines
like never before, and our
compatibility between iOS and
Mac OS regarding text sizing is
very useful especially given the
presence of UIKit on the Mac
this year.
We covered controls like
NSSwitch as well as collection
view.
And we definitely encourage you
to check out the collection view
section because collection view
has become a very important part
of our UI vocabulary.
We covered some great
enhancement for NSToolbar
allowing you to make push
buttons more easily and more
versatile ways of using the tool
bar item group.
And then we've also covered some
things for handling tablet
events in NSEvent and specific
support for the Apple Pencil.
And again, with so many more
tablet users coming to the Mac
in the near future, we think if
your app can use tablets, it's a
great feature to add.
And we wrapped up with the
localization enhancements for NS
or for foundation geometry data
types and then new formatters.
So we hope you're excited to
adopt these too.
And please have a great week.
Thank you very much.
[ Applause ]