Improving Battery Life and Performance

Thanks, everyone.

Hi, how are you all doing? Welcome to WWDC. My name is Phillip Azar and I'm proud and happy to be able to share with you our talk on Improving Battery Life and Performance today. Your apps are the backbone of our software experience. They enable our users to do so many things and engage in so many experiences that without your apps, they could never do.

And so you can imagine when your apps don't give good battery life and don't give good performance, this really disappoints your users. And so today we want to talk about a few things. We want to go over a set of tools that you can use that are both new and old to be able to optimize your application for battery life and performance. We want to go over a set of metrics that you can collect using those tools to be able to understand and quantify your application's impact on battery life and performance. And then I'm going to hand it over to my colleagues, who are going to go into these tools in more depth and go through some demos with you and show you how you can use these tools in your application to improve battery life and performance. And then I'll come back and we'll wrap it up. So, let's get started by talking about some tools. And in order to get started talking about tools, we need to talk about the development process and get all familiar with it. Development comes in phases. We've set it up into three different phases. Development and testing is the first phase. And at this stage, we're ideating and creating, and it's a very iterative process. We're either at our desks or maybe in the park, and we're really trying to understand what's going to make our app great.

The next phase is called beta. After we've solidified the features in our application and we're ready for a test run, we give it to a few people, our beta users, and we try to get feedback. And then finally, when we're really proud of our application, when we've collected all the feedback, we're ready for primetime. It's public release. And this is when it's on the AppStore and available to millions of customers around the world.

For battery life and performance, every step is critically important.

We need to optimize at every step of the way to make sure that we're fixing bugs and making our experience as good as possible for our customers.

And so with that in mind, before iOS 13 and Xcode 11, we offered a great set of tools for you to understand the impact of your application's battery life and performance.

During development and testing, we have Xcode and all the tools it contains within it. Things like Instruments, the Energy Gauges, and Profiling tools.

And then in beta, you can collect traces directly on beta devices using the developer settings and open those up in Instruments. And these are great for understanding problems that may not occur in your development environment but occur in the field such as when you don't have good cell reception. And then finally, the Xcode organizer gives you access to a powerful set of logs that you can see from your public release such as crashes and CPU energy reports. And these help you understand problems that are maybe specific to certain regions or specific to certain customers that may not have the same conditions as you. And so with these tools, we thought to ourselves long and hard over the last few years and wondered there are probably some gaps we can fill.

And we spoke to many of you, both indirectly and directly, and the feedback that we got that was most of the gaps are in metrics. How do we quantify our application's battery life and performance? How do we make a decision about feature A versus feature B? Well today, as a part of Xcode 11 and iOS 13, I'm super happy to announce that we think we've solved that gap and we've bridged it with three new tools that you can start using today, starting with XCTest Metrics. This is the first new tool that we've shipped with Xcode 11 and this is going to allow you to collect directly within your XCTest performance and battery life metrics of measure blocks. This is going to give you some critical advantage when you're running XCTest and trying to understand at a very early stage what is the impact of a certain feature.

The next is MetricKit, and this is a powerful new framework that we've built specifically for battery and performance metric collection. And this is going to give you metrics directly in your application and help you understand from all different users how your application is doing in the field.

And then finally, we've beefed up the Xcode Organizer with Xcode Metrics Organizer. And this is going to be a high-level aggregated set of metrics that you're going to be able to look at directly in the Xcode Organizer without changing any code. And this is going to give you a great high-level overview of how your application is doing across the world for all your customers. And so looking back at this graph we just talked about, you can imagine all these tools fit really well in the development process, starting with XCTest Metrics during development and testing.

Then, MetricKit, as you might imagine, falls really well into beta and public release when you may not have access to the devices that you're interested in collecting metrics about. And then finally, the Xcode Metrics Organizer beefs up your knowledge about the public release and helps you understand problems from primetime users. And so when you put these all together, we see that we have more metrics to quantify battery life and performance at every stage in development. And we think this is awesome. So, we've talked about these tools then a little bit and my colleagues will go into depth later about each of them. But right now I want to talk about the metrics that they provide.

