Static analyzers for Swift and Objective-C
There is a number of articles, devoted to the static analyzer for C/C++/C#, Java, etc. Concerning research activities in the use of various static analyzers for native development for MacOS / iOS, they are paid much less attention.
This article offers an analysis of the application of the static code analyzers that are used in different on ObjC — and Swift-based projects. At the same time, this is not a review, but rather some application notes of various tools to find errors of one or another kind of the code, starting from the memory leaks and finishing by vulnerabilities searches. However, the data do not pretend to objectivity and completeness of the findings, as well as the depth of results obtained analysis on each tool.
Several years ago, being still a beginner iOS developer, I faced with the problem of verifying the quality of code written in ObjC for the iOS application. Unfortunately, I didn’t always succeed to find mistakes and to discuss the code with more skilled colleagues in the absence thereof. The first negative feedbacks, though they were perceived constructively, but anyway, led to the loss of customers who wanted to evaluate the examples of code developer before the conclusion of the contract. As a result, there has been a need for application of tools that identify a maximum of code defects before displaying them to the customer. I note, it was always important to get reports on the quality of the code in Continuous Integration, after the all the commits to identify potential problems in the developed product.
I had to work in different teams with different projects from solo to distributed ones, with a team located on different continents. The skill level of the colleagues ranged from entry level up to architect’s one. The teams’ composition was analogically and constantly undergoing changes and this despite the fact that every year the new versions of Swift appeared and ObjectiveC was not standing still.
All these factors stimulated the search for tools to identify the maximum number of errors and to make the code more consistent and easy to read.
This is the first built-in analyzer, which any XCode-user meets. To analyze the code each time the application is started, it is necessary to make settings described here. These guidelines should be used by all users as the first step of verification code before each its commit.
The lack of support for Swift strongly limits the fields of its use. Of course, in XCode, there is Address Analyzer and Thread Sanitizer, which supports Swift — but these tools are not static analyzers and can be used only when running an application, that is run time.
Suitable for a preventive search of potential memory-leaks and errors in the code structure.
Faux Pas (wrong step- Fr.) — the first third-party static analyzer, with which I had to face, having a full-fledged GUI and CLI. After the start of its use, the code quality was noticeably higher. It helped to identify in my on ObjC-projects from 20% to 50% of the hidden bug. The most curious one was the fact that at the first its run the tool identified exactly those mistakes that the customer noticed. That was the main argument why, in fact, it was decided to get this tool for private money of the developer rather than to wait until the entire company would make active use of it.
Unfortunately, not all colleagues perceived this instrument positively — some felt that the analyzer should be free of charge, others — complained about a large number of settings, not wanting to understand them.
The main drawback — the lack of Swift-support, but the developers promise its support, at least for now they do not announce the date.
The less important problem — is that the workspaces are not directly supported — it has to be checked either through the command line (to configure the workspace check), either individually by each project, that, in turn, is not always convenient.
Nevertheless, Faux Pas finds problematic areas of code that are contrary to Apple Coding Guidelines. For example, the use of self.propety in init and dealloc, reminds about the use of Modern ObjC syntax, Missing NSNotificationCenter observer detachment and so on. Easily integrated into the CI.
The generated report in Json or plist is better to convert into something more readable. The report contains a detailed description of the problem; it also provides links to external rules. Despite the fact that, sometimes, the references rely on stackoverflow, but not the white paper, it is still not a significant disadvantage.
The example of results of done work of the tool is given above. To run the analyzer in the XCode, for subject problem detection, it’s possible to use CLI.
To analyze the report presented in JSON a small application was written which generated reports in Excel with the sampling by each problem in the representation similar to the GUI FauxPas.
Concerning configuration of the analyzer, the tool is configured with:
GUI, CLI arguments and configuration files. The way to create its own rules was not detected.
The analyzer was first met in a small but long-lived project of a German company written in ObjC. The developers of this company were very conservative and did not want to transfer for Swift, because of the complexity of migration to the new versions of this language.
Despite the fact that OCLint allows to change and add rules through Scaffolding, this, however, requires a lot of time. In the process of development in the company, the code will not be committed to the repository until all the alerts of the analyzer will be fixed. Some of the verification rules were not always processed correctly. To eliminate all the alerts of the analyzer it had to use workarounds (crutches), that made the team eventually to refuse from the support of this analyzer.
Nevertheless, the analyzer allows to reveal:
- Empty operators if/else/try/catch/finally without expressions,
- Unused local variables and parameters
- Reports of high cyclomatic complexity
- Responds to redundant code from the if operator and unused braces
- Allows to find the inverted logic and variables redirection
The analysis time of a small project is enough big (in comparison with the Clang analyzer), and if your project has not previously used this tool, it can give a huge amount of alerts that will complicate the primary analysis. That is why, if the wish to check the entire code base and receive a huge list of alerts is not available, you can write a small script that checks only changed files before commit, that is important for any analyzer.
As a standard, it is integrated into XCode through build Script.
The tool is rather flexible, but, nevertheless, it would be good to have a more advanced heuristic analysis of the code, as this tool exists for a long time. Currently, there is a need in the plugin extensions for the XCode of this analyzer that would simplify its use significantly.
The Cloud Codebeat analyzer supports both ObjC, and Swift, that was critically important when the product was selected for use in a specific project. One of the drawbacks was that the test was carried out only after a commit came to GitHub before pull request, thus making the development process slightly unstructured in our case. At the time of writing this article, the developers promised to release the automatic code review utility to completely minimize the participation of developers in the process. It is an urgent task, in connection with the irregular or inattentive checks of the code in teams of developers in some projects with a human review.
It supports Swift + Obj-C, Python, and Ruby, that is very convenient for mobile development.
The ObjC code analysis does not work satisfactorily. This is due to the fact that the company is focused mainly on the analysis of Swift code, and the work with ObjC has been added recently and requires a further construction.
Regarding the product support, it is at the top position. Always there was an opportunity to contact the customer service for a day, and even at weekends, there was a necessary assistance.
Regarding configuring metrics, it can be done by creating its own json-file and by changing the validation rules. Nevertheless, the possibility to create new rules of verification or modify existing ones is absent. However, the developers assured me, this possibility is planned in the future.
This tool is free for opensource projects and for private repositories, the price is not too high, by the way, the trial period lasts three months, that can be considered sufficiently democratic.
The Facebook product, which has opened its own code analyzer is suitable not only for the analysis of projects on iOS but for Android/Java- development.
Immediate running of the analyzer in the command line for the test project failed, but after the creation of the query for Github, I was let into some of the subtleties of its settings. I even managed it to integrate into XCode using the “Run build script”.
To run the analyzer further it was created an additional scheme — Infer in Xcode, by analogy with other analyzers that use CLI. In the particular case, the big benefits of its use were not identified. Perhaps it makes sense to use this tool in other larger cross-platform complex projects.
Very popular among the Swift-developers analyzer is that one which has a plugin for the XCode, that is very convenient.
The GitHub’s Swift Style Guide was taken as a basic rule. There is a possibility of creating own regex-based verification rules. In particular, it is very easy to create rules for refactoring when new functionality is added to expand the classes of tools, for example, the NSLocalizedString() function is becoming simply a field in NSString (or String) class extension.
In the specific case of the teams worked on distributed branches, which were without refactoring. With the help of «autocorrect» option, the code can easily be led to a common style when the code was merged into a single branch.
SwiftLint was used in a big hybrid project containing both ObjC and Swift code. The author of the idea of its introduction into the project, unfortunately, did not know about the vicissitudes of «autocorrect» option application — and put checking in the «Run Script» in the Xcode. Of course, in large projects with a team that has no common synchronization point, not all set this tool immediately. At the same time, there was a migration for the Swift 3.0, that certainly added confusion to the new commits.
Beginning from the 0.16.0 version, some rules of false positive alarms have appeared, for example, the large_tuple projects ceased to be compiled through the build script. In addition, not all of the rules were properly processed that is common to many analyzers, and it forces to use the workarounds, which the code quality suffers. This problem made to relate more accurately to the introduction of SwiftLint into “Build phases script” for each project.
This tool was also integrated into Jenkins, that obviously improved the control over the code base project.
Tailor is a cross-platform static analyzer for Swift. Quite unusual is the fact that the Windows platform is supported thereof.
It was used as an alternative to the SwiftLint based on pilot projects. However, at this time it only supports Swift 2, that does not meet modern requirements a little. However, there is an issue enchantment for Swift 3.0.1 support. It supports code style rules for the Swift Programming Language, GitHub, Ray Wenderlich, and Coursera.
To support the pods and the workspace it is recommended to use the following recommendation.
The ability to create its own custom rules is not observed, although the probability that it exists, is available, but this should be carefully studied out.
It is integrated into Xcode through the “Build Script”. To suppress the alerts like trailing-whitespace, which immediately begin to put to trouble from the first its usage.
It is recommended to use the keys:
tailor — except=brace-style,trailing-whitespace
The report by wish can be displayed in HTML, JSON or XCode format that is convenient enough for the use in CI when publishing the results on the web server.
Formatting in Swift Style
Speaking of the analyzers it can not be but mentioned about the code “formatters” for a specific style guide.
Despite the fact that they are not static code analyzers, and as well format code to Swift Style, however, they serve the same purpose of detecting errors by bringing code to a single style, allowing better to perceive the code by the programmer and, consequently, to quickly identify the problem sections of the code.
It is convenient because it gives the ability to create its own rules to meet the specific code style command. The configuration takes place by means of CLI, which can not be by all liked. Nevertheless, it can be installed as a plug-in for XCode.
The tool can be used both as by CLI, and Xcode extension. It is, indeed, a good tool, even though it contains several critical bugs that lead to a drop of the XCode during its use. However, the developer quickly eliminates them. The ability to add your own verification rules are available.
In the particular case, it was used for formatting a small project code, which proved to be the best one in terms of convenience and given results.
Both formatters are comfortable to use as an extension for XCode, and at the moment they are supported and improved.
In fact, at times, there are projects from customers, who are critically related to the manufactured product. For such projects, it is better to use the Static Application Security Testing (SAST) solution for source code audit of the company Checkmarx.
This cloud-based solution, that is, the tool, can be located either on the local server for development or on the company’s server Checkmarx. It is a well-advanced analyzer, which uses its own patented technologies. Checkmarx, which earlier worked closely with the US Department of Defense, has a lot of interesting developments concerning the research of various vulnerabilities. It maintains Swift, but in the specific case, the ObjC project was under analyzing. Unfortunately, it does not have the plugin extension for Xcode.
Reporting is very informative and presentable. One of the pages is cited above.
The informative report may contain from 10 to 300 pages, depending on your project. The report also gives an explanation on how to fix the problem, and even the examples are cited. A common mistake for all the projects that were analyzed was “Third Party Keyboard Enabled”, that was associated with a possible vulnerability when installing third-party keyboards for iOS (though, one of the analyzed applications didn’t contain the keyboard input fields).
Some tools for static code analysis would be still good for an acquaintance in practice, eg, Sonar. However, due to the product high price and complexity of installing such a possibility has not come yet. At the same time for some interesting projects, it is of interest to try Solar inCode to find vulnerabilities in the code for customers, worrying about the security of their applications. To my regret, this product could not be got even for the Demo-version.
Many of the above-mentioned tools helped to create products more stable and more resistant to various vulnerabilities in the code. In principle, any analyzer — is an unbiased judge, to whom you are indifferent and have no personal claim to him, that makes the work more objectively and orderly.
Nevertheless, it is obvious that there are no perfect tools, and even the use of all existing code analysis tools is not a silver bullet. Not to mention, the cases of false tool alarm when you have to use workarounds to meet the requirements of the analyzer. In this regard, the human review will always be important to at least identify semantic errors like “dragState”, instead “drugState” or “cacheData”, instead “cashData” (though you can set autocorrection option…).