Ladies and gentlemen,
please welcome Vice President OS X Platform, Andreas Wendker.
[ Cheers and applause ]
ANDREAS WENDKER: Good afternoon.
Welcome to WWDC 2015.
This is another exciting year to be an Apple developer.
With the addition of the new watchOS SDK,
there are now three major platforms for your apps.
Our approach with these platforms is integrating great
products with unique user experiences,
while leveraging the same underlying OS technologies,
APIs, and programming concepts so it's easy to move
between these platforms to share code
and make these apps work together across the platforms.
But we are preserving a unique flavor for each of them.
The SDKs with these three platforms are going
to ship later this year with a new version of our Xcode IDE.
It's going to be version 7.
It contains a number of great new features.
I just want to highlight one here at the beginning
of the session, that is that we are going to allow anyone
with an Apple ID to download Xcode
and run their apps on their own devices.
If you really want to make becoming a developer a lot more
approachable, especially for our younger students,
so this will work with all three platforms.
Once you have worked on your app and you want to deploy it,
we have another bit of good news for you.
As of today, a single paid developer program membership
will be enough to deploy your apps in all our App Stores.
You don't have to sign up and pay
for multiple memberships anymore.
Of course, with that single paid membership,
you get many additional benefits,
like access to pre-release software,
or our powerful store analytics and crash reporting tools.
Now, let me talk about software updates a little bit.
The iOS adoption curve is, of course,
the envy of the entire industry, and it's a huge advantage
to U.S. developers because you don't have to deal
with the same fragmentation that you find
in other app ecosystems.
However, with iOS 8, we found that a number
of users had a difficult time upgrading
because of the large amount
of free space required for the installation.
We've been bringing that number
down with our subsequent iOS 8 updates,
and we are continuing to do so with iOS 9.
As you already heard this morning in the keynote,
iOS 9 will only require 1.3 gigabytes of free space.
We are also changing the way software updates are presented
to the user.
Users will be given a choice to install right now or later
at night, when they might not need access to their devices.
So we think this is going to keep pushing users
to update quickly and allow you to focus your energies
on the latest version of iOS.
Now, we are also working on a number of technologies
that we call App Thinning that will enable you
to return some space to your users.
App Thinning consists of three technologies: App Slicing,
On Demand Resources, and Bitcode.
Let's go over these one after the other,
starting with Slicing.
Developing an app for iOS actually means developing
multiple variants of the same app
and then packaging them all together
into a single app bundle.
So if you look inside an app, you find a number
of redundant components to cover the full breadth
of Apple devices.
There are binaries for 32- and 64-bit processor architectures;
images for different screen sizes and resolutions;
and resources like shaders, potentially written
in different languages for the various kinds of GPUs.
But to run an app on each given kind of device,
you only need a single slice of these components.
So to make the most of the available storage space,
we are going to strip away all the components
that are not actually needed
on the device the app is running on.
So you would still develop and submit the same universal app
that you are used to, but the store will only deliver a thin
variant of the app to the user at install time.
So this leads to quite impressive size reductions.
As you can see on the chart, typical apps will get savings
in the range of 20 percent to 40 percent.
And leveraging App Slicing is particularly interesting
for apps like games that often bump
up against the download size limit for cellular app installs.
The thin variants will have a much easier time staying
under that size limit,
so you can now pack more device-specific resources
into your apps and provide the users
with a more refined experience.
And best of all, assuming you are using Xcode's asset
catalogues, you don't have
to change a single thing in your projects.
The Store will simply do this automatically
for you the next time you submit your app.
If you're using additional custom data formats,
we ask that you opt into slicing by creating an Asset Catalog
and using the new asset categories we added to declare
for what kind of devices your resources are needed.
Now, some apps benefit from using even more resources,
through they usually don't need them all at the same time.
For those kind of situations, we are introducing
On Demand Resources, or in short, ODR.
With ODR, the store will separate your resources
into the appropriate device slices
and then host them on Apple servers.
But downloading gets delayed
until your app explicitly requests them,
and then later iOS will reclaim that space
when your app doesn't need the resources anymore.
Typical candidates for ODR are level-based games,
but many other apps can benefit from ODR as well.
For example, you might want to consider offloading tutorials
into ODR assets so that they only get downloaded
when the user actually wants to watch them.
Using ODR requires a little more planning on your part,
but the important point is that you can use more
than 4 gigabytes of resources, just not all at the same time.
So App Slicing and On Demand Resources are going
to help greatly with the storage space for an app.
But we are also working on a new technology
that is a little more forward-looking.
We are introducing Bitcode
into the App Store submission process.
Bitcode is an LLVM Intermediate Representation of your binary,
which allows the store to reoptimize your apps
for each kind of device before they get delivered to the user.
You develop and debug the app the normal way in Xcode,
but the store will be in a position
to constantly reapply the latest compiler optimizations we have
been working on so that your apps run great
on all kinds of devices.
It also future-proofs your apps because it will allow the store
to let your apps take advantage
of new processor capabilities we might be adding in the future,
and all that without you having
to resubmit your app to the store.
So generating Bitcode is controlled
with a simple setting in Xcode.
It will be mandatory for all watchOS apps right
from the beginning, and for iOS it will be optional for now,
though we feel that the benefits are so strong
that we are you are going
to opt all your projects into it by default.
So that's App Thinning.
It consists of App Slicing, On Demand Resources, and Bitcode.
These will greatly optimize your apps,
especially for storage space.
Now let's take another quick look
at the binaries in your apps.
The store currently requires you to submit both 32-
and 64-bit versions of your apps.
Over the last few years, we've seen an explosion
in processor capabilities on our iOS devices.
For our CPUs and even more so for our GPUs,
and all that especially since we introduced our 64-bit
So this category of apps that are really only possible
when they target these 64-bit processors --
So going forward, we will allow you to submit 64-bit only apps
to the store, starting with iOS 9 later this year.
So next we want to talk about the watchOS SDK,
and to talk more about that, I am going to hand it
over to my colleague, Eliza Block.
ELIZA BLOCK: Thank you, Andreas.
We're delighted by the reception that the Watch has gotten
in the developer community.
There are already thousands
of your WatchKit applications available in the Store,
and today I am excited to get to tell you a little more
about some of the great new features we're introducing
in the watchOS 2 SDK.
First, let's talk about the architecture
of an existing watchOS application.
You have a user interface, which you've constructed
as a storyboard, and this is installed on the watch.
Powering this user interface is your app extension,
which runs on the iPhone.
In watchOS 2, we are making a significant change
to this architecture.
The user interface remains the same, but the extension moves
over to run natively on the Watch,
and this has a number of advantages.
Because interactions with your Watch application no longer
require a round-trip to the iPhone, your users are going
to notice a substantial improvement to the speed
and responsiveness of your application.
And of course, for the same reason,
your Watch application can now work even
when the iPhone isn't present.
And since the extension is running natively on the Watch,
it gets access to the Watch hardware,
which opens up tons of possibilities.
Okay. So now that you're writing a native watchOS application,
what APIs are you going to use?
The good news is it's many of the same frameworks
that you're already familiar with from developing for iOS.
There's one important addition.
The watch connectivity framework allows your extension to talk
to the iPhone app, which, of course, is now running
on a different device.
In addition, your extension can talk directly
to web services using the NSURLSession API.
And this works even when your iPhone is out of range.
There are three ways of surfacing your data
in an existing watchOS application --
Glances, Notifications, and the app itself.
But wouldn't it be cool
if you could see your app's content just
by raising your wrist without even having to touch the screen?
In watchOS 2, this is possible
because now you can create a Complication for the Watch face.
We designed the Watch for brief interactions,
and the quickest way to see your content is
through Complications, Glances, and Notifications.
So let's take a closer look at these.
Despite their name,
Complications are actually quite simple.
They're snippets of information that appear
on your Watch face alongside the time.
So if we take these Watch faces and we remove the time,
everything left is a Complication.
Now, the ones you see here are all built right into the OS,
but now you can create your own.
Now, you might not all be aware of this,
but the fictional San Francisco Soccer Club is currently holding
its 2015 tournament.
So we could create a Complication
for the modular face to show what match is coming
up next in the tournament.
If I were to install this on my Watch,
I am going to see it every time I raise my wrist right away,
and that's great, but for it to be a good experience,
it's important that as time goes by and the content
that the Complication needs to show changes,
this has already happened by the time the screen turns on.
And to make that possible, we're going to be collecting the data
for your Complications in the form of a timeline.
That way, as I glance at my watch throughout the day,
the Complication will always be showing the information
that makes sense at that moment.
So creating a timeline for the schedule
of a fictional soccer tournament is pretty easy.
For one thing, I made up the schedule,
and for a second thing, it's pretty unlikely to ever change.
But that might not be the case for your Complications.
As things change in the world, you're likely to need
to update your timelines accordingly.
And we've provided a couple ways to go about this.
The first is Scheduled Updates.
Scheduled updates are perfect
for Complications whose data changes
on a predictable schedule, like a weather forecast.
If you've written a weather forecast Complication,
you may know that your server has access
to more accurate weather data maybe once an hour.
So when you load your timeline, you can tell us a good time
to next wake you up to refresh your data.
Your extension will be given the opportunity
to run in the background.
You can hit your server, pull down new forecast data,
and reload your timeline.
But not all data can be refreshed
at predictable intervals.
Suppose I wanted to add live scores
to my soccer Complication.
It's not going to be good enough for me
to hit my server every hour or so or even every 15 minutes
to pull down the current score because when a goal is scored,
that needs to show up right away in my Complication.
To support this kind of case, we're introducing a new kind
of high-priority push notification.
If you are providing data that is needed for a Complication,
you can send this push notification to your iPhone,
and it will be delivered immediately
to your extension on the Watch.
So timelines are great for making sure the content
in your Complications is always up to date,
but they also serve an important additional purpose.
If you went to the Keynote this morning, you will have heard
about the Time Travel feature that we are introducing
in watchOS 2, which allows you to turn the Digital Crown
to peek forwards and backwards
and see what your Complications will be showing
at different times of day.
For example, here it looks
like the Marina Noe Valley game has already ended
and I missed it because I was on stage talking about WatchKit.
Luckily, I can Time Travel backwards to see what happened.
It looks like Noe Valley won in stoppage time.
That must have been really exciting.
So that's Complications.
They are a really quick way to access data that's important.
Small amounts of data.
But what if you wanted to see a little more detail?
That's when you might use a Glance.
You get to your Glances by swiping up on the clock face,
and Glances give you the opportunity
to display an entire screen full of data to your user.
Here, for example, my soccer club Glance is showing me the
standings for Group A in my tournament.
Complications and Glances allow me
to access your app's data on my own schedule.
But sometimes you need to get information in front
of your user right when it matters,
and for that you would use a Notification.
Notifications on the Watch are incredibly powerful.
You can take full advantage of the screen
to show an entirely custom UI.
For example, here I am being alerted that it's my last chance
to pick the winners in this afternoon's SoMa Cow
In addition to the custom UI,
you can also provide custom actions.
Pressing either of these buttons would register my pick
with the application.
But that's not all.
Because in watchOS 2,
we are introducing Notification in-line text reply,
so I can add a button to my Notification allowing me
to compose a message to send.
I am a really big SoMa fan, and I want the world to know it,
so I am going to choose that option.
When I pick the Reply option, I am given the Quick Reply sheet,
and I can even use dictation to compose a message,
all from inside the Notification without switching context.
You are very kind.
So that's Notifications.
So Complications, Glances, and Notifications are so easy
to access, they are probably the way
that your users will most commonly interact
with your app's content.
But sometimes you have a little more time
and you want a more interactive, immersive experience,
and that's when you would launch the full application.
And there is so much you can do with applications in watchOS 2.
To give one example here, now that you have access to input
from the Digital Crown, you can use it to scroll quickly
through the groups of your tournament
to quickly find your favorite team and get more information.
But that's just one of tons of new opportunities
that you have with watchOS 2.
You can also add animations to your UI now.
You can access the Taptic Engine.
You can do audio recording right from the Watch.
And you can embed audio and video playback.
You can make a phone call from your application,
and you get access -- live access --
to the data from the health sensors and the Accelerometer.
We are so excited to see what you guys create with all
of these possibilities, and now to show you how easy it is
to bring your app to watchOS 2,
I'd like to invite up Josh Shaffer.
JOSH SHAFFER: Thanks, Eliza.
So I am really excited to show you how easy it can be
to take your existing watchOS 1 app and upgrade it to watchOS 2
to run natively on the Watch.
If you have downloaded the WWDC app this year,
you may have noticed that it now includes a WatchKit extension
to install and run on your Watch.
So what we are going to do is take a look at how we can update
that application and use it as a native watchOS 2 application,
and we'll add a few features to it using some
of the things Eliza showed us.
So over here, you can see that I have the Xcode project open
for the WWDC app, and Xcode has noticed
that I have a watchOS 1 extension and is offering
to upgrade it for me to a watchOS 2 extension.
I am just going to click here
and let it perform those changes.
It's going to take all my existing targets
and update them, leaving my source code and storyboards
in place so I can reuse all of what I've already done.
We can go over here and check out our controller context,
and what we have to do first of all is make a few code changes
to the way we access our data.
Now that we are running on a different device,
we need to be able to move the data from our iPhone
over to the Watch, and we can use the new Watch Connectivity
frameworks to do that.
So I will start adding the Watch Connectivity framework,
and we will replace the open parent application call,
which is what I used in the watchOS 1 version,
with the new Watch Connectivity code that will ask for the data
to be copied from the phone to the Watch.
With that changed, now we can add some additional
functionality, and one really cool thing to take advantage
of is the ability to interact with the Digital Crown.
Now, the way that you interact with the Digital Crown
in a watchOS app is using a new interface picker control.
We will drag that out in our Storyboard in just a minute,
but first we are going to add some code to hook up to it.
We will make some references to be able to hook
up to the Storyboard object once we drag it out,
and you add the items that you want to choose
from the picker programmatically.
So we are going to loop through all of the session tracks
that exist throughout the week and add an entry
to our picker for each track.
This way we will be able to sort the list of sessions
and view just the ones for the track that we are interested in.
Then finally, we have to add an IBAction that will hook
up to our control that will get called every time it changes.
So we will add that code there.
Now we can switch over to our Storyboard and figure out where
to put this in our app.
So I will come over here and find the new picker control,
and we will drag it out and put it in our session controller.
The session controller is the view that displays all the list
of sessions, so by adding at the top, it will provide a way
to filter that session list.
Just make it a little shorter so it's not quite so tall.
Now, the picker control is really flexible,
and there's three different appearances
that you can choose -- list, stack, and sequence --
that you can learn about throughout the week.
The list one is a really good choice
for what we are doing here, so we are going to leave that.
And we are going to turn on a focus outline
so that we can make sure the user can tell
when they turn the Digital Crown what's going to happen.
So with those changes made, we'll then hook up our picker
to the code that we pasted in a minute ago.
We'll drag out the connection to our IBOutlet
and drag a connection into our IBAction
so that it gets called every time the picker changes.
And that's it.
So with that, we are going to hit Build and Run,
and we can switch over to the Watch simulator
and see how this works.
The great thing about the watch simulator in watchOS 2 is
that it's a full simulator in the watchOS,
so you can run your entire watch app side by side
with your iPhone app, debug at the same time,
and test the connectivity code between them.
So now we can jump over here, and you can see
in our session list, we can scroll through the list
of sessions, and we can also filter based
on what track we want to see,
and it all updates as we change it.
Now, one last feature that I would really
like to add is the ability to display the sessions right
on our Watch face, and to do that, we are going
to add a Complication to our app.
Now, I wrote most of the code for this earlier,
so I am just going to drag the file out and add it
into my project right here.
The one thing that I haven't done yet is added the code
that will iterate through and build the timeline.
Now, Eliza mentioned that we are going to be providing the data
in the form of a timeline, so we want to iterate through all
of the sessions that I favorited so that
on the Watch face I can see my favorite sessions all week long.
Now, to save us some time, I built and installed this
on a Watch earlier today, so I am just going to switch
over here and take a look at how we can add
that to our Watch face.
So right at the beginning, I had a Watch face configured
with Calendar in the middle, but because I've got all this
on the WWDC app, we will just switch over here
and customize it, and then we can scroll down to the bottom
of the list of Complications, and you will see
that now the WWDC app has an entry all the way at the bottom.
We can click there to turn that on and go back
and view our session list.
Now, obviously, the platform State
of the Union is the session I favorited for right now,
but with no additional work, we can Time Travel forward
through that session list and see
that up next is the Apple Design Awards,
which I definitely don't want to miss, and then looking forward
to tomorrow we've got the Intro to WatchKit for watchOS 2
in the morning, which is definitely something I want
So that's how easy it can be to update your existing Watch app
to run natively on the watch as a watchOS 2 application,
and add some support for some great new features.
So next up --
Next up, Sebastien Marineau-Mes is going to tell us
about some great new foundation technologies.
SEBASTIEN MARINEAU-MES: Thank you, Josh.
That was great.
Let me now talk about a number of foundation technologies
that apply across our platforms, and I am going to start
with the first one that's in the theme of performance,
and it is compression.
We are going to make compression exciting.
[Laughter] So Apple's always delivered a number
of compression algorithms as part of our core frameworks,
LZ4, which is optimized for speed; LZMA,
which has high compression, and zlib, which many of you use,
which hits the sweet spot between compression and speed.
We set out to build a better compression algorithm
that improves on zlib.
As you may know, zlib is over 20 years old.
It was built when processor architectures were very
different, so we thought let's build something optimized
for today's processors and microarchitectures.
Now, we call this new algorithm Lempel Ziv Finite State Entropy.
You may know of them.
They are also a great Indie band.
You should go check them on Connect.
To avoid any confusion, we are going to simply call this LZFSE.
[Laughter] So now LZFSE -- thank you --
improves on zlib on compression, but more importantly,
it actually is three times faster than zlib.
This is a great improvement in terms
of making your apps more responsive.
On top of that, it helps with battery life.
It gives you a 60 percent reduction in energy use
with the same compression algorithm,
it also gives you a 3x speed improvement.
Finally, we've made it super easy to adopt.
We've added it to our standard framework.
All you need to do is switch your algorithm to use LZFSE.
We do all the hard work for you, and you
and your users can reap the benefits.
So this is LZFSE, really redefining the sweet spot
in mainstream compression.
Next up, I want to talk about battery life.
Craig mentioned battery life this morning.
Now, in our industry, when we test battery life,
we often do so using repetitive tests.
For example, we'll do web browsing over
and over again as our test.
And we know that in the real world,
the way that we use our devices is very different
from these synthetic lab tests; right?
We take the device in and out of our pocket,
we receive notifications and messages, we may use a variety
of applications, we may go in and out of network coverage.
So what we've done in iOS 9 is really focused on a broad set
of optimizations that apply
across all the most popular apps on our platform.
That's step one.
Step two, we focused on a number of infrastructure improvements.
For example, the algorithms that drive the backlight intensity,
facedown detection so that if you receive a notification
and are not able to see it because the phone is face down,
we will simply not light up the screen.
A number of other optimizations in how the system, for example,
sleeps, and optimizing its lowest power states.
All together, these optimizations add up to one hour
of extra use -- sorry -- of typical use for average users.
Craig also talked about Low Power Mode this morning.
Well, we've made it easy to turn on Low Power Mode.
Simply go in Settings and turn it on.
It activates a number of internal levers.
For example, preventing the CPU and GPU
from entering the highest performance,
but most power-hungry, states; preventing applications
from doing too much work in the background; preventing them
from doing unnecessary network activity; and finally,
turning off a number of power-hungry animations.
And altogether, Low Power Mode, when you start
from a full charge, will give you an extra three hours
So again, great improvement.
Let me now turn to protecting customer data.
So from the start, iOS has really focused
on protecting customer data, and with iOS 9,
we are taking a number of important steps to protect data,
both on device and in the cloud.
So let's start with the cloud.
Of course, use your Apple ID and use that to access a number
of services in the cloud, your photos.
You might have documents that are on iCloud, your purchases.
Use it for messaging with iMessage and FaceTime.
And the biggest threat to your data in the cloud is
that somebody gains access to your password,
either because you've shared that password
on another website that's been compromised
or perhaps an attacker, through a phishing attack,
is able to gain that password.
The solution to this is two-factor authentication,
and we are making it easy for everyone to adopt.
So let me show you how it works.
So with iOS 9, when you get a new device and you want
to sign it up to your existing iCloud account, you will be,
of course, prompted for your password, but on top of that,
you will have to enter in a verification code.
Simultaneously, we send a notification to your existing,
trusted devices, and that notification includes the
location of this new device that's signing in.
So if that's you that's signing in,
you can simply enter the verification code.
But if it's an attacker that's trying to sign
in to your account, you can stop them in their tracks.
That's the cloud side.
Let's now talk about the device
where the passcode is your last line
of defense protecting your personal data.
So historically, we've kept that passcode at four digits
because you had to enter it every time you wanted
to use your phone.
But of course, these days we don't enter the passcode
We use our fingerprint with Touch ID to sign
in seamlessly into our phones.
So now with iOS 9, we are able to extend the length
of the passcode from four digits to six, increasing the strength
of the passcode by a factor of a hundred,
without compromising ease of use for our devices.
Now that we've talked about the device,
let me introduce a new technology on all
of our platforms, which we call App Transport Security.
App Transport Security is really all about securing data
as it transits over the Internet from a device
or from your applications to your backend servers.
So of course we want that information as it transits
over the network to be secure.
But it turns out that today it's actually hard
for you to do that.
It's hard to get it right.
You can't use HTTP.
You have to use a secure protocol, but then you have
to worry about protocol versions, downgrade attacks,
Keeping it straight and doing what is best practice
With App Transport Security, we are building this right
in to our core frameworks.
And so now when you use our standard networking frameworks,
we will enforce a secure best practice connection
between your application and your backend servers.
Today that best practice is TLS 1.2 and Forward secrecy,
but as the standards and the state of the art evolves,
of course the framework will implement that new state
of the art and will enforce it for you automatically.
So where do you go from here?
If you use out standard networking frameworks,
for example, NSURLSession, it is built right in.
It is on by default with iOS 9,
so when you download the developer beta --
which I am sure many of you already did --
and you recompile your app,
we will enforce best practices secure connections
to your backend.
It is possible that you haven't updated your backend
yet to support best practices
or perhaps you are using a third-party library.
If that's the case, we have provided an exception mechanism
to give you time to update your backends through your info.pls.
So that's App Transport Security.
Let me now switch and talk about the Mac
and introduce a new technology
which we call system integrity protection.
Now, on the Mac, user accounts typically have administrative
privilege, and that administrative privilege is
really equal to kernel-level access,
and it makes it difficult
to protect the integrity of the system.
With system integrity protection,
we break that equivalency
and administrative-level access is no longer sufficient in order
to do a number of operations in the system.
Let me show you some examples of this.
So for example, if you have administrative-level privilege,
you cannot modify system files.
You can't install to system locations.
You can't attach to system processes and, for example,
introspect the memory or change the control flow.
So with the beta that's out today, we encourage you
to download it, test your apps to make sure that you are able
to basically adhere to all of these rules.
Now, you might also be wondering how will this affect the way
that I develop?
Well, the good news is we've updated Xcode
and the development tool chain, and for the vast majority
of you, you will see no difference.
For those that have a specific development requirement --
for example, you are developing kernel extensions on OS X --
we do provide a utility that's part of the recovery partition
that allows you to disable system integrity protection.
Which takes me now to the last technology that I want to cover,
one that underpins the modern Internet, IPv6.
Now, why is IPv6 important?
We've all heard about the shortage of IPv4 addresses.
Well, guess what.
It's finally here.
In fact, in China and Asia, they ran out of IPv4 addresses back
in 2011, and in the U.S., we will be running
out in the next couple of months.
What it means in practice is that a number
of carriers are now deploying IPv6-only networks.
And if your application doesn't work properly with IPv6,
it will simply not function on those carriers, those networks,
and for those customers.
So really important to support IPv6.
Now, the good news is we've had IPv6 support as part
of the platform for a long time, well over a decade on Mac.
It is field proven, and many of you
that are using our standard networking frameworks are making
use of IPv6.
But we want to go further.
We want to make sure that every one of you is building an app
that works on IPv6 networks,
so we've got a simple recipe for you.
Use the standard networking frameworks.
We've mentioned NSULSession.
It really takes care
of extracting the complexities of the network.
Avoid the use of IPv4-specific APIs,
many of which were developed before IPv6 was even conceived.
And finally, don't hard-code addresses.
Once you follow the recipe, you might say, how do I test
that it works properly?
Because not all of us have access to an IPv6 network.
The good news is again you all use Macs for development,
and we are turning your Mac
into an IPv6 network emulator with the latest beta.
So all you need to do is set
up through a new connection sharing mode a personal hot
spot, you check the IPv6 only box,
then you can connect your test device, test your applications,
and make sure that they work on IPv6.
It's as easy as that.
So finally, because IPv6 support is so critical
to ensuring your applications work across the world
for every customer,
we are making it an App Store submission requirement starting
with iOS 9.
So that takes me to the end of my foundation technologies.
Let me now hand it over to my fellow Canadian, Toby Paterson,
who will be talking about higher-level APIs.
TOBY PATERSON: Well, I know many of you have come from all
over the world to be here today, some of you from even
as far away as Canada.
[Laughter] Well, your customers are just as diverse as you are.
Here is an interesting fact you may not have realized
This chart shows the worldwide App Store sales broken
down by country.
One of the interesting things it tells you is
that if your app is not localized properly,
you are not going to reach potentially the vast majority
of your customers out there.
Now, the good news is it's not hard for you to do.
We have an internationalization and localization guide
that tells you everything you need to know, and of course,
we've got some great support
in our frameworks and SDKs for this.
We have formatters for dates and numbers.
And this year we are introducing a new formatter
to help you display people's names properly.
Now, names are a tricky thing.
Everybody has one, of course,
but different cultures represent them differently
and have different conventions around their use.
In English, we typically write a name as first, middle, and last.
Chinese, on the other hand, leads with the family name
and doesn't even have the notion of a middle name at all.
The NS person name component formatter --
which I promise looks better in code than it sounds
when you say it out loud --
[laughter and applause] -- thank you.
This takes care of all of the details for you.
And it even has some cultural smarts.
So if you ask it for the short version of a person's name,
it knows when it might be inappropriate to use
that person's first name all by itself.
Now, we have some really exciting news for Arabic
and Hebrew speakers out there.
We've had rudimentary support -- welcome -- [laughter] --
we've had some rudimentary support
for these languages for years.
On iOS it was limited strictly to text; whereas,
the Mac had some more sophisticated layout
of your UI elements.
Well, I am really pleased to tell you that in iOS 9,
we have full mirrored UI support for right-to-left languages.
Here's what it looks like in Springboard.
Now, we haven't just reversed some
of the UI elements on screen here.
This is a much deeper conversion,
where we've reversed the flow between your view controllers,
your user interactions, and the system gestures.
This is what the UI would look like if it had been designed
by a native Hebrew or Arabic speaker.
Let's take a look at what this looks like on the phone.
I'd like to bring Sara Radi up on stage
to give you a quick tour.
SARA RADI: So let's take a look
at the new right-to-left languages support on iOS 9.
So here I am running my iPhone in Arabic, and starting
from the lock screen, I slide from right
to left to unlock my device.
Here, my app icons are also laid out from right to left,
and my page view flows naturally
from the first page to the second.
So the whole system and all our native apps fully support user
interface mirroring or running in right-to-left localizations.
So let's take a look at the Photos app, for example.
Here, all of my photos are laid out the way I expect them to be.
The entire UI feels just right from the navigation bar
at the top to the bar at the bottom.
Now let me show you Mail.
In addition to the standard layout, navigation, gestures,
and animations also flow as expected.
So hitting Mail to trigger the quick message actions,
I am going to swipe from the left edge
of the screen to the right.
And that compliments the layout flow of the table view cell.
Also, the navigation gesture works as expected
from the right edge of the screen.
Now rotating my device
to landscape reveals the Message view.
As a native speaker, this feels so natural to me
since all my emails are on the right side
and the details are on the left.
And since we've built all of this into UIKit,
your apps will get the exact same behavior for free
for running in right-to-left localizations.
Now let me show you a third-party app
from the App Store.
And just in case you are wondering,
we didn't choose Kayak because the name is a palindrome
and you can also read this from right to left.
So since it is using autolayouts and our new APIs
with very minimal work, they just add translations,
and their app just works as expected.
So after WWDC, I am planning to go on vacation, so I am going
to explore some views.
So the first slider lets me pick the number of days
of my vacation, so I am going to drag that slider
to the right side to decrease the number of days.
Since they are using a stock UI slider,
they got this behavior for free.
I also prefer nonstop flight only, so I am going to turn
on that switch at the bottom, and as you can see,
it also flows from right to left.
So the entire UI feels just right and feels very intuitive
for natives of these languages.
And that's how easy it can be to add right-to-left localizations
to your apps on iOS 9.
Thank you so much.
Now back to Toby.
TOBY PATERSON: Thank you, Sara.
Well, as Sara mentioned, we have full support for this in UIKit
and our other system frameworks.
So you can get a lot of this just for free
in your own applications.
If you have custom views or gesture recognizers,
you do need to think about what they mean
in a right-to-left language.
We have this API here, which I am not even going to try and say
out loud, to tell you which way the UI is flowing
so you can make the appropriate decision for your UI.
Next I'd like to talk about links,
and by these I mean the kind of links that you get from a friend
in a message or an email.
You tap on it, and invariably it opens up in a web page.
Well, this is exactly what you want on the Mac
because Safari is a natural home for web applications.
iOS, on the other hand, is all about the native app.
Wouldn't it be great if that same link when you tapped
on it could open up right in the associated application?
Well, that's exactly what we've made possible in iOS 9.
This kind of universal app linking that takes you to the --
the same link that can take you to the natural destination
for the platform that you are on.
Safari on the Mac or native apps on iOS.
Here's how it works.
You host a file on your website that lists the kind of URLs
that your application can handle natively.
When the user taps on one of those URLs,
we wrap it up in an NSUserActivity and hand it off
to your application the same way
that Handoff does, and that's it.
It's that easy.
Now I'd like to talk about some of the new things in iOS 9,
starting with HomeKit.
So this morning we announced a number of great new features
for the HomeKit platform, and of course, we've been continuing
to enhance the HomeKit framework.
Certain classes of accessories can now post push notifications
right to your devices, doors, windows, and alarm systems.
And we have a new system UI for managing
who you are sharing your HomeKit network with.
This is available in Settings, and we also have an API
so you can bring it up right in your own application.
But I think the really interesting things are
These let you set up "if this, then that" sequence of actions
so that you can turn the lights off
when you activate the alarm system or, more importantly,
turn the coffee machine on first thing in the morning.
I think these are going to be really powerful.
Now we have some new things in Search
that I think you are probably all interested in.
The big news for iOS Search, of course,
is that now it can search your application content.
We can show rich results, and when the user taps on them,
take them straight
to the appropriate spot in your application.
There are three ways that you can index your application data.
Core Spotlight lets you explicitly index all
of the application content that you have.
Now, some of that data may only be valid for a limited time,
and so you can optionally provide an app indexing
extension, which Core Spotlight will call out to
at the appropriate time to make sure your indices are
up to date.
Another way of indexing data is via NSUserActivity.
This lets you index things that the user is seeing or doing
in your application so that they can easily find them
and get back to your application.
And finally, if your app is mirroring content
from your website, you can mark up that website content
so that our web crawler will find it, index it,
and provide results when searching locally on the device.
Now, you saw this morning that when you swipe
into the new Search UI, we already have a series
of suggestions ready and waiting for you
without you having to type anything.
Well, Siri can even suggest results from deep
within your application.
If you are using NSUserActivity to make a note
of what the user is doing in your application, Siri can take
that into account when coming
up with these proactive suggestions.
You've probably noticed we are building a lot on top
of NSUserActivity here.
There's Handoff, of course,
universal links, Search, Suggestions.
I think this is a great example of how we are building
on our existing foundations to make your apps
and the whole ecosystem much richer.
Now, the big news this morning, of course, was Multitasking,
and we are really excited to bring this to you today.
There's slideover and split view,
which lets you pin apps side by side so you can work
on them at the same time.
I could almost hear many of you wondering out loud this morning,
oh, gosh, what do I have to do on my application now
to take advantage of this?
Well, the answer hopefully is not very much at all.
You may remember last year we introduced this notion
of Adaptive UI, which is a really simple concept.
It says that instead of designing your UI
for fixed screen sizes, instead pick a layout and then adapt it
to changes in your window bounds.
And we provide a number of tools to help you with this.
There's Dynamic Type for laying out your text
and autolayout constraints
for adapting your UI to changes in bounds.
Now, we recognize, of course,
that a single layout is not going to make sense
across all these different screen sizes,
so we introduced this abstraction called Size Classes,
which try to allow you to choose the appropriate layout
without having to resort to a device-specific check.
This works by broadly categorizing sizes,
screen sizes, into two buckets, regular and compact.
You can see here that the iPad has a regular horizontal size
class, and the iPhone has a compact horizontal size class.
We are using these exact same mechanisms
for the Multitasking UI.
You can see here in the slide overview it has a compact
horizontal size class.
And when I tap to pin those two apps in split view,
we adjust the bounds of the main app there on the left
but keep it with a regular horizontal size class.
Now, the interesting thing, when you resize that split view
to 50/50, is not only do we adjust the window bounds there,
but we also change the size class of the main app
on the left from regular to compact.
We found in our own applications that this is the best layout
for these window dimensions.
So if you have already adopted Adaptive UI in your app,
there's actually very little left for you to do.
You need to use a launch Storyboard,
which is a more flexible replacement for default pings,
and then declare that you support all orientations,
and that's it.
As Craig mentioned this morning, we have literally converted apps
in a matter of minutes and had them up and running.
It's really great.
Now, this morning we also announced Picture in Picture,
which lets you continue to watch videos over top
of your other applications.
And if you are a video application,
it's really straightforward for you
to take advantage of this yourself.
The first thing you need to do, of course,
is just support background media playback, and then you need
to enable Picture in Picture support in your controller.
We have this built into our standard media playback
controls, and we provide an AV Picture in Picture controller
to give you very fine-grain control
over entering Picture in Picture.
Next I'd like to talk about the Mac.
So OS X, of course, has had Multitasking,
multiple windows forever,
and this year we announced some new window management features
that make that even more compelling.
The key element of this is the ability
to tile two applications side by side in a split view,
as you can see in this screenshot here.
Now, adoption of this is really easy.
Any resizable window can partake in this, and the key thing
for you to do there is to make sure that your window lays
out nicely in both narrow and wide geometries
so that it can play along well with just
about any other window in the system there.
And of course, we've added some new APIs and behaviors to AppKit
to make this really easy for you,
such as automatically hiding the sidebar
in the NS split view controller.
Another key development on the Mac is the introduction
of Force Touch, which we released a few months ago.
So Force Touch opens up a whole new dimension of Touch,
with pressure sensitivity and haptic feedback on the Trackpad.
We use this in our own apps for things like text lookup,
pressure-sensitive playback controls, and finer control
over drawing, preview, and markup.
Naturally, we've added some API for you to take advantage
of this in your own application.
You can set the pressure configuration for the kind
of Force Touch that you want,
configure the default haptic feedback on the Trackpad,
and have pressure changed events delivered to your views
and gesture recognizers.
We think Force Touch is a really exciting new capability
for the Mac.
We can't wait to see what you guys do
with it in your own apps.
Now, I have some updates on iCloud for you.
Last year we launched iCloud Drive, and this is a great way
for accessing all of your documents
across your mobile devices, your computers, and the web.
Now, on iOS, apps provide a great in-app experience
for managing your documents,
and we think this simple app-centric model is great
for many people out there.
But Mac users, of course, are accustomed to working
with their documents directly in iCloud Drive.
So for those folks, we are adding a new application
to iOS, the iCloud Drive app.
This is what it looks like.
You can see all of your documents
in iCloud Drive organized just as you would expect.
You can preview many document types right in the application.
And naturally, you can open a document in its own application.
Now, prior to iOS 9, the only way of accomplishing this was
to copy the document into the application container,
and of course, that's exactly what you don't want
for documents in iCloud Drive
or any other document provider for that matter.
What you really want is to be able to edit those documents
in place without moving or copying them.
So if you are a document-based application,
here's what you need to do to enable that.
You need to support file coordination
since there may be multiple processes trying to access
that document simultaneously.
And then you just add this key to your Info.plist
and handle the application open callback.
And that's it.
iCloud Drive is built on top of CloudKit as are, in fact,
many of our iCloud services.
CloudKit is a public API, and when we launched it,
we said it was going to be basically free
for probably most of you.
Well, what does that actually mean in practice?
Here's what you can store in iCloud Drive for free right
from the get-go with no users.
As you add more users to your application,
these grow commensurately up to these maximum data limits.
Now, we've built a CloudKit Dashboard for you
that shows you all of the key metrics at a glance
and includes a line below which everything is free for you.
We project that line a short ways out into the future
so you can have some advance notice before crossing it.
And if you do cross that line, we've published a clear
and simple pricing guide here.
You can also find tons of other interesting information
about CloudKit here, such as the details of a new feature
that we are launching this year, CloudKit Web Services.
This is basically a full-on CloudKit implementation
for web apps.
Anything that you can do
with the native CloudKit API you can now do via JSON.
as possible the native CloudKit API.
And we provide a web login flow
so that you can authenticate your users securely.
We think this is going to make it really easy
to write a CloudKit-based web application
to run alongside your iPad, iPhone, and Mac apps.
And that's what I have for CloudKit.
Now I'd like to hand off to Chris Lattner, who is going
to tell you something about Swift.
[ Cheers and applause ]
CHRIS LATTNER: All right.
Thank you, Toby.
The response to Swift has been amazing,
and it's really actually hard to believe
that it was unveiled just one year ago.
When we talked about Swift back then, we talked about some
of its major features like performance, safety,
and also the interactivity of Playgrounds.
But we want Swift to be pervasively available
to everybody, and so we are open sourcing the compiler
and the standard library and even kicking things off
with the Linux board as well.
This project is going to be run
under an OSI-approved permissive license starting later this year
after we wrap up work on Swift 2.
We look forward to working even more closely with you all,
incorporating both your ideas
and your code contributions as well.
So there's been a lot written about Swift, and we're not going
to go through all the quotes, but one of our favorite was
when Swift topped the list
of Stack Overflow's most-loved programming languages.
And there's a lot of reasons to love Swift; right?
One of which is it's built to run your applications
at top speed, and over the last year,
performance of Swift code has grown tremendously
as we've implemented new optimizations in the compiler.
And there is a ton new in Swift 2
with improvements across the board.
But let's talk about a few of these, and maybe we will start
with one of the most requested features,
a new error handling model.
So error handling is a very well-known field.
There's a lot of known approaches.
But all these approaches have very well-known problems
So we weren't satisfied with any of the existing approaches,
so we came up with something we think will feel familiar
but will solve these kinds of problems.
So let's talk about it now.
It starts out simple.
A method or function in Swift can now be marked
as being able to produce an error.
This greatly simplifies many common Cocoa APIs
and also allows the compiler to verify
that you are handling your errors properly.
Swift now has familiar catch syntax to handle errors
and uses powerful pattern matching to enable you
to express rich cache conditions.
Swift uses the try keyword but uses in a different way.
It uses it to mark calls to methods
that can produce an error.
This defines the way an entire class of errors that happen
when you have unanticipated control flow by making
that control flow explicit in the code
so you can reason about it.
Of course, it's easy to throw an error, like you'd expect,
and Swift is the perfect way to define your own categories
and families of your own custom error conditions.
It works really great.
Now, we think that Swift --
error handling in Swift will be super familiar
and will feel really natural,
but it will also greatly increase the quality
of Swift code across the board.
Let's move on now and talk about our next big feature,
So we introduce great new APIs all the time.
Often you want to adopt some of these new APIs
to get new capabilities in your applications as well,
but you can't always drop support
for the previous OS X or iOS release.
Now, this brings a challenge because some symbols you want
to use are unconditionally available,
where other symbols are conditionally available
depending on the OS that your app is running on in the field.
With Swift 2, handling this is a breeze.
Now if you try to use a symbol that's conditionally available
without checking for it,
the compiler will produce an error message,
so you can't mess it up.
And Xcode goes even farther
by giving you several great ways to handle this.
The first is you can use the new "if available" statement
to add a fine-grain check right where you need it.
But I think even better than that is
that you can also mark an entire method or even an entire class
as dependent on new OS features.
This eliminates the need to do fine-grain checks
and directly expresses many common situations
that you will have in your code.
It's a great solution that works really well together.
Now, the error handling features
and the availability checking features
of Swift 2 are two great ways to make it easier
to write correct code.
But, of course, we want your code to be beautiful as well.
So we've done several great changes in Swift 2 to help this.
Swift 1 introduced a number
of really powerful global generic functions
to do powerful things with algorithms.
Powerful and wonderful.
The problem is these were not always beautiful to use.
Let's say I have a collection of numbers, I want to scale them up
and drop some of the results.
With Swift 2, this is easy,
but writing it requires rearranging a lot of code,
and when you look at it, you have to read it inside out,
which makes it difficult to reason about.
Swift 2 introduces a new language procedure called
With protocol extensions,
we can now recast these global functions as methods,
the way they should have been all along.
This means that the new code that you write is beautiful.
It's simple to write, and it's simple to read.
Let's talk about early exits.
It's very common to want to exit a scope early for some reason,
so maybe you have a method that takes a parameter
that could be nil, and if it's nil it doesn't want
to do anything.
Well, the "if let" statement gives you a very familiar,
comfortable, and great way to check these conditions,
but it requires you to indent all your code an extra level.
To solve this problem, we have introduced a new guard statement
that allows you to check a condition
and then bail out early.
It allows you to write nice straight-line code
without the excess indentation.
Next, a huge component
of how Swift feels is how well it works with Cocoa.
But with a plain Objective-C API,
the Swift compiler has no idea whether
or not a pointer is nullable
or what the element types of a collection are.
We solve this by introducing new features subjective C,
including the ability to express nullability for pointer types,
and in Xcode 7, we introduced an entirely new first class generic
system to Objective-C that allows you
to express element types
and many other things right in Objective-C.
Through the adoption of this and a whole bunch of other features,
Cocoa is feeling quite swift.
Finally, let's talk about Xcode.
Xcode 7 introduces a revamped Swift migrator.
It automatically will move your Swift 1 code to Swift 2 syntax,
including adoption of the new error handling model.
As we continue to evolve the Swift language going forward,
we will keep moving the migrator forward to match.
Next, let's talk about header files.
But wait. Header files and not having header files are a huge
feature of Swift; right?
The problem is, is that sometimes you actually do want
to skim a bunch of code to understand what it does
at a glance, and all the implementation details get
in the way.
Well, Xcode has solved this problem
by introducing a new Assistant editor,
which gives you a header file-like view
of an arbitrary Swift source file.
This gives you all the skimmability advantages
of a header file without the maintenance burden of having
to write, maintain, and edit it yourself.
Next, rich comments.
Xcode allows you to write beautiful Swift Playgrounds
by writing rich comments directly into the Xcode editor.
These rich comments use the very popular Markdown syntax,
and now we've brought in the syntax
to documentation comments as well.
We've even added support for new features, like in-line images
and links, giving you a great, consistent experience
between Playgrounds and doc comments.
-- finally, let's talk about Playgrounds themselves.
Playgrounds are very important to us.
We know that they are a great way to experiment with API
and with the Swift program language itself.
But we think that Playgrounds can be a great way for teaching
and learning programming as well.
And so we have been adding a number of features
to Playgrounds, including most recently support
for multiple pages within a Playground.
To show you this and more, I'd like to invite up Max Drukman.
MAX DRUKMAN: Thanks, Chris.
Today I'd like to show you how easy it is to learn
and to teach using Playgrounds in Xcode 7.
Let's start off with a playground that I am developing
to teach students about some of Apple's great graphics APIs,
and in this section, I am introducing them
to a brand-new one, GameplayKit.
As you Playground says, GameplayKit is used
to develop the mechanics that drive your gameplay.
We will see a little bit more of that in a minute.
This Playground uses a car chase visualization
to demonstrate some of the GameplayKit capabilities,
and I have created this Playground
so that my students have the ability to edit the bad guy cars
by tweaking these three Sprite Node variables.
Now, Playgrounds have always had the ability to show you results
for each line of code.
This year, we added the ability to add them in line.
So now I can start by editing my Playground the way my students
will, by changing the values
to get a different look to the bad guy.
And you can see that as I make my edits,
the changes are updated live.
Now that's a bad guy car.
[Laughter] Down here, I am asking my students
to write a little bit of code to put the pieces
of the bad guy together into one Sprite.
So now as I write that code,
it's going to assemble my bad guy, and now I am ready to go.
That's it for the setup.
Now it's time to move on to the main event,
which is making stuff move.
Which I have on another page.
Now, pages are a great way to divide up your Playgrounds
into subtopics, kind of like a book.
You can navigate to pages using the handy navigation links
at the bottom of the page.
You can use the jump bar.
And of course, the navigator.
Here are all the pages in my Playground.
Now, each page can have its own sources and resources,
so you can factor your Playgrounds exactly the way
Let's check out the next page.
I am going to put away the navigator for now.
So this page talks
about GameplayKit's flocking behaviors.
Now, flocking is what's going to take the bad guys
and make them move as a unit.
Now, without any further ado,
I am going to open Xcode's timeline Assistant
and let's meet the flockers.
Okay. Here are all my evil
but colorful bad guys tracing our intrepid truck-driving hero.
But you can see they are kind of driving all over the place.
They are a flocking disaster.
[Laughter] Let's see if we can fix that.
So there are several parameters that you can adjust in order
to govern the flocking behavior.
Here is an interesting one, cohesion,
which governs how much the bad guys want to stick together.
I can just play around with that value
and see immediately what the effect is.
That's a little bit too much cohesion,
so I think I will back that one off.
That's a little better in terms of spacing,
but they're still not quite as goal-oriented as I'd like,
so I am going to play with the seek parameter,
and give that a different value and see
if I can get a good flock going here.
Now they're flocked.
So now I know what kind of range of values I want
to tell my students to play with.
I am going to put away the assistant, and I am going
to switch the editor to be in raw markup.
So now I can edit the prose
of my Playground using familiar Markdown syntax.
And I can go back down here to the seek parameter,
and I can add a little bit of extra prose to tell my students
to play around with these values.
I can even come up here and add some branding
in the form of an icon.
And now whenever anyone asks me if I know about flocking,
I say I wrote the flocking book.
You are very kind.
These are just a few of the authoring features we've added
to Playgrounds in Xcode 7.
Can't wait to see what you build with them.
And now, to tell you about some more great Xcode features,
I'd like to invite up Matthew Firlik.
MATTHEW FIRLIK: Thank you, Max.
Alongside the new releases of watchOS, iOS, and OS X,
we are excited to bring you Xcode 7.
This new release includes features and support for all
of our platforms, and the unique experience
of each platform has been integrated into the tools
to allow you to target and deliver your applications
to all of our devices.
That unique experience is where I'd like to start today,
with our design tool Interface Builder.
And first up is a new way for you to lay
out your applications called stack view.
With stack view, you can design your applications using
horizontal and vertical stacks.
You start by selecting an orientation
and add your controls.
With each control that you add,
stack view automatically adjusts sizing and positioning
to give you just the right look.
Stack views nest beautifully, and they allow you
to change orientations,
so you can get the precise layout you want.
Now, we've built stack view on top of autolayout,
and it handles all the constraints for you.
Zero constraints gives you control over alignment, spaces,
and distribution in the stack.
And we've made stack view flexible as well, allowing you
to play with your interface
in Interface Builder and at runtime.
When you add controls into a stack view, you can reorder them
to try out different layouts and, perhaps best of all,
when you hide views at runtime,
stack view automatically adjusts.
So stack view, a new way in Interface Builder for you
to get the precise layout you want.
Next up are Storyboard references.
With storyboards, you can create and design scenes
and connect them together with zero code
to make complete user interfaces.
Now, knowing that your scenes and the interfaces evolve
and become a little bit more complex,
we wanted to make this easy to manage.
Storyboard references allow you to take a section
of your interface and move it to a separate storyboard file,
continuing to make connections to and from the scene.
With storyboard references, you can keep your interfaces focused
and modular, the same way you do as your application code,
and still easily design your application flow.
Now, equally important to the flow and layout
of your application is the look.
And in this release,
we are making Interface Builder something to see.
In an upcoming scene, you will see more of iOS
and OS X's visualizations brought right
into Interface Builder.
Blurs and shadows will render inside of the canvas.
Vibrancy will become a standard part of the presentation.
And your own designable controls can present masking and shadows
that compose with other views in your scene.
And the combination of these visualizations alongside our
preview editors, which allow you to further refine the look
and layout of your interface for specific devices,
means that now, more than ever,
you can design your interfaces right in Interface Builder
and see what your users will on their devices.
Another aspect of building your applications is managing assets,
and Xcode includes tools to work with the new
On Demand Resource APIs.
With Xcode 7, you can tag assets
and files throughout your project
to be downloaded and used on demand.
Each tag represents a collection of resources,
and we call these a pack.
And you can apply multiple tags to any individual resource,
allowing you to use that resource
in different situations.
To help you manage your tagged resources,
Xcode includes an overview of your tags in the Project Editor.
Here you can easily add, remove, and rename tags.
You can change the pack contents.
And you can also configure various aspects
of On Demand Resources, such as the download order
and the download priority.
When you build your applications,
your tagged assets are automatically assembled
into resource packs.
You just need to tag your assets and you are ready to go.
When you deploy your applications,
your On Demand Resources will be hosted by the App Store.
While you are debugging, Xcode will host your
On Demand Resources on your Mac and stream them
down to your devices on demand
to simulate the Store download behavior.
And for those of you using Xcode's continuous integration,
your bots will build and host your On Demand Resources,
so you can easily test your apps over the air amongst your team.
And finally, to help you track your packs,
the debug gauges will show you the progress and status
of all your On Demand Resources while you are debugging.
So the combination of all these tools makes it really easy
for you to adopt On Demand Resources in your apps.
Xcode 7 also has some great new debugging and profiling tools
to help you further enhance the quality of your applications.
Sebastien mentioned earlier our focus on battery life.
Getting the most out of your devices and getting
through the day on a charge is very important.
So we are making it easy for you
to track the energy use of your application.
The new Energy gauge for iOS will show you CPU usage,
calls to networking APIs and location services,
and also show you your apps' transitions
from foregrounds to background states.
And as with our other debugging gauges, you can gain insight
into the behavior of your application and,
when you need more information,
dive into Instruments for all the details.
And speaking of which, Instruments has been updated
to be better than ever.
The track view is now more compact and makes it easier
to visualize your data with new fluid gestures.
We also have a number of updated instruments and new instruments
for you to use, such as core location profiling
and a new GPU system trace.
And in this release,
we are integrating Clang's Address Sanitizer
into our debugging workflow.
Address Sanitizer is a memory error detection system
for C-based languages.
When enabled, Xcode will monitor memory used by your application
and can detect common issues, such as buffer overruns.
When these are detected, Xcode alerts you
and provides essential details to help you diagnose
and debug the problem.
And unlike other similar tools, Address Sanitizer is fast,
so fast you can use it with all
of your interactive applications.
But even with great debugging and profiling tools,
sometimes -- sometimes --
bugs get out and will cause crashes for your users.
To help you get these fixed quickly,
Xcode has integrated support for crash logs.
For your apps submitted to --
-- for your apps submitted to TestFlight and the App Store,
Xcode will provide symbolicated crashes for each submission.
The integrated view will provide an updated list
of the top crashes for your apps, showing you the backtrace,
details about the crash, and charts of recent occurrences.
You can retitle the crashes for easier tracking,
you can add notes to yourself, and you can mark the crash
as resolved once you fix the issue.
Now, when reviewing a backtrace, you want to make it easy,
so Xcode has this Open In Project button
that will load the backtrace into the debug navigator
in your project, giving you the very familiar workflow
to navigate your source code for the crashing frames
and find and fix the problem.
Earlier this spring, we brought you crash logs
for your iOS applications.
Starting today with Xcode 7, you can get crash logs
for your OS X applications, and crash logs
for your watchOS applications will be coming soon.
And in this release, we will also be bringing you crash logs
for all app extensions on all platforms, so you can track
and improve those as well.
Now, another way to improve your applications is with testing.
And we all love testing; right?
I am going to try that again.
We all love testing; right?
[ Cheers and applause ]
That's good because testing is an essential part
to delivering a great application,
and we have two big new additions for you this year.
The core of our testing solution is the XE test framework
and our test navigator, which combine to provide great ways
for you to design and organize your tests.
Building on top of these, Xcode has provided a number of ways
for you to test your application.
You can test the correctness of your APIs and measure
and track their performance over time.
You can evaluate synchronous and asynchronous behaviors
in your code, and you can run your tests locally in Xcode
and continuously on your integration bots.
And all of this combines together
to make it a really powerful unit testing solution.
But we wanted to kick it up a notch.
So this year we are adding in user interface testing.
This is built on the same testing foundation,
so now you can develop correctness
and performance tests that work through your user interface
to further extend your testing coverage.
And speaking of coverage, we are adding that as well.
Code coverage is a great new way for you
to evaluate your testing progress
and ensure you have all the tests you need.
So let's take a quick look at a demonstration
of the new UI testing and code coverage features in Xcode 7.
So here I have an application my team and I have been working on.
It's a SpriteKit game for iOS and iOS 10 called Demo Bots.
As we have been developing the application,
we have been working on tests, and you can see here
in the test navigator we have quite a few of our tests.
It's helpful to know which area of our code has not
yet been tested either because we have not
yet written the tests or because our current tests are
With Xcode 7, this is exactly the kind of insight you can gain
about testing with code coverage.
Xcode collects coverage data each time you test,
so I am going to jump to the testing report,
and we'll see there's a new coverage section.
Inside of the coverage section, all of the files
in my application are listed with an indicator
on the right showing the percentage
of coverage each file has.
Now, in this list, I've sorted it from highest
to lowest coverage, so all this might look good.
As we scroll down, we see I have some work to do here still.
For each file in the list, you can disclose the contents
and see the coverage of the methods
and functions contained therein.
For the file I've disclosed,
the first two functions have 100 percent coverage,
but the other three have no coverage at all.
The report gives you a good high-level overview
of the coverage for your project, but we wanted
to bring this information directly to you.
So we'll see here when I navigate to one
of the source files, we bring the code coverage information
right into the source editor.
The darkened areas are the parts of my code
that have not yet been tested.
And this is great.
It allows me to see where I need to focus,
and it also works great with our assistant editor
because you can have your source code and the tests side by side,
and as you continually test, get updated information.
If we go back to the report and look at the classes
that were not covered, many of them are user interface classes.
They are view controllers and the like.
So to help me with that,
I am going to create a user interface test.
I've already set up a user interface testing bundle
and class, and so I will select that here.
The test I want to write is testing the options panel
of our game.
Now, the new APIs and XE tests give you the ability to interact
with user interface elements, accessing their properties
and triggering actions, and it's really easy to write.
But you know what's actually easier than writing a UI test?
Let me show you how that works.
I am going to collapse the project navigator
to give myself a little bit more space,
and with my insertion point in the test I want to implement,
I am going to click this little Record button down here
at the bottom of the editor.
You will see when I do this, Xcode launches my application.
I want you to pay attention in the test
in the upper left-hand corner.
The first thing I want to do is click the Options button
in my application, and you can see
that Xcode's recording inserted the corresponding line
of testing code.
You can see it's pretty simple API.
It's asking the application for the window and the button
and telling it to click.
For the next piece of my test here, I want to fill
out my player name here, so I will start typing
in my standard gamer handle, and you will see here
that two cool things are happening.
One, while I am typing in the text field,
the editor is updating live to show me the values.
That's pretty cool.
The other thing that happened is
that UI recording noticed I was interacting
with the same user interface element more than once,
and it refactored my test to create a local variable for it.
This keeps the tests readable and means that refactoring
and reusing this code later is really easy.
Let's continue selecting some options here.
You'll see that the test updates.
For the last element, I want to select a different robot here,
so I will click this button and select the blue robot.
I will click Done, and go back and look at my test.
Just like that recording was easily able
to track all of my actions.
Now a test should probably do more than just poke things.
We should probably validate some values here.
So before we click the Done button, let's insert some code
to check that I have the right settings.
I am going to insert a little bit of code here that gets
that value of the active robot from the interface.
It's in a text field.
I will compare it to the value I expected, blue bot.
With no further ado, let's run our test.
I will stand back.
Here we see it's updating the values,
selecting the right robot,
validating our test, and our test passes.
So recording makes writing UI tests really easy.
We can look at our tests inside of Xcode and run them locally,
and we can also have them run on our continuous integration bots.
I have bots set up for both the iOS and the OS X version
of the application, and if I select my iOS version and look
at my tests, when I filter down to the failed ones,
I see something interesting.
I have four user interface tests that are passing on an iPhone
but they are failing on an iPad.
To make it easy to diagnose your test failures,
each test run includes a transcript
of all the testing actions that took place, and I can see these
by expanding the test.
Here's a list of all the actions that took place
in this test that's been running.
Because user interface tests are visual, though,
we wanted to go a step further.
So each one of these actions includes a screenshot.
So if I look over at the passing iPhone test,
I can get the screenshot for how the test starts,
there's the start of our game.
I can look partway through at the test.
Here we've typed a value
into the text field with the keyboard up.
And I can also look at the very end of the test.
Here's the state of the UI just before we click the Done button.
If I flip over and look at the tests on the iPad
and jump all the way to that last action,
we can see here's our iPad UI with all the right settings,
but there's no Done button.
Clearly we misconfigured something in our UI,
but the screenshot was able to help us narrow
that down really quickly.
So code coverage showed me where to write tests.
UI testing and recording made it easy
for me to get more coverage.
And the new testing reports helped me narrow
in on my problems.
That's just a little bit of code coverage
and UI testing in Xcode 7.
User interface testing makes use
of our systems' accessibility APIs
to interact with UI elements.
This means if you've already invested
in making your app accessible, you've also already invested
in making it testable.
UI testing also works great with UIs designed with size classes
and localizations, including right-to-left support,
which means your UI tests can scale
to all presentations of your UI.
The new APIs -- yes, you can clap for that.
The new APIs and XE tests are available in Swift
and UI recording will generate whichever one you are using.
So these have been some of the many new features you will find
in Xcode 7 as you build your apps for all of our platforms.
Now, we also have some exciting new technologies to share
with you for games and graphics, and for that I'd
like to invite my colleague up, Geoff Stahl.
GEOFF STAHL: Thank you, Matthew.
Xcode 7 looks amazing, and I am really excited to be here
to talk about games and graphics.
It does not seem like so long ago
that we were here introducing our first game-related API Game
Center or social gaming network.
Since then, we've been busy with APIs for key input
and graphics technologies, like game controllers, SceneKit,
SpriteKit, most recently Metal.
This year, we are introducing a number of new game technologies,
including things like Model I/O for modernizing your graphics;
ReplayKit for extending your game's social reach;
and Game Center for adding super-smart brains
to your games.
Also, we're packaging all of these together into GameKit,
so with one include, you get all this functionality
at your fingertips, a great solution,
great complete solution for game development
across our platforms.
So let's take a look at some of the new cool features
in GameKit, starting with Metal.
So as you know, Metal is a 3D API we introduced last year
We are really excited that this year we are bringing it to OS X.
And let's, as a recap, look at an example we ran
into just recently of game development moving
from OpenGL to Metal.
So here you have a game when we started out on --
running on OpenGL, and what you notice is
that OpenGL command processing is keeping one CPU completely
saturated, which has pushed the game play to the second CPU,
and the GPU is not very busy.
In fact, in this example, we saw the GPU was 40 percent idle.
Moving to Metal, we drastically reduce the command
We have an API that you can program more directly
to the GPU.
And if you choose, you can split your command processing
across multiple cores.
In this case, we've unlocked the full performance of the GPU.
We've been working with some third-party developers on Metal
for OS X, and let's take a minute
to see what they've done on the Mac.
So it's my pleasure to introduce David McGavran
from Adobe Systems up to show what they've done
with OS X in Metal.
DAVID McGAVRAN: Thank you very much.
Adobe was very excited when Apple brought iOS
to Metal's iOS last spring.
In fact, we have already been using it to optimize some
of our popular iOS apps like Premier Flip and Photoshop Mix
and seen great results.
So we were thrilled when Apple told us they were bringing Metal
to OS X.
This way we can share our code on both of those platforms.
So today I would like to show you some of our progress
with two of our flagship Mac OS products,
Illustrator and After Effects.
Let's take a look.
So here we are in the current version of Adobe Illustrator
with a massive piece of artwork with over 300,000 points,
gradients, and blend modes.
I want to go ahead and do a zoom on this piece of artwork.
You are going to notice a bit of lag as it works its way
into that complex piece of art.
We really wanted to see if we could do something better.
So with this version, we are demonstrating what we can do
with Metal when we take the entire rendering engine
and put it on Metal.
In fact, it was so performant, they were able
to demonstrate a brand-new feature with continuous zoom.
So here you can see the results are amazingly different
when you are looking at what we can do with Metal.
In fact, I can zoom all the way in here extremely far
until you can actually read the text.
So this just drastically changed the way artists can work
with our products.
Now we want to talk about After Effects.
So here is a video from extreme sports
Let's take a quick look at this.
[ Music ]
That's pretty fun.
What we want to do is take one of those shots
into After Effects and add some effects
into it to make a promo spot.
So here we are.
I am going to turn on some color correction, some ripples,
and some lens flares, and go ahead and play
that back without Metal.
And you can see while it's working quite hard on the CPU,
it's not really giving
that interactive performance we'd love to be able
to give our compositors.
So we really challenged our programmers to take a look
at this and see what they can do with Metal.
So in a very short time, they were able
to port those three effects to Metal, and they are going
to show you a pretty astounding difference.
So now I am going to switch to the same composition,
but this time those effects have been replaced
with the Metal versions, and I am going to play that back.
Immediately you are going to see it's playing in real-time
without dropping any frames, and we are seeing
that in these effects up to an 8x performance improvement
and drastically reduced CPU usage.
So Adobe is committed to bringing Metal to all
of its Mac OS creative cloud applications,
such as Illustrator and After Effects I showed you today,
as well as Photoshop and Premier Pro.
We are very excited to see what Metal can do
for our Cloud users.
Thank you very much.
GEOFF STAHL: David, thank you.
That is amazing.
I agree with Craig.
It's really interesting to see
when you can take an interaction that's not real-time and move it
to a silky smooth user interaction.
But Metal is not just for applications.
As we spoke about this morning,
we are bringing key graphics technologies for both OS X
and iOS onto the Metal API.
Up to now, technologies like core animation
and our hardware accelerated Core Graphics,
PDF and Safari page rendering, have been on top of OpenGL.
That meant the CPU was very busy feeding the GPU commands.
With Metal, we get improved efficiency and performance
for critical user-level tasks.
Also, we didn't want to just increase the system performance;
we wanted to actually make it really easy for all
of you to adopt Metal.
So we are introducing MetalKit.
So MetalKit is your gateway to Metal.
It does the heavy lifting for you.
MetalKit can do anything from set up your rendering loop
to load 3D models via its interaction
with Model I/O from your artist.
In fact, MetalKit can load meshes directly
into Metal buffers and set
up pretty much everything you can do to render your scene.
We didn't stop there.
Metal performance shaders are high-performance image-
processing shaders for Metal applications.
These are GPU-based parallel compute shaders individually
tuned for all of our GPUs, again, making it really easy
for all of you to adopt Metal.
So now you have a great rendering pipeline,
but you need great content.
So we have Model I/O.
Sometimes loading and working with 3D models can be tricky.
So that's what Model I/O comes in.
It makes it simple to load content
from all the file formats you expect directly into SceneKit
or Metal with this interaction with MetalKit.
But where it sets itself apart is the way it handles lighting.
Model I/O offers state-of-the-art, raytraced,
materials-based lighting solution for you.
What this really means is it offers amazingly
Let's take a look.
So let's start with a baseline.
This is just a model with textures loaded.
This is not really interesting.
It's actually pretty flat,
and I think the '90s is calling this model back.
If we strip away the textures
and apply a global illumination solution,
what we see is something
that immediately looks more realistic.
We add the textures back in, and we get something
that looks really good.
Finally, of course, even with Model I/O
and its lighting solution, you can add your own lighting in
and shadows to get something that looks amazingly realistic,
giving you those amazing results, from ordinary
to extraordinary, Model I/O provides you a great solution
for your models and for lighting.
So now you have a great rendering pipeline,
you have great models, great content,
you need great Gameplay.
So we have GameplayKit.
Gameplay is divided really into two areas.
We have navigation or how you move your objects in your game.
We also have your strategy or how your game thinks.
GameplayKit has solutions for both of these.
GameplayKit is a component-based API that is a full coverage
of solutions for Gameplay.
Whether you need to track the gold from each of your players
or need to navigate your bad guys from point A to point B
and avoid the obstacles in between,
or you need to generate deterministic random numbers
for your next online multiplayer game,
Gameplay has solutions for you.
From very simple games to very complex,
we think Gameplay will do a very good job helping you guys
develop your games.
We started out with a social piece, Game Center.
ReplayKit can extend the social interaction.
ReplayKit allows your players to record video replays
of their gaming exploits.
They can save them or they can share them.
It's hardware accelerated, it's high performance,
and it's absolutely brilliantly easy for you guys to adopt,
really easy to add it to your game, and maybe it's the thing
that kicks off that next viral marketing campaign
for your game project.
Finally, SceneKit and SpriteKit.
We have some great updates for SceneKit and SpriteKit,
but I think the most interesting,
maybe the most compelling, is we have built tools
for both SceneKit and SpriteKit directly into Xcode 7,
and I'd like to hand it off to my colleague,
Jacques Gasselin de Richebourg,
to show you these tools inside of Xcode 7.
JACQUES GASSELIN DE RICHEBOURG: Thanks.
So last year with Xcode 6, we introduced visual scene editing
for SpriteKit right inside Xcode.
This year we are kicking it up a notch
and have added animation editing right inside Xcode.
So here we have a little cut scene I am making.
It's got this cute red panda and he is about to make his way
across the two chasms to the other side.
These are the base animations I have on there.
I want to layer these into the animation we expect.
First off, obviously, you need to make him run.
So let's go down and grab an action.
Now, here we have a really interesting action.
It's a reference action,
which means it actually lives in a different file.
It lives in this actions.sks file.
I am referencing here so I can make composed actions.
So I am going to grab that.
Of course, it's just as easy to just copy and paste.
I am going to do that a couple times, and naturally it appends
after on the same track.
Let's have a look at that, and we are going
to use the scrubber this time, so it's a timeline
with a scrubber, and you can basically preview what the
animation is going to look like at any time.
That's not just a great preview tool;
it's actually great for editing as well.
So you noticed he didn't jump over the chasms,
and that's a problem and something we are going to fix.
So let's figure out a good spot for him to jump.
Looks like here is about perfect.
And then we are going to grab a move action, and we are going
to build the jump right here.
Now, notice how it's snapping to the timeline.
Okay. I am going to make it go up 100 units,
and then I am going to use the timeline yet again
to figure out the apex.
I want it to be about there.
Now I am going to snap the duration.
Okay? It's that easy.
Obviously, when he jumps, I want him to ease out.
That means he is going to have a lot of velocity at the start
and very little at the apex.
Going to copy and paste that and reverse it.
That's going to ease in so
that he has some hang time up at the apex.
Okay. Let's scrub across that.
That's a parabolic jump.
Perfect. Now, obviously, it looks a bit weird
if he just runs in the air, so let's add an animation.
You notice here I am layering animations on top of each other,
and SpriteKit handles that for you.
Here I am going to snap the animation to the length
of the jump, and I am going to hop into the media library
and fetch my jump frames.
So I am filtering jump, select that one, select all of them,
drag and drop, perfect.
Okay. That's a cute jump.
Now, there are two chasms, so I am going
to have to do this twice.
The easiest thing to do here is to turn this into a reference,
so I am going to select all those, right-click,
convert to reference, and I am going to call that Jump.
That's going to store in the actions.sks file
that I used the run from before.
Great. That's a jump.
I'm going to use the scrubber again to lay down another jump.
The excellent thing about references is they turn up here
in the object library straightaway.
So I am just going to drag and drop that in.
And here we should have our final cut scene.
Okay. Jump and jump.
The great things
about references is they also help you structure not just your
other scenes, but your code as well.
So here using SK action named, I am going to load
up those very same actions, and I am going to hook them
up to the left and right keys and the space bar for jump.
Let's run that and have a look at it.
So here we have the panda doing the cut scene.
Now I am going to control it.
Look at that.
Left and right.
It's that easy.
Now, we've been busy, so we took this
to the next dimension as well.
So new in Xcode 7, we have full visual scene editing
of 3D content using SceneKit as well.
This editor is very much like the 2D editor for SpriteKit.
Same things work.
Drag and drop to add new content.
You can use the manipulators in 3D to drag it around.
You can snap to other objects.
You can even duplicate.
And we have physics
and animations live inside the editor.
So we are going to now animate.
Perfect. And let's interact with this as well.
So I am going to play.
And we got the same cute panda from the previous demo.
Here we go.
[Music] This is a red panda, not a fox; a red panda.
I am going to walk up, and I am going to interact
with that little block I had before.
Oh, yeah, kick you down.
Great. So in this game, you are playing a little red panda
that collecting flowers and pearls and -- oh.
Sorry about that.
I promise, no pandas were hurt in the making.
Okay. This is not just a demo for stage here.
We are actually handing this out to you, and this is a sample
that you can use to build your next 3D SceneKit game using this
editor, SceneKit, and Xcode 7.
I am going to hand you back to Andreas.
ANDREAS WENDKER: All right.
Let's quickly review the technologies we discussed
in this session.
We announced new versions of our OSs today, and of course,
the new native watchOS SDK.
The SDKs contain many new APIs you can take advantage of,
particularly for gaming.
The new optimization techniques with App Thinning.
A new version of Swift that advances your apps faster
and at the same time lets you write more effective code.
And of course, this new version of our Xcode now
with user interface recording and testing.
And all these technologies will be available for download
from the WWDC attendee portal this afternoon.
We hope that you will quickly adopt them all
and create even more innovative apps for users.
Please go ahead and install all this stuff
and let us know what you think about it.
Also we are doing something new
with our TestFlight service for you this year.
Starting today, you will be able to deploy apps written
to the iOS 9 SDK in TestFlight, and over the next several weeks,
it's even going to add support for App Slicing,
on-demand resources, and Bitcode so you can test your apps even
with those new technologies before we launch iOS 9 later
So there are, of course, many opportunities to learn more
about these technologies here at the conference.
There's more than a hundred sessions you can attend,
numerous labs where you can go and get help with your projects.
In fact, there's more than a thousand Apple engineers here
on site to answer your questions.
So I hope you enjoyed this session.
I hope to hear from you later this week.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.