Getting Started with Instruments

Chase
8 min readDec 27, 2023

--

Instruments is the best place to start finding any kind of performance issues you may have in your apps! In this article, we will go over the basics of what it is, how it works, along with how and when to use it.

Before we get started, please take a couple seconds to follow me and 👏 clap for the article so that we can help more people learn about this useful content.

What is the Instruments app

The instruments app is used for measuring any kind of performance for the apps you write. It can measure things like hitches or hangs for visual issues, animations hitches, help you find slow database communication, or even show you what is happening during a network call in your app.

After Xcode I would argue that Instruments is probably one of the most powerful tools in your app building toolbox.

One thing to call out is that this app shouldn’t only be used when your app is having issues with performance. Using Instruments with your app on a regular basis can help you find problems in your apps before they are released to users, ensuring that each release of your apps works great and can help your users stay happy with the performance of your app.

How do I get the Instruments app

If you have Xcode, you should already have the instruments app on your mac… that was easy.

How do I use Instruments to measure the performance of my app

There are a couple ways that you can launch the instruments app. One way is to open it from a Spot Light search. The other way is to open the Product menu from inside Xcode, and choose Profile (or you can use the keyboard shortcut of COMMAND+I when Xcode is open).

After you have launched instruments, you should see an image similar to the following. Even though this might look daunting if you are first starting out DON’T PANIC, the icons on this screen are just templates. These templates are similar to what you would see when starting any other app like pages or keynote, they simply offer a helpful set of predefined measurements that you can run against your app. Just like using a template for any other Apple program, once you have chosen a template, you can always customize (even create your own template), add, or remove anything from the template once you get in to it, in fact, let’s go over how to do that in the next section.

A screenshot of the list of templates available in the Instruments app

Understanding the Instruments Interface

For this tutorial, I will be using the code from the following article that I wrote earlier about making a performant tab view. I will be running the built in tab view with 100,000 tabs. You can find that code here: https://medium.com/@jpmtech/making-a-performant-paged-tabview-45e360d55637. Feel free to following along either using your own code, or the code from the link.

Once you have the code open that you want to measure, we will use the CMD+I shortcut to open the Instruments window. To start with I have chosen the Time Profiler template. Now we should be in the Instruments app ready to go over the interface.

A screenshot of the instruments app interface with 3 areas highlighted
  1. This highlights the recording button, this is how you can start/stop the recording.
  2. This is the list of measurements that will record data once the record button is pressed. Apple refers to this as the track event list.
  3. This is the Library button which holds all the different kinds of measurements we can perform.

Let’s click the plus button (Library button) to add a “View Body” instrument to the list of things we want to measure. The View Body instrument will let us see how many times the body of a SwiftUI view is called. For our short test, we can remove the Thermal State measurement, this lets us know the thermal state of the device while the code is being run. To remove a measurement from the list, click on it once to select it, then press the delete key (or backspace) to remove it.

After those changes have been made, we will want to change the recording mode. We can change it by going to the top bar menu and choosing File, then Recording Options, and making sure that the “Deferred” option is checked under the Global Options.

A screenshot of the recording options with the “Deferred” option highlighted

Since we want the app and Instruments all to run on our system at the same time, changing the recording options allows Instruments to record more data by not updating its UI as it records measurements from our app. Now that we have updated the recording options, we are ready to click the record button, interact with our app for a short time, then stop the recording.

Once we have stopped the recording and instruments has had a chance to analyze the data, we should see our interface updated similarly to the image below.

A screenshot of the instruments app interface with 2 areas highlighted
  1. This section displays the data that was recorded during our interactions. Apple refers to this as a track event.
  2. This section displays a list of detailed data based on what we have selected in the first window. Apple refers to this as the Detail View.

How to navigate the interface to find problems in your app

If we right click on one of the micro hang bars in the chart, we can chose “Set Inspection Range” (holding the Option button while the right click menu is open will also give you the option to zoom and set the inspection range). This will highlight the bar that we clicked on and give us all the details about our app that it recorded during that time window. Note: Apple classifies a micro hang as anything that takes between 100ms and 500ms, anything greater than or equal to 500ms is classified as a hang.

A screenshot of the instruments app interface with a micro hang selected in the chart

In the list on the bottom left (which Apple calls the Detail View), we can see that our profile view has updated with all the events that happened during the selected window. We also have a new window on bottom right corner that gives us the Heaviest Stack Trace (which probably holds the cause for any issue we may have currently have selected). Apple refers to this window as the Extended Detail View.

One note about the Heaviest Stack Trace window, the text items that are colored grey are system processes, and the text that is fully opaque is the list of processes that are coming from our app. Double clicking on any of the items in this list will display the source code in the detail view where your code (or in the system stack if you choose something that was not fully opaque) was called (as you can see in the image below). If we click on the disclosure indicator in the top right corner of the Detail View, we can choose to open this code in Xcode which allows us to quickly make changes to our code.

A screenshot of us viewing the source code in the Instruments app

Going back to the Detail List View, if we wanted to walk through all the events that are in the Detail View, we would need to click the disclosure indicator several times. However, if we hold the OPTION key down when we click the disclosure indicator, then it will expand the list out until there is a control flow branch.

How should I use Instruments

One thing that is very important to remember about using Instruments, is that it is meant to measure the performance of how your code works on an actual device. Running it in the simulator isn’t a true test of how your code performs in the real world. Going back to my article on making a performant tab view, the side by side comparisons showed a large jump in memory, but the gauges made it look like that memory footprint had very little impact, and on my M1, it did in fact have little impact. However, running that same code on a friends iPhone 6s caused the app to take about 30 seconds to get to the next screen when swiping. Which brings up an important point, measuring the performance of a simulator isn’t the same as measuring the performance of a physical device, because your simulator has all the power and resources of the computer it is running on, and a real mobile device has very different limitations.

I know it seems crazy to say that we should test on several physical devices, who has the money to do that kind of thing except for large companies, right? I know, I thought the same thing when I started learning to code years ago. As an indie developer, freelancer, or even a kid learning to code, you may have family, friends, or coworkers that would let you borrow their phone to try something out. You don’t have to buy all new devices either, see if any of those same people have an old device laying in a drawer that they would be willing to just give you (you would be surprised how many people have old phones just lying around), all you have to do is ask. The point being, when you are measuring for performance, make sure you are measuring on a real device.

If you got value from this article, please consider following me, 👏 clapping for this article, or sharing it to help others more easily find it.

If you have any questions on the topic, or know of another way to accomplish the same task, feel free to respond to the post or share it with a friend and get their opinion on it. If you want to learn more about native mobile development, you can check out the other articles I have written here: https://medium.com/@jpmtech. If you want to see apps that have been built with native mobile development, you can check out my apps here: https://jpmtech.io/apps. Thank you for taking the time to check out my work!

--

--