evgzor February 16, 2017 at 16:05

Static analyzers for Swift and Objective-C

Foreword

There are a large number of articles devoted to static analyzers for C / C ++ / C #, Java, etc. As for research on the use of various static analyzers for native development under MacOS / iOS, much less attention is paid to them.

An analysis of the use of static code analyzers used in various projects on ObjC and Swift is proposed. At the same time, this is not a review, but rather some notes on the use of various tools to find errors of one kind or another in the code, starting from memory leaks and ending with the search for vulnerabilities. However, the data do not pretend to objectivity and completeness of the conclusions made, as well as to the depth of analysis of the results obtained for each instrument.

Introduction

Several years ago, while still a beginner iOS developer, I ran into the problem of verifying the quality of code written in ObjC for iOS applications. Unfortunately, it was not always possible to find errors and discuss the code with more qualified colleagues for lack of such. The first negative reviews, although they were perceived constructively, but, nevertheless, led to the loss of customers who wanted to evaluate examples of developer code before concluding a contract. As a result of this, there was a need to use tools that identify maximum code defects before demonstrating it to the customer. I note that it was always important to have reports on the quality of the code in Continuous Integration after all the commits to identify potential problems in the product being developed.

I had to work in various teams with different projects from solo to distributed, with a team located on different continents. The skill level of colleagues ranged from entry level to architect. The composition of the teams likewise constantly underwent changes, and this despite the fact that new versions of Swift appeared every year, and ObjectiveC did not stand still .

All these factors stimulated the search for tools to identify the maximum number of errors and make the code more consistent and easy to read.

Clang static analyzer

This is the first built-in analyzer that any Xcode user encounters. In order for the code to be analyzed each time the application is launched, it is necessary to make the settings described here . These recommendations should be used by all users as the first stage of code verification before each commit.

The lack of support for Swift greatly limits its scope. Of course, Xcode has an Address Analyzer and Thread Sanitizer that support Swift - however, these tools are not static analyzers and can only be used when the application starts, that is, at run time.
Suitable for proactive search for potential memory-leaks and errors in the code structure.

Faux pas

Faux Pas ( wrong step - Fr. ) is the first third-party static analyzer to be encountered, having a full-fledged both GUI and CLI. After starting to use it, the quality of the code became noticeably higher. It helped to identify from my 20% to 50% hidden bugs in my ObjC projects. The most curious thing was that the tool at its first launch revealed exactly those errors that the customer pointed out. This was the main argument why, in fact, it was decided to purchase this tool at the personal expense of the developer, and not wait until the whole company takes it into service.

Unfortunately, not all colleagues accepted this tool positively - some believed that the analyzer should be free, others - complained about a large number of settings, not wanting to understand them.

The main drawback is the lack of support for Swift, however, the developers promise to support it , although they have not yet announced the date.

A less significant problem is that workspaces are not supported directly - you have to check either through the command line (configure the workspace check) or individually each project, which, in turn, is not always convenient.

However, Faux Pas finds problem areas that contradict Apple Coding Guidelines. For example, using self.propety in init and dealloc reminds you of using Modern ObjC syntax , Missing NSNotificationCenter observer detachment, and so on . Easily integrates into CI .

It is better to convert the generated report in Json or plist to something more readable. The report contains a detailed description of the problem, it also provides external links to the rules. Despite the fact that, at times, there are links to stackoverflow, and not to the official documentation, this, nevertheless, is not a significant drawback.

An example of the result of the tool is given below. To run the analyzer in Xcode, for subject detection of problems, you can use the CLI.

To analyze the report presented in JSON, a small application was written that generates a report in Excel with a selection for each problem in a view similar to the FauxPas GUI.

Regarding the configuration of the analyzer, the tool is configured through:
GUI, CLI arguments and configuration files. No way to create your own rules was found.

Oclint

For the first time, the analyzer met in a small but long-lived project of a foreign company written in ObjC. The developers of this company were very conservative and did not want to switch to Swift, due to the complexity of migration to all new versions of this language.

