Detect bugs early with the static analyzer

♪ ♪ I am Ravi Kandadai Madhavan, and in this video, I will show how to use the static analyzer in Xcode to find and fix bugs in your apps. First, I will demonstrate how to use the static analyzer to find bugs and also understand them. Then, I will describe the new checks in Xcode 13, which can help find more kinds of issues in your code. Finally, I will describe the ways in which you can customize the analyzer to better integrate it with your development workflow. Let's now see how to use the analyzer to find bugs. The static analyzer is a tool in Xcode that can discover bugs by analyzing the source code without running it, so it can reveal bugs, even before you do testing and quality assurance of your app. It can also find problems in code paths that are rare and not covered by tests. The analyzer finds bugs in C/C++ and Objective-C code, even in mixed Swift and Objective-C projects. Let us see the analyzer in action using an app I am developing. I am trying to improve an existing app written in Swift and Objective-C that allows exploring the solar system. This is the Xcode project for the app. I am going to run the Static Analyzer to see if it finds anything wrong with my code. It's very easy to run. Just go to Product and choose Analyze, or use the keyboard shortcut Command-Shift-B.

You can see the analyzer running in the status bar of Xcode. Analyzing your project is very similar to building it. The analyzer scans all the sources files in the targets of the currently-active scheme looking for bugs. As you see in the status, the analyzer has found an issue in my project. I can go to Xcode's issue navigator to learn more about it. As I showed you, all it takes to run the analyzer on your project is a single click. And with this single click, you can find several kinds of bugs, like security issues, logical bugs, misuse of APIs, and many more. The analyzer can not only find bugs, but can also explain them. Let's get back to the bug found in my app and try to understand it. The problem here is that the Objective-C method positionAtDate is returning nil when it is not supposed to. The method's return value is declared to be non-null in the method's definition. But now, I want to understand how this method is returning nil. You can expand the analyzer issues and see the sequence of events that lead to the bug. The events are also shown in the editor, alongside the statements where they happen. The arrows show how the events are ordered. I find it easier to read these reports from bottom to top. The last event shows that the returned value, position, is nil. The previous events show that this is because the method regularPositionAtDate, meant to initialize position, is not called because its receiver object is nil.

Looking at the arrows, this happens along the default case of the switch. Going back to the beginning of the report reveals that the receiver object is initialized to nil and remains so along the default case. Now, I understand that I haven't handled objects that are not spherical or irregular within the switch.

To fix this, I am going to make the default case identical to the spherical case. I will rerun the analyzer to make sure the issue is fixed.

I am quite relieved that this bug is detected while I am developing the app. This is because returning nil from an Objective-C method annotated as returning a non-null value can result in unexpected runtime behavior when the method is called from Swift, which happens in my code. Thankfully, running the static analyzer has revealed this bug before it could affect the users of my app. In Xcode 13, we have made the analyzer even better, and we have some brand-new checks for you. The analyzer can now catch more logic bugs in your code. It can detect infinite loops and redundant code, such as unnecessary branch conditions. It can report side-effects in asserts, and in C++ code, it can catch errors in the use of move and forward operators. Parts of these new checks are open-source contributions made to Apple's Clang compiler. Let's see some examples of bugs these new checks can catch. In general, it's a good practice to use asserts to validate your expectations about your code. However, you must make sure that asserts do not have side effects, such as writing to variables or memory. For example, consider the code snippet shown here that traverses an array of astronomical objects and counts the number of those that have associated moons. It has an NSAssert that checks that the number of objects with moons is less than or equal to the number of planets. But the assert has a side effect of incrementing the counter tracking the objects with moons. Updates like this can be lost in the release build configuration, where asserts could be disabled to make your code run faster. So this code may not increment the counter at all in release builds. It's easy to miss bugs like these during development, as they do not show up in debug builds. Starting Xcode 13, the analyzer can find such issues in your code and report it. This check works not just for NSAsserts, but also for asserts in C and C++. These bugs are easy to fix, and you just move the side effect outside of the assert, as shown here.

Infinite loops are another common bug. You might have seen it happen when there are loops with complex logic. For instance, the nested loop shown here tries to populate a two-dimensional grid with a value. It hides a bug where the variable value is incremented by the inner loop instead of column, which is the actual loop counter. The analyzer can now detect such mistakes and explain it to you.

Once you spot it, this bug is very easy to fix. Just replace value by column. Though these checks find simple mistake, we have found real bugs with them. Now you can use them, too, and find bugs and fix them as you develop your app. Xcode offers many customizations for fine tuning the analyzer to fit in with your development workflow. You can make the analyzer run along with every build of your project from the project's build settings. To quickly narrow down on the relevant settings, make use of the search functionality. For example, using "analysis" as the search keyword, I can look at just those options relevant to the analyzer.

To enable Analyze During 'Build', all you need to do is turn on a build setting. Like incremental builds, the analysis runs only on files that are modified. This makes running the analyzer after code changes both fast and easy. The analyzer offers two modes of analysis: shallow and deep. Shallow mode is faster, but avoids exploring bugs spanning multiple functions. Use this mode in projects that are sensitive to build and analysis times. As I mentioned earlier, the analyzer has checks for finding different kinds of bugs, and some of them are opt-in. You can fine tune the checks that suit your project by enabling or disabling them selectively from the build settings. For instance, if your project has security-critical code, enable the checks for security issues. On the other hand, if you find that some issues are not relevant to your code, you can disable less useful checks individually and still benefit from the other checks.

You can also analyze a single file instead of the entire project. Choose the file to analyze from the Product > Perform Action menu. Use this to check your changes quickly, without even needing to build your project. This is particularly useful when modifying header files. It would skip reanalyzing all files importing it. The static analyzer in Xcode can reveal bugs in your code very early during development. Run it with a click of a button and find many kinds of bugs. And don't forget to customize it to your workflow. In Xcode 13, we have further improved the analyzer and added many new checks for finding logical bugs. Use the analyzer and fix bugs in your app before they reach your users. Thank you, and enjoy the rest of WWDC! [upbeat music]