Because without these metrics, we wouldn't be able to quantify our impact. So, let's go through them now.

This year we're providing two sets of metrics - battery and performance.

Who would've guessed? Starting with the battery metrics, we're providing a really great set this year that are going to help you quantify your impact on battery life.

Processing, location, display, networking, Bluetooth and accessory metrics, multimedia metrics, and camera metrics.

This is a huge set of metrics that are really powerful but I want to go through a certain subset of these that we think are really important for everyone.

Starting with the processing metrics.

Processing metrics, as you might imagine, are things like CPU and GPU time, and we want you to use these metrics to quantify and understand the workload of your application. So for example, you can do things like find CPU spinners in areas where you might not expect them to be.

Additionally, you can use, you can find unexpected rendering in your application using these metrics.

And critically, we want you to use the processing metrics to compare the algorithmic efficiency of your features, just like we discussed before. If you have feature A and feature B, you can use these metrics to determine which one is better for battery life. Next up we have the location metrics. And these are going to be metrics that are going to help you understand and quantify your location usage, such as your cumulative usage, different accuracy buckets, and your background location usage. Use these metrics to understand your location usage, because it's a common pitfall when it comes to battery life. For example, you might find cases where you leave location running when you don't expect it to be running. Or you may use an accuracy bucket that's too powerful for the use case that you've implemented location for. So, these measures are going to help you understand and optimize those scenarios. Next, we're providing display metrics.

And this year we're giving you a variety of display metrics but I want to talk about one in particular called average pixel luminance.

On your OLED devices such as the iPhone X and XS, the color of your UI in your application has a direct impact on the amount of energy that you consume on the display. And we represent this through a metric called average pixel luminance or APL. And in a nutshell, the lighter colors that you use in your UI, the more energy you'll consume on OLED devices, and this is what we call a higher APL.

And the darker colors you use in your UI, this is what you call a lower APL, and this will consume less energy, so keep an eye on average pixel luminance this year. Last but not least, we have the networking metrics.

And as you might already imagine, these are going to be metrics such as upload and download bytes over cellular and wifi and connectivity metrics. We want you to optimize networking usage whenever possible because it is a high-energy subsystem.

So do things with these metrics such as validating your expected upload and download counts.

Maybe you have an upload that should've occurred at a later time. You can use these metrics to figure that out. And more importantly, we want you to understand the impact of connectivity on your network transfers. It plays a huge role in the amount of energy that you consume when doing networking. So, these metrics will help you understand if you're staying in poor connectivity condition for long periods of time. And those are the battery metrics. We think these are a great set of metrics that are going to help you quantify the impact of your application on battery life. Let's move onto the performance metrics and this year we're providing hangs, disk metrics, application launch metrics, memory metrics, and custom interval metrics.

And as with the battery metrics, I want to focus on a subset of these that are going to be really important for all of us here, starting with the hang metrics. Hang metrics this year are going to be a histogram of the amount of time your application spends unresponsive to user input.

And this is a huge user impact. You can imagine if your user is user your application and suddenly it stops working, that's not good.

So, use these metrics to work, to understand where you can move work off the main thread of possible and utilize things like dispatches and asynchronous cues to reduce your hang rates. Next we have the disk metrics.

And this year we're going to be focusing on disc logical writes. And we want you to quantify disk usage whenever possible because disk usage, as with all subsystems, is a resource that you should only use when you really need to.

So, use these metrics to verify if you have instances of unexpected disk writes and if you're employing any coalescing strategies for your disk writes, you can use these disk metrics to verify those as well.

Next are the application launch metrics.

And this is super great, because this year we're providing launch and resume time histograms to help you understand your launch and resume times of your application.