Although OCLint allows you to change and add rules through Scaffolding , this, however, is time consuming. According to the development process in this company, the code will not commit to the repository until all analyzer warnings have been fixed. Some of the validation rules were not always processed correctly. To eliminate all analyzer warnings, we had to use workarounds (crutches), which forced the team to eventually abandon the support of this analyzer.

Nevertheless, the analyzer allows you to identify:

Empty if / else / try / catch / finally statements without expressions,
Unused local variables and parameters
Reports high cyclomatic difficulty
Reacts to redundant code with if statement and unused brackets
Detects invertible logic and variable reassignment

The analysis time of a small project is quite long (compared to the Clang analyzer), and if this tool has not been used in your project before, it can generate a huge number of warnings, which will complicate the initial analysis. Therefore, if there is no desire to check the entire code base and receive a huge list of warnings, then you can write a small script that checks only the modified files before the commit, which is relevant for any analyzer. Integrates

standardly into Xcode through build script .

The tool is quite flexible, but, nevertheless, I would like a more advanced heuristic analysis of the code, since this tool has existed for a long time. Currently, there is a need for an Xcode plug-in for this analyzer, which would greatly simplify its use.

Codebeat

The Codebeat cloud analyzer supports both ObjC and Swift, which was critical when this product was selected for use in a particular project. One of the drawbacks was that the check was performed only after commit got to GitHub before the pull request, which made the development process slightly unstructured in our case. At the time of this writing, the developers promised to release an automatic review code utility in order to completely minimize the participation of developers in this process. This is an urgent task, due to irregular or inattentive checks of the code in the development teams in some projects with a human review.

It supports Swift + Obj-C, Python and Ruby, which is very convenient for mobile development.

The analysis of ObjC code does not work quite satisfactorily. This is due to the fact that the company focuses mainly on Swift code analysis, and work with ObjC has been added recently and requires further refinement.

Regarding product support, it is on top. There was always the opportunity to contact support during the day, and even on weekends the necessary assistance was provided.

As for the configuration of metrics , this can be done by creating your own json file and changing the verification rules. However, the ability to create new validation rules or modify existing ones is not available. However, as the developers assured me, such an opportunity is planned in the future.

This tool is free for opensource projects, and for private repositories the price not so high, besides the trial period lasts 3 months, which can be considered quite democratic.

Infer

The facebook product, which opened its own code analyzer, is suitable not only for analyzing projects on iOS, but also for Android / Java development.

It was not possible to run this analyzer immediately at the command line for a test project, but after creating a request on Github, I was devoted to some subtleties of its configuration. I even managed to integrate it into Xcode using the “Run build script” .

To run the analyzer, an additional scheme was created - Infer in Xcode, by analogy with other analyzers using the CLI. In the particular case, great benefits from its use have not been identified. Perhaps it makes sense to use this tool in other larger cross-platform complex projects.

Swiftlint

A very popular analyzer among Swift developers, which has a plugin plugin for Xcode , which is very convenient.

As a basic rule taken GitHub's Swift Style Guide . It is possible to create regex-based custom validation rules. In particular, it is very convenient to create rules regarding refactoring when new functionality is added to extensions of tool classes, for example, the NSLocalizedString () function becomes just a field in the NSString (or String) extension of the class.

In a specific case, the teams worked on distributed brunches that were not refactored. Using the “autocorrect” option, you can easily bring the code to a single style when the code is merged into a single brunch.

SwiftLint was used in a large hybrid project containing both ObjC and Swift code. The author of the idea of introducing it into the project, unfortunately, did not read the article about the vicissitudes of using the “autocorrect” options and inserted the check in “Run Script” in Xcode. Of course, in large projects with a team that does not have a common synchronization point, not everyone installed this tool immediately. At the same time, there was a migration to Swift 3.0, which undoubtedly added confusion to the new commits.

Starting with version 0.16.0, there were some rules for false positives, for example, with large_tupleprojects stopped compiling through the build script. In addition, not all rules are processed correctly, which is typical of many analyzers, and this forces the use of workarounds that affect the quality of the code. This problem made me more careful about introducing SwiftLint into the “Build phases script” for each project.

This tool was also integrated into Jenkins, which obviously improved control over the project codebase.

Tailor

Tailor is a cross-platform static analyzer for Swift. Very unusual is the fact that the Windows platform is supported.

Used as an alternative to SwiftLint on pilot projects. However, for this period of time, it only supports Swift 2, which does not meet modern requirements a bit. However, there is an issue enchantment for supporting Swift 3.0.1. Supports code style rules for The Swift Programming Language, GitHub, Ray Wenderlich, and Coursera.

To support pods and workspace, the following recommendation is recommended .

The ability to create your own rules was not found, although there is a possibility that it exists, but you should carefully understand this.

Integrates into Xcode via “Build Script”. To suppress warnings such as trailing-whitespace , which immediately begin to cause inconvenience the first time you use it, it is
recommended to use the keys:

tailor --except=brace-style,trailing-whitespace

If desired, the report can be output in HTML, JSON or in Xcode format, which is convenient enough for use in CI when publishing results on a web server.

Formatting in Swift Style

Speaking about analyzers, one cannot but mention the “formatters” of the code for a particular style guide.
Despite the fact that they are not static code analyzers, but format the code to Swift Style, nevertheless, they serve the same purpose of detecting errors by bringing the code to a unified style, allowing the programmer to better understand the code, and, therefore, to quickly identify problematic ones. sections of code.

Swiftformat

It is convenient in that it makes it possible to create your own rules to satisfy the code style of a particular team. Configuration takes place through the CLI, which may not appeal to everyone. However, it can be installed as a plugin in Xcode.

Swimat

The tool can be used by both the CLI and the Xcode extension. This is indeed a good tool, although it does contain some critical bugs that cause Xcode to crash when used. However, the developer promptly eliminates them. The ability to add your own verification rules is present.

In a particular case, it was used to format the code of a small project, where it proved itself to be the best in terms of convenience and the result.

Both formatter are comfortable to use as an extension for Xcode, and are currently supported and improved.

Checkmarx

In practice, at times, there are projects from customers critical of the safety of the product. For such projects, it is better to use the Static Application Security Testing (SAST) source code audit solution from Checkmarx.

This cloud solution, that is, a tool, can be located either on a local development server or on a Checkmarx server. A fairly advanced analyzer using its own patented technology. Checkmarx, which previously worked closely with the US Department of Defense, has a lot of interesting developments regarding the study of various vulnerabilities. It supports Swift, but in a specific case, the ObjC project was analyzed. Unfortunately, it does not have an extension plugin for Xcode.

The reporting system is very informative and presentable. One of the pages is below.

An informative report can contain from 10 to 300 pages depending on your project. The report also explains how to fix problems, and even provides examples. A common mistake for all the projects that were analyzed was “Third Party Keyboard Enabled”, which was associated with a possible vulnerability when installing third-party keyboards for iOS (although one of the analyzed applications did not contain keyboard input fields).

Afterword

I would still like to get acquainted with some tools of static code analysis in practice, for example, Sonar . However, due to the high cost of the product and the complexity of its installation, such an opportunity has not yet been presented. At the same time, for some projects it is interesting to try Solar inCode to look for vulnerabilities in the code for customers who are worried about the security of their applications. Unfortunately, this product could not be obtained even in the Demo version.

Many of the above tools helped make the products created more stable and more resistant to various vulnerabilities in the code. In principle, any analyzer is an unbiased judge who does not care about you and has no personal complaints against him, which makes all the work more objective and orderly.

Nevertheless, it is obvious that ideal tools do not exist, and even the use of all existing means of code analysis is not a panacea. Not to mention those cases of false alarms when you have to use workarounds to satisfy the requirements of the analyzer. In this regard, the human review will always be relevant in order to at least detect semantic errors such as dragState, instead of drugState or cacheData, instead of cashData (though you can configure auto-replacement ...).

useful links

Tags: