The Static Analyzer in Xcode 7.3 learned a few new tricks that are off by default.
I added the following to my xcconfig file:
CLANG_ANALYZER_LOCALIZABILITY_NONLOCALIZED = YES CLANG_ANALYZER_LOCALIZABILITY_EMPTY_CONTEXT = YES CLANG_ANALYZER_NONNULL = YES CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES
I thought “Missing localizability” was about missing translations, which would be super useful.
Instead, it warns when using raw, unlocalized NSStrings into UI methods. Which is cool, but less useful.
Now how does clang know which API is “UI”? Behold
It’s pretty impressive in that it can even find an
NSString that’s used to create an
NSAttributedString that’s used for a menu title. However, it also finds some false positives because it assumes that every string needs to be localized. For some that doesn’t make sense. And others, such as my alert help anchors, may not need to be based on your specific situation.
If your project deliberately uses unlocalized user-facing strings (for example, in a debugging UI that is never shown to users), you can suppress the analyzer warnings (and document your intent) with a function that just returns its input but is annotated to return a localized string.
There is currently no solid mechanism for suppressing an analyzer warning, although this is currently being investigated.
When the static analyzer is using clang to parse source files, it implicitly defines the preprocessor macro
__clang_analyzer__. One can use this macro to selectively exclude code the analyzer examines.
I’m using that because the analyzer complains about an
NULL even though the documentation says it can be.
Update (2016-05-11): Note that the analyzer warnings don’t work for Swift code.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.