We want you to quantify the impact on performance that launch and resume have using these metrics. And we want you to understand the impact of the launch activities, so when you do things before your application launches such as a database update, this can directly impact your launch and resume times. These metrics will help you see that in real time. And we also want you to see the difference between launch and resume, because they're two very different paths.

And for more information on that, and how to optimize App Lauch, I recommend that you go see the talk tomorrow on Optimizing App Launch at 4:20 pm. Last but not least, we have the memory metrics. And for memory this year, we're going to be providing things like average suspended memory and peak memory. Memory management can really impact launch times, and so we want you to use these metrics to keep an eye and keep tabs on your memory usage, which is a critical metric for performance. Use these metrics to understand your memory usage and if you have spikes of peak memory that are way higher than your expectation, this could be indicative of a problem such a hard-to-reproduce memory leak.

If you focus on reducing your average memory on suspend, which you can quantify with these metrics, you'll also be able to reduce your launch times and your susceptibility to background termination. And so those are the performance metrics or subset of them, and we think these are going to be really key I helping you understand your performance both on and off device. And so to recap, we talked about the tools that you had before Xcode 11 and iOS 13 to understand and quantify power and performance.

Then we talked about the new set of tools that we're offering you this year to be able to take that quantification one step further and help you optimize your application.

And these great set of metrics that they provide that are going to really help you take your app to the next level. And so without further ado, I want to hand it off to my colleagues who are going to go into some deep dives with each of the tools that we discussed, starting with Sastry, who's going to talk to you about measuring app impact during development and testing with XCTest Metrics. Sastry? Thank you, Phil.

Hello, everyone. My name is Sastry Vadlamari. I'm a software engineer here at Apple. Let's recap some of the tools at your disposal to measure application impact during development and testing.

Right inside the debug navigator of XCode, you can get a high-level overview of the CPU memory and energy subsystems. And when you want to dig into the details or diagnose some issues, Instruments is a real useful tool. It comes with templates that help you diagnose memory issues, system unresponsiveness, and excessive disk usage, and energy issues.

You can also use XCTest to measure performance. XCTest is a program that lets you write UI and unit tests that are seamlessly integrated into XCode testing workflow.

You can not only measure performance, but you can catch regressions who have baselines. But then until last year, the only metric you could measure was world clock time. Performance has more dimensions. So this year we've added new performance metrics into XCTest. So, let's take a look into the details. This is how a sample performance XCTest looks like. You need to pattern a block of code where you specify the actions you want to perform into the measure method and it would measure the time it takes to perform - to execute this this block of code. Now, in order to convert this into the new style of performance test and to get more details, we just need to pattern your time, memory, and CPU objects, pack them into a list and pass them in as a parameter to the measure method. And with such minor changes, your existing performance test can measure multiple dimensions.

We've gone a little further. With every new UI testing target that you create using XCTest, we're going to give you an application launch test for free. So, without writing any code, you will have a test that'll measure your application's launch time. Let's jump into a demo.

So, for the purpose of this session, we created an application that we call an Awesome Photo App. Now, it has a few features. Let me walk you through that. So, it lets you take images.

And when you take an image, it geotags it so you can see the location below. And then you can apply some fancy effects to the picture.

We'll be referencing this application tool for the rest of the demo. You also have standard features like being able to load a picture from your photo screen, save the picture, and upload the picture to the server. So, what does this mean? How do you test this application from Xcode? Well, as I mentioned earlier, every new XCTest UI target that you create comes with an application launch test for free. So, I've already taken the liberty of running this test prior to this presentation and here's how the results look like. As you can see, it takes about .2 seconds for launching my application. That's acceptable. You can see the results of the multiple iterations and all of them are around the same numbers.

And this is an interesting fact. You can set your baseline. The baselines are a mechanism wherein you set guidelines for what you expect your performance numbers to be. So, whenever your performance numbers go off them, your tests would fail and that's how you catch regressions. So, you can set the average, you can set the standard deviation, and whenever you run your test next time, if any of the numbers exceed these conditions, your tests would fail.

So, I've made a change in the code and I want to ensure that my application launch time hasn't regressed. So, let me just run the test again.

There's a couple of points you need to keep in mind when running performance tests. It's a good idea to not have the debugger attached to your process at it adds some overhead and it's also a good idea to turn off all diagnostic options like sanitizers. You can do this easily by either creating a separate scheme or you could use the test plan feature that was recently introduced to turn it off easily. So, now you can see that the test has run and it has failed. If you were to dig into the details, you will see that's becuase the average has really exceeded. I mean, what was .2 seconds has now become about 1.2 seconds. So, in order to debug this, you can attach this to Instruments and use the Timer Profiler template and find out why your app launch time has gone so bad. I'll spare you the mystery and I'll tell you what I did. So, I'm actually trying to look for a database, checking for database updates in my main thread. And as Phil mentioned earlier, it's a real bad thing to do. So, the right solution for this is to dispatch this into a background queue and hopefully this fixes our problem. Let's run the test again and ensure that the numbers are well within what we expect it to be.

The point here is you can, XCTest not only helps you measure but it also helps you ensure things don't regress. So, it's more for you write your test once and you can forget about it and keep running it in your CI system and ensure that, you know your performance doesn't degrade. As you can see, the test passed and yay, we fixed our bug. So, it's pretty easy to convert your existing XCTest performance tests into to have more dimensions, as I mentioned earlier. So, all you need to do is pattern the objects in a list of what you intend to measure. Like for instance, I had a performance test that was measuring the time it took to take a picture and, you know, use the photo and apply an effect. And earlier, this would've just measured the amount of time. But now, by just passing the additional memory metric object, I can now even measure the memory, in fact, of performing these actions.

XCTest doesn't have to be restricted to only UI tests. You can also use it for unit tests.

And I'll give you an example here. So I have the Apply Effects feature, and I have an option of selecting whether I want to use one photo or multiple photos. It adds very little value from a feature perspective but if the overhead isn't much, I would rather like to do it. So, I took the liberty of running this test and measuring the time it takes to run this, to apply the effect with one photo. And it's about 1000KB. But now it's really easy to measure the impact of adding, of a different scenario. All you need to do is change the code. I've changed the code to choose filters, and you run the test again. And the test runs and you'll get back your numbers immediately. And when that happens, you can check your impact. So, as you can see, the impact is, the test failed because this one is about 100% worse. It's about 2000KB. So probably I'm going to stick with one photo. So, to summarize, I gave you a demo of using a few metrics like memory. But we added a whole bunch of them. We added memory. We added storage. We added CPU. We added OS Signpost. But we didn't stop there. We put away generic underlying system, so you can actually implement your own custom metrics and use the underlying reporting system to catch regressions. Please look into the documentation for more details.

And then as I demonstrated in the last example, you can also use XCTest to do some sort of AB testing. It's really a low-cost, easy way to check if algorithm A is better than algorithm B. Just wrap them around on simple unit tests and you can have your numbers.

And because XCTest works so well with both Xcode and Xcode server, you could use this performance test, both in your development and testing phase and also as part of your continuous integration system and ensure that your app doesn't regress on the performance front. So, that's what's new with performance testing with XCTest. Next, I'd like to call upon Ashish, who's going to talk to you about measuring your application's impact out in the field.

Thanks, Sastry.

So, after your initial testing and development phase, there are many benefits of collecting field metrics to further optimize your battery life and performance of your application.

This includes leveraging your beta population of a few users as well as your broader customer population. In the field, your application goes through a wide range of user scenarios such as different cellular networks, signal conditions, different types of devices, as well as different locations. These help identify issues that may not have been caught during on-desk testing. You can also use this field metrics to compare the battery life and performance with previous operations. You can use this data to figure out whether there are any new regressions or egregious issues. These field metrics already helps you to also understand the impact of new features and do AB testing in the field with a broader set of users. To solve this problem, I am very happy to announce we are releasing MetricKit, which is an on-device framework to collect battery life and performance metrics for your application.

We also added a capability in MetricKit to collect metrics around the critical sections in your application. We have built all these features into MetricKit while protecting your users' privacy in our data collection aggregation mechanisms. It's very easy to adopt MetricKit and get started, as I'll show you next. So, the code here is all you need to get started. First, you import the MetricKit framework and create a class in your application which conforms to the metric manager subscriber protocol. And inside the class, you have the subscribe for metrics. This lets the device know that your application is interested in receiving metrics for the metric kit so that it can start collecting that on the device. Finally, as a developer, you have to implement a delegate method called didReceive. This method is involved whenever there is a metric payload to be delivered to your application on the device.

And it's up to you to take any actions once you receive this payload on the device. For example, you can choose to save it to a file, or you can also upload to your server so you can collect this from the field for multiple users.

After using metric, after adopting MetricKit, as your application gets used during the day, we automatically collect an aggregate metrics for our application.

And at the end of a 24-hour period, we generate a metric summary for the entire day, the last 24 hours, and return this payload back on the device. Now, let's understand how we can measure the impact of critical code sections in our applications.

Going back to the awesome PhotoApp example which Sastry described earlier, users can perform any activities in there.

For example, they can choose to take a photo and on that photo, they can apply many cool effects. If they like the effect that they took, they can choose to save the photo on the device.

MetricKit provides the ability to capture the precise battery life and performance impact of each of these features of your application.

Now, let's see how we can do that.

We are happy to introduce a new API inside MetricKit called mxSignposts which is implemented as a wraparound OS Signpost.

By bookending the critical sections in your application with mxSignpost, you can capture the precise impact. Let's take an example.

So, to use mxSignpost, all you need to do is to use MetricKit's make log handle maker and create a log handle with it.

And use that log handle to drop mxSignpost around critical code sections.

In this example, I want to measure the impact of the save photo feature that we have in our awesome photo app. So, I've dropped in mxSignpost just before and after this application code.

MetricKit will automatically collect metrics and process them for you on the device. Now, let's jump into a demo where I'll show you how to adopt MetricKit in your own application.

So, now I'm back in the Xcode project of my application and I'm in the view controller.swift file after my application. As you can see, I have already adopted the MetricKit framework here and created a class which conforms to the metric manager subscriber protocol. And inside that class, I've added some code already for the didReceive method. So, this method is involved whenever there's a metric payload available.

For my application, I've decided to save the data to a file so that I can do some on-device processing later. For the purposes of today's demo, I've also written a function to print this data so I can walk you through the contents of the payload.

Finally, I have written this function to upload this data to my own server so that it can collect this data from multiple users during beta testing as well as customers. Now, as this method is only involved at most once per day, whenever there's a payload available for our application, we built a new feature in Xcode to help you test this out. So, let me show you how that works.

We're first going to run this application on my test device here.

So the application is running now. Now, I'm going to go into debug and click on select MetricKit payloads.

What this does is it sends a dummy payload to your application so that you can test the code inside the did receive method. Now, let's walk through some of the contents in MetricKit payload that is available today.

So, the first example here shows a meta data related to the application such as the build version, device type, and the OS version. Then we get a few histographs related to very useful performance metrics such as application launch, resume, and hangs.

Then we get metrics related to the application usage such as foreground and background times and a few background metrics such as CPU time and GPU time.

Then there are metrics around location usage as well as networking, disk IO memory, and disk play.

And finally we have a section around the mxSignpost summary for your application. As you can see, there are a lot of metrics that are available right now in MetricKit. So, I would highly recommend you to check out our documentation to learn more about the details here. So, let's go back to the slides now.

So, as you see, as we saw during the demo, it's very easy to get started with using MetricKit and start getting metrics on your devices right now.

So, for the, also for the application, we decided to take a road trip and collect some field metrics as well as some fun photos.

The next day after using MetricKit in the field with our awesome photo application, we get, we got a payload on the device which is uploaded to my own service using the application code that I showed you earlier.

Now, let's use this data that we received from the field to identify some hotspots in our awesome photo application.

Following the first example, this data shows the overall foreground time and the background time of the application as well as the overall location sage by different accuracy markets.

It shows that the location uses by the application which is around 720 seconds, is very close to the foreground time, which is very unexpected. All I'm using the location for is to geotag a photo whenever I capture it on the device. Going back to the application, I found that if I'm going to close the location after I started taking it. So, this is a very good example of how you can use MetricKit to identify an expected application behavior.

Another thing we can optimize using this data is to reduce the location usage if it works for our use case. Because the higher the location accuracy, the more the battery drain.

The next example shows the histogram of application hang durations. So, the data shows there are many instances of hang durations of more than 5 seconds, which is very bad for user experience.

So, one of the ways you can solve this as Phil described earlier is to avoid long blocking calls in the mainframe, so we can reduce any hang instances. The final example shows how you can use the mxSignpost data in MetricKit to identify hotspots from a specific application code region.

In my application, I decided to put mxSignpost around all the main features. For example, load photo, apply effect, date photo, save photo, and upload photo.

Using mxSignpost, MetricKit was able to figure out how many times each of these instances run in the field as well as a few back to life and performance metrics such as this CPU time, and the overall CPU time for the entire application.

This data shows that there were many, so the CP usage by the ApplyEffect feature was more than 50%. So, now I know where I can go and further optimize my application so that I can reduce the battery usage overall.

So, following are the key takeaways from this section.

You can use MetricKit to collect field battery life and performance metrics for your application starting from iOS 13. You can use MetricKit to identify hotspots early from your application, such as the example I showed today with the beta population, and you can do so in the customer population, too. Another example we saw today is how I use MetricKit data from a single user to identify hotspots. Aggregating the same data from multiple users can provide you much deeper insights about improving your application.

So, now I hand over the stage to Anshul, who's going to talk about an out-of-the-box telemetry solution in Xcode. Anshul? Thank you very much, Ashish. Hi, I'm Anshul Davra. I'm here to talk about Xcode Metric Core Organizer. That's a new cool tool that we are introducing this year with Xcode 11.

Xcode Metrics Organizer is an out-of-box solution that we are providing with Xcode 11 to view your power and performance app analytics. You can see how your app is doing on the customer devices in terms of battery life and performance. There is no change required to your app. It is available as-is in Xcode 11 for you.

We have built in privacy into this whole process right from collecting the data on the device to aggregating the data on the server. So, you can start using this data as of today. The way it works is when somebody, when a user uses your app, we collect metrics around your app.

These metrics are aggregated on the device and then sent over to our server. On the server side, we run analytics on this data and extract insights. These insights are what show up in metrics organizer.

Please note that insights only show up in metrics organizer if there is enough usage of your app that meet our threshold.

And all of this is available out-of-the-box with no changes to your app or your development process, and is available for you today.

Now, without further ado, let's jump into the demo.

So, to open Metrics Organizer, go to window, organizer. That brings up a familiar organizer window with archive, crashes, and energy tab, and brand-new tab called metrics.

If you click on metrics, you see all your apps on the left-hand side that you have published to the iOS app store.

Let's say our awesome photo app that we publish shows up here. When we click that awesome photo app, metrics around that app show up in the middle pane. So, metrics like battery life, launch time, hang rate memory, and disk write. Metrics that we think that you should consider for an awesome app experience show up here.

When you click on a metrics, details about the metrics show up on the right-hand side. You can look at the metrics for a given version of an app or you can compare it with a previous version. So, X axis is here. It represents app version and Y axis represent the metric value.

Let's start by looking at the battery metrics. Two kinds of metrics show up for a battery. The first one is onscreen battery usage. That is the amount of energy that is drained when a user is interacting with your app onscreen. And then background battery usage is amount of battery drained when, if the app is running in the background.

Now, and each of these metrics are further subdivided by system components like processing, networking, display location, so that you get an idea of which of these components are consuming most of the energy. Let's start with the background battery usage, because we know our awesome photo app is foreground only.

But looking at the background, it seems like it's consuming around 10% of the user battery daily, which is pretty high.

Out of this, it seems like processing is consuming 5% and networking is consuming 3.66%, which is quite high and we need to debug it further to figure out why the app is consuming battery in the background.

Let's look at the latest version of the app when it is onscreen.

The latest version of the app when it is onscreen seems like there is a 10% degradation in the latest version as compared to the prior version. Of which, display seems to be static. There is a slight increase in networking and decrease in other, but the main culprit here is processing.

We can look at this data for the 90 the percentile user population or look at the 50th percentile user population to see if the user population is playing any role in battery drain.

We can also look at this data for all iPhone categories or all iPad categories, or we can jump to individual devices. Let's jump to, let's say, individual device called iPhone 6.

For iPhone 6, it seems like the battery drain is pretty static. Slight decrease in 1.0.8 as compared to 1.0.7.

Let's look at a newer version of the device like iPhone X. Ah, iPhone X has a big jump. If you see here, there's a 14.4% jump from the prior version and the main culprit here is processing. There are a couple of ways we can debug this further. We can directly jump to our code or we can jump to our familiar energy tab that we saw last year.

Energy tab shows you energy exception reports from the field. You can look at the stack frame to figure out where it is consuming the most energy. I know Ashish was talking about a new feature that he added only for the newer devices and 1.0.8 version of our app, applyFilter caused it so we can go there and start debugging it. So, this is one way we have shown you can use metrics and energy tab to figure out the problem and fix the problem. Now, let's look at the other metrics that are available. Launch time is pretty important to our users because apps that are slow to launch can frustrate our users. Ideally, a launch time should be in low seconds. Our awesome photo app for all iPhones is taking around 6 seconds to launch. You can use the tools that Sastry talked about in his earlier demo to debug it further.

Hang time is unresponsive time of your app, in seconds per hour. Ideally, the hang time should be 0 to avoid user frustration. We showed two kinds of memory - peak memory and average memory. Memory is a resource and we should be, we should only use what is absolutely needed.

Disk write is the logical writes your app is doing. we need to be mindful of how much write we are doing and we can use Instruments to debug it further.

Now, that was Xcode Metrics Organizer, an out-of-the-box tool to view your battery and performance analytics and start debugging the problems around high battery drain, performance like high launch time. You can detect, you can look at the data for the latest version of the app, compare it with the prior version, and create a baseline. And this tool is available today to you without any changes to your app or your development lifecycle. So, please, try to use it and let us know the feedback. Thank you very much for listening, and back to Phil.

Thank you, Anshul. We saw those great tools and I want to talk quickly about a summary of everything we spoke about today.

We talked about the tools that were available before Xcode 11 to debug and understand your power and performance impact on device.

And then we showed you some new tools that we think are really powerful and are going to help take your quantification of your performance and battery life impact to the next level. And a set of metrics that you'll be able to collect from those tools to be able to understand and debug your code further. If you take anything away from this demo, I want you to leave knowing that we've built three great tools for you and we'd love to hear your feedback about them. And these tools are going to help you quantify the impact that your application has on battery life and performance.

And that quantification is going to be able to help you make decisions about your application to better your experience for all your users.

For more information, go online and check out our session documentation.

Or, visit us at the Power and Performance Lab tomorrow, and we'd love to see you there and walk you through how to implement these tools in your application and use them to make your experiences great for your users. Don't forget about the Optimizing App Launch talk tomorrow, where they'll go in depth about app launch performance.

Thanks again for coming and enjoy the rest of your WWDC. [ Applause